"ms_files_rewriting" site option is not created during upgrades

[gradyetc]

While testing an upgrade for a MU era multisite install from 3.1.4 -> 3.6.1 I discovered that the "ms_files_rewriting" site option was not being created.

The attempt in upgrade_network()...

if ( $wp_current_db_version < 21823 )
 	update_site_option( 'ms_files_rewriting', '1' );
}

... is failing. I believe this has gone unnoticed since the default value is forced to true in wp-includes/ms-default-filters.php:

// If the network upgrade hasn't run yet, assume ms-files.php rewriting is used.
add_filter( 'default_site_option_ms_files_rewriting', '__return_true' );

[gradyetc]

The call to update_site_option( 'ms_files_rewriting', '1' ) in upgrade_network() is failing due to that filter.

In most cases the "ms_files_rewriting" site option will not exist when running the upgrade. The default value added by that filter causes the check within update_site_option that would normally add it to fail:

if ( false === $oldvalue )
	return add_site_option( $option, $value );

The end result is it continues, attempting to UPDATE a non-existent meta_key within wp_sitemeta.

UPDATE `wp_sitemeta` SET `meta_value` = '1' WHERE `site_id` = 1 AND `meta_key` = 'ms_files_rewriting'

A fix is attached in 25819.patch.

[dd32]

25819.patch​ looks good, however, it'll only apply to future users updating their networks, anyone who has updated past-3.5 won't trigger this again.

Perhaps we should also add a 3.8 update check that checks to see if the row exists in the DB at all, and if not, creates it?

[nacin]

Let's deal with this at once.

[gradyetc]

Perhaps something like this in upgrade_network() or a 3.9 upgrade routine?

$ms_files_rewriting = get_site_option( 'ms_files_rewriting' );

remove_all_filters( 'default_site_option_ms_files_rewriting' );

if ( get_site_option( 'ms_files_rewriting' ) != $ms_files_rewriting ) {
	update_site_option( 'ms_files_rewriting', intval( $ms_files_rewriting ) );
}