How to Fix the WordPress Admin Upgrade Loop

WordPress is typically great about taking care of itself and dealing with upgrades elegantly. However, sometimes it gets stuck in a rut. One common issue we’ve seen is the upgrade loop, which presents you with a page in wp-admin explaining that you need to upgrade your database, and upon clicking the button to do so, you’re looped back to the same page.
It’s important to understand what this is doing. Automattic (the developers of WordPress) knew that they might need to change around the database schema in future versions of WordPress. WordPress has a simple equality check to determine if the database version matches the version specified in the files. If these two versions don’t match, WordPress assumes that the database is out of date and needs to be updated.

The version of the files is tracked by wp-includes/version.php. The actual line looks like this:
[php]$wp_db_version = 18226;[/php]
Here is the actual code that checks to see if WordPress is at a matching files/DB version (from wp-admin/admin.php):
[php]if ( get_option(‘db_upgraded’) ) {
$wp_rewrite->flush_rules();
update_option( ‘db_upgraded’, false );
/**
* Runs on the next page load after successful upgrade
*
* @since 2.8
*/
do_action(‘after_db_upgrade’);
} elseif ( get_option(‘db_version’) != $wp_db_version ) {
if ( !is_multisite() ) {
wp_redirect(admin_url(‘upgrade.php?_wp_http_referer=’ . urlencode(stripslashes($_SERVER[‘REQUEST_URI’]))));
exit;
} elseif ( apply_filters( ‘do_mu_upgrade’, true ) ) {
/**
* On really small MU installs run the upgrader every time,
* else run it less often to reduce load.
*
* @since 2.8.4b
*/
$c = get_blog_count();
if ( $c <= 50 || ( $c > 50 && mt_rand( 0, (int)( $c / 50 ) ) == 1 ) ) {
require_once( ABSPATH . WPINC . ‘/http.php’ );
$response = wp_remote_get( admin_url( ‘upgrade.php?step=1’ ), array( ‘timeout’ => 120, ‘httpversion’ => ‘1.1’ ) );
do_action( ‘after_mu_upgrade’, $response );
unset($response);
}
unset($c);
}
}[/php]
Now, to find out what our database version is, we can issue the following query:
[sql]
mysql> select * from wp_options where `option_name` like ‘%version%’;
+———–+———+————————+————–+———-+
| option_id | blog_id | option_name | option_value | autoload |
+———–+———+————————+————–+———-+
| 58 | 0 | db_version | 18226 | yes |
+———–+———+————————+————–+———-+
[/sql]
Looking at these, we can see that the version matches, which is good. If the version between these matches and you’re still seeing the “upgrade loop”, try clearing your browser cache first, but you might also need to clear your WordPress cache. If you’re using W3 Total Cache on one of our new WordPress Optimized Blog Platform plans, you can contact Nexcess Support to clear your memcache cache, or simply restart memcached.
Between these two methods:
1.) Ensuring that the database version specified in the wp-includes/version.php and the database version specified in the db_version option of the wp_options database table match
2.) Restarting or otherwise flushing all of the memcache cache
I have been able to resolve every instance of the “upgrade loop” issue. I hope your luck is as good as mine has been if this issue has you stuck. As always, feel free to contact Nexcess Support with any questions.