More weirdness: no records error, duplicate check not working, swapped records

Here are some PHP error log entries (I’ve redacted table prefix and email address before posting:

Participants Database Plugin: IP blocked for too many retrieval attempts from IP 216.115.113.24 in 24-hour period
—
WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1 for query UPDATE participants_database SET date_updated = NOW(), first_name = ‘Jane’, middle_initial = ”, last_name = ‘Test’, suffix = ”, address = ‘456 Hwy Way’, city = ‘Fairbanks’, state = ‘AK’, zip = ‘99701’, length_of_time_at_residence_address = ‘3 months’, phone = ‘907-123-4567’, primary_phone_type = ‘Other’, alternate_phone = ”, alt_phone_type = ”, fax = ”, email = ‘redacted’, hometown = ”, photo_need = ‘I need my photo taken’ WHERE id = made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, Participants_Db::init, Participants_Db::process_page_request, Participants_Db::process_form

A thought: Some of these issues (especially the first?) may be explained by the same “lots-of-testing-on-the-same-computer” as your suggested in the related thread on weirdness. I tried testing in incognito mode, but was using the same IP at the time. However, it cannot explain the 3rd issue (showing one participant another participant’s info after submitting the form) which one of our user testers reported. She was only asked to submit one test application. Let me know if you have seen this before or have ideas on how to troubleshoot it.

I noticed from one of your other posts that you placed a link to the “lost private link” form on some of your form pages. I would recommend against this because you’re going to get people who have unfinished forms visiting a page with the retrieve link form and that’s asking for trouble.

I would recommend placing links to the retrieve form on your home page or some other place where they would go after they have completed the form and have had a chance to lose their private link.

This other issue is the kind of thing that comes up in testing. Spurious reports are common in testing, especially in “one off” tests like you’re looking at there. Unless the report suggests a specific bug to check, usually, you’d wait for another similar report before really considering it something to dig in to.

I can’t think of how such a thing would happen, the protocol I’m using to securely identify a user and maintain state between page loads is pretty standard. It would be very concerning to me if it were to happen again.

OK, you say “I would recommend against [placing a link to the “lost private link” form on some of your form pages] because you’re going to get people who have unfinished forms visiting a page with the retrieve link form and that’s asking for trouble.”

Can you explain why this is trouble? Once they start a record, they have an ID, so why can’t we email them a link?

Another solution to the “very long form” issue that I tried initially was to have them just fill out one page of it with their personal info and then send them immediately to the thank you page (no action to take them to page 2), so they could get their link, and then choose to continue entering info (I had a button-styled link that said “I’m ready to Continue” which took them to the first page of the multi-page pdb_record) or use the link to come back later. However, they end up on the same Thank You form when they finish the last screen of the pdb_record, so that was confusing. I broke that into two halves (New Applicants and Returning Applicants) with separate instructions (New users could see their link or choose to continue; People who had filled out the whole form could click on the button-styled link to go to the signature page). But that failed in usability testing because the people who elected to finish the form in one setting didn’t feel like they were “returning” and ignored that message.

This is all to say that having one single flow from signup through thank you (as in your multi-page tutorial) seemed to work best AS LONG AS we can give users an EARLY way to retrieve their link. If this is indeed asking for trouble, then I’m out of ideas for making this work for such a long form. I’m open to any ideas.

I think I finally understand what’s going on here.

I never intended for the retrieve link function to be used in this way, so it’s untested and will possibly have unintended consequences. The plugin keeps track of whether or not a multi-page form is complete or not, and this information is used to determine what the [pdb_signup] shortcode will do. The retrieve link form is closely related to the signup form and so there is the potential for problems under certain circumstances. I don’t know exactly because I never tested this use. I’m always learning something new from the plugin’s users.

I would suggest you don’t use the [pdb_signup] shortcode for your retrieve link function, use the [pdb_request_link] shortcode on another page and send your users there if they want to get their private link emailed to them. This may solve your problem with that form misbehaving.

However:

The approach of having the private link return to the multi-page signup form series is also untested, and won’t work properly because the plugin doesn’t know that the user is jumping in to a multi-page form at that point. Mutli-page forms are not designed to be re-entered at a later date, especially not at some point other than the first page. It is expected that the user complete the whole series in one session, and begin on the first page of the series.

If you were to stay within the tested use of the plugin, you would have an initial signup form that completed normally, sending the private link to the user. That link would go to the multi-page form series (it must go to the first page of the series) where the whole form could be completed. If the user needs to do this in multiple sessions, that is OK, they just have to start again at the first page, they can’t come in somewhere mid-series.

It is possible custom functionality could be developed to support this use, however.

Thanks, this helps I think. Though am still deciding where to go with it. One clarification: I already use the [pdb_request_link] on a separate page, and not the [pdb_signup] method for getting them their link. When they use it they ALWAYS reenter at the first page with the [pdb_record…] shortcode on it, even if they have completed more pages, and they can use the “save and next” (aka submit) button to review what they have entered and get to where they left off. But it sounds like even this is not within the tested use of the plugin. So.

I could go back to my original method and have them just complete and submit the signup fields (and none of the other field groups) (i.e. a [pdb_signup] with no actions that takes them right to the thank you page, and then they can use their private link to return and enter the rest of the paged field-groups, then return to the same thank you page on completion. I believe you said there were also issues with not having an action with the original [pdb_signup] shortcode, though it worked in initial testing. The single thank you page was the main usability issue, but I may be able to overcome that through better wording and design cues. Before I do that let me know if there are fundamental technical issues with this approach that would argue against it.

Are you available/interested in doing any custom development needed to either a) create a separate custom thank-you page template for initial sign up and then for completion of multipage form; or b) a different/better solution for allowing someone to fill out long multi-page forms in more than one sitting (and ideally allowing them to come back to where they left off)? Let me know and I can send an email to your support address to follow up on timing and pricing.

(I will mark the other open thread as resolved so we can keep any additional discussion on this one.)

I am open to helping you with custom functionality, but it will be a couple of weeks before I can get to it. Contacting me at my support email is the best way to proceed with something like this.

OK, I will talk to the client and get back to you by email to discuss scope and budget if they want to make it work better for next year (this is an annual signup), which I will recommend. Unfortunately, the timeline is too soon to make that work for this year since they have calendar dates that can’t be changed. Right now the form is set up completely kosherly (i.e. following multi-page form instructions for all shortcodes and not providing the Lost Link on the signup page, but putting it on its own page), yet it is still giving me a Record Not Found error on page 3 or 4 of the form (it varies) in IE, Firefox and Safari (Chrome seems more resilient), and then throwing the same Catchable Fatal Error in those browsers:

Catchable fatal error: Argument 2 passed to Participants_Db::replace_tags() must be of the type array, boolean given, called in /–full-path-redacted–/wp-content/plugins/participants-database/participants-database.php on line 2942 and defined in /–full-path-redacted–/doyoncandidate/wp-content/plugins/participants-database/participants-database.php on line 2953

I will investigate other Form plugins this weekend to see if I need to completely change gears. Let me know if you know of any I should look at. I will also re-install everything I have created so far on a new WordPress site, and see if I can at least get it to work as intended on most major browsers. I don’t know if it will be acceptable to the client to have them complete the entire form in one sitting, but that’s a starting place at least.

Can’t give you an answer on the “file not found” issue and that error. That will happen if the session goes stale or missing and the plugin can’t find the record ID, but I can’t account for why that would happen in the middle of a form being filled out…intermittently.

Are you using a page caching plugin?

I am using WP Super Cache with the default settings

I suggest you turn off all caching for testing and development until you’re sure everything is working, then turn it on. This sometimes means you need to look at the .htaccess file for hard-coded caching rules.

Will do. Thanks for the suggestion.