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.
Quick Fix
- clear Memcached/Redis or any other memory cache
- if you use the wp-optimize plugin, it may have additional caching. Disable/Remove it
- check the db_upgraded value in wp_options MySQL table. It should be set to 1 (true)
- If all else fails, reboot your server as this will clear memory caches
Why is this happening?
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.
How to Fix No Update Required
Clear the WP Object Cache
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:
Use the hosting company’s user interface to clear the 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.
Rename object-cache.php to gain Dashboard access
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.
Clear in-memory caches with WP-CLI
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.
Clear in-memory caches from the server command line.
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
- telnet localhost 11211
- flush_all
- quit
These three commands should get the job done.
Less common problems and solutions associated with “No Update Required.”
Some users have reported experiencing this infinite loop, without using any caching plug-ins.
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.
Solution : restart PHP on your server
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.
WP-Optimize plug-in
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.
Wp_options table db_upgraded value
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 all else fails, reboot your server
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.
Conclusion
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).
Filed in . Read more about Wordpress.