Expand the WordPress user profile with unlimited Participants Database fields. Automatically create a WP user account with a Participants Database signup form. Provide a frontend profile page for your WordPress users.
Product Setup
This plugin is primarily for the purpose of expanding the WordPress user account to include additional information which the user (or administrator) can edit on their profile page. It provides several ways to connect a Participants Database record to a WordPress user. This works whether you already have WordPress users, or you have Participants Database records, or even if you have nothing to start with.
Start by Defining Your Data Fields
Unless you already have your Participants Database fields defined, you need to first set up the fields of data that will be stored with the user’s profile.
To do that, go to the Manage Database Fields page in Participants Database and define the fields you want for your users. Using field groups, you can define fields that are public, private (for the user only) or admin (only site admins will be able to see these). Once the fields have been defined, you can configure how it interacts with WordPress users and user registration.
You can define as many or as few extra fields as you want. Participants Database comes with a set of predefined fields, these can all be deleted if you don’t need them.
Link Key Participants Database Fields to WordPress Account Fields
There are a few key fields in the WordPress user account that are usually linked to fields in the Participants Database record. This establishes synchronization between the two on these fields: First Name, Last Name, Email, User Login, and User Avatar (also known as the Profile Picture). It is not absolutely necessary to set up these fields, but it can be helpful to be able to see the user’s name, etc. in the Participants Database record.
To set this up, go to this plugin’s settings under the “WordPress User Profile/Participants Database Record Settings” heading. This is where you can determine which Participants Database fields relate to the core fields of the WordPress profile. In most cases, the defaults will be OK.
When a new WP user account is created from a Participants Database record (either an existing record or a new signup), the information in these fields will be used. The User Login field can be used as a way to let user determine their own user login name (this works for new signups only). In most cases, if this field is configured, it is for the purpose of showing the username in the PDB record.
Creating WordPress User Accounts
If you want new WP user accounts to be created automatically (there are several ways this can happen), check the “Create New WordPress User Settings.” If you want the new users to get a welcome email, make sure “Send the WordPress New User Email” is checked. If you’ve got the Email Expansion Kit installed, you can also define your own welcome email. If you’re doing that, you can uncheck the setting so only the custom email gets sent.
Creating WP User Accounts with a Signup Form
If you’re starting from nothing with your membership, or you want to let new members register, you can use the Participants Database signup form to provide a way for your new members to sign up. This is enabled using the “Create New WP User Mode” setting in the PDb User Profile plugin settings.
When a Participants Database signup form is submitted, you can set it up so that the person registering will be given a WP account. You can also set it up so that when they register, it stores their info but does not set up the WP account until the registration is approved by an administrator.
When the registration is approved, the info from the signup is used to create the new account. The Participants Database record is now associated with the new WP account.
The signup form can have as many fields as you like, so your new accounts can be established with a full set of information. The one exception is you cannot use the PDb signup to establish the password as explained below.
Note that when this setting is used, a logged-in user won’t see the signup form because they already have an account.
User Account Passwords
When using a Participants Database signup form to create new WP accounts, you cannot use a PDB password field to set the password on the new account. This is because WordPress requires that new accounts be verified via email with a link that forces them to create a password. User account passwords are handled by WordPress, not Participants Database.
Creating WordPress User Accounts on Approval
If you want to be able to approve the new user before granting them an account, you can use the approving records mechanism to create the user account. When a record is approved, a new WP user account will be created using the info in the signup submission. This can also be used to turn the user’s account access on and off. If a record id unapproved, the user won’t be able to log in. If the record is approved again, they will regain access.
If you have WP User accounts already, if you use this feature, be sure to set the approval field to default to “approved” so that your existing users won’t get deactivated.
Creating WordPress User Accounts Manually
If you’ve got people in Participants Database and you want to establish WordPress user accounts for them, you can easily do that on the admin List Participants page. Select the records you want to establish WP user accounts for, then select “create WordPress user account for record” then confirm the operation by clicking “apply.”
Select the users you want to establish accounts for, then use the “with selected” dropdown to select “Create WordPress user account for record” and click “apply.” Each of the people who got new user accounts will be sent the welcome email (with the login link) if you have that configured. It is probably a good idea to test this on a single user before doing it for a lot of them.
Starting with Existing WordPress Users
If you have WordPress users already registered and you want to give them expanded information storage in their account profile, it’s very easy. When the user visits their profile page, a new Participants Database record is created for them if it did not exist before. All the extra information that they enter on the profile page will be added to that record, which is now fully connected to the WP user.
The Profile Page
WordPress has a built-in profile page on the backend that is accessible to users where they can edit their profile info. This plugin can add Participants Database fields to that profile page. This is configured in the plugin settings under the “User Profile Settings” heading. There is a checkbox that enables this functionality.
You can also control which groups of Participants Database fields are shown in the profile. There is another setting where specific fields can be excluded.
When a logged-in WP user visits their profile page, the matching Participants Database record is used to add the extra fields. If there is no record for the user the “Create PDb Record for WP User” option creates a new record for them. That record is now attached to the WP user, and will be used to store their information.
Frontend Profile Page
If you want your users to be able to access their profile on a regular website page (instead of an admin page), you can do that using the [pdb_user_profile] shortcode. Just select or create a page for your profile and put the shortcode on that page. This is perfect if you don’t want your users going to the backend to edit their profile.
When the frontend profile page is set up, the plugin automatically changes the user’s profile link to point to this page instead of the default profile page in the backend.
There are two built-in templates for the frontend user profile page. The default template is a responsive layout based on the Bootstrap framework. There is also a flexbox-based layout that can place the fields in columns and will generally be more compact. You can use the flexbox template by adding the name of the template to the user profile shortcode like this:
[pdb_user_profile template=frontend-profile-flexbox]
The frontend profile uses the same configuration settings as the backend profile page. The layout and appearance of the profile page is under the control of your WP theme. If you need to make changes to its appearance, you will need to use your own CSS rules to make the desired changes. The main Participants Database plugin has a place for your custom CSS rules in the settings.
It is also possible to create a custom template for the frontend user profile. The name of the template file must begin with “pdb-record-frontend-profile” and must be based on one of the two frontend profile template included in the plugin.
Using a Custom “Welcome” Email
If you have the Email Expansion Kit installed, you can easily create a custom email that goes out to the user when a new account is set up for them. If you are notifying your users this way, you should uncheck the “Send the WordPress New User Email” setting to avoid sending two emails.
When creating the email template, use the “WordPress User Profile:: New WP User Created” action to send a notification to the new user that they have a WP User account and need to activate it using the activation link.
This email must contain the “activation link” so that the user can activate their new account. This is a security feature that allows you to avoid putting a plaintext password in the email.
The user must visit the site using the activation link, where they will need to create a new password for themselves.
Here is an example content for your welcome email template:
If you do want to send them the plaintext password, you can use the tag [user_pass]. They will be able to use that with their user login to log into the account immediately without changing their password.
Showing a List of Users
You can use the Participants Database list shortcode to show a list of your users, showing only users with a specific role. For example, to list all the subscribers, use
[pdb_list role="subscriber"]
You can also name more than one role there, for example:
[pdb_list role="subscriber,member"]
This will work to show both subscribers and members if you have a custom role named “member.”
Showing the Current User’s Record
It is possible to show the current user’s record in a non-editable form by using the Participants Database single record shortcode. This is done by using the “current_user” key for the record_id shortcode attribute, like this:
[pdb_single record_id=current_user]
Of course, you can use the other available shortcode attributes to configure the display, including using a custom template.
Product Settings
User Profile Settings
Show PDb Fields in WP Profile
This is the overall enable switch for including the extra fields defined in Participants Database in the WordPress user’s profile page.
Profile Groups
Select which Participants Database field groups to include in the profile page. Only public and private groups will be available here.
Profile Excluded Fields
If there are specific fields within the selected field group that you wish to exclude, list them here. It should be a comma-separated list of Participants Database field names.
PDb Profile Title
This title is printed above the extra fields that Participants Database adds. Blank it out to show no title.
Create PDb Record for WP User
This determines whether a participants Database record should be assigned to the WP user if they visit their profile page and there is no PDB record associated with their account. In most cases, you will want this checked.
WordPress User/Participants Database Record Settings
These settings set up a correspondence between the key fields of the WordPress profile and the Participants Database record. These settings are optional, the plugin does not use these fields to determine which record belongs to the user. They are helpful, however, because it provides a readable way to know which WP user the PDB record belongs to.
These are configured by default to connect to the default fields in Participants Database if they exist.
First Name Field, Last Name Field, Email Field
These setting tell the plugin which PDB fields are connected to the WP user profile fields. In most cases, you won’t need to change these, they will be set up by default.
User Login Field
This setting provides a way to store the user login name in the PDB record. If the site was previously configured to use the user login as a way to identify which user the record belonged to, this setting should set that up automatically. This works by looking for a hidden field in the PDB field definitions that is set up to record the user’s user login name in a signup form.
User Avatar Field
This provides a way for the user to use a “local” avatar for their profile. Normally, WordPress would attempt to get the user’s avatar from Gravatar, but with this feature, the user can upload an image to use instead or if they don’t have a Gravatar image configured. This image will be used to identify the user anywhere on the site that the avatar is displayed.
This selection must be an “Image Upload” type field.
Create New WordPress User Settings
It is possible to use this plugin as a way to set up a WP user account for someone who is in a Participants Database record. This can happen in several ways, and these setting determine how that will work.
When a new WP user account is created, an email is sent to the person informing them of their new account, along with information to go to the site and set up their password. They will not be able to log in until they do this. This is standard WordPress functionality, but it can be overridden when using the Email Expansion Kit.
Create New WP User Mode
There are 3 ways a new WP user account is created in this plugin. This setting determines which one you want to use. If you don’t want WP user accounts to be created at all, use the “Manual” setting (which is the default).
When a new WP account is established by any method, an email is sent to the new account holder with their login instructions.
With the Manually setting, new WP user accounts can be created for people in Participants Database by using the “With Selected” function on the admin List Participants page. Note that you can always use the “With Selected” action, no matter what setting you have here.
The On Signup setting means that the WP user account is established immediately when the signup form is submitted.
The On Approval setting also works with the signup form, but instead of establishing the WP account immediately, it only does so when the record is approved. (See Approving Records for how this is configured in Participants Database). This setting also means that if you approve an unapproved record that was already in the database that does not have a WP account assigned to it, a new WP account will be created.
New WP User Role
This determines the role given to new WP users that are created by this plugin. If you have custom roles defined, you will be able to assign new users to a custom role.
New User Login Name Source
When a new WP user is created, the account is given a username. This setting determines what information will be used to set up the account user name.
If you have a user login field defined, it is possible to let the person signing up determine their own username. The plugin will make sure it is unique.
Usernames cannot be changed once established.
There are 4 options for how the username is constructed:
- First or Last Name – this will use the first name if possible, then the last name if the first name isn’t available as a username.
- First and Last Name – the first and last name will be combined to create the username.
- Email Field – the user’s email address is used to create the username: the “@domain” part is removed and what is left is the username.
- User Login Field – this makes it possible for the user to set their own username, this is only possible in the signup form.
If the selected method creates a username that is alredy set for another user, a numeral is added to the username to make it unique.
Joining Character
When building the username, this setting sets the character that is used to join the parts together. This character is also used if a numeral is added to the username. “No Character” means the parts are joined together with nothing in between. The setting is limited to characters that are allowed in a username.
Send the WordPress New User Email
This preference determines whether the WordPress standard “welcome” email is sent to the new user when the account is established. If you are using the Email Expansion Kit to define a custom email for this purpose, you can uncheck this to prevent the built-in WordPress email from getting sent.
If you just don’t want that email going out at all or at a later time, you can uncheck this.
It’s always possible to resend the “welcome” email using the “With Selected” function on the admin List Participants page.
Deactivate WP User when Unapproved
When a record is unapproved (if it was approved before it was unapproved) the WP user account can be deactivated at the same time. The account is not deleted, it just becomes inactive and the person won’t be able to log in. This is done by setting the deactivated user’s role to “None.” If the record is approved again, the account will be reactivated, using the New WP User Role setting above to restore the user’s role.
Handle WP User Account on PDB Record Delete
When a Participants Database record is deleted, this setting determines what happens to the associated WP user account.
Deactivate means the account still exists, but the user will be unable to log in. Choose this if you think you may want to give the user access again in the future.
Do Nothing means they can still log in, but note that when they visit their profile page, a new Participants Database record will be created for them. The plugin doesn’t try to prevent that.
If you set it to Delete, the associated WP account will be deleted along with the PDB record. Admin accounts and accounts that have authored posts will not be automatically deleted.
Deactivated Account Message
This lets you define the error message that is shown to the user when they try to log in while their account is deactivated. You can include some simple HTML here.
F.A.Q.
Is it possible to use this add-on with Field Group Tabs to provide a tabbed interface for the frontend profile?
Yes, it requires the use of a special custom template. I’ve created an example of how this can be done, the template is available below.
Please read Using Participants Database Custom Templates so you understand how to install and use this custom template.
To use the template, set up your shortcode like this:
[pdb_user_profile template=frontend-profile-tabs tabs=true ]
You must (of course) have the Field Group Tabs add-on installed for this to work.
https://gist.github.com/xnau/e4480bb20d7d58d65dbb37535f5ea970
I notice on the https://xnau.com/product/participants-database-user-profile/ page it says the latest version is 1.4.6, but I still have 1.1 on my website. Does this add-on auto update? I’m suspecting the old version of the add-on and the updated 5.8 WordPress is causing the below problem. When clicking the update button on the [pdb_user_profile] section, even without any edits, I get: Fatal error: Cannot redeclare add_user() (previously declared in xx/wp-admin/includes/user.php:17) in xx/wp-admin/includes/user.php on line 17.
Updates will be available on your admin Plugins page. You can initiate the update there.
The WP backend Plugins page lists this as Auto-Update and when I click the “Check for Updates” link I get “The Participants Database WordPress User Profile plugin is up to date.” The info on the plugin says “Expands a WordPress User Profile with Participants Database fields.
Version 1.1 | By xn*au webdesign | View details | Support | Check for updates | Updated: 2020-09-21 | Requires at least: v5.1 | Tested upto: v5.5.999”
Is this a different plugin, with or without WordPress in the title?
OK, what I suggest you do is log in to your account at xnau.com and download the plugin again (I just updated your access). Before you install the new one, deactivate the one you have currently installed. Then upload, install, and activate the new one.
Thanks for that update, I got it installed. The original post error regarding add_user() persisted. It turns out it was a conflict with the “WP File Manager Version 7.1.2” plugin. I can easily remove that latter plugin.
glad you got the plugin working, thanks for letting me know what the problem was.
I need to show a logged in user their record without giving them the ability to edit it (or at least most of it). The [pdb_user_profile] allows all fields to be edited, is there any way I can prevent editing?
Or, can I use [pdb_single] for a logged in user? Does the user profile have the record id anywhere, that I could use in a link?
Thanks
Thanks for your question, I hadn’t considered this possibility.
The plugin isn’t set up to present the user’s data in a form that can’t be edited, so the options for doing so are limited.
You can set individual fields to “read only” which will prevent the user from editing them in the profile display. I don’t know if that is what you want because it means the user will never be able to edit those fields. If the field data you don’t want edited is only set by an administrator or an import, then this approach could work.
The [pdb_single] shortcode can be used to display the user’s data in a read-only form, but it is not set up to use the current user’s ID to select the record to show. You can do this with a bit of php code in various ways. For example, if you can place a php snippet on the page, you can do that with a bit of code like this:
<?php$record = new \pdbwpu\users_record();
echo do_shortcode( '[pdb_single record_id=' . $record->record_id() . ' ]' );
?>
If I set the fields to read only, I’m guessing they would only be editable by an admin on the back end not the front end too (ie in pdb_record and pdb_signup)?
Yes, correct, admins cannot edit read-only field on the frontend, however read-only fields in signup forms are editable. This is because there is no value to protect.
Ok, thanks. I’ll try the php method.
Hi there,
i wanted to use “Name Fields” for “User Login Name Source” so i chose “Name Fields”.
The docs say “The Name Fields setting creates the username by adding the last name to the first name, removing any illegal characters, and then lowercasing it.”
I testes this with a Testuser named: “John Doe”
So i expected the username to be: “johndoe” – but it is only “john”.
Any ideas whats wrong ?
bonus question:
Is it possible to get my own default login value by referencing other PDB Fields in the wordpress user login field as default value and if so how ?
Easiest way to customize this is to use the “user login” field for your username source. You can designate any field for that purpose, and the plugin will use the value in that field to create the username. If you use a “string combine” field for the “user” login” field, you can arbitrarily construct the username from record values.
That is the expected behavior, it will use the first name only if it is available. It tries to provide the simplest username possible.
Hello – I’m using this add-on and we also have Paid Memberships Pro installed. When we update a profile on the admin side with this add-on plugin installed, the Paid Membership Pro level is cleared out and set to no membership. Is there anything in the plugin settings we can change to prevent this from happening? Thank you.
My guess is you have a field defined in Participants Database that has the same name as the “level” field used by your paid memberships plugin. Our plugin is designed to play nice with other plugins that might be managing profile fields, but it can’t anticipate a field name conflict.
That was it! Thanks so much for the tip.
Thanks for the quick answers to my other questions. Here is another one. I noticed when using the radio buttons with multiple choices, only two would show when looking at the responsive view for mobile. It’s as if the small screen size would not do multiple wraps for each choice to show.
I solved the problem by replacing the radio with a series of check boxes, but wanted you to know about this if it is a bug and not something I am doing.
Display issues such as you describe are due to the specific way your theme is displaying the radio buttons. I just checked this to make sure we weren’t doing something wrong there. The plugin can only provide a responsive HTML structure, but then it is up to the theme to display it properly. You can undoubtedly fix this with some additional CSS if you want to return to using the radio buttons.
thanks for the reply. Just to complete the thought as you look around. I am using the very popular Astra theme – always the current version – with Elementor Pro to do the editing.
Before I abandoned Drupal for WordPress, I learned to stay away from making any modifications to the theme – even with a child theme as an alternative. Just not worth the maintenance hassle.
Please keep up the good work.
Odd behavior … I do not know if this is an user issue or a utility issue. On a few of my records, there is gibberish (“DsvCbWepAKNVYIzo” – different random letters) in Text Line fields. Since the user provided a valid email address, I do not think this was a user entry.
I updated the field description to include a default value of “First Name…” etc.
Will that solve the issue? Thanks
This is likely an example of human-generated spam, which is very difficult to block automatically. Often, such spam submissions will include a piece of data that can be used to identify the submission externally. This tells the spammer that they can make submissions to your form that will be automatically published on your site, which can be used to publish backlinks. If this is not the case, such submissions can be ignored.
If you really need to block them automatically, it can be very difficult because you will need to discover a pattern your can use to detect the spam. This can be complex and time-consuming to implement if you want to avoid false positives.
The best approach is usually to require that submissions be approved before they are included in public-facing content.
Is there a limit to the number of database records?
If there is a limit, it will be imposed by your server. The plugin does not limit the number of entries.
thank you for the quick response. I anticipate getting several thousand people to sign up for a petition through your utility. If you ever make a pro version, I recommend giving the website the ability to have people sign up on different databases for different petitions/initiatives.
You probably don’t need separate databases for that…take a look at this article with some ideas on how to set that up:
“Multiple Databases” with Participants Database
I have a number of wordpress subscriber accounts and we are not allowing self management of their profile data at this time. We get a file of updated subscribers info and would like to use that file to create pdb records and insert/update/delete pdb records as needed.
Can you share an example of the use of the API write_participant? We will need to remove some pdb records as well from processing this file. Is there an API for delete_participant? Otherwise, how would we do this?
Thank you!
Jim
The retired members are only subscribers in the wordpress role definition.
There is no api call to delete a record, you can use a query like this:
$wpdb->delete( Participants_Db::participants_table(), array( 'id' => 1 ) );There is an example of the use of the write_participant method here:
Participants_Db::write_participant
I am no longer seeing the roles setting drop down in the user edit profile page. The roles setting drop down is added by the plugin user_role_editor and we need use as we assign multiple roles to our members.
Can you be specific about what page you’re looking at?
The user role dropdown is not shown on the frontend as this is an administrative field, you should see it in the admin user edit page that is accessed under the “Users” menu item.
We are not seeing any role setting options now under the admin user edit page accessed under the Users menu item.
Changes I made to the code would not have affected this, so I’m not sure I can explain what you’re seeing there. Is this option missing when someone with an administrator role accesses the page? That option has access restrictions normally.
Neither I who has administrator role nor a test user trying to do Edit Profile are seeing the role settings.
We are now seeing the roles in the user edit profile page for non administrator roles.
Sorry
We have another issue where the participants list returned by a $pdbEMAILs = Participants_Db::get_participant_list( array( ‘filter’ => $pdbfilter ) ); call does NOT seem to be the same as the WordPress PDB List Participants panel with what should be the same filter.
The call returns 12 Objects and the List Participants panel shows 14 with the same filter (I think).
Hi James,
So, just so I know we’re talking about the same thing, the method to use to get a list of records is
PDb_List::get_list( $shortcode_atts ).If you can supply the exact filter you are using I can take a look at this.
Not sure why get_participant_list is an incorrect function, however if use $pdbEMAILs = PDb_List::get_list( array( ‘filter’ => $pdbfilter ) ); then I should get the same 14 as List Participants shows?
What is returned exactly?
OK, I’m sorry, I forgot about that function…it works pretty much the same way. And yes, it should be the same list of records as the shortcode would generate, they both use the exact same code to generate the list. I guess the first step would be to mkae sure the “filter” value you are providing is correct.
SO, when using the
Participants_Db::get_participant_list( $shortcode_atts )method, what it the exact filter you are using?OK – in this case I am NOT using the template for sending an email. I am just attempting to send a plain non fancy text email using: PDb_Template_Email::send($config, $data);
OK, that’s fine you can do it that way, I thought you were using a defined template is all.
Now I really confused I thought the Template version was: \cpt_email_templates\sender::send( $template_id, $pdbEMAIL, $context = ” );
?
So, the way you use the
cpt_email_templates\sender::sendmethod is to place all the data you need to include in the template in the second argument. Then, the first argument is the template ID from the defined email templates. The third argument is optional, it’s there so you can label the send, but it’s not needed.If you’re using P
Db_Template_Email::send($config, $data)then your template must be in the $config array as the “template” element of that array. The template in that case must be the literal text of the template.The $data argument must be an associative array of all the data you want to include in the template. If the template has a tag like [full_name], then the $data array must have a “full_name” element with its value as the content to be substituted for the tag in the template.
I’ve tried:
$pdbEMAILs = PDb_List::get_list( array( ‘filter’ => $pdbfilter ) );
$pdbEMAILs = Participants_Db::get_participant_list( array( ‘filter’ => $pdbfilter ) );
$pdbEMAILs = PDb_List::get_list( array( ‘filter’ => $pdbfilter ) );
The one last seems to crash the script and the log file stops.
Where $pdbfilter is: hiking=Yes
hiking is a pdb field of radio button type : Yes or No
Have you determined what the correct number of records is? Which is correct, the shortcode or the function? Have you looked at the log to see how the database queries differ? That’s probably a good place to see what’s going on.
Third one that crashes looks identical to the first, so not sure what happened. The error log is a good place to start with that kind of thing.
The correct number of records is 14. The debugging log creates an SQL query that when entered into my SQLyog database editor returns 14 rows. However, when I run the get_participant_list with what should be the same filter, I get 12 Std Objects, which I convert to 12 arrays.
Appears to be dumping two results from the SQL Query.
Ok – I’m seeing something. The list of stdClass Objects returned by Participants_Db::get_participant_list( array( ‘filter’ => $pdbfilter ) ); appears in our as follows:
Activity name: bocce
Filter: bocce=Yes
Array
(
[Robert] => stdClass Object
(
[first_name] => Robert
[last_name] => REMOVED LAST NAME
REMOVE FIELDS
[email] => REMOVED EMAIL ADDRESS
REMOVE FIELDS
[bocce] => Yes
[bridge] => No
I removed the last name and email address here and copied only up the bocce setting.
The line: [Robert] => stdClass Object seems to be using the first_name as a key. In our list of participants first_name is not unique. We have in this list – three James and three Robert. One James and one Robert have bocce set to No. The missing rows are a second Robert with bocce set to Yes and a second James with bocce set to Yes.
What is: [Robert] => stdClass Object and why isn’t [Robert] something unique to the pdb record?
While these are interesting questions, however instead of analyzing the code, I think it will be easier if we focus on what it is you are trying to accomplish and the problem you having in doing that. I’m having a very difficult time understand your question, so I suggest we go back to basics and tell me what you need to do.
Remember that custom code is your responsibility, I can offer help, but at the end of the day, it is your knowledge and skill that will get the job done.
I need to know why the object in my log file is showing as follows:
Array
(
[Robert] => stdClass Object
(
[first_name] => Robert
[last_name] => REMOVED LAST NAME
REMOVED FIELDS
[email] => REMOVED EMAIL ADDRESS
REMOVED FIELDS
[bocce] => Yes
[bridge] => No
….
What is the [Robert] in the line [Robert] => stdCLass Object?
All of the 12 Objects have the first_name in that key. Since there are two of [Robert] and two of [James], it seems to me the second one of [Robert] is overwriting the first instance of [Robert]. And the second one of [James] is overwriting the first instance of [James].
The above text is written in the log file directly from the return of Participants_Db::get_participant_list( array( ‘filter’ => $pdbfilter ) with a print_r.
The get_participant_list function call, internally, seems to be overwriting two of the participants and thereby throwing them away in the returned array.
Custom code is my responsibility, but I need to know why the function call to get_participant_list is not returning 14 Objects as it should.
If the SQL returns 14 rows why isn’t get_participant_list?
“If the SQL returns 14 rows why isn’t get_participant_list?” what we need to look at is the database query that is used in both cases so we can compare them. When you use the get_participant_list function the query will be logged, so you can see what it did to get the result.
On your first question, I don’t know how you’re getting that result, so I can’t comment on why. Tell me what you’re doing to get that result, and I’ll check it out. Normally, it uses the record id as the key.
$pdbfilter has the text: bocce=Yes
*******************************
echo “Filter: ” . $pdbfilter . “”;
fwrite($logHandle, “Filter: ” . $pdbfilter . PHP_EOL);
fflush($logHandle);
$pdbEMAILs = Participants_Db::get_participant_list( array( ‘filter’ => $pdbfilter ) );
fwrite($logHandle, print_r($pdbEMAILs, true) . PHP_EOL);
fflush($logHandle);
****************************
The following is recorded SQL in the Debugging log for the get_participant_list function call.
***************************
SELECT p.first_name, p.last_name, p.address, p.city, p.state, p.country,
p.zip, p.phone, p.email, p.mailing_list, p.edit_link, p.photo, p.website,
p.interests, p.approved, p.id, p.private_id, p.date_recorded, p.date_updated,
p.last_accessed, p.pdbwpu_user_id, p.biking, p.birding, p.bocce, p.bridge,
p.craftsmens_list, p.eds_boch_room_boys, p.fellowship, p.golf, p.gourmet,
p.hiking, p.kayaking, p.ladies_luncheon, p.memorial_day_parade,
p.men_can_cook, p.mutual_aid, p.spring_picnic, p.octoberfest, p.pinochle,
p.poker, p.speakers_program, p.trap_shooting, p.wine_wizards, p.zoom
FROM wp_participants_database p WHERE p.bocce = “Yes”
ORDER BY p.date_updated DESC
**********************
The second fwrite is to my log where the 12 stdClass Objects that were returned are recorded – incorrectly.
**********************
The above SQL run in my MySQL database editor produces 14 rows – correctly.
***********************
The id field needs to be the first one in the query, so that it will be used as the index. When you provide the list of fields to the function, make sure the id field is first in the list.
I think there is something wrong with get_participant_list.
However, I’ve gone back and tried using get_record_id_by_term and get_participant which seem to work for this purpose.
TY
I have added a new group and a bunch of fields as checkboxes. In both the List Participants edit and the User Profile the checkboxes show, but show the following text in a red bordered area.
The xxxxxx field is required.
The xxxxxxx field is required.
The xxxxx field is required.
The xxxxxx field is required.
The xxxxxxxxx xxxx field is required.
The xxxx xxxx xxxx xxxx field is required.
etc.
Both block the update after clicking Submit, on the re-display of the List Participants page, it shows the settings retained. If I go back to the List Participants and try to edit the same user, we see the settings did not get retained.
I get the same behavior if I try to edit a wordpress user from the wordpress Users admin page.
A couple of times, I’ve seen all these checkboxes as checked when I had explicitly unchecked most of them on a previous update. Currently these checkbox fields have no default set.
Make sure you have your checkboxes defined with at least one option.
I’ve changed them to radio fields with a Yes and a No option and Required validation, no default.
If I set the Default value to No, can I count on the radio fields set like this to have No and show No in the PDB edit and WP Profile edit?
TY!
Yes, the value will be saved as “no” when the record is updated. No need to have the validation on, if you set a default value it will always validate.