Product Support

Participant Database WordPress User Profile

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.

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 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.

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.

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.

Note that when this setting is used, a logged-in user won’t see the signup form because they already have an account.

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 thatyour 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.

Placing the frontend user profile shortcode


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.

The Name Fields setting creates the username by adding the last name to the first name, removing any illegal characters, and then lowercasing it. The Email Field setting uses the email address, stripping out the “@” and the domain. The User Login Field setting uses the value in the user login field (as defined in the “User Login Field” setting above) to create the username for the new account.

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.


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.


Support Discussions for Participants Database User Profile

  • Roland I am looking to hire someone that will sync our database to a Mailchimp account. Can you suggest someone or send my email address to them?


  • Is it possible to show a thank you message on WP user creation?
    I know I can use pdb_thank template or set an action page but I want to personalize the message with field values.
    I ended up doing a trick by creating a Signup submission thanks email template that sends the email to me and the email on WP user creation is also sent correctly to the right person.

    • You can use value tags in the thanks message that is defined in the Participants Database settings or if you use a custom filter. This works whether you use a special thanks page or not.

      • I want a different thank you message depending on the context so I cannot use the global setting. It works fine with the trick. I’ll have a look later to do that properly with a custom filter but then I would have to put the html body of the email into a script which is not great either. Thanks

  • Hey there!
    My template is successfully sent on new signups and all fields get their values correctly except the user_login which is set in the setting page. Why doesn’t it get filled by the username created by WP?
    That might explain why the activation link shortcode doesn’t get resolved either.
    If I tick the option to send the normal WP email, I do receive a working link to create my password.

    • NB: The user_login field is set as hidden field and signup is ticked but it doesn’t get any value after the signup

      • Do you have the default value on the hidden field set to “current_user->user_login”?

        • Thanks! Sorry about that, I forgot to put the value back there…
          So now I do have the user_login sent to the user but the [activation_link] and [login_link] are not resolved even though I can see their values in the debug.

          To create the username, the string before the @ is taken, how can I change that to create the username like this first_name.last_name?
          Because if there is already the same username in WP users then I noticed it won’t create a WP account.
          Ex : then
 won’t have a WP account created.

        • I will need some clarification, where are you seeing the problem with the activation link? The debug should be showing you what’s going into the email, so I’m not sure how it can be right in one place and not in the other.

          You can change the way the username is constructed in the settings, but you don’t have a lot of control over it unless you set up a custom filter. However, it should generate a unique username no matter what (by adding a numeral), so I’m not sure what you’re seeing there.

        • As regard to the “bug” on WP creation it actually happens only if there is already an account with that username in WP users and not PDB.
          If the same username is already in PDB then you do create WP account appending a digit to the username

        • In the debug I can see the array of the created account by pdbwpu.
          I can see there the values for activation_link, password etc…
          Then I can see the email being sent with activation_link between brackets, so the “shortcode” is not resolved

        • OK, thank you, that makes sense. This suggests that either there is a syntax issue with the template (check it in plain text mode) or another plugin is interfering with the replacement. The body of the email is passed through the global “the_content” filter, which is used by a lot of other plugins. You can try changing the “Use WordPress Auto Formatting” setting which is in the main plugin under the advanced tab.

        • I tried the 3 formating settings you suggested with no luck.
          I also tried on another WP test site with default theme and only the 3 necessary Pdb plugins but I get the exact same result. I typed the shortcodes into the template body, no copy/paste but still no resolving for activation_link
          I guess I’ll have to modify the default WP email and not use a Pdb template.

        • Now I get what’s happening: when using the Email Expansion Kit, use the “WordPress User Profile: New WP User Created” send action for the email template.

          It looks like the login credentials are not available in the “Signup Thanks” email send action, something I apparently never tested.

        • It does work now correctly with the action WP User created! Thank you

  • Hi Roland,
    Thanks for this great addon.
    1. Is it possible to use a special submit form to add a participant in the database but not create a WP account for newsletter purpose? I’m trying to use pdb-before_submit_signup and Participants_Db::write_participant( $data, $id ) but I don’t see how to stop the rest of the execution. I also tried returning null to the hook.
    2. The last_name field only appears in the Public list column setup, it disappeared from the admin list, any idea how to get it back?

    • For your first question, you need to use the pdbwpu-new_user_on_signup filter for that. The filter gets two arguments: a bool true (the default action) and the submitted data. The filter requires a true or false return. You may need to add a field to the signup form that tells you which form was used, then return true if you want the signup to get a WP User account. The new user mode must be “on signup.”

      Check the Manage List Columns page in the admin for your list column configuration.

      • Thanks for the quick reply!
        1. I tried that at the beginning of the signup template but it doesn’t call my function :

        function inl_newsletter($bool,$post){
            write_log("log: $bool" );
            return false;

        2. Yes i’m on Manage List Columns page but that field doesn’t show up so I cannot drag and drog it to make it visible. It’s avaiblable on the public setup that’s weird. I did double check with a CTRL+F

        • Are you sure the add_filter function is running? Also check that the add new account mode is “on signup.”

          Yeah, it’s strange that doesn’t show up as available to the admin list. Try swapping some fields around in that setting to see if it resets.

        • 1. Yes On startup is on
          Am I calling the filter in a wrong way/timing because other filters like pdb-before_display_form_input do work as I get log2 to display the field object.

          function inl_newsletter($bool,$post){
              write_log("log1: $bool" );
              return false;
          function inl_test_callback( $field )
              write_log("log2:" . print_r($field,1) );
              return false;

          2. I fixed the display issue by dropping the column in mysql and recreating it

        • Depends on where the code is placed. I have it in as a plugin and it works fine, placing it in the theme functions.php file didn’t work.

        • Yes it works inside a plugin thank you!

  • Hi Roland!

    It seem that participants added via the backend “Add Participant” do not create the WP User. I’ve tried both On Signup and On Approval. I can go back an manually create the WP account from the Participants List, but that’s not the workflow we are trying to achieve.

    What we are working on is having two classes of Participants: Subscribers and Members. Subscribers should use teh standard sign-up process and immediately get WP User accounts created (as role subscriber) on sign-up. Members will be created by the club’s membership admin manually via teh Add Participants page. These should also have WP User accounts created, but this doesn’t seem to be triggering. Is there some way to trigger the account creation and approval from Add Participants form?

    I’m really liking Participants Database. Well designed and very flexible and looks to be a great solution for some of our club sites that need simple membership management. But I’m still on a pretty steep learning curve.

    • Adding a new user on the backend doesn’t automatically create a WP User for the record…since you brought it up I will consider the impact of making that possible.

      I didn’t set it up that way because the user accounts can be created in bulk on the backend, so that gives the admin the option to create the account or not for a new record…and when they create it since an email is usually triggered when a WP User account is created for someone. It seemed the more flexible option to me, but I will consider adding a preference to create a WP User account immediately when a new record is created by an admin.

  • This error notification appears in the dashboard header on the Manage Database Fields configuration page :

    httpdocs/wp-content/plugins/participants-database/classes/PDb_Settings.php on line 1182

    • I’m sorry, the message is incomplete, so I can’t say what the problem is. Can you see if there is more to the message?

      • Initially I wanted to find this problem on my other hosting so that the website was not disturbed, after I installed it on my other hosting in a different place, it turned out that the notification error did not appear, so I concluded the problem was hosting. enlightenment please what should I do

        • talk to your hosting company…without the complete error message I cannot help, I’m sorry.

        • i can just copy this only :

          arguments in /var/www/vhosts/domain-is-hiden .com/httpdocs/wp-content/plugins/participants-database/classes/PDb_Settings.php on line 1182

          That’s all I can copy, if possible, where can I send the screenshot

      • I can just copy this

        argument at /var/www/vhosts/ on line 1182

        sorry my domain name is hiden
        That’s all I can copy, if possible, where can I send the screenshot

        • Thank you, but I know what is in the code, I don’t have the error message, ask your hosting company to check the error log. Without the full text of the error message I cannot help you.

  • Here’s a new issue. I’ve looked through your documentation and see nothing related to this. I’ve installed the add-on (as detailed in my other post), and everything SEEMS to have worked correctly. The WP User Profile shows all of the fields in the Participant Database record as it should, but they are all empty. Moreover, it has reset all of the WP users in the database to the “base” custom user level AND (presumably because it doesn’t seem to be communicating) is causing all of my members to encounter a “This account has been deactivated” message upon login. The system still allows login using the proper credentials, but apparently works through a progression of failures upon subsequent attempts to log in. Ultimately the system locks them out (likely a fallback response of our security software with multiple login attempts using unrecognized credentials). I’ve tweaked every setting, made sure there is nothing recognizable that is going on with the back-end configuration. This appears purely to be a situation where the two “databases” aren’t communicating/synching with one another. Are you aware of any plugin incompatibilities, or other possible causes, that could be responsible for this? Once this hurdle is cleared it appears that this will be a very useful add-on for me.

    • It sounds like you have it set to deactivate the WP User account when the PDB record is unapproved…and then you don’t have any of your users approved. Don’t use the approval setting, I’d say, if you’ve got WP users to begin with, that’s not going to work because it’s designed for situations where you’re registering new users then approving them one by one.

      • I thought that, too, but my PDB records are (for the vast majority) approved. I’m going to go through and “unapprove”, then “reapprove” all of them. Perhaps there’s a hook in the code that is reading for the actual approval as an after-the-fact event rather than just looking for a “yes/no” answer?

        • Yes, the approval field must be configured so that the saved data correctly matches the defined options.

        • to answer your question, it just looks at the database, the action does nothing except change the value in the db.

    • You can also go through and approve all your PDB records, that should restore the WP accounts.

      • I manually “unapproved” every member, then went back and manually “approved” all the members who had previously been approved, and the fields in the WP User Record all populated with the proper information, so the approval-as-it-happens was the answer (rather than thinking, as I did, that it would recognize the previously-approved records as “approved”).

        All seems to be well now. I expect this tying of the two functions will serve our organization very well now that we’re past the configuration/setup hurdles.

        • The reason what you did fixed it was because it corrected the database entries for the approval field.

        • Sadly, this corrected only part of the problem. The WP User Profile fields are now populated, and correctly, but even though the members (who were already approved) have been re-approved, the system is still not recognizing them and still reporting their accounts as deactivated (with subsequent limited login attempts due to our security software). We even tried clearing caches, and logging in with entirely new browsers (not just browser windows), but to no avail. The system is not recognizing the login credentials as valid, even for long-standing members who had no issues in the past and who were, as described in this comment, manually unapproved/re-approved.

          I imagine I can change the approval setting on the add-on setup screen so that approval (as a WP User) is automatic, but that defeats our system (which requires manual approval of any member). Other than that, I’m out of ideas for what could be causing this login issue.

    • Hello Roland,

      I’m submitting this as a reply to the original query because it all seems to be related. I am still having trouble with logins and the “deactivated” message previously mentioned, even though I’ve unchecked the “deactivate” option in the settings.
      We were having none of these issues prior to installing the user profile add-on, and sadly, that isn’t the only issue we’re experiencing.

      Currently, our system is set up to only create a WP User account when the PDB signup form is submitted and approved manually. Via this setup, PDB fields that show on the newly-created WP User account are always blank. They will not populate unless I manually unapprove the PDB record and then approve it again, and even this only sporadically works; often, the fields remain empty despite doing this. I’ve had success by unapproving the PDB record,, then manually DELETING the associated WP User account, then manually approving the PDB record again. This creates a new WP User account which SOMETIMES populates the PDB fields in the WP User account. We have the same problem if we change the settings to create the WP User account upon signup.

      Does any of this set off any bells for you? Anything you can think of that might be causing this oddity (or the login problems we’re still having)?

      • Also, upon manual approval of a submitted PDB form, the WP User account is NOT created at all (despite the WP User Create Mode setting being selected for “On Approval”). I’m sure this is related to the other difficulties. Is there something not communicating, or being “blocked” somehow?

        • This should say “SOMETIMES not approved at all”; sometimes it is. There seems to be no pattern to when it shows and when it doesn’t, or when it’s right and when it’s not.

      • This kind of intermittent issue can be caused by page caching. Don’t use page caching on any pages with a Participants Database shortcode. It’s a good idea to turn caching off altoogether when configuring or debugging because it can cause problems.

        I’m not clear about what you’re seeing, so it’s hard to interpret the results. However, I’ve not seen problems like this in my tests, I’m attempting to duplicate your setup, but not seeing problems like you describe.

        The issue you’re having with the deactivated message is still vague to me…I would suggest you go through your users looking for users that don’t have a role designated, make sure they all have a role (unless they are supposed to be deactivated).

        Where are you looking at the user profile and seeing blanks where values should be?

        • The blank (unpopulated) fields show up on the WP User profile itself (which I view strictly from the back end). The fields are properly populated in the PDB Member Record. I’ve been successful at “forcing” the fields to populate in the WP User Record, but sporadically; sometimes a specific set of steps will work, and other times it won’t; or a different set of steps will work on occasion, but it won’t the next time (though I think it’s still the same steps, with extras in between).

          Regarding page caching, I don’t (knowingly) have caching set up via any plugins, though it’s possible something administrative from the host could be installed and running. I do, however, have my pages served through Cloudflare, which I believe is fundamentally a caching operation. It seems odd that I’d see cached pages as an administrator–or at least I always see the proper changes when I update a page so I assume I’m being shown a “fresh” page.

          The “deactivated” message has been a complete conundrum. The problem started with the installation of the PDB User Profile add-on, but honestly almost seems otherwise unrelated. I thought about the user role designation too, so I went through and manually checked every one. It isn’t that. I wonder if it’s the security software not playing nice with the User database when “filtered” through PDB User Profile? The “you have XX number of login attempts remaining” message makes me think it might be security related…?

  • Hello Roland,

    My apologies; I seem to be becoming a bit of a pain.

    I purchased this plugin, together with two others. Following your installation instructions, I attempted to install this one first, and get this error message:

    The uploaded file could not be moved to wp-content/uploads/2021/02

    The other two installed and activated just fine. Thinking it may have been a corrupt download, I downloaded again, but still get the same error upon attempted installation. Sadly, this one of the three is the most important to me, by far.

    Is there anything you can think of that would account for this difficulty?

    • My guess is that there is a file with the same name in the uploads directory, but I can’t be sure, the error doesn’t say anything about why it’s failing. Try checking on that directory and make sure the plugin file is not in there, then attempt to download and install again.

      • It wouldn’t be the filename; the second download appended (1) to the filename, and that’s the one I tried to upload and install the second time, so that kinda negates the filename issue (I think). Could it be a filename conflict within the unpacked archive? I’m not sure how the zip file unpacks and installs.
        I may try to manually unpack the zip, re-archive with a .zip extension but using 7-Zip or something, and then try to upload and install that way (unless you think that unwise or pointless). Is it possible to install the archive contents in a form other than the zip file? Perhaps I can manually work around whatever is causing the conflict…

        • I suspect it’s some kind of issue at the server level, so looking at your server error logs might help, but unless you’re pretty comfortable looking though such logs, it will be easier if you can circumvent the issue. You can try using FTP to upload the unzipped files to the plugins folder.

        • To solve this problem I effectively used Roland’s FTP advice (though I simply worked through my cpanel file manager rather than FTP); I simply unzipped the plugin folder, extracted down to the “root” installation folder, uploaded that to the proper plugins folder, and then went to the “plugins” section of the WP backend and activated.

          Thus far everything appears normal. I’m still unclear why it wouldn’t upload and install in the traditional way, but this might help anyone else who runs into this problem.

      • This turns out to have been essentially correct, though it was within the download itself rather than on the server. It turns out that your add-on ZIP file contains two folders named “pdb-wp-users”; one is a version that contains a language folder (presumably a translation of some sort) and the other is likely the folder that this newer one deprecated. I deactivated and deleted the add-on completely (which caused our registration problem to cease, so it definitely is related to the add-on). Next, I manually opened the ZIP file and deleted the older of the two “pdb-wp-users” folder. Then I followed the rest of your installation instructions, and this time it installed on it’s own with no issues.

        I’m still testing the re-installed add-on to see if the registration issues persist.

  • Hi Roland, I need to change the name of the fields “Search”, ¿maybe can you give me a hand? Amazing job

  • Hi, I need to edit this codes:

    First Name

    Last Name


    Private ID

    Date Recorded

    I need to see not email label unless others (sorry my english) maybe that can configure manual?

    I want something like this:


    Thanks for your help, and sorry for the second message, I want to explained much better

Got a Support Question?

Your email address will not be published. Required fields are marked *