Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#21745 closed defect (bug) (fixed)

Database Upgrade Redirect Loop

Reported by: mdawaffe's profile mdawaffe Owned by:
Milestone: 3.5 Priority: normal
Severity: major Version:
Component: Upgrade/Install Keywords: has-patch close
Focuses: Cc:

Description

Whenever I do a Database upgrade (non-Multisite), I get stuck in a loop:

  1. See "Database Upgrade Required"
  2. Click "Update WordPress Database"
  3. See "Update Complete"
  4. Click "Continue"

This is not being caused by object cache.

Chrome is aggressively cacheing both the 302 redirect from whatever admin page is first requested and the responses from wp-admin/upgrade.php:

Request URL: http://hacek.local/wordpress/wp-admin/options-privacy.php
Request Method: GET
Status Code: 302 Found

Request URL: http://hacek.local/wordpress/wp-admin/upgrade.php?_wp_http_referer=%2Fwordpress%2Fwp-admin%2Foptions-privacy.php
Request Method: GET
Status Code: 200 OK

Request URL: http://hacek.local/wordpress/wp-admin/upgrade.php?step=1&backto=%2Fwordpress%2Fwp-admin%2Foptions-privacy.php
Request Method: GET
Status Code: 200 OK

Request URL: http://hacek.local/wordpress/wp-admin/options-privacy.php
Request Method: GET
Status Code: 302 Found (from cache)

Request URL: http://hacek.local/wordpress/wp-admin/upgrade.php?_wp_http_referer=%2Fwordpress%2Fwp-admin%2Foptions-privacy.php
Request Method: GET
Status Code: 200 OK (from cache)

Request URL: http://hacek.local/wordpress/wp-admin/upgrade.php?step=1&backto=%2Fwordpress%2Fwp-admin%2Foptions-privacy.php
Request Method: GET
Status Code: 200 OK (from cache)

...

Note the "(from cache)" in each of the requests after the initial ones.

Attached adds nocache_headers() to wp-admin/admin.php before the redirect and to wp-admin/upgrade.php. That's the minimal change that works for me.

It's possible we should instead add a nocache_headers() to the top of wp-admin/admin.php (in addition to the patched change to wp-admin/upgrade.php), but I haven't thought through what all else that might affect (there is already a nocache_headers() call at the bottom of that file).

Chrome 23.0.1246.0 dev/OS X

Attachments (1)

21745.diff (885 bytes) - added by mdawaffe 12 years ago.

Download all attachments as: .zip

Change History (6)

@mdawaffe
12 years ago

#1 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5
  • Severity changed from normal to major

We call nocache_headers() after auth_redirect(). Would have to think about whether it can/should be placed above that. The only code before auth_redirect() in admin.php is the rewrite rules DB upgrade routine, so 21745.diff seems like it would fix all issues in the admin.

Last edited 12 years ago by nacin (previous) (diff)

#2 @nacin
12 years ago

In [21913]:

Send nocache_headers() in the admin earlier, on the DB upgrade page. Prevents a potential redirect loop reproduced in Chrome from heavy caching of headers. props mdawaffe. see #21745.

#3 @nacin
12 years ago

  • Keywords close added

Pretty sure calling nocache_headers() first thing in the admin should be fine. If so, [21913] fixes the ticket.

#4 @dd32
12 years ago

  • Resolution set to fixed
  • Status changed from new to closed

I'm calling this fixed by [21913], If that doesn't fix it, nothing will.
I've also done quite a few DB upgrade loops today and It hasn't got stuck in a loop once (I used to trigger it once in a while)

Re-open if there's still reports of it.

Note: See TracTickets for help on using tickets.