• Install virtual versions of WordPress by commenting out the existing $table_prefix in wp-config.php
• redo the “5 minute install”
• create/import your project appropriate test data.

Commenting/uncommenting the appropriate WP table prefix you can turn on and off various databases for rapid testing of wildly varying data on a single theme. N.B.: You will also need to switch to the new theme you are working on since the “other databases” will be showing whichever theme you tested last.

Wanna know more? Read on for some background and a how to if that didn’t quite make sense…

Background

The title kind of says it all really and is probably obvious to most developer types. However,  since incorporating WordPress as a recommended client solution for more and more client projects it became clear to me early on from the WordPress documentation and types of tips and tricks articles I see for WordPress  a lot of WordPress users (and even some folks calling themselves theme developers) are not developers but often are having to modify their own themes without any knowledge of PHP.

When designing or modifying a new WordPress theme it is vital to have useful test data at your fingertips. Even an existing installation with lots of “real” posts and pages can necessarily ensure that your theme is going to perform properly no matter what is thrown at it. If you need to rapidly develop, test, and deploy multiple custom client WordPress themes this is even more important. The problem is that every custom theme you make has different requirements that cannot easily be tested with any random test data. A traditional blog design will contain different post/page data than does a WP install being used as  a CMS. Depending on how stylized the theme needs to be (posts with thumbnails in an elaborate custom magazine grid layout) generic test data becomes useless. Some themes use categories for menus and others use the new 3.0 menu system. Other themes

At one point I created multiple installs with different databases on my development and production server for the wildly different data. Then I got smart (or so I thought) and just started changing the WordPress $table_prefix on one sandbox database but kept doing different installs for each client project (really dumb for client theming unless you are doing the entire WP install and custom development and content placement/layout).

Step by step multiple (almost) instant testing WordPress databases

These instructions assume you have a local copy of your website you work from. I do not actually do this on my live production server but on my local development server. If you do not have a local development server  and must test on your live website remember that anybody coming to your blog is going to see that as well.

Open wp-config in your text editor of choice

On line 62-ish comment out your existing table prefix
and add a new line with a new table prefix below that.

Load your blog and redo the “5 minute” install.

N.B.: If you deleted /wp-admin/install.php  after initial install you will need to put it back (get it from the original download). Don’t know why that is important? Read this guy’s story…
NOTE: I find it easiest to create the same credentials for each install as you will need to be logging in and out depending on how many test sources you use.

Create or import your project appropriate test data

I will be posting several collections of test data soon but for now use these:

• WordPress Theme Checklist (halfway down the page under “Theme Unit Test”)
• Maverick Conceptions (link at top of page takes you to GitHub with a “download source” link at upper-right)
• Church Crunch

N.B.: When importing WP XML or SQL files from other domains, open them in your text editor and search and replace “theirdomain.com” with “yourdomain.com” to ensure all the links and imported media content still works.

Switch to the new theme you are developing/testing

Every time you begin working on a new theme you will need to set each of these “virtual wordpress database installs” to use the new theme you are working on. If you are just testing changes to your existing theme then this is not necessary.

Repeat for as many test databases as you have/need.

Just remember to only have one $table_prefix line commented out a time (if you don’t the last uncommented line is the one that will be used).

That’s it.
Now you can switch testing databases as quickly and easily as commenting/uncommenting 2 lines of code (and setting each database to use the theme you are currently working on).

Last words

At some point it would be nice to create a plugin that could handle this and other theme testing protocols. I can’t think of any easy way to do change the $table_prefix once WordPress has started loading the database however. Ideally the plugin would setup the alternate testing sources and allow you to switch between databases on the fly while keeping the theme active you are currently using. But for now this is working great for me.

I’m a little embarrassed to say I didn’t think of doing this immediately upon working with WordPress.  The phrasing of the comments in wp-config.php, “You can have multiple installations in one database if…”, somehow blocked me from immediately thinking of simply switching databases like that for testing purposes.

Any other tips on how you test and develop your custom themes would be much appreciated in case I’m missing other useful theme design and development tips and tricks.

WP install and import screenshots from:

• http://www.shinephp.com/wordpress-3-0-installation/
• http://www.ivanwalsh.com/technical-writing-tips-tools/how-to-import-a-wordpress-blog-into-another-wordpress-blog/3231/