After a core WordPress update, many users get locked out of their WordPress Dashboard, with an endless loop saying No Update Required Your WordPress database is already up-to-date!
It can be distressing, but it’s easy to fix, and we’ll lay down the options in this article to get you back to blogging.
It’s essential to understand why this is happening in the first place as it may help you figure out how to solve it, just in the unlikely case our solutions below don’t work.
When the database is upgraded, a small piece of information is marked as “upgrade done” and WordPress can move on. The problem at hand is caused by a glitch in which that information stays in a “need upgrade” state in the cache.
Therefore, WordPress thinks it needs to upgrades the database, only to find out that it has already been upgraded, hence the message and infinite loop! All pages within /wp-admin/ will redirect to that dreadful message.
The solution is to clear the cache responsible for retaining this outdated information, but there are many cache options, so we’ll cover as many of them as possible.
Typically, this is happening to people who some form of in-memory cache such as Memcache, Memcached, or Redis but is also valid for less commonly used WP in-object cache such as PHP APC.
A file called object-cache.php in the /wp-content/ folder is responsible for letting WP PHP code talk to the selected in-memory caching system. Once the in-memory cache is cleared, you should regain access to WordPress and be out of the loop.
Here are some ways to clear the in-memory cache:
The Easiest way to clear the cache is to do it through a control panel at your hosting company, or ask support to clear all caches on your behalf. Each hosting company may have a slightly different way of doing it, so here are some references for GroundSite or Cloudways.
If you have FTP access to your WordPress, you can go to /wp-content/ and rename object-cache.php to object-cache.bak.php (or any other name). This will disable the in-memory cache code, so WordPress won’t access the out of date data anymore.
After doing this, you should be able to regain Dashboard access. From there, you can go to your favorite cache plugin (W3TC, WP-Rocket, Redis, Memcached, or any other) and click on the “Clear cache” / “Flush cache” or “Clear all caches” button).
Most likely, interacting with the caching plugin will prompt the plug-in to create a new object-cache.php file that you can see via FTP.
This means that in-memory caching has resumed and that things are back to normal.
Many hosting companies now support WP-CLI, a command-line tool for WordPress websites. This allows people to execute WordPress code without access to the Dashboard.
If you have access to the WP-CLI command line prompt, use “$ wp cache flush” to clear the in-memory object cache. Here’s the documentation of the WP-CLI cache flush command.
If you are comfortable with the Linux command-line, it is also possible to clear Memcached or Redis without going through WordPress. Here’s how to do it with Memcache, and instructions for clearing Redis cache data.
Clear Memcached from the command-line
These three commands should get the job done.
It may be true that no caching plug-in is installed, but it is possible that PHP (the runtime which executes WordPress) itself has some form of active caching.
To test this theory, you can restart PHP using the web hosting user interface (if there is such an option) or ask support to do it for you. Optionally, restart your web server (Apache or Nginx) as well.
Alternatively, you could do it via the Linux command-line, and here are the instructions for Ubuntu and general guidelines for various Linux distributions.
This happened to me: I did clear the cache (Redis), but the problem kept repeating. Apparently, the WP-Optimize plug-in that was installed was interfering with the caching issue, and it is only after I removed it that the cache was cleared correctly.
I haven’t taken the time to investigate “why” this was going on, but the takeaway is that if you have several plug-ins that may use in-memory caching, this could happen, and you might need to disable that plugin by renaming its folder name in /wp-content/plugins/ or delete it.
There are many ways to disable plugins, and Kinsta has made an excellent article on that topic.
Some users have reported that after the upgrade, the “db_upgraded” value in the MySQL “wp_options” table was still set to 0 (false). Using PhpMyAdmin to set it to 1 (true) may solve the problem, that is why many hosting companies install PhpMyAdmin on their servers.
I usually don’t recommend people to edit the MySQL database manually. If you’re not very comfortable with MySQL (the database standard powering WP) and PhpMyAdmin (a graphical MySQL admin interface), ask your hosting support to do it for you. You may want to backup your Database too.
If your in-memory caching system is on the same WordPress server, a complete reboot should also get rid of the problem.
It creates downtime while the server reboots, but that should get the job done and clear all forms of in-memory caching.
This problem has been around for a while, and I suspect it will happen again. If all else fails, you can head to the WordPress.org forums to ask for help, or drop a comment in this article (click on the speech bubble).