Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#26710 new defect (bug)

Wrong redirect URL after core update when WP is in subdirectory

Reported by: targz's profile tar.gz Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:


When updating WP 3.7.1 to 3.8 on a WP install that is located in a subdirectory (using the "Giving WordPress Its Own Directory" method), after the update, the browser forwards to a non-existing URL which causes a 404 error.

In this configuration, in the wp-config file, WP_SITEURL is set to and WP_HOME to

The update is triggered from the admin area located at

When the update finishes, instead of forwarding to, it sends the user to Because of the missing subdirectory, this displays a 404 error.

Upon returning to the dashboard, the user will notice that the update has been correctly applied, but he won't ever see the "Welcome to 3.8" page.

Change History (7)

#1 @SergeyBiryukov
11 years ago

Related: [19524], [21702].

Could not reproduce on a clean 3.7.1 install. My steps:

  1. Set up a 3.7.1 install in its own directory (following the Codex article).
  2. Added these lines to wp-config.php:
    define('WP_SITEURL', 'http://releases.wordpress/3.7.1');
    define('WP_HOME', 'http://releases.wordpress');
    Note that this step is not necessary, as long as "WordPress Address (URL)" and "Site Address (URL)" fields on General Settings screen have the same values, respectively. I tested without these constants as well.
  3. Went to Dashboard → Updates, clicked "Update Now".
  4. Got redirected to http://releases.wordpress/3.7.1/wp-admin/about.php?updated, as expected.

#2 @tar.gz
11 years ago

I just observed that behavior on two "real world" sites, not test sites. They were originally installed a couple years ago, 2010 or 2011. Perhaps some detail changed in the meantime, in the Codex method for directory installs?

Will see if I can reproduce the problem in "laboratory conditions".

#3 @dd32
11 years ago

If they're a few years old, and you're using constants to enable the sub-directory view, can you check what the value in the home and siteurl OPTIONS are in the DB?

#4 @tar.gz
11 years ago

I checked for one site, and in the OPTIONS table, both home and siteurl were set to

I now remember that the story went like this:

1) the site admin defines both URLs on the General Settings screen.
2) another admin accidentally changes both URLs to, breaking the website.
3) the site admin fixes the situation by hardcoding the URLs into wp-config.php
4) after that, the fields on General Settings are greyed out - but in the OPTIONS table, both fields are still holding

Would this scenario explain anything?

However, I also checked the DB of the second site that produced a 404 redirect – here, the siteurl entry is correctly set to

#5 @tar.gz
10 years ago

Ok, I think I figured out a possible cause.

What I recently noticed is that the issue affects:

  • freshly installed WordPress sites.
  • sites that are simply placed in a subdirectory.
  • sites that are running on shared hosting.

Typical scenario:

  • The site is installed in a subdirectory, such as (WP_SITEURL and WP_HOME are identical)
  • The manual upgrade runs from
  • The site being hosted on a slow server, the install ends with the messages "Disabling maintenance mode...", "Database is being upgraded...", "WordPress database error: [MySQL server has gone away]".
  • The page then redirects to - this results in a 404 error.

So, in the event that the database doesn't respond, the post-install action fails to retrieve the WP_SITEURL, and redirects the browser to the domain root (ignoring the current subdirectory).

It's an edge case for sure, and I'm not sure if something can or should be done to fix this... just reporting.

#6 @SergeyBiryukov
10 years ago

#28018 was marked as a duplicate.

#7 @chriscct7
9 years ago

  • Keywords needs-patch added
Note: See TracTickets for help on using tickets.