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.

Get file permissions, owner and group with PHP

Here are a few functions to help you when interacting with files:

Find the owner of a file:
An array of information about the owner is returned.

function foo_get_file_ownership($file){
	$stat = stat($file);
		$group = posix_getgrgid($stat[5]);
		$user = posix_getpwuid($stat[4]);
		return compact('user', 'group');
		return false;

Get the four digit file permissions number:
A permissions string is returned. Example: 0755

function foo_get_file_perms($file){
	return substr(sprintf('%o', fileperms($file)), -4);

Convert permissions number to Read Write eXecute format:
Directory Example: 0755 converts to drwxr-xr-x
File Example: 0664 coverts to -rw-rw-r–

function foo_convert_perms_to_rwx($perms, $file){
	$rwx = array(
	$type = is_dir($file) ? 'd' : '-';
	$owner = $perms[1];
	$group = $perms[2];
	$public = $perms[3];
	return $type.$rwx[$owner].$rwx[$group].$rwx[$public];

Debug This – WordPress Plugin

I’m excited to release my latest plugin. It’s a great tool for developers to debug their plugins or themes. Debug This comes with 49 different debug modes to help expose specific raw data when you need it. The benefit of Debug This is the time saved from hardcoding var_dump or print_r to see WP globals, queried objects, etc… Developers can easily add new debug modes from their theme or plugin.

Debug This utilizes the WordPress Admin bar for mode navigation. All mode navigation links are relative to whatever page/post you are viewing. Custom modes and be nested in grouped drop-downs.

I really like the Debug Bar plugin and I’ve created several extensions for my personal use. However, there are times when I want to see the raw data in a full-screen width. Once you click a Debug This mode, it takes you to an immersive full-width experience.

Finally, DT renders the page first before displaying the debug mode. Custom debug extensions can analyze the rendered page with the supplied buffer in their callback function. This allows for intricate debugging that no other plugin offers (that I know of).

Update: If Debug This doesn’t suit your needs, I came across another great debug plugin called Debug Objects.

Debug This

WordPress Plugin11KDownloadsDownload Now »

Audit Post Attachments

One of the more annoying things about WordPress is the inability to see how many files are attached to a post without invoking the media upload area. Here’s a plugin I whipped up to report posts and their attachments by post type. Enjoy!

WordPress Remove Attachment Rows Where File Doesn’t Exist

Here’s a nifty script I cooked up tonight. This basically looks through all of your attachments and see if the associated real files exist on the server. If they don’t, the attachment database row is deleted. I realize this isn’t the most useful tool for everyday use. It was built for a one-off use case and I didn’t want this script to get dusty in my local files. So, here it is for your consumption or truncation!