Product Support

Participant Login

Provides username/password access to edit a Participants Database record.

Product Setup

To configure the plugin for use, start by making sure your “Participant Record Page” is correctly configured by visiting the “Record Form” tab in the main Participants Database settings. This tells the login form which page to go to when the login is accepted.

Setting up the Participant Record Page

Configure the Login Form

On the Participant Login settings page, you can configure the form to show one or two fields that the user will need to fill in to access their editable record. The first field is called the “Username” field, and it is used as the primary identifier. This can be an email address, an ID number of some kind, or really anything that can be used to uniquely identify the user.

The second field is called the “Password” field, but it can also be anything you want. It is usually used to verify the user, especially if the Username field is something that would be generally known, such as an email address. It is also possible to set up the form to use only a single input field by unchecking the “Require Password” checkbox. When this is unchecked, only the Username field will be shown in the form. You might do this if your username field was something only the user would know, such as an ID number.

When selecting the field to use for the password field, it is important understand that “password” type fields store the password in encrypted form, which means an administrator cannot know what the password is. If you need to be able to tell people what their password is, use a text-line field for your password field, then you will be able to look up their password because it will be stored in plaintext.

Create Your Login Page

Once you have configured the login form, you should create a page that will be the login page. On that page, place the [pdb_login] shortcode to show the login form. It is possible to use a custom template for the login form if you need.

This shortcode will accept the following attributes to configure how it looks and works:

  • template for using a custom template
  • record_page to set the page (use the page name or ID) that the user goes to after successfully logging in; that page must have the [pdb_record] shortcode.
  • login_button_text to set the text on the submit button for the login form

Persistent Login

When using the “Extended Access” preference, the user is automatically forwarded to the record edit page from the login page for 24 hours after successfully logging in. This period can be changed using a code filter.

Logout

To end the persistent login before it expires, you can use a logout link. You may need to use this if you have users that must have access to more than one record. The logout URL is simply the login URL with “?pdb-logout” appended to it. For example, if your Participants Database login page is at /pdb-login, your logout link would look like this:

/pdb-login?pdb-logout

If you are not using pretty permalinks, you need to do it slightly differently. For example, if your login page is on a page with an ID of 2034, your logout link would look like this:

/?p=2034&pdb-logout

It’s a good idea to put the logout link in a menu somewhere where the user can find it.

Product Settings

Login Form Settings

Username Field

Selects the field that holds the username. This could be an email address, a made-up username, or even a member ID number. If the password is not required, this will be the only field shown. This field should hold a value that uniquely identifies the record. If more than one record matches the value, the first record found will be used.

Username Not Found Feedback Message

Message to show if the username does not match any record.

Username Field Extra Attributes

This setting provides a way to add attributes to the username input element. This can be used to add client-side validation to the input, which can be helpful to users typing in the correct thing for the input. It can also be used to add simple javascript interactivity to the input.

This setting uses the same format as the “attributes” setting in the field definition: name::value,name::value etc. Because the comma is used to separate attributes, you must use the HTML entity , to represent the comma if it is in the value.

To set up a client-side validation, use the required and pattern attributes. The link provides the details on using the pattern attribute. Here is a simple example setting:

pattern::[a-z]{3,20},required,title::username must be all lowercase letters between 3 and 20 characters

That pattern will only accept lowercase letters and the length of the input must be at least 3 characters and no more than 20. You can use the “title” attribute to add a message to the pop-up that is seen when the validation fails.

Require Password

If this is checked, both the username and the password must match an existing record for the login to be accepted. If unchecked, no password will be required, and a correct entry into the username field will take the user to the record edit screen. Be careful with this, it could allow data to be changed by unauthorized persons.

Password Field

This is where you set the field that is used for your”password.” This field can be a “Text Line” type or a “Password” type field. If the field you want to use does not appear in the selector, you should either create it if it doesn’t exist or change its form element type to one that is valid for this setting.

If you select a text-line field for this, it will be stored in the database as plaintext. This will often be the case if you are using something like a customer ID for this field. If you use a “password” type field, the password will be encrypted in the database when the user saves their password.

It is important to understand that you cannot switch from or to a password field after the record data has been entered. Changing the field type cannot encrypt or decrypt passwords, so if there is data in this field, it will become incompatible with the field type. If the password field is empty, that is OK, the password will be saved in the correct format when the user enters it.

Login Button Text

This is where you can set the text that is shown on the login form submit button.

Bad Password Feedback Message

Message shown if the password doesn’t match the value in the database.

If checked, a cookie is stored on the user’s browser when they successfully log in, so tha when they are directed to the record edit page, the URL does not show the private ID of the record. This can also be used to allow the user to bypass the login for a while if the setting below is set.

Extended Access

This sets the cookie to stay valid for 24 hours, allowing them to bypass the login for that period of time. This requires the the “Use Cookie” setting be selected as well. When a user with such a cookie visits the Participant Login page, they will be immediately redirected to their record edit screen. The 24-hour period can be changed to another value by using a code filter.

Password Recovery Settings

Provides a way to send the direct link to the user’s record so their password can be changed or recovered. This requires the the “Resend Private Link” functionality in Participants Database be correctly configured. This does not send the password or set a new password, it functions in the normal way for Participants Database: it provides the recipient with a private link to edit their record. They may use that link to change their password if they wish.

Lost Password Form Shortcode

This shortcode is used to generate the lost password form. This setting allows you to customize the shortcode, primarily so that a custom template may be used. the default value here is [pdb_request_link].

Password recovery works by emailing the user a “private link” which can be used to access their record edit page, bypassing the login form. When checked, this setting will change the private ID every time it is used to access the record edit page. This keeps the private link secure because it can only be used once. Don’t use this if your users need to be able to use a static URL to access their record edit page. This setting has the effect of changing the private ID code every time the record is saved.

F.A.Q.

Is it possible to use the login form to show a list of records?

If you want to only show the list of records to people who are registered, you can set the destination of the login form to the page with the list shortcode. You can use the “record_page” attribute in the shortcode to direct the user to any page, for example:

[pdb_login record_page="show-list"]
How does the "brute-force" protection work?

Every time the form is tried, the attempt is recorded with a timestamp and and the user’s IP. If there are over 10 attempts in a hour from a single IP, that IP is not allowed any more attempts for an hour.

Can I change the number of login attempts are allowed before the IP is shut out?

Yes, it quires the use of a filter callback. The number of attempts allowed is filtered by pdb-login_max_attempts and defaults to 10. The time within which this number of attempts is allowed is filtered by pdb-login_attempt_timeframe and defaults to 1 hour in seconds, or 3600.

What if someone loses or forgets their password?

The plugin uses the “Resend Private Link” function that Participants Database uses. There is a setting to include the link in the login form. If someone doesn’t know their password, when they click the link and enter their identifying information (usually an email) a “private link” is sent to them that they can use to access their record. They can change their password at that time if they wish.

How secure is the login form?

The login form provides a reasonable amount of security for non-critical applications. While security is very important to the design and operation of Participants Database, the plugin is not recommended for storing high-value information such as credit card numbers, social security numbers, passwords, etc.

The level of security when using this plugin is largely determined by it’s configuration by the administrator. Security is always a trade-off between convenience and how hard it is to break in. If you opt for convenience, it will be at the expense of security, that’s just how it works.

This plugin is designed to be useful in low-security situations where things link single-field logins and plaintext passwords are desirable. The security can be enhanced by using encrypted strong passwords, and hard-to-guess usernames that are not publicly viewable.

How do I use encrypted passwords?

The first thing to do is to use a “Password” type field for your designated password field in the Participant Login settings.

If you want to use encrypted passwords, you will need to give the user the opportunity to create one. The way this usually works is when the record is created, either by a signup submission or in the backend, the user will receive an email (given that this is properly configured) with their “private link” that takes them to their editable record. They can enter a password at that time, then after that, they can use the PDB login form to access their record.

It is also possible to include the password field in the signup form so that the user can set their password when they sign up.

The use of encrypted passwords is not compatible with the use of plaintext passwords, so if there are records in the database that already have a value for the designated password field, changing the field type to or from a password type field can cause problems. If you do that, the data will become invalid, and cannot be used to validate a login.

If you were using plaintext passwords and decide you need to change to using encrypted passwords, you must have your users go to their record using the private link, then enter a password. After that, they can use the password in the login form.

Is there any way to find out what someone's password is?

If you are using encrypted passwords, there is no way to know what the password is. In that case, the user must set a new password. If you are using plaintext passwords, then yes, no problem, the password will be visible to an administrator. The password will also be visible to the user when they edit their record.

How can I prevent the private ID from being seen in the URL after they log in?

In the Participant Login settings enable the “Use Cookie” setting. Now, when someone uses the login form, they will be directed to the record edit form without any indication of the record ID or private ID in the URL.

Is it possible to direct the user to a different page depending on a value in their record?

Yes, there is a filter that is used to get the URL of the page the user goes to after they successfully log in. The filter is ‘pdb-login_after_validate_submission’ and it passes in the user’s record and whether it was validated or not. (This means this can also be used to change where they go if the login wasn’t valid.)

I have created a simple plugin that demonstrates how this can be done:

Redirect PDB Login

You can download this demo plugin and make the changes needed to work for your situation.

How can I add a CAPTCHA to the login form?

It is possible to add reCAPTCHA protection to the login form if you have the PDb reCAPTCHA add-on installed and working. You need to use a custom template, I have provided an example of the template you can use for this.

pdb-login-recaptcha.php

You will need to understand a bit about how custom templates are set up, ready this article for the details:

Using Participants Database Custom Templates

Once you have the template in the correct location, you can use that template in the login form with this shortcode:

[pdb_login template=recaptcha]

Support Discussions for Participant Login

  • hi
    there is a problem in the resend private link email
    we received email without the private link how to go about?

    • Make sure the “Participant Record Page” is configured. This is in the plugin settings under the “Record Form Settings” tab.

  • Hi,

    is it possible to force strong passwords to the participant login?

    Best Rene

  • Latest PDP update broke the system again. I had everything working perfectly, and had delivered to the users. I had configured it so SAVE on changing a record taking the person to a new page to inform them they had updated their record and been logged out. As of the latest update, this no longer works. They are now left on the record page, with a record updated note, but if they try to save again they get TYPE MISMATCH. I have tried all variations on Cookie settings, etc. And on different browsers and platforms (PC, phone etc)

    • I’m sorry about that, but since I really don’t know what the fundamental issue is there, I don’t know what changes broke it. I’ve never seen the “type mislatch” error you’re seeing, I don’t know what causes it. It is almost certainly something that is happening on the server, so a different browser/device won’t matter.

      I just tested the use of the “action” attribute in the [pdb_record] shortcode, no problems with that that I’m seeing. Is that how you are directing users to the page after submitting changes?

      • OK. Thanks for the feedback, that gave me the clue to where to look. I apologise for the hassle – my fault this time, I had messed up the action attribute and lost a “. Always helps if you put ” at end of the page URL.

  • The latest update to the plugin is WORSE than before.
    Any page containing the shortcode ] now fails to render at all. The code above and below the short code is not sent to the browser, the entire page sent from the server is empty.
    I have verified this is due to the short code. Firstly, I already had a login page which was rendering OK, just not finding members when they used it. After installing the update, that page become empty when rendered. I removed only the short code and reloaded. Page loaded perfectly. I then added the short code. Page became blank. I tried putting the short code above and below the rest of the content in case it was breaking a synchronous load, but makes no difference.

    There is a new line in the PDP debug log:

    PDb_List_Admin::initialize
    list query: SELECT * FROM wppe_participants_database p WHERE CAST(p.next_renewal_date AS SIGNED) > CAST(1593558000 AS SIGNED) AND p.membership_type LIKE “%FULL%” ORDER BY p.last_name desc LIMIT 0,20

    This is the ONLY line in the debug log.

    I am also running WP_Debug. It is not showing any errors related to PDP.

    • I have verified this is not a cache issue by creating a totally new page with the [pdp_login] short code. It has the same problem.
      I have tried cookies on and off, and 24-hr cookie on and off. I have also tried changing many of the fields in the pdp_login settings to force it to address the DB, just in case there was an issue accessing settings or something when the short code was called.

      The problem is worse than I first thought. Since updating this plugin, I have discovered any attempt to display a record results in a blank page, even by admin. All the records are displayed correctly in the LIST PARTICIPANTS screen, but clicking to open any results in a blank page.

      This problem was not there before updating the plugin, and updating the plugin is the only change made to the site since I was last able to see member records. In fact, the whole system was working OK, with the exception of the login. Now the whole system is totally broken.

      • Correction – you can see the record in Admin mode if you click the Pencil edit icon. You cannot see the record if you use the PID. Using the PID renders a blank screen with no source code.

        • Now have it working.
          STEPS TO SOLVE: –
          1) disabled debugging plugins (WP_DEBUG and QUERY_MONITOR). This resulted in page rendering. Still said NO RECORD FOUND with correct login.
          2) Changed “password” field from “membership number” field I created to the ID. This worked. System performs as it should.
          3) Changed password field back to original “membership number” field, everything continued to work.

          This leads me to conclude the password field in Login settings needs to be reset after update. I switched to ID because it was system generated. I had tried changing to other user fields without any effect earlier, which had made no difference, but I was still running WP_DEBUG at the time, so that may have got in the way. I don’t have conclusive evidence switching to a system-generated field is needed as part of the fix, but I imagine it is queried differently from a user generated field?

        • Hi Brandt,

          I’m sorry for the inconvenience caused by the update. I was not aware that a specific configuration prior to the update would lead to a problem like that, I need to take a look at the code to see how that can be avoided. I really appreciate the detail you provided, it’s very helpful.

  • Latest update has broken the system.
    I updated the PDP login plugin today. Now it no longer works. When people log in, it says “no record found” – it was working until the update, I was testing it at the time. As soon as the update was completed, it no longer worked. I therefore conclude the update broke the PDP login.

    • I have this problem too. From yesterday I began getting the “there-has-been-a-critical-error-on-your-website” error, mainly when I tried to use Participants Login to access client records. I disabled all plug-ins including Participant Login, Participants Database and Participants Database Custom Templates. While reactivating the plug-ins I got the “there-has-been-a-critical-error-on-your-website” error after reactivating the three Particpants Database plug-ins. I saw there was an update for the Particpant Login plug-in and updated. So far I am not getting the WordPress critical error problem but I have the same problem as you …. my PDB logins work fine and access the client record but … NO RECORD FOUND.
      Please can you help, we are in the height of the holiday booking season and use PDB to manage our bookings…..

      • I have also got the critical error on the website error message. I got this when I tried to deactivate the Login plugin AFTER the update. Once it ceased to work, for security purposes I tried to deactivate it, triggering the critical error. To test whether this was unique to the PDP Login plugin, I tried disabling other plugins, logging out and back in first. I could deactivate other plugins OK, but attempts to deactivate the PDP Login consistently produced the site critical error. I was able to disable the PDP login plugin via putting the website into recovery mode.

        • It’s good to know it’s not just me … I have had to disable access to my Guest Booking Management …. right in the middle of the season!!

        • Can you give me any specifics about the error you’re seeing? The system usually provides a specific error when it notifies you of the problem.

        • I found the deactivation problem, thanks. I’m not seeing a problem with the login itself, however, I need more specifics about your setup to I can try to duplicate the problem.

          I’m issuing an update that fixes the deactivation issue.

    • Can you tell me more about your login form? Are you using a password? Recaptcha?

      I’m not seeing the problem here, so if you have any specific information that was provided in the error email you gor from your site, that would be helpful.

      • Hi, Unfortunately, I was getting nothing more than the critical error message with no other detail. There was no error email from the site even though it said there would be.

        After I updated the Participant Login, it seems that the critical error message may no longer be occurring but maybe it is too soon to tell.

        I have set up Participant Login to use the guest email address and an encrypted password, The login is successful in that it is not rejected for incorrect email or incorrect password but there is no data and the form shows No Record Found.

        I am happy to give you access to my site if you want to investigate it there.

        Ciao, Debbie

      • The site did not generate any error emails. I have never had an error email from PDP. However, attempts to send them may explain why the error log contains multiple instances of “escapeshellcmd() has been disabled for security reasons in class.phpmailer.php” – this line only occurs when the system has failed:
        1) when getting “no member found” messages using PDP login since update,
        2) now and prior to update, when it fails to display PDP log in a member’s record when they accessed it via PDP login.
        I have tried changing the field used for the “password” on login, but this does not change any behaviour.
        I have tried totally disabling cache and firewalls, in case these were getting in the way.
        There is no recaptcha. I never use them.
        Everything works fine when member records are accessed via admin, and if directly accessed by a member via PID. It is only the PDP Login which is having problems.

        • The error in the mailer class is probably preventing your site from sending any emails, and depending on where in the code it is, probably causing other issues. One way to possibly avoid this is to use an SMTP plugin so you’re using the SMTP transport for email functions instead of the default mail.

          There were several changes to the code that uses a cookie to keep a user logged in, so there seems to be something in that that isn’t working in your case…i’d really love to know what the problem is…I can’t find it here because the login is working fine here. Were there any other errors in the log that might be connected with someone opening their record edit page after using the login form?

    • Are you using custom templates? I eventually got this fixed by renaming the particpants-custom-templates folder, un installing participants custom template pllug-in, reinstalling it and moving my templates from my renamed participants custom template folder to the newly created particpants-custom-templates folder in wp-content

  • Hi

    I’ve been using Participants Login for sometime. I need to add a logout button to the Guest record but I’m not sure how to do it.

    I read that I should use /?p=2034&pdb-logout but I am not sure where to put it or how to format it

    I would appreciate some help!!

    • The easy way to do this is to start with the URL you want them to go to when they log out, then add the logout variable. For example, if you want them to go to the login page after logging out, and the name of your login page is “member-login” you can use a URL like this on your logout link:

      /member-login?pdb-logout

      If you want it to be a button, you’ll need to provide the HTML for that, the exact code to use would depend on your theme, but the URL will be the same.

  • Hello i like this plug in a lot.

    Was wondering if the shortcode [pdb_login ] can display Captcha

    like ideally [pdb_login fields="captcha,"]

    Thanks!

    • This wasn’t possible, but your question got me thinking how that might be possible. What you need to do is use a custom template for the [pdb_login] shortcode. I created a template for adding the reCAPTCHA to the form here. Once you have the template uploaded to your site (must be in the correct location, read this if you don’t know where it goes: Using Participants Database Custom Templates) you can use the shortcode:

      [pdb_login template=recaptcha]

      • Hey thanks for this example.
        I have installed
        1. pdb-custom-template2 plugin
        2. uploaded pdb-login-recaptcha.php to that plugin’s theme folder.
        3. placed shortcode [pdb_login template=recaptcha] on the page I was using for a log in.

        – i am receiving the default theme still.
        in your documentation for the custom themplates
        i read :
        “Each shortcode uses a template to display it’s output. First, it will look in the theme directory for the template to use, and if it doesn’t find it there, it looks in the plugin directory to use a default template provided by the plugin.”

        – as i understand the custom template2 plugin folder is the correct place for this if the plugin is active?

        – i logged in the shortcode form and the debug log said “PDb_Login::handle_incoming input: email@the-email.com login query: SELECT * FROM lqumk_participants_database WHERE

        email

        = ‘ email@the-email.com
        -I’m not sure but that did’t look like an error

        What do you think?

        • The correct location for custom templates when using the Custom Template plugin is

          /wp-content/participants-database-templates/

          sorry about the confusing instructions, I need to make it more clear.

        • Entries in the debugging log are informational, they do not always indicate a problem. I recommend you turn debugging off for normal operation of your site.

      • Okay that is the location to place the template is /wp-content/participants-database-templates/ – I looked for it in the readme and the doc page

        This worked – THANKS

        however the page looks correct the captcha displays. and pops out.

        but when i tried to log into accounts without passing a captcha

        It still redirects to the user display page without validating

        thanks again

        • reCAPTCHA will validate automatically in the background if it can determine you are a legitimate user.

        • I thought that but does this sound right?

          if i don’t captcha on this form [pdb_signup fields="captcha,other,fields"] i will be prevented from submitting the form. perfect right behavior

          But it appears to not prevent a submit on the forms [pdb_request_link fields="captcha"] or [pdb_record fields="captcha"]

          it will offer an input in the blank form field but it won’t prevent a submit if it is not filled out

          i’ve cleared the browser, other devices, phones etc.

          the forms [request_link fields=”captcha”] , [pdb_record fields="captcha"] and the new [pdb_login theme=recaptcha] all show the captcha field but only [sign_up fields=”captcha”] requires it

          and thanks.

        • Just use the shortcode that is given for the custom template:

          [pdb_login template=recaptcha]

  • Setting USE COOKIE generates a 404 on some browsers.

    As indicated in my post about the log, I need to use a cookie to preserve login, otherwise users who spend too long on the form get logged out without any notification. If they then try to submit they get a PHP type mismatch error.

    However, when I activate this option, some browsers, such as Vivaldi, generate a 404 error message when the login link is activated.

  • We’re having a security issue in Firefox using the participant login feature. Our participants sign in to update their information using an order number as the username and a zip code as the password.

    No matter who signs in, it’s always pulling up the same record. Chrome and Safari work fine, but Firefox won’t pull up a separate record no matter what.

    The user does have to enter valid credentials for some record in the database. But, it always pulls up the same record.

    I can get you direct access to take a look in a private message.

    • This sounds like a caching issue, are you using some kind of caching or accelerator plugin? You should exempt the login page from page caching.

      • Thanks for the speedy reply! I think you’re correct.

        I just exempted the pages in question from our cache plugin and it appears to be working correctly now.

        Really appreciate your help.

  • Thank you for your excellent plugin!

    I was wondering, is there an option for administrator approval of edits to records before the changes are made public? That would be a massively beneficial feature to safeguard against any malicious edits.

    If this does not exist, is it possible that I make a financial donation for you to create it, please?

    • Yes, this is in the doumentation here: Approving Records

    • I’m in the process of designing an add-on to Participants Database that provides for an “undo” feture for record edits, and it occurs to me this plugin could also hold new edits back until they were approved. This add-on is in the design stages, and would be somewhat complex, so the development timeline would be several weeks.

Leave a Reply to Brandt Dainow Cancel reply

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

Would you like to be notified of followup comments via e-mail? You can also subscribe without commenting.