Testing Plugins and Themes on Multiple WordPress Versions

If you’re a theme or plugin developer, it’s essential to support at least WordPress 3.3+. Smaller sites and blogs have an easier time upgrading to the latest WP version. However, upgrading large corporate sites becomes a major operation because the codebase is usually collaborative and has many dependencies built on earlier versions. With that said, it’s good to be inclusive of those users as well by adding backwards compatibility.

I typically test my plugins on the major releases. If users have issues on minor releases, I’ll generate an install for that version on my local environment and debug from there.

On my local, I surface all WP versions under one domain, whatever.com. Each WP version is a subdomain. So, WP 3.3 is found at 3.3.whatever.com and so on. It’s easy to copy a vhost and a /etc/hosts entry for a new WP instance or use a software like MAMP Pro to do it for you. Another approach is to place each version in a subfolder off the domain docroot. You can find all of the WordPress versions at the core SVN repo. If you want to use GIT, you can find a synced SVN > GIT repo here. Simply fetch whatever branch corresponds to your desired version number.

To install my plugin, I checkout the trunk of my plugin into the plugins folder of each WP version. I use Versions App and title the bookmark as the version number. If you’re on Windows, you can use TortoiseSVN as well. I find SVN to be annoying on the command line, so I use a GUI. To note, the reason I use trunk checkouts and not symlinks for my plugin folders is because symlinks don’t play nice with plugins_url() from my experience. It’s a good practice to stay away from using constants directly to circumvent the symlinks issue and use API functions instead.

I keep all of tagged versions of WP in one database with different table prefixes. This keeps everything nice and tidy and in one place. For example, WP 3.3 becomes wp_33_ and WP 3.4.2 becomes wp_342_. Another benefit to this approach is you don’t have to create a new database each time you want to spawn a new WP instance. I also title each WP instance site title with the version number as another indicator of which version I’m developing.

Finally, I keep a copy of the latest nightly build to test for future compatibility as well. To get the latest nightly, simply do a SVN checkout of WP trunk.