Running a Development Copy of WordPress Multisite – Update

WordPress Multisite Updates

Back in January I wrote a guide which provided details on how to setup a WordPress Multisite environment for Production and Development that both shared the same database. Since then there have been several updates with the WordPress core and I’ve also come up with several fixes for the sunrise.php file, so I thought I would write a follow up guide. At the time of writing the original guide the only method to make the Development environment fully operational was to modify two core files, which goes against common practice and was especially problematic when it came to updating WordPress. So I would like to focus on the WordPress core updates, incorporated into WordPress 3.9, that allow for the use of a newly introduced filter instead of modifying the core files.

A Better Way of Doing Things

Prior to the WordPress 3.9 release, two core files, ms-settings.php and ms-blogs.php, both needed to be manually edited in order for the Development environment to function properly. Specifically, this fixed the issue where WordPress would check to see if the current request URI matched the site URL saved in the database and since the Development environment differed from the Production environment this test always failed and redirected to the Production environment. Thanks to the introduction of several new methods and most notably the new “pre_get_site_by_path” filter we can now prevent this redirect from happening by making WordPress think it’s being viewed from the correct URI.

To do this we need to add some additional code to our customized sunrise.php drop-in plugin to account for the “pre_get_site_by_path” filter.

/*
* Replacement for /wp-includes/ms-load.php get_site_by_path
**/
function dev_get_site_by_path($_site, $_domain, $_path, $_segments, $_paths) {
	global $wpdb, $path;
	
	// So that there is a possible match in the database, set $_domain to be WP_PRODUCTION_DOMAIN
	$_domain = WP_PRODUCTION_DOMAIN;
	
	// Search for a site matching the domain and first path segment
	$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $_domain, $_paths[0] ) );
	$current_path = $_paths[0];
	
	if ($site === null) {
		// Specifically for the main blog - if a site is not found then load the main blog
		$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $_domain, '/' ) );
		$current_path = '/';
	}
	
	// Set path to match the first segment
	$path = $current_path;
	
	return $site;
}
add_filter('pre_get_site_by_path', 'dev_get_site_by_path', 1, 5);

The comments within the code explain what exactly is being done, and for further understanding look at the ms-loads.php WordPress core file. The only item not covered in the comments is the WP_PRODUCTION_DOMAIN defined variable, which should be defined in your wp-config.php file. Please read the original guide for full details.

Thankfully, that’s all there is to it! At this point we can undo the changes to the WordPress core files and don’t need to worry about making changes to core files with each new WordPress update.

Also, note that I’ve added some other filters to the sunrise.php file to allow all content (database and wp-content/uploads) to reside in a single location and thus be shared by the Production and Development environments without needing to clone any data. I’ve updated the original guide to reflect those additional filters.

As always I hope this has been helpful, and please leave comments if you have questions or comments.