rolandbarker

You don’t mention how you know it didn’t work, but the best way to tell if this feature of hidden fields is working is to inspect the HTML of the form and find the hidden fields, which will be at the top of the form near the <form> tag.

The syntax in the “default” setting of the field is simply post->post_name

There are a couple of reasons why this might not work as expected. First, the field must be included in the form, so if it is a signup form, the signup checkbox in the field definition must be checked. This is why inspecting the HTML is helpful, so you can check to see that the hidden field is there, and what value it holds, since the default value will be placed in the field before it is printed to the page.

The second reason this might not work has to do with the context of the shortcode you are using to display the form. It has to be in a context where the WP $post global is available and will have the “post_name” property. For example, if it is in a widget, this might not work…or if you’re using a type of layout block where the content is placed on the screen using JavaScript, it might not work there either. Try putting the shortcode on a regular page in a shortcode block.

If your site does not use text permalinks, then the post_name property might be empty, you may need to use post->ID instead so you can get the post ID of the page.

I’m sorry we haven’t been able to get to why this is happening, I’d like to know myself, but I can’t log in to your site and start changing code, just not a good idea in case something goes wrong.

Reinstalling the plugin could be helpful. You wouldn’t have to start over, you can reinstall the plugin without losing any data. Of course, you should have backups made by a WP backup plugin that makes a backup of all database tables. I posted an article that explains how to reinstall, keeping all of your settings and data intact.

Reinstalling a WordPress Plugin

Well, I’m sorry, but I’m at the end of things I know to check. I mean if I could get the issue to show up here, I’d have a problem I could solve, but at this point all I can suggest is you try to debug it yourself.

If you have any suggestions for how I can duplicate the problem here I’d be happy to keep trying.

If you’re seeing a blank page, you need to check your php error log for information about what is happening. I have not tested Participants Database with this plugin, so I don’t know anything specific about compatibility.

Are you doing this as an administrator on the backend? There is a setting that allows the admin to save records and skip validation.

OK, so when you test this…it shows the validation error message but saves the new record anyway? Or does it not show a validation error at all and behaves as though the submission was valid, showing the “thanks” message?

I assume you saw no errors in the debugging log…I don’t know what the issue is, I sure can’t make it do this in my tests. Did you try re-saving the settings?

OK, so to drill down on this, compare what is in that query to what is in the database. Is it checking the correct field? Is it an exact match?

If it matches, then check again that you have the match preference set to show an error when a match is detected.

Since it is working in my tests, I don’t have any other way to help you other than to check on what is going on there and hopefully you’ll be able to see what the problem is.

This is working in my tests here, so I’m wondering what might be different in your case. Do you have any custom code or plugins that might be altering how the plugin matches records?

Try turning plugin debugging on and clear the debugging log. When you test a signup and check the debugging log, you can see the database query that is used to find the match, this may help show where it’s going wrong. Here is an example of such a query from my tests:

[02/28/25 12:41pm] PDb_submission\matching\record::field_value_exists query: SELECT EXISTS( SELECT 1 FROM wp_participants_database p WHERE p.email = '[email protected]' AND p.id <> '0' ) 

The check is looking for an exact match, so to do something like this with a phone number, you need to make sure the format of the input is exactly the same…there are lots of different ways to write a phone number.

I’m sorry, I can only guess what is wrong there. The plugin gets the path to the content directory from the WP configuration, so if that is incorrect, it can’t be fixed in the plugin.

Since you have migrated, there could be incorrect information in your wp-config.php file, which should be checked to make sure everything is correct in there. It is possible there are additions to that file that are specific to your previous install that should be removed. There is an excellent reference for editing the config file here: Editing wp-config.php

Hi,

I’m not aware of an issue where options table entries are building up due to CSV imports, but if you can give me an example of the name of such an option entry, I’ll be happy to look into it.

Sorry for the late response, I had to create a new account to continue this thread.

All plugin forms will accept ampersands and store them unencoded as a plain ampersand, so I’m not sure how it happened that that particular one got saved in its encoded form. Perhaps a CSV import?

Yes, you can do this on the Manage Database Fields page. Each field has a selector for the group it belongs to, you can select the group you want to move it to there. Save the change, and the fields will then be under it’s new group.

You can also do this to multiple fields by selecting the fields you want to move, then use the With Selected Assign Group control (seen above the list of fields) to move the fields.