One of the big problems I’ve run into as a WordPress plugin developer is the diversity of PHP installations. Simply stating you only support PHP5 and greater is insufficient to ensure compatibility. Things you may take for granted in your development environment may be missing or worse, partially functional. I’ve decided to document a few of the bigger “gotchas” I’ve run into so future WordPress hackers will have a starting point for investigating problems.

Minimum PHP Version

One easy way to reduce compatibility confusion is specifying a minimum version of PHP for your WordPress plugin or widget. To do so you can use PHP’s version_compare function:

if(version_compare(PHP_VERSION, '5.0.0','<')) {
	die(sprintf('You are currently running PHP version %s and you must have at least PHP 5.0.x', PHP_VERSION));
}

Take a look at the version_compare documentation for more information.

PHP Modules

The biggest single thing to remember is that any module for PHP is optional. If you want to require something like curl, that’s great, but be aware that some non-trivial percentage of your potential users may not have it. Still want to use that module? Test for its presence during the instantiation of your plugin and die if it’s not present. This will prevent users from being able to successfully install your “broken” product if they don’t have the proper requirements.

Sometimes you’ll find yourself using functions you think are core to PHP like “mime_content_type”. This is not the case. In fact, I have frequently run into PHP installations that have no MIME detection facilities at all. Consider writing a fallback for suffix detection¹ in addition to coding for mime_content_type and the finfo_* methods.

Safe Mode and Related Problems

Another common issue is safe_mode and open_basedir. These flags enforce certain security restrictions (must have the same group as PHP when writing to a directory, can’t open files beneath the basedir, et cetera). However, they also impact some modules. For instance, using curl you can’t use CURLOPT_FOLLOWLOCATION. This will trigger the error “CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set”.

Network Communication

I’ve already talked a bit about the curl module, but you may also be tempted to use file_get_contents() assuming allow_url_fopen is enabled. This is very frequently untrue in shared hosting environments. Luckily, you don’t need to rely on curl or allow_url_fopen or write your own fsockopen() wrapper class. Instead, WordPress has integrated Snoopy into the core. Invoking it to fetch just the contents of a URL could not be easier!

require_once( ABSPATH . 'wp-includes/class-snoopy.php');
$snoopy = new Snoopy();
$result = $snoopy->fetch($url);
if($result) {
	$response = $snoopy->results;
}

Just hit up Google for the class docs to learn everything Snoopy can do for you.

There are many more where these came from, so drop your problems and solutions in the comments!

Awhile back I signed up for Skitch, a service that lets you create quick screenshots, edit them, and upload them to a variety of services. Unfortunately, despite the abundance of choices, Cloud Files support is not an option. This was irritating, and since I’ve never been one to let phrases like “ridiculous kludge” or “bereft of all sanity” deter me an idea was born. Why not write a (very) rudimentary WebDAV interface in PHP and use that to bridge to Cloud Files?
To accomplish this feat it turns out we really only need 3 distinct pieces of functionality. The actual plumbing that communicates to Cloud Files will be provided by the PHP Cloud Files API.

1. HTTP Basic Auth to capture the necessary Cloud Files credentials
2. PUT method for WebDAV
3. DELETE method for WebDAV

The code below represents the minimum subset of WebDAV functionality required to support Skitch without issues (uploading and deleting). It is nowhere near a complete WebDAV implementation. Additionally, some code (mime_types function and some logging and error handling) have been omitted. You can download the full package for use on your own server.

require('cloudfiles.php');
 
if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
	list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':',base64_decode(substr($_SERVER['HTTP_AUTHORIZATION'],6)));
}
if (!isset($_SERVER['PHP_AUTH_USER'])) {
	header('WWW-Authenticate: Basic realm="CloudFiles"');
	header('HTTP/1.1 401 Unauthorized');
	echo 'You must be authorized!';
	exit;
}
 
$auth = new CF_Authentication($_SERVER['PHP_AUTH_USER'],$_SERVER['PHP_AUTH_PW']);
try {
	$auth->authenticate();
}
catch(AuthenticationException $e) {
	echo 'CF Authentication failure';
	exit;
}
$conn = new CF_Connection($auth);
$skitch_container = $conn->create_container('skitch');
$public_uri = $skitch_container->make_public();
 
switch ($_SERVER['REQUEST_METHOD']){
	case 'DELETE':
		$file = substr($_SERVER['REQUEST_URI'] , ( strrpos($_SERVER['REQUEST_URI'], '/') + 1) ) ;
		try {
			$skitch_container->delete_object($file);
		}
		catch(NoSuchObjectException $e) {
			echo 'no such object to delete';
			exit;
		}
		catch(InvalidResponseException $e) {
			echo 'invalid response to delete request';
			exit;
		}
	break;
 
	case 'PUT':
		if($datain = fopen('php://input','r')){
			while(!@feof($datain)){
				$data .= fgets($datain,4096);
			}
			@fclose($datain);
		}
		if(isset($data)) {
			if (isset($_SERVER['PATH_INFO'])) {
				$file_name = substr($_SERVER['PATH_INFO'],1);
			}
			$mime = mime_types($file_name);
			$object = $skitch_container->create_object($file_name);
			$object->content_type = $mime;
			try {
				$object->write($data);
			}
			catch(InvalidResponseException $e) {
				echo 'Invalid response error from CF';
				exit;
			}
			catch(SyntaxException $e) {
				echo 'Syntax exception error from CF';
				exit;
			}
		}
	break;
}

To wire this up now, we have just a few steps to perform.

1. WebDAV can’t return the public base URL for the container, so use another program to create a container named “skitch”, mark it public, then copy the URL.
2. Go to the Webpost tab in Skitch and create a new account using WebDAV.
3. Set server to the server you uploaded the file to, user to your CF username, password to your API key, directory to the name of your script (potentially /path/to/script.php if it isn’t at the root of your server’s httpdocs), and finally paste the base URL (without a trailing /). A screenshot of a sample config can be seen below.

Success! I’ve been using this several weeks and haven’t had an issue, but this hack does make me wonder how usable a full blown WebDAV translation layer would be…

I am pleased to announce the initial public release of CDN Tools, my latest WordPress plugin!

What is CDN Tools?

Well, it’s a WordPress plugin that lets you load javascript files and your blog’s media (pictures, movies, audio, et cetera) to a content distribution network (CDN) to speed up page loading. You can load up all your javascript and media with a single click and then your media will be automatically sideloaded to the CDN after that. The plugin will operate totally transparently.

Do I need a CDN account?

No! You can offload prototype and jQuery to Google’s servers with this tool with just a single click. These are large libraries so moving them to Google’s bandwidth is very useful!

What if I want to remove it?

Simply deactivate the plugin and everything will revert to normal. Since CDN Tools only temporarily rewrites the URLs of your uploads, nothing is lost if you choose to stop using it.

If you’ve got a WordPress blog why not give it a shot? Download today! You can also check the version history and get more information at the plugin’s homepage.