If you’re a WordPress Plugin developer, you may find yourself in the unenviable position of needing to maintain one of your plugins across multiple versions of WordPress. Until recently, I maintained the IntenseDebate plugin for versions 2.5 and up of WordPress, including versions 2.6 of WPMU and up. That’s a lot of versions (10 actually, not counting minor revisions). Here are some tips I picked up/developed to try to make my life a little easier along the way.

Table Prefixes

Did you know that WordPress supports to use of a different table prefix for each installation? You may not really have noticed but it’s even an option in the wizard-style installer if you don’t manually configure your wp-config.php file during setup. This means that you can modify the names of the tables used for a specific installation of WordPress to avoid clashing with other tables that may already exist within your database. It also means that you can easily run multiple copies of WordPress from a single database by using a different table prefix on each install. I just use a different prefix for each major version of WordPress (wp28_, wp29_, wp30_) and then I can install them all in a single database and have easy access to everything.

For the sake of my own sanity, I opted to install WPMU in different databases (named according to the version I was installing) since it creates lots of tables.

Multiple Installs

Apart from the table prefixes trick, I like to use the version of the install as the name of the blog (“WordPress 2.9”) so that I always know what I’m looking at. I’ll set all of the admin accounts to the same details, and then import the same set of test content (via a WordPress Export/Import). That gives me a consistent environment to work from.

Symlinks

So now you have a bunch of different installations of WordPress, all using the same database (although different tables). You need to get your code in place so that you can test it on each version. One option would be to put a copy of your plugin in each wp-content/plugins directory, but then that quickly gets out of control if you make changes to any of them while you’re debugging/developing. A better option is to put your code in one place, then symlink it into location in all of your installs. I use something like this:

ln -ns ../../../dev/pluginname pluginname

(executed from within the wp-content/plugins directory of each install, and assuming a directory called dev/pluginname containing the plugin, at the same top level as all of your installations). This links wp-content/plugins/pluginname from each install back to the same set of code, and allows you to modify it in any of them and have that change be reflected in them all.

Capability Checks

Rather than checking for a specific version of WordPress (which is actually easy to do), I usually prefer to test for specific functionality. For example, to see if you can use the WP_Http() API (introduced back in WP 2.7), you could do something like this:

if ( function_exists( 'wp_remote_get' ) ) {
    // Can use WP_Http()
}

If you really want to check for a version of WordPress, then you probably want something like this (note that the $wpmu_version check in this case is to make sure we’re NOT using WPMU). You might need to declare it as global if you’re doing this within a function:

if ( version_compare( get_bloginfo( 'version' ), '2.7', '<' ) && empty( $wpmu_version ) ) {
    // do stuff
}

Tracking Major Changes

The other big issue is keeping track of what changes from version to version and how that might affect your plugins. Probably the easiest way to at least get a cursory glance at this is using the announcement pages on the Codex. For example, here is the announcement page for Version 3.0. If you need more detail, you can also try getting a report from Trac, like this one which covers everything in 3.0. Combining these, you can come up with a bit of a list of things that are likely to affect your plugin, depending on exactly what it does. As usual, the more you stick to the documented APIs, the less likely that your plugin will break over time. I personally use this to find new/better ways of doing things and harnessing new features that are introduced more than anything else.