fix: ensure give custom db tables exist #3966
As a Give user, I don't want to encounter random features of Give not functioning and not know why and not get actionable responses from Support.
Several users are encountering a smattering of issues with Give and it's often difficult to diagnose the issue, but many of them come down to the custom Give database tables not being present or never having been created despite the user running the DB Updates process correctly and seeing the success message.
Either these tables need to be created reliably 100% of the time, or we need a tool, most likely in the System Info, that checks and confirms that these tables exist. If they don't exist then ideally we have a way to generate them with the click of a button.
Steps to Reproduce
It's almost impossible to reproduce these issues, but here's a list of customer reports:
NOTE: Some of these issues have MANY issues on them, and the DB tables issue is early in the thread. You might have to scroll through quite a ways until you see the original info about the missing tables.
The Support team is now also using the tag
Slack Call Summary
Ravinder explained that missing tables could be due to a missed hook when the plugin is updated from a previous version of Give (as opposed to a fresh install). Custom tables have been reliably created during plugin activation, but Ravinder will also makes sure that they are created during a plugin update by hooking into the action that fires when the Give plugin version is updated. This will ensure that any required tables are created during activation or update.
Upgraded From Value
In addition, we discussed the incorrect behavior of the
In summary, Ravinder will submit one PR to handle table creation and correct the
Health Check Plugin or Give Core
@mathetos We also discussed whether this should be handled in a health check plugin or in a Give core update. @ravinderk and I agree that it is better to handle this fix with a Give core update in 2.4.1 because the updated logic will be in place to look for the tables and create them if they are missing.
We also feel handling the missing tables in a Give core update will better fix the issue for customers who are aware or unaware of the missing tables, whereas a health check solution would include more friction as it requires the customer to realize and report the issue before we can help them.
Manual Trigger or Not
I agree with Ravinder. The tables are created by a PHP function that (after 2.4.1) will fire automatically based on plugin update, so there is no concern with admin AJAX like there would be for other database updates. If something prevents the tables from being created, then it is more likely a MySQL permissions issue in which case a manual trigger won’t help.
Thanks for these details and the careful consideration.
With all that's been said, I think a system info report on whether the customer tables exist or not is still necessary since you mention that a MySQL permissions issue could prevent the tables from being created. Having the report on those tables in the System Info allows us to at least see an obvious problem immediately instead of having to spin wheels figuring out the source of the problem.
I understand your point about the manual update option though, that makes sense.