Wrong redirect URL after core update when WP is in subdirectory

[tar.gz]

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 example.com/wp and WP_HOME to example.com.

The update is triggered from the admin area located at example.com/wp/wp-admin/update-core.php

When the update finishes, instead of forwarding to example.com/wp/wp-admin/about.php?updated, it sends the user to example.com/wp-admin/about.php?updated. 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.

[SergeyBiryukov]

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.

[tar.gz]

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".

[dd32]

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?

[tar.gz]

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

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 example.com, 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 example.com

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 example.com/directory.

[tar.gz]

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 EXAMPLE.com/wp (WP_SITEURL and WP_HOME are identical)
• The manual upgrade runs from EXAMPLE.com/wp/wp-admin/update-core.php
• 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 EXAMPLE.com/wp-admin/about.php?updated - 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.

[SergeyBiryukov]

#28018 was marked as a duplicate.