It’s 5am here and I’ve spent the better part of the last 14 hours installing 6 new WordPress blog sites. One for a girlfriend, one for a friend, and the rest for domains that have been sitting unused for way too long. While not a fully automated process yet, I’ve worked out a few techniques which make it much easier than starting from a fresh install each time.

First a warning though, I’m writing about the general process I worked out and not providing technical details. Aside from the time it would require to explain all the details, I’m afraid it would only generate endless emails and comments asking why this or that step isn’t working.

Franchising My Optimal WordPress Configuration

My first goal was to have each new installation begin with my favorite set of plugins, a nice selection of themes to play with, and my preferred set of options preset. So I began by installing the latest WordPress distribution (1.5.2), setting it to a basic theme, changing the options in Admin and installing extra themes and plugins. I think relocated the wp-content folder outside the site’s directory and soft linked it to the location WordPress expects to find it at. This allows all the WP blogs to share the same themes and plugins.

One Database, Many WordPress Blogs

I discovered early into this process that I wanted to keep all blogs in a single database to simply backup management and periodic maintenance. inside the wp-config.php file you can change the default prefix for the WordPress MySQL tables (defaults to "wp_"). So I used phpMyAdmin to export the default (but now configured) WordPress tables from MySQL to an SQL file and used BBEdit to do a global search and replace on the default table prefix, changing it to something indicative of the domain at which the next blog will be hosted. For example, a site about Fast Cars would get a prefix of "wp_fastcards_". (An aside here: if I get around to further automating this process, I’ll just write some shell scripts and use mysql for the database export, but phpMyAdmin was an easier way for me to watch what I was doing and think things through.)

Now here’s where my mistakes will help you out if decide to try this at home: the blog’s URL is stored in the wp_options table and if you don’t update those before creating the next set of tables, you’ll have an impossible time working within WordPress Admin. Apparently there’s a bit of redirecting that goes on in Admin and without the site’s domain/URL properly set ahead of time, you’ll keep getting bounced to the template site’s URL. So after doing the global replace on the table prefixes, you need to search for the domain name and replace all occurrences with the new site’s domain name.

[Be careful doing global replacements, it’s possible you might match on something you didn’t want to change…]

So after the SQL script has been updated, it’s onto the next step in replicating your template site.

Duplicate WordPress Files and Import MySQL Tables

Here we go…

1. Import the database tables to the existing database containing the other blogs’ tables. I used mysql for this step:
   mysql --user=wayne -p my_blog_db_name < wp.sql
2. Duplicate the template WordPress site to a different domain’s directory.
3. Switch to new directory and change the table prefix in wp-config.php
4. Open web browser and login to the new WordPress blog! Since it contains all the configuration from my template blog, the admin login is all set up (and you could include additional user logins in your template if you want them in all the sites). At this point I changed the blog name and description — something which could also have been done before importing the tables, I just didn’t bother thus far.
5. Sit back and admire the new blog a minute then onto the next one…

Left out of this description is the fact that I had to keep making changes to my Apache httpd.conf file since all these domains had been disabled and dormant, but overall the process was pretty easy once I figured out what works. And it wouldn’t take much effort to run all this from the command line using a mixture of MySQL and stream editors (or Perl if you prefer).

I wish I could manage all the blogs from a single Administration control panel, but I’m afraid the various multi-user WordPress hacks floating around probably have their own headaches which I’m not ready to deal with yet.

To recap some of the advantages this type of multi-blog configuration has:

• A single database to backup and maintain.
• A single set of themes and plugins shared among all blogs which reduces disk space usage and makes all additions and modifications to those directories instantly available to all blogs.
• A big time savings in configuring each new blog to my preferred arrangement - including default users, writing options, and for several of the plugins I use (AdSense-Deluxe, wp-Amazon and a few others) the customization they require is already in place.

I’m interested in hearing comments on ways to further simplify or improve not only the process of replicating WordPress installations, but also managing multiple installations. Comments on this post are open, so leave me your thoughts. I’ll compile the best of them into this or another post.

This entry was posted on Thursday, October 6th, 2005 at 5:10 am and is filed under WordPress. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. | Permalink