Opened 17 years ago
Closed 17 years ago
#8407 closed defect (bug) (wontfix)
Endless loop of upgrade
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.7 |
Component: | Upgrade/Install | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
An endless loop of upgrade can happen.
It seems the cause is the test in wp_upgrade()
if ( $wp_db_version == $wp_current_db_version ) return;
While the test in admin.php is :
if ( get_option('db_version') != $wp_db_version ) { wp_redirect(admin_url('upgrade.php?_wp_http_referer=' . urlencode(stripslashes($_SERVER['REQUEST_URI'])))); exit; }
I just got a WP2.7 install with
// in upgrade.php echo "<br />$wp_db_version == $wp_current_db_version"; // > 9872 == 9872
so the upgrade process never take place
but
// in admin.php echo get_option('db_version') .' != '.$wp_db_version; // > 9771 != 9872
always redirect
Change History (3)
#2
@
17 years ago
I have enable_cache on, so it may be that
the test in upgrade.php should have a update_option on wp version
#3
@
17 years ago
- Milestone 2.7 deleted
- Resolution set to wontfix
- Status changed from new to closed
If you're using the Memcache object cache backend, upgrade to the latest version, which has a fix for this. I'm closing as wontfix, because it's a bug in a backend, not WP, that is causing the discrepancy.
Note: See
TracTickets for help on using
tickets.
That looks like you are using some form of object cache and the options cache has old data in it.
the Upgrade/Install process uses it's own version of get_option which goes straight to the db every time without going near a cache.
As far as the database is concerned you have upgraded.
But your cache doesn't think so.
The call to update_option at the end of the upgrade seems to have made it to the db but not into the cache you are using.