This post was updated November 6, 2019 to be compatible with current versions of WordPress.
A very common support request is along the lines of “how can I give my users access to a set of Participants Database records?”
There are basically two ways to do this, depending on what privileges you want to give your users. If you just want them to be able to use a couple of pieces of information (email and password, perhaps) to gain access to their one Participants Database record for editing (and nothing more than that), you can use the Participant Login add-on to provide a login form for that purpose.
If you need to provide your users with other privileges, such as access to protected areas or the ability to know who they are on other pages, then you have to register your users as WordPress users. That will give them a way to log in and that will be persistent throughout your site.
Participants Database can work very well with WP users, but it can be a little tricky figuring out how the two functionalities will work together. In this post, I lay out a simple scheme that can serve as a starting point for your own integration. What I describe here won’t require much coding, but you’ll probably need to get deeper into the code if you want to take things beyond this.
Relating Records to Users
The easiest part is relating a record to a user. When a user is logged in, several pieces of information about them is available. All we need to do is capture a bit of information that will identify the user and store that with the record. I’ll provide an example of how to do that.
Create a hidden field named “username” to hold the user login. After creating the field, I changed the title to “User Name” for readability, you should choose whatever title makes sense to you. Set the default to current_user->user_login That will grab the “user_login” property of the current_user object when a new record is created.
If your application allows users to create multiple records, they will all be associated with the user through this value. Be sure to set the field to appear in the signup form by checking the “signup” checkbox.
Of course, for this to work, your signup form has to be accessible only to logged-in users.
Showing a List of the User’s Records
It’s not difficult to filter a list display so that it only shows records that relate to a particular user. What we need to do is set up a custom shortcode that filters the list according to the currently logged-in user. What it does is how a list that is filtered by the user_login field using the current user’s login name value. That means that the list will only show records that that user created.
The code included in this tutorial will install a plugin that gives you a shortcode for this purpose: [pdb_user_list].
The tutorial code can be modified for your specific needs, for instance, you may want to combine this with: Adding an Edit Record Link to the Frontend List which you can do by adding a template attribute to the list shortcode string that is used in the user_list_shortcode method in the tutorial code.
The tutorial code provides alternate content if the user is not logged in, you can of course change that to show whatever you want such a user to see. This is also in the user_list_shortcode method.
Showing the User an Editable Record
If each user only has one record associated with them, you’ll probably want a way to let them edit it. Showing a single, editable record is a bit trickier because we need to find the record id of the user’s record, but the plugin has methods to help us do that.
The plugin provided with this tutorial creates a shortcode for this purpose [pdb_user_record] This shortcode will show the record that matches the user’s ID and allow them to edit it.
The core of this is the call to Participants_Db::get_record_id_by_term() to which we supply the name of the field (or term) to look at and the value to match. The method returns a single id number, if there are multiple matches, the first in the series is returned.
Showing the User their Record
If you just want to show the user their record (not editable) there is a shortcode provided for that purpose in the tutorial code. Use [pdb_user_single] to show the user’s record.
The Tutorial Plugin
This plugin will install the three shortcodes described in the article. With a little php knowledge, you can modify the plugin to suit your specific needs.
Be sure to check the private $user_id_field = 'username'; line: that is the name of the field you are using to capture the user’s ID value. It must match the field name you use in your setup.
Installing this plugin: How to Install a WordPress Plugin from a Gist
Henry Pham 
Roland Barker 
Andrew Hanssen 
Sandra Vileta 
Sören Carl Tesdorpf 
Jasper Drexhage 
Jasper Drexhage 
Hi Roland, how can I create a field that stores the last WP user that edits a record? I used a hidden, editable field with default value current_user->user_login but it only stores the first user and doesn’t change when another user updates the record. I am obviously new to WP. Thank you for your help.
Only way to do this is with some custom code. You need to place a handler on the pdb-before_submit_update filter that updates the user ID field of the record.
Hi, I’ve just been tasked with re-designing a website and adding in a new membership platform with restricted content, login, etc. The current site uses your plugin to register and store over 2000 ‘members’ as a list. ‘Members’ are able to report information which is stored in the database. PDB is an integral part of managing that reported data and user information and in building visible data-tables/charts. I do not want to break their system as you already have a great plugin and it seems to work for them.
I am using a membership plugin that registers and creates wp_users and assigns custom roles. It gives them access to manage their information, see submissions, access restricted content, etc.
My questions are:
1. Am I able to convert current ‘members’ from their Participants Database into wp_users? If so, can I select only a certain group or number of listed ‘members’ to convert?
2.If a user registers through the membership plugin or wordpress system will their information automatically be added to PDB using the methods you describe in the article?
Thank you for your time.
A good way to convert Participants Database records to WP users is to export the list as a CSV. You can determine who is included in the export on the list page before exporting. The CSV is then imported to a spreadsheet application where you can reassign the fields as needed to generate a CSV to be imported to WordPress. You will likely need another plugin that will create WP users from an imported CSV. This plugin will determine how you will need to structure the data you are importing to get your users.
Once your users are in, you will need to figure out how to associate each user with their Participant Database record. This may involve performing more import/export operations using a spreadsheet to store the new WP user’s ID in their PDB record.
Of course, this could all be done using a php script, if that is your preference. The spreadsheet method provides a convenient way to interact with the data more concretely, I find.
It is possible to use filters/actions that will synchronize WP users and Participants Database when things like signup forms or registrations happen. This is not something that is discussed in this article, but you can, for instance, set up a handler on the pdb-after_submit_signup action that creates a new WP user and then goes back and sets the new WP user ID value in the Participants Database record.
Roland,
You have no idea how impressed I am with Participants Database. After just a few days, I am still trying to get my bearings.
QUESTIONS:
1. Is this a relational database?
Based upon what I’ve read in the documentation so far, it appears to have that kind of capability. We need a database that will allow each of our customers to enter, edit, and store their personal mailing lists, which we can selectively export as cvs files for printing. Customers also need to be able to indicate which addresses in their mailing list they want printed at any given time (for their Christmas card envelopes or their child’s graduation party, for example). I’m assuming that it is entirely possible to set up Participants Database to do all of these things.
2. Is there a limit on the number of users who can be logged in and entering or editing their private mailing lists at the same time? So far, I haven’t been able to find any information about simultaneous users.
Best regards,
Sandra
Hi Sandra,
Participants Database is not a relational database, but when used in conjunction with WordPress users, you can relate a Participants Database record or set of records to individual users as described in this article. How this works is Participants Database does not hold your user’s information, it is only used to store the items in each of their mailing lists. How to relate the records to an individual user and how to show each user their own records is explained in this article.
Your users will all have a WordPress account on your site (you can create a custom role for that if you want) and then when they are logged in, they will be able to view, edit, and add to the items in their mailing lists.
If you need to store additional personal information for your users, you need to use another plugin that adds fields to the WordPress user profile. Participants Database does not do this.
To provide them with a way to download a CSV for their list, take a look at this article: Adding a CSV Download Button
Roland.
First, thank you for that follow-up information.
1. Forgive me, but I don’t understand the distinction you are apparently making in your statement “Participants Database does not hold your user’s information, it is only used to store the items in each of their mailing lists”. What is “user’s information,” as apposed to “items in each of their mailing lists”? By “user’s information,” do you mean their personal information, such as the user’s first and last name and email address?
2. Using the solution you described, would users have to create a WordPress account, as an independent action, or would users have to wait until we set up a WordPress account for them? Can the creation of such an account be done seamlessly by a shortcode, for example?
3. Would the fact that they would actually be in a WordPress account while accessing their mailing list mean that the number of simultaneous users would be unrestricted, in theory at least?
Typically, customers come to our website, open an account, and immediately begin adding their mailing lists. Since 2001, we’ve used FileMaker as our database to do all of this (but, apparently, it was never intended to be used in that way). Back then, neither we nor Lynda (the founder of Lynda.com, who wrote the book for Apple’s FileMaker that we used to design our database) knew that. In recent years, the “flaw” that allowed the program to be configured in that way, has been eliminated.
Needless to say, it feels as if we are facing a doomsday clock, and we are desperately hoping that this is indeed the solution we’ve been looking for.
Incidentally, my heart sank a little bit when I read that you are no longer available for development projects. If you ever need an editor, I am definitely open to a proposition. ( I’ve taken your advice and begun reading Chris Newman’s Teach Yourself PHP in 10 Minutes, the first of several library books I borrowed today.)
Best regards,
Sandra
Each of your users must have a WordPress account on your site so that Participants Database can know who the user is and manage their mailing list. Participants Database does not have user accounts or logins, that is provided by WordPress. This means that your users must register, this is not something the Participants Database does.
When I say PDB will not store the user’s information, I may not have been clear: it would not store any of the user’s profile information, it will only store the users mailing list.
There is no restriction on the number of simultaneous users as far as WordPress is concerned, this would only be limited by your server’s capacity.
Hello! I’m hoping to use this database as a searchable field on our site. Three groups would be involved. 1. Us as site and project hosts. 2. agencies with listings in the database 3. general public who can search the database without having to create access or login and they can find free information about people in group 2.
This looked really promising, as agencies can go in and help us keep this database up to date, but I’m not seeing a way for it to be displayed and searchable publicly. Is that correct? If it is possible to make this database public, how do I do that?
I suggest you start with the instructions on the Setup Guide found in the plugin admin menu, this will give you a working starting point which you can adjust to your needs.
Showing a searchable list of records is explained here Using the List Shortcode
Is there an easy way to test/verify if the post/user is already known in the database?
I think something like
If [pdb_user_record] is ‘Empty’ then use [pdb_signup]
Thank you in advance.
/Michael
Hi,
You new updated plug-in contains [pdb_user_list] and [pdb_user_record]
However I do not see [pdb_user_single]
Do you know when you will have an update including [pdb_user_record] ?
You can create your own [pdb_user_single] short code.
You just have to add the following lines in your plugin-code through the plugin editor
and
public function user_single_shortcode( $atts ) { $current_user = wp_get_current_user(); return do_shortcode( ‘[pdb_single record_id="' . Participants_Db::get_record_id_by_term( $this->user_id_field, $this->user_id(), true ) . '"]‘ ); }it does not look sexy, but works if you want your users print a pdf version of their data.
Thanks for that. If you want to polish the look of the printed record, you can use the print stylesheet settings in the Participants Database settings under the Custom CSS tab.
Hi,
I followed the instructions above to use PDB with wordpress users. Users can now login to edit their data. (still have to figure out to disable the “old” edit link, for this is not compliant to European Privacy & security regulations).
But, I also have admin edit the user date trough the back-end of wordpress. The current_user->user_login is then overwriting the original user name so the relation is lost (wordpress user – pdb user record). How can I prevent this from happening?
This is not how it normally works: once the value of the hidden field has been set, it does not get set again when editing the record. I just tested this, and did not see the problem you describe. Are you using the latest version of Participants Database?
Hi,
Yes I’m using the latest version. The problem is when a admin makes a new record in the back end the username field is overwritten with the login name of the admin.
Our workflow is. Admin creates new record, user gets invited trough mail (and trough wordpress login) to edit and add their record.
In my tests here, when an administrator creates a new record on the backed the user info is not filled in, so I’m not sure what is happening in your case. You should be able to blank out the field before saving it, however, and when the record is opened by the user on the frontend, their user info will be filled in.
Thank you for your plugin and add-on.
I want only our members to be a WP user and logged in when managing there own record.
I have been able to setup the database and registration using the above information and able to get ‘showing the User their Record’ code to work and show my own record, the the basis part should be ok.
But when I try to use the above example for a user can Edit there record i only receive ‘ No record was found’
The code used is the below, but I do not really understand what do_shortcode is or where it is defined.
<?php
$current_user = wp_get_current_user();
echo do_shortcode(' No record was found.')
;
Have I overlooked some other code needed to Edit/Update existing Participants database record?
Hi,
Looks like the php code shown and used is not complete.
I modified it to include the following and then better, however the output looks awfull with lots of spaces. Anyway to get it to look like the standard [pdb_record] using e-mail links provided og Participant Database login ?
Her the code which works but output looks awfull
ID ) {
$record_id = Participants_Db::get_record_id_by_term(‘user_login’, $current_user->user_login );
echo do_shortcode( ‘[pdb_record record_id=' . $record_id . ']‘ );
} else {
echo ‘You must log in to see your record’;
}
do_shortcode is a WordPress function and so the details of how that works can be found in the WordPress codex. Basically, what it does is execute whatever shortcode you provide in the argument. So, to show record edit display for a logged in user, you could use code like this:
<?php $current_user = wp_get_current_user(); $record_id = Participants_Db::get_record_id_by_term( 'user_login', $current_user->user_login ); echo do_shortcode('[pdb_record record_id=' . $record_id . ']'); ?>you will need to adapt this example code to your specific situation, but that is the general idea.
The issue was solved easy by selecting
In Danish:
Fjerne linjeskift Fjerne linjeskift fra alle plugin shortcode output.
Assume English is something like:
Remove Newline Remove newline from all plugin shorcode output
Thank you! That will work fine.
Thank you for this wonderful plug-in. It is so easy to use – quite intuitive.
Noob here – I haven’t been able to find how to differentiate between active and inactive list members. I’d like to be able to hide inactive list members from a general search by the active members but still allow administrators to see, manipulate and export that data. We often have members change status and we don’t want to lose that history by deleting and then re-entering the information later. Can you please point me to the appropriate information to set this up in my own iteration of the plug-in?
Thanks in advance for the guidance.
Take a look at the docs here: Approving Records you can use the same idea to manage your active/inactive members.