WPIntell

Source evidence

Error adding signup record

Volunteer Sign Up Sheets · support · 2025-01-21T11:44:00+00:00

mixedsentiment
highseverity
0.95relevance
3replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

7 / 35 rows with source links

20.0% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

28 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
skirridsystems resolved
Hi Stephen, I have the latest version of your plugin installed on a multisite and several different users have reported an error message when trying to sign up. “Error adding signup record. Please try again” When I log in and add myself to a sheet, I can’t reproduce the problem, and nor can the original reporter after that. The people signing up are generally doing this as not-logged-in users (I know, security, but they insist…). I’ve tried that too, but I’ve not been able to do it before logging into the site as they usually disable signups when there’s a problem. That message appears to be generated in an add_signup function when a call to data->add_signup fails, and that in turn only seems to fail if the list is full (it’s not) or if the WPDB insertion fails. I’m not seeing anything in the error log. Are there any illegal characters which might cause problems? Is this something you’ve ever seen or heard of before? I know there’s not a lot to go on. Simon Is it still happening to anyone, or did it stop after you logged in to check things out? You correctly tracked down where that error is coming from. However, the form is validated first by a separate validation function that I split out from a bigger function in the current release so other extensions could access it. Part of the validation function checks to see if the slots are filled first and will return a different message saying all spots are taken. That was actually added several versions ago, one of the 4 versions, when some other user was having problems with multiple people trying to sign up at the exact same time (which I find hard to believe), but if they both had the signup forms open to take the last spot, then by the time the second person submits the form, the task is already filled. So, I added that extra check and a message specific to that, which is not what you’re seeing. But, you are also correct in that the function in the data class will return false if the task is already full, since it also does a similar check. That was the problem the other person had, saying that multiple people would try to sign up at the same time, and they would get that database error if someone else beat them to it, and that wasn’t clear. So, that’s why I added the extra check in form validation before even attempting to add the signup. However, the add signup function in the data class checks to see if the WordPress database functions returns false when it executes the SQL query. If it has returned false, then that’s when you will get that error message you said your users were seeing. That means that the database insertion failed. You would need to check your error logs on your server around the time that it happened to see if there is anything in there. Since it’s not an error, you might not see anything. The WordPress database interface won’t crash the site if it fails to insert a record, it just returns false. My best guess at this point is that you maybe had the plugin set to do automatic updates, and so it automatically updated to the new version, but the update somehow didn’t trigger the function that updates the database if that saved db version is older than the current version. That check should happen any time the plugin loads, as it’s one of the functions that is run when the plugin is initialized, so it should get triggered from the public side or the admin side. There was one new column added to the signups database table to store the validated status for signups. If, for some reason, the database update function wasn’t triggered, then that column would not have been added, and then the WordPress wpdb function wouldn’t be able to insert a record that contained the validated value if that column did not exist yet. Oh, and you did mention multi-site, so that leads me to believe that maybe the above is what is happening. My plugin does check if it’s multi-site on activation and runs the activate function for each site in the network, but the function that checks the database version only runs on the current site when the plugin is initialized. It still should do the update for the current site, but, again, this may not have happened. I would suggest you login to the super admin account for your multi-site and run the Network Update function, which will hopefully take care of updating the database tables for any sites that didn’t get updated for some reason. If it’s still happening after that, I would suggest enabling debug in WordPress and setting it to use the debug.log file. Then, if the wpdb->insert function is returning false for some reason, WordPress should add an entry to the debug.log file saying what it didn’t like about the SQL. That’s my best guess at this point. If it’s not easily reproducible. In all my testing, I have not received an error. For the new validation system, I did a lot of testing on other browsers where I was not logged in. So, I did plenty of sign up and clears when not logged in, on several different browsers, but I’m also on a single site install (if that makes any difference). Also, the new validation system was created for sites like yours where they don’t want to require user accounts. It gives you an extra layer of protection against spammers, while also allowing a method for users without a user account to be able to view and manage (i.e. clear) their own signups. Read the updated documentation on my site about it. It might be a good compromise if they insist on not using user accounts. I forgot to address your idea of invalid characters. That would not be the issue since I first validate the fields, and then use the proper wpdb functions that will properly prepare values for safe insertion to the database. So, I still think the best guess is what I mentioned above. Thanks for your detailed reply, that’s all helpful information. It appears that the act of logging in as admin (and possibly doing a test signup) clears the error permanently, so your suggestion that it’s related to the DB update seems very likely. I’ve run a network upgrade, so hopefully that will fix it for any remaining sites.

Comments

3 shown
DBAR Productions 2025-01-21T17:18:00+00:00

Is it still happening to anyone, or did it stop after you logged in to check things out? You correctly tracked down where that error is coming from. However, the form is validated first by a separate validation function that I split out from a bigger function in the current release so other extensions could access it. Part of the validation function checks to see if the slots are filled first and will return a different message saying all spots are taken. That was actually added several versions ago, one of the 4 versions, when some other user was having problems with multiple people trying to sign up at the exact same time (which I find hard to believe), but if they both had the signup forms open to take the last spot, then by the time the second person submits the form, the task is already filled. So, I added that extra check and a message specific to that, which is not what you’re seeing. But, you are also correct in that the function in the data class will return false if the task is already full, since it also does a similar check. That was the problem the other person had, saying that multiple people would try to sign up at the same time, and they would get that database error if someone else beat them to it, and that wasn’t clear. So, that’s why I added the extra check in form validation before even attempting to add the signup. However, the add signup function in the data class checks to see if the WordPress database functions returns false when it executes the SQL query. If it has returned false, then that’s when you will get that error message you said your users were seeing. That means that the database insertion failed. You would need to check your error logs on your server around the time that it happened to see if there is anything in there. Since it’s not an error, you might not see anything. The WordPress database interface won’t crash the site if it fails to insert a record, it just returns false. My best guess at this point is that you maybe had the plugin set to do automatic updates, and so it automatically updated to the new version, but the update somehow didn’t trigger the function that updates the database if that saved db version is older than the current version. That check should happen any time the plugin loads, as it’s one of the functions that is run when the plugin is initialized, so it should get triggered from the public side or the admin side. There was one new column added to the signups database table to store the validated status for signups. If, for some reason, the database update function wasn’t triggered, then that column would not have been added, and then the WordPress wpdb function wouldn’t be able to insert a record that contained the validated value if that column did not exist yet. Oh, and you did mention multi-site, so that leads me to believe that maybe the above is what is happening. My plugin does check if it’s multi-site on activation and runs the activate function for each site in the network...

DBAR Productions 2025-01-21T17:31:00+00:00

I forgot to address your idea of invalid characters. That would not be the issue since I first validate the fields, and then use the proper wpdb functions that will properly prepare values for safe insertion to the database. So, I still think the best guess is what I mentioned above.

skirridsystems 2025-01-21T17:34:00+00:00

Thanks for your detailed reply, that’s all helpful information. It appears that the act of logging in as admin (and possibly doing a test signup) clears the error permanently, so your suggestion that it’s related to the DB update seems very likely. I’ve run a network upgrade, so hopefully that will fix it for any remaining sites.