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.

svn switch http://svn.automattic.com/wordpress/tags/2.8/

Once that was complete, I logged into my admin panel and completed the DB upgrade, then I had to check some plugins. I had these problems/changes:

• TinyMCE Advanced had an update available, so I did that,
• One Click Plugin Updater seems to clash with the new Plugins page, and I don’t really need it now anyway since its functionality is in core, so I deactivated it and then deleted it
• IntenseDebate seems to clash with some of the JavaScript now used in the admin, but I work with those guys now, so I’m working on a new version of the plugin to address those issues! My comments are a bit ugly while I deal with this, but I figure that’s a good motivation to get it done ASAP.

Have you upgraded yet?

Part of add the delete functionality required me to write out the (very, very simple) plugin API for adding and removing tools to the toolbar. I may be a little biased (and not at all modest), but I think it’s pretty cool More about plugins later – but basically webpad 3.0 supports plugins through a “My Plugins” section, so hopefully people might even write some new features for it, allowing access to more external sources of text to edit!

So, I can hear you asking; what’s left? Well:

1. MovableType Support (open, edit, create, delete)
2. WordPress Support (ditto)
3. Update a few interface niceties (like the ‘About webpad’ dialog)
4. Write the new Help Manual, which is a lot different to the last version, and will be a lot bigger
5. Update the webpad project page
6. Fix a scrolling bug in Mozilla (fixed on PC, needs a tweak for Mac)
7. Pretty up some of the error messages
8. Thorough system testing before release
9. Packaging up with some instructions on installation

Oh yeah, and of course, I’m doing the whole dog-food eating thing and as usual, this is posted with the very latest version of webpad (from FireFox), using a couple of the tools and bits and pieces and it’s all looking good.