From a production to a development installation

Published

Cut to the chase

I've been using WordPress to power client websites since 2008. In 2009 I discovered the WordPress MU fork, a version of the software which allows multiple blogs to run from a single installation, which hugely simplifies maintenance if you're hosting more than a couple of WordPress sites. Now, with version 3.0 of WordPress, MU and standard WordPress have merged, MU becoming a feature called Multisite.

In maintaining client websites, a Web developer always faces the challenge of making adjustments, fixes, or upgrades to a live site seamlessly. Sometimes I can get away with a quick hot fix here and there, where I just log into the production site and make the change. However, if I'm doing anything very complicated—such as a custom plugin or major modifications to the theme—the last thing I want is my client or one of their customers loading the site when I just saved a line of PHP with a syntax error in it, causing the entire site to break. Or worse, if I need to work on some element that is shared between blogs, I could accidentally take down half of my clients' websites.

So the best thing to do when testing out changes to a blog is to copy the production version to a development installation so that it can be independently tinkered with. But how do you do that? A typical WordPress blog has not only posts, pages, and media, but comments, widgets, plugins, and other settings which are not copied using the Import/Export feature of WordPress.

Once again I'm in the situation where I need a development version of an existing blog, and I want to stop wasting time manually recreating the blog.

The chase

I wrote a Python script that takes the ID of the production blog and copies it to a separate development WordPress Multisite installation. Configuration is currently done by editing the appropriate variables at the top of the script. As of this writing, the script does the following:

  • Copies the main wp_blogs entry
  • Copies the database tables for the specified blog
  • Copies any active plugins (if they do not already exist on the development blog)
  • Copies the media uploads directory

Some missing features which would be useful but are more complicated to implement:

  • Copy the active theme
  • Copy/re-associate user accounts

The code can be found on GitHub. Comments and critique are welcome.

Note: The script makes use of a couple non-standard libraries. You will need the MySQLdb module, as well as phpserialize to read the list of plugins from the WordPress options.

Alternatively...

Add your thoughts