Make WordPress Core

Opened 10 years ago

Last modified 3 years ago

#26056 new defect (bug)

Database is not upgraded in multisite if loopback is disabled

Reported by: creativeinfusion's profile creativeinfusion Owned by:
Milestone: Priority: normal
Severity: major Version: 3.0
Component: Upgrade/Install Keywords:
Focuses: multisite Cc:

Description (last modified by SergeyBiryukov)

If on a server that disables loopback connections (like several shared hosting companies have implemented) when attempting to upgrade a WordPress Multisite the database is never upgraded from the normal upgrade process.

The normal upgrade process fails on the Network Upgrade wp_remote_get call with

Warning! Problem updating http://domain/subsite. Your server may not be able to connect to sites running on it. Error message: couldn't connect to host

The intent seems to be that logging in to the site(s) would fix it as the help on the Upgrade Network page (/network/upgrade.php?action=upgrade) says

If this process fails for any reason, users logging in to their sites will force the same update.

but although logging in attempts the update, that also fails (but silently) as it also fails on the wp_remote_get.

There's nothing that indicates the database version is out of step with the code and so no prompt. At least manually going to /wp-admin/upgrade.php and all /subsite/wp-admin/upgrade.php does fix it.

To replicate:
1) Get a server where loopback is disabled (or perhaps simulate it using the pre_http_request filter)
2) Install multisite using WP 3.0
3) Create a subsite
4) Upgrade to latest WP version using the link in the admin
5) Check the database version in the wp_options, wp_x_options table - or use this code to add the version into dashboard rightnow

function dbversion(){
	$dbv = get_option('db_version');
	echo "DB Version: $dbv";

6) Log in/out to main site and subsite - database version remains at the old level
7) Manually visit the /subsite/wp-admin/upgrade.php page and upgrade it's database. The subsite db version will now be correct, but the main site will not until /wp-admin/upgrade.php is also visited

Change History (8)

#1 @creativeinfusion
10 years ago

In principle in network/upgrade.php couldn't we call wp_upgrade() after the switch_to_blog() and avoid a wp_remote_get entirely?

#2 @SergeyBiryukov
10 years ago

  • Component changed from Upgrade/Install to Multisite
  • Description modified (diff)

#3 @SergeyBiryukov
10 years ago

I was under an impression that if the database needs to be upgraded, a redirect to wp-admin/upgrade.php is performed upon logging in for both single site and sub-sites of a Multisite install.

However, that's not the case, the redirect is only performed for single site. Multisite still tries a full network upgrade via wp_remote_get(), as noted in the ticket description: tags/3.7.1/src/wp-admin/admin.php#L44.

#4 @jeremyfelt
10 years ago

  • Component changed from Multisite to Upgrade/Install
  • Focuses multisite added

#5 @here
9 years ago

Similar issues if sslverify fails due to self-signed certs (dev environments), mentioned here

#6 @here
9 years ago

Related to #31405 -- upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites

#7 @kwisatz
8 years ago

This is still a thing in 4.6.1 and the main problem is this failing silently. I have, through problems with the term meta api, discovered that some of the databases were still at really old versions, 28000 something…

Running the upgrade on each networked site individually, as described in the original post, still works.

#8 @oglekler
3 years ago

It is still the case (checked with 5.7.2). If this cannot be fixed, possibly an instruction or a link to some guide about what needs to be done manually will, if not solve the problem itself, at least save people's time on investigation.

Another point is even if bulk Upgrade is failed, 'wpmu_upgrade_site' is updated and an obvious reminder that there are things that need to be done is absent.

Note: See TracTickets for help on using tickets.