Database is not upgraded in multisite if loopback is disabled

[creativeinfusion]

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

add_action('rightnow_end','dbversion');
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

[creativeinfusion]

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

[SergeyBiryukov]

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

[here]

Similar issues if sslverify fails due to self-signed certs (dev environments), mentioned here ​http://wordpress.stackexchange.com/questions/115279/multisite-database-upgrade-ssl-error/

[here]

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

[kwisatz]

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.

[oglekler]

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.