It is most likely possible, but I am not familiar with the membership plugin you’re using, so I can’t get too detailed about interfacing with it. But I have done this for a client who was using MemberMouse.
Doing something like this takes some planning. the first thing to do is figure out your user experience: the registration procedure (if there is one) and how they need to interact with their stored data. It’s really important you think this through thoroughly.
Once you have defined how you want it to work for the user, you need to figure out how to handle the two main points of interface between the two plugins. The basic idea is that Participants Database (PDB) is set up with an administrative field that holds the ID number of the corresponding record in your membership plugin. This means that PDB is essentially slaving to the membership plugin, that’s important to be clear about.
So, the first point to figure out is how does Participants Database get that ID number from the membership plugin? If there is a registration page, then you would hook into that action (assuming the membership plugin gives you a hook for that!) to establish the PDB record for that user when the registration happens. There are several ways to do that depending on your user flow.
If there is no registration, it’s harder because you don’t have that action to set up the job for you on a record-by-record basis…perhaps you’ll want to “preload” the PDB database with all the users somehow.
The second point is when the user accesses their profile, they will need to be able to edit both the profile fields from the membership plugin, and the fields provided by PDB. This can get pretty complicated. I solved this one by giving the user a tabbed interface: the first tab had all the fields from the membership plugin, the other tabs were for the fields from PDB. That way, you’ve got separate “submit” button on each tab, so there’s no need to aggregate all the user’s fields and figure out how to display them on one page or to save them to two different databases. You can just use the PDB shortcodes, it will save you a lot of coding.
Take a look at the Plugin API, it should give you the hooks and filters you’ll need to get this all working.
A good way to organize all this is to create a class (or a set of functions) that provide basic utilities…for instance a method to find the PDB record ID given the membership plugin user ID, and vice-versa.
