After an update to GiveWP, 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. GiveWP Support is always available to help if you’ve exhausted your options here.

The Problem

screenshot of an alert on the top of the plugins page in a WordPress back end telling the site admin to update the database.
Sometimes, database updates stall out, so even clicking the blue button doesn’t work.

GiveWP 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 GiveWP 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

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 GiveWP needs to do some maintenance to the database, that’s often interpreted as malicious by these security plugins and squashed. GiveWP the bouncer some time off, and disable security plugins before attempting database updates.

Admin-ajax issues

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 GiveWP database updates. Here’s an article fully devoted to admin-ajax.php. If the admin-ajax.php file is blocked, GiveWP database updates will not function.

Known Conflicts

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.

Object Caching

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:

The link to the object caching setting via your WordPress Admin, found in “WP Engine > General Settings”

The Solution(s)

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 GiveWP support technicians can do to restore your site without data loss.


We’ve built-in a way to manually re-run the database update/migration process. If you are noticing irregularities in your data, we recommend deactivating your security and caching plugins and trying this manual method.

  1. Go to the following URLs, in order: (add your base URL to each)
    /wp-admin/?give-run-migration=create_revenue_table — this manually forces the database routine again
    /wp-admin/?give-clear-update=add-past-donation-data-to-revenue-table — this clears the update so that your site can try again. You should see an update alert after this one runs. If you get a message like “No upgrade for the given ID” it should mean that you already see some updates ready to run. Proceed to the next step.
  2. Run the update at Donations > Updates or by clicking the message at the top of the admin screens.
  3. Go to this URL:
    /wp-admin/edit.php?post_type=give_forms&page=give-tools&tab=logs&section=updates — this checks the logs to see if there were any errors. If you see errors, pass them along in a reply here.

Next, if deactivating all security and caching plugins/solutions does not allow the database updates to complete, attempt deactivating all non-GiveWP plugins, and then run the updates. We recommend using a staging or development environment to do this and migrating the data to your live site later.

Finally, sometimes it’s necessary to run the database updates in a controlled environment, and then push the updated database back to the site. We have a detailed guide on how you can migrate local data to your live site here.

Troubleshooting the ‘donor missing’ Issue

In some rare instances, after the GiveWP 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.

GiveWP 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 GiveWP Database Health-Check helper plugin was created to resolve this issue.

  1. Download this ZIP File: GiveWP Database Health Check Donor Missing module
  2. Install and activate it as any other plugin.
  3. Some new GiveWP database updates will appear (refresh the plugin page if they do not appear). Run those.
  4. 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 GiveWP support, we are happy to help in any way.