I’ve been saddled with Movable Type since the start of the 2000s mainly because I coupled an external database with Movable Type a bit too tightly. It was a design decision that snowballed into a monstrosity from which I could not easily extricate myself.

Recently, I started a blog on WordPress.com and discovered I liked the responsiveness of the WordPress UI more than Movable Type. So I started to experiment with WordPress on my own server. The Network feature in 3.x appealed to me because I like being able to use one interface for multiple blogs.

(Side note: I had actually tried out WordPress a few years back, but the lack of support for multiple sites kept me in the Movable Type fold.)

I’ve been impressed so far, and I feel like I want to learn more about WordPress development. So I wanted to mirror the WordPress network I created for a development environment.

And that’s when the wheels came off.

Round and round: Redirection loop

WordPress does some funky things with redirection that I’ve not had time yet to reverse engineer. I just discovered that simply copying the file system and loading a database dump into a new database is not enough. The WordPress Codex site has documentation on creating a development mirror, but it only really works for single-blog installations. When you try to enable the WordPress Network configuration values in wp-conifig.php, you get a redirection loop.

On an unrelated task, I wanted to find out how to change the domain of the primary blog in a WordPress Network. A Google search led me to these instructions, which actually are a bit more heavy-handed than they need to be but contain all the right information to get it done. I noticed as I tried to get my domain changed that I was running into what seemed to be the same redirection loop.

Perhaps my trouble with creating a development mirror is related to changing the domain of the primary blog in the network? As a matter of fact, it was.

Change your primary blog’s domain in three queries

Despite what the instructions say, you do not need to replace every instance of your domain in your database dump. In fact, you can change the domain of the primary blog with three MySQL statements:

• update wp_site set domain = 'newdomain.com';
• update wp_options set option_value = 'http://newdomain.com' where option_name in ('home', 'siteurl');
• update wp_blogs set domain = 'http://newdomain.com' where id = 'blog_id';

Of course, substitute newdomain.com in those examples with your own domain name. blog_id is the numeric id of your primary blog in the database, which is most likely “1”. NOTE: The table names in the example may not reflect the actual table names in your database. But some form of wp_ and site, options and blogs should be in the names.

You will need to change the DOMAIN_CURRENT_SITE constant in wp-config.php to your new domain name as well.

define('DOMAIN_CURRENT_SITE', 'newdomain.com');

These steps assume you’ve already set up a domain separate from your production site, and you’re pointing that domain to a development copy of your WordPress file system. They also assume you have access to a MySQL command-line interface.

In short, creating a development mirror of a WordPress Network involves changing the domain of your primary blog to prevent a redirection loop.