Bubbles

Edited the plugin’s CSS, which means CSS has to be modified every time the plugin updates. This really should be a setting option in Registration Magic‘s admin panel.

Thank you, Benbodhi!

We have site access by 4 custom roles, and the menus need to be different by role. We have people registering who aren’t familiar with WP, and we want them to be able to navigate back to the “members only” section intuitively. Thus the use of these two plugins.

What I did in the meantime is make one menu item — Return to “Members Only” Section — which links to same page, no matter their role. On that page, some PHP code determines their role and shows them the Role-appropriate links.

I am still interested to know what may conflicting between the two plugins though, and appreciate your looking into it. ??

Again, thank you, for taking time to respond, xnau.

I’ve been going through my PHP error logs (nothing relevant), de-activating plugins, and stepping backward through every single thing I touched since making that one change and then reverting that file yesterday — all the usual troubleshooting for when WordPress goes wrong. I’m marking the topic resolved, since, at this point, I’ve got to think it’s something I’ve done and not the fault of the plugin. (I’m just not sure what yet!)

I still want to mod the display for the [pdb_single] page (to render more like the [pdb_record] page). If that goes well and quickly before our Monday launch, I may do the dual install you suggest. Good idea!

So I’m in phpMyAdmin to see if anything looks “off” or if that one record was in a state of half-updating itself.

id default is set to NULL and private_id default is set to RPNE2. It seems to me, based on their usage, both should be NULL.

I didn’t change anything because I don’t know if maybe private_id sets itself up for the next added participant (and I don’t want to break anything further).

Feedback?

That didn’t work. ??

Any other suggestions?

Thanks, xnau.

I haven’t updated to the new version. We go live with this project Monday, and updates are not always smooth with so many factors involved between WP versions, themes, and the plugins themselves (I know you understand this). I’m concerned there may be issues with updating which I won’t have time to fix between now and our launch.

If I de-activate and re-activate the version I have installed, will the plugin retain all of my settings? (Well, except hopefully this setting I broke!)

I did as noted above, @xnau, and when I click “apply,” the private_id changes back to its original value.

I haven’t updated to the new version of Participants Database just released. Any idea why the change wouldn’t stick?

Oh, and in case anyone is wondering, the code is super simple:

[tabby title="titlehere"]

[pdb_signup template=custom groups="groupname1"]

[tabby title="anothertitlehere"]

[pdb_signup template=custom groups="groupname2"]

[tabby title="thirdtitlehere"]

[pdb_signup template=custom groups="groupname3"]

[tabbyending]

Repeat for as many Tabs and Groups required.

My [pdb_signup] uses a custom template only because I modified how the Group title appears; otherwise, it’s default code. And then there’s my custom CSS for both the Tabby plugin and Participants Database plugin. Otherwise, this page display can be set up in just a few minutes.

I’m using the same layout for [pdb_single] and [pdb_record].

Hi, again, xnau!

I appreciate that suggestion; I did look at using multi-page forms.

The team I’m working with is a Type-A “gotta keep moving” sort of group, so I wanted them to have the option to input as little as possible now and click ‘save’ to rush off to see a client (or whatever) OR input everything now.

Using a multiple-page signup form felt too much like they were being forced to move through all pages before being able to save.

My compromise was to use Tabby Responsive Tabs (highly recommend!) to offer all Groups at one time, while not actually displaying all Groups on screen. So the save button appears on each “tab,” and the user can save at any point after the required fields are completed on the first “tab” and walk away.

The “thank you” page still displays and the Edit Record page isn’t immediately available, but I think it gives the team a sense of control over the process. The “thank you” page has buttons to Add Another and Return to List.

The feedback has been positive, and I really like the page display this way.

Thank you for the suggestion!

For other people seeking help who may not have already visited the author’s site, the link in @xnau’s response (https://xnau.com/work/wordpress-plugins/participants-database/participants-database-documentation/participants-database-1-6-api/the-template-helper-class/) is broken. Here’s the correct link: https://xnau.com/work/wordpress-plugins/participants-database/participants-database-documentation/participants-database-api/the-template-helper-class/.

Instead of adding the NAME field to the headline, since it’s the second field on the form, I changed the CSS for it to make it red, bold, and larger than the other fields on the page, in order for it to stand out. That resolution worked for my purposes.

I did use the Template Helper Class to pull other fields outside of the loop. I am very well versed in databases and not that well versed in PHP, but I eventually figured it out. Marking this as resolved.

Thanks for your help.

Thank you, xnau, for responding yet again!

There are so many moving parts to this thing, and I think my head is spinning at this point. That’s meant as a compliment — all the parts do seem to be moving in the same direction, and the plugin does so much!

Ooooh! Well, that’s interesting and good to know, xnau! My db is private, but I would’ve thought no indexing. I may have to use this in other places, once I get the hang of it!!

I am looking for help with something else and noticed your post, @hikertommy.

There’s a “link” for every record (something like https://www.domain.com/whatever-you-call-your-record/?pdb=6). You can retrieve each product’s link by viewing your [pdb_list] list page (presuming you set a field the Record Link in the admin panel for the plugin).

As you say, though, there isn’t a “page” or “post” for all of those products.

It seems to me the way to accomplish what you want without advanced programming skills is to create [pdb_single] pages for those products you want to be indexed by search engines and add shortcode for the record ID. So the page containing [pdb_single record_id=6] would show only that one record. On that page, you could SEO info, like your title, description, etc. with the aid of a plugin like Yoast or All in One SEO (so it wouldn’t appear twice on the page).

It creates extra work, but if you don’t know the programming to do it, it’s one way to get it done.

Again, thank you for your time.

I changed 'options' => self::_get_identifier_columns(), for the Primary Email admin field to 'options' => $this->_get_sort_columns(), which I copied from the Sort field code. It seems to work and doesn’t look like I broke anything.

Using 'options' => $this->_get_sort_columns(), lists every field, including those which are not formatted as email fields, but since the original code listed all text fields (not all of which were email fields), I’m okay with that.

I appreciate your help and am marking this resolved.

I understand the use of the field. My Dropdown field offers email address choices. By using an email which is selected instead of typed, I don’t have to deal with incorrectly typed addresses, admins can choose theirs from the list, and no one has to type twice to verify — it’s faster and provides accuracy. Since all email addresses in this field are clickable on the front end, the plugin is obviously reading them correctly, so I didn’t think it would be a stretch to use the field for Primary Email.

It sounds like you are saying this is a limitation of how the plugin is written. Thank you for taking the time to respond.