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.

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.

 

Join the Conversation

1 Comment

  1. Hello
    thank you
    I wanted a guide. WordPress blog post service. There are plenty of plugins, but unfortunately, they only duplicate WordPress database data, which increases the volume of the database, which goes out of control as the number of blogs grows. Do you have a way to provide only a blog service database?
    as

    CREATE TABLE IF NOT EXISTS blogs (
    id int(11) NOT NULL AUTO_INCREMENT,
    poffline text NOT NULL,
    ponline text NOT NULL,
    pro text NOT NULL,
    lid int(11) NOT NULL,
    username text NOT NULL,
    password text NOT NULL,
    email text NOT NULL,
    semail text NOT NULL,
    btitle text NOT NULL,
    bdesc text NOT NULL,
    ads1 text NOT NULL,
    ads2 text NOT NULL,
    ads3 text NOT NULL,
    ads4 text NOT NULL,
    PRIMARY KEY (id)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;

Leave a comment

Your email address will not be published. Required fields are marked *

You can also subscribe without commenting.