I always run one trunk build or another of WordPress. Generally every few weeks I’ll svn up just to make sure I’ve got the latest code. Most of the time I don’t have any problems…

Tonight was the exception. As soon as I updated the codebase my blog was returning the white screen of death. A quick look at the Apache error log for my vhost showed that there was a duplicate user_can function in the Admin SSL plugin. Duplicate functions throw a fatal PHP error and kill the entire blog…

The guilty bit of code was two simple lines in the plugin:

function user_can($what){ # checks if function exists before calling it
	return(function_exists("current_user_can") ? current_user_can($what) : false); }

Basically all this does is, presumably, help the plugin work in older versions of WordPress where the current_user_can function does not exist. I don’t know what version that would be or if the rest of the plugin would work, but we’ll give them the benefit of the doubt.

So the plugin declares a user_can() function that will always work instead of testing to see if current_user_can exists every time they want to make a permissions check. Great idea in theory. In practice, not so much.

As of r16209, WordPress includes a user_can function of its own. Because the WordPress developers, in their infinite wisdom, see no use in putting methods in logical classes (in Habari the same functionality is provided through either the can() method on a User object or the ACL::user_can() static method) everything is in the global scope. When your plugin provides functions that have generic names you risk naming collisions later on when a piece of code out of your control changes.

So the common solution is to either adopt a complex and lengthy naming convention for all methods in your plugin (ie: admin_ssl_user_can()) or simply put all your code into a class:

class AdminSSL {
	public function user_can ( $what ) {
		return ( function_exists("current_user_can") ? current_user_can($what) : false );
	}
}

The latter method is more forward-thinking and obviously the cleaner and significantly more preferred way… that is, if you’re developing with developers who care about the quality of their work.

The best part? The Admin SSL plugin doesn’t even use their custom problem-causing user_can method most places, they perform the function_exists() check and call current_user_can manually instead.