One of the most frequent support requests I receive for the plugin is: can it do multiple databases? Can multiple instances of the plugin be installed? To both questions, the answer is no, it’s not designed for that, but you can do a lot with this plugin and in most cases it’s not really necessary to have separate databases. All that’s needed is a way to differentiate more than one kind of record.
First of all, any kind of website that needs something like this is probably going to have complex functionality. It is not the kind of website that can be put together by installing a few plugins. It will require a good understanding of the user experience, how to help people interact with the site so it’s not confusing, and it’s going to require some knowledge of HTML, CSS and PHP.
The purpose of this article is to outline the task so you’ll have a better idea what’s involved and then you can determine whether you need to bring in coding help or not. The example I give later on in the article is simplified, and wouldn’t require any coding, but many real-world applications won’t be this simple.
Is Participants Database Enough for the Job?
When people ask about multiple databases, they usually have two or three different classes of thing they want to store in the database. In some cases one of those things would be better handled by another plugin or functionality.
For instance, let’s say you have some people signing up for a newsletter and some people offering their time as a volunteer. Participants Database is not well suited to managing a mailing list, so you would likely be better off using a newsletter plugin for your newsletter subscribers, and Participants Database for your volunteers: it’s much better suited for that. You may need to figure out how to handle it when a person wants to both volunteer and subscribe to the newsletter, but that will be a lot easier than trying to customize Participants Database to handle a mailing list.
Another common thing people want Participants Database to do is register users, then let those users do things like post messages or ads. In this case, you’re much better off creating a custom role and registering your users with your website as WordPress users, then letting your logged-in users post ads or whatever you are having them do to interact with Participants Database. Once again, no need for multiple databases there, and I’ve written an article describing how to do that: Using Participants Database with WordPress Users
Simulating Multiple Databases
In those cases where you have different, but similar things to store in the database, the Participants Database plugin can handle that pretty easily. That is done by setting up a field that is used to differentiate your records as being a member of a class. Let me show you one way to do that…
In this example, fairly typical of the kind of thing plugin users ask about, there is a kid’s sports team that expects the parents to be involved in various ways. You want the kids to sign up and give the needed info for their participation, but you’ll have a different set of questions for the parents. This means we have a page for the kids to sign up and another page where the parents sign up.
The key to this is a field that differentiates the records. For this, we create a field named “type” that will indicate whether the record is for a team member or a parent. Make this field a hidden field and set the default value to
post->post_name. What this will do is record the name of the page the signup form was on. With that, you’ll be able to tell which form was used to create the record.
Setting up the Signup Forms
An easy way to manage your fields is with field groups. Since some of the fields for both the parents’ and kids’ records will be the same, it’s convenient to group those together…things like name, address, phone number, email address…and, importantly, our “type” field. We’ll call this group “contact.”
Now, we create two more groups for the rest of the questions: one for the kids and one for the parents. The kids one would have things like t-shirt size, left- or right-handed, preferred position, experience, etc. We’ll call that group “player.” For parents it’s things like how they’re willing to help, when they’re available, and who their kids are.
Now that the groups are defined, we can set up the signup forms. For the kids’ page, put something like this:
For the parents, it’s
Pretty simple, huh? We now have two different signup forms.
This article provides some more detail in setting this up: Using Multiple Registration Forms
Maybe you need to be able to add administrative notes to the records, too. You can put those into another group, “administrative” that holds things like the payers status (active, pending, inactive). Keep the “display” checkbox unchecked on this group so it’s not shown on the website. You’ll be able to edit these fields in the admin.
Showing the Team Roster
Once you have the records, you can do different things with them depending on the type. For instance, to show the current team roster, you could use a shortcode like this:
As you may have guessed, the page where the kids signup form is has the name (slug) “kids-signup.”
At this point, you have your basic working setup, and I’ve demonstrated the general idea behind getting the effect of multiple databases out of the one database that Participants Database uses. You can extend this idea to many different applications.
Showing the Record Detail for Different Types
You can set up a custom template that will show the single record differently based on what kind of record it is. This code shows a special single record template that chooses which shortcode to use based on the “type” value in the record:
You can also set up a record update form that will present different fields depending on the type: see the link below for instructions on setting that up.
Here is an article that explains how to show a record edit form based on the type of record: Showing a Record Edit Form Based on a Value in the Record