After an update to Give, you sometimes are asked to perform database updates. In the event that those updates don’t complete, this article walks you through all of the options for resolving this problem. Give Support is always available to help if you’ve exhausted your options here.
Give is a complex plugin that extensively interfaces with your site’s database. From time to time, modifications to the database structure itself need to happen, whether to increase performance or to resolve issues. When that is the case, you will see a prompt on every admin (backend) page of your site.
These updates to database structure have been tested on a wide variety of server setups and on extremely large datasets. But as is the case often in software development, unforeseen edge cases can slip through. The one variable the Give team can’t control is the hosting environment your site has, and in a handful of cases, some server and database configurations have proven impossible to perform the updates.
In general, there are three types of issues that will conflict with the database updates on otherwise-healthy server environments: Caching, Security Plugins, and Admin-Ajax issues.
In an effort to speed up page load time and efficiency of your site, some hosts (and some plugins) cache things aggressively. Specifically, database-related caching can cause problems with respect to database updates. Before attempting the database updates, be sure to flush the cache, and then temporarily deactivate the caching solution. This resolves stalled DB updates for a significant percentage of users.
Security plugins, by their very nature, are like overly aggressive bouncers at the party that is your website. Any time they get even an idea that something funny is happening, they stop it. That’s fantastic for parties and for normal day-to-day operation of a website, but when a plugin like Give needs to do some maintenance to the database, that’s often interpreted as malicious by these security plugins and squashed. Give the bouncer some time off, and disable security plugins before attempting database updates.
Related to security, but can often be triggered by other plugins or even themes and the host, access to the admin-ajax.php file is critical for Give database updates. Here’s an article fully devoted to admin-ajax.php. If the admin-ajax.php file is blocked, Give database updates will not function.
Admin-ajax issues on Siteground
Siteground hosting, which includes access to a staging site as well as some excellent caching, has proven difficult to update. One issue is that the staging site, in some of our tests, uses the admin-ajax.php file of the live site, which causes the updates to not work at all on staging. We don’t know of a workaround for that.
The other issue on Siteground has been their “Supercacher” not deactivating, even when told to in the admin. We found that going in via cPanel in the Siteground interface we were able to fully deactivate the caching and process the database updates. If you are having trouble with that, their excellent customer support should be able to assist you with fully deactivating the cache.
Low Processing Time Limit
Some shared hosts have too low of a time limit for processes to run without being shut down. This is generally only an issue if your site has a very large database of donations, and your web host may be of assistance in raising the time limit for those processes.
Some hosts implement object caching (memcache or memcached). This is a type of database caching. While it is very helpful for making your WordPress site run more quickly, it prevents our updates from being able to write to the database effectively. If you know your site uses object caching either via a plugin or your web host, make sure to disable it and clear your cache before starting the database update process.
Some hosts use a must-use or drop-in plugin to enforce object caching. In these cases you either have to know how to disable them via SFTP, or reach out to your host to do so for you.
Others, like WP Engine have a setting in the customer portal. For WP Engine, you can access and deactivate object caching via a link in your WP Admin. See here:
First, before this or any update on your WordPress website, be sure to fully back up everything (files, database, etc) in a way that you can confidently restore to, in the event that things don’t go as planned.
Warning: If you don’t have a full site backup including database and files and things break, there is nothing Give support technicians can do to restore your site without data loss.
Next, if deactivating all security and caching plugins/solutions does not allow the database updates to complete, attempt deactivating _all_ non-Give plugins, and then run the updates. If you can’t deactivate all plugins on your production environment, we recommend using a staging or development environment to do this. We recommend WP Stagecoach for simple staging sites.
Finally, sometimes it’s necessary to go fully manual and run the database updates in a controlled environment, and then push the updated database back to the site.
Here’s the steps for that:
- Spin up a “blank” local WordPress install (we recommend Local By Flywheel and Desktop Serverfor this purpose)
- Install all the same Give add-ons manually to that blank install.
- Migrate the database from the live site to the new blank local site.
- Run the updates locally.
- Push the updated database back to live.
We recommend Migrate DB Pro for the heavy lifting in terms of pushing the database. Here are the only known caveats to this approach:
- Local by flywheel has an issue with the admin-ajax file not being accessible to Give on sites with a faux-SSL certificate, so the local site needs to be non-SSL. This doesn’t affect anything on the live site since the database transfer done by Migrate DB Pro is SSL-agnostic.
- When you push the Database back to the live site, select the advanced option to not send the active plugin list, so that all active plugins on the live site stay that way.
Never attempt database changes or updates without a backup of the site to which you can confidently restore.
Troubleshooting the ‘donor missing’ Issue
In some rare instances, after the Give database updates complete, Donations in the list at Donations > Donations show as “donor missing” with incorrect amounts.
Usually, this issue means that the update (if you are interested in the technical details: specifically the portion of the update that moves all donation meta and donor meta out of the default postmeta tables into new tables) did not process correctly.
The reason the data is incorrectly displayed is that in certain cases, even when the update did not actually proceed as expected, the option saved to the database indicating that DID complete is still saved.
Give essentially is telling itself “the updates are complete, look in the new tables” and it goes to look in the new tables and nothing is actually there. That data is still most likely safe and sound in the original database tables from before the update.
The Give Database Health-Check helper plugin was created to resolve this issue.
- Download this ZIP File: Give Database Health Check Donor Missing module
- Install and activate it as any other plugin.
- Some new Give database updates will appear (refresh the plugin page if they do not appear). Run those.
- Once you’ve verified that the issue is resolved, deactivate and delete the database health-check plugin.
If you are still running into errors, please don’t hesitate to reach out to Give support, we are happy to help in any way.