This article is about a new WordPress plug-in that I have just released in ALPHA.  Download and use at your own risk: it is far from finished.

I love WordPress. But writing plug-ins for WordPress sucks. There are a lot of plug-ins out there, all of them using WordPress’ smashing plugin API to create some great functionality. But at the end of the day, the native API leaves me wanting more.

I want to develop WordPress plug-ins using MVC principles. I want for security to be easy to remember and easy to implement. I want to be able to write plug-ins that provide body content on the front-end with minimal modification to my themes. I want to be able to utilize AJAX without implementing esoteric, hack-like features in my plug-in.

And I don’t want to have to refer to the gigantic Codex every time I need to one-off a new project: give me a manageable API.

With these goals in mind, I have written a plug-in for WordPress that creates a new plug-in framework. This framework, based on CodeIgniter, has far exceeded my personal expectations for the project (and it’s still in alpha!). Not only did I manage to satisfy my own requirements, I managed to do so without hacking either of the proven stacks, all while taking advantage of some very cool features of PHP 5 (annotations).

I named the plugin WP-CI.

A bit on how it works

Explaining the nuances of MVC development in CodeIgniter is beyond the scope of this article, and with good reason: they have some great documentation.  But for the uninitiated, know this: CodeIgniter divides application functionality into Controllers and Actions.  Each Controller gets its own PHP file, and each public function on the Controller is exposed to the Web as an Action – discreet units of application functionality, each with a specific purpose (like display a form, save some data, delete a record, or return some JSON).

In WP-CI, each controller file (stored in ./application/controllers) is, in effect, a special WordPress plug-in that I call a WPCI Plug-in.  Within the body of each PHP file you have complete access to the entire WordPress API, as well as complete access to the CodeIgniter framework.

To learn more about the structure of a WP-CI file, download the latest release and have a look at ./application/controllers/hellosparky.php.  A more complicated example exists in the WPCI Plug-in Administrator, which is itself a WPCI Plug-in.

Using annotations

Once again, for the uninitiated, annotations (in PHP) are special comments added at various locations in a PHP file.  This is a concept specific to PHP’s object-oriented programming syntax, and allows developers to add meta-data to class definitions.

WP-CI makes extensive use of this PHP 5 feature, making this framework incompatible with PHP 4 (sorry guys and gals: welcome to the future).

Annotations look like this

/**
 * @user_can(edit_plugins)
 */
class Admin extends WPCI_Controller {
  function index() { /* ... */ }
}

The annotation featured above, @user_can(edit_plugins), is a cue to our framework to require any user accessing this plug-in to have the built-in WordPress capability of editing plug-ins.  (This requirement implies a user be an administrator.  You can read more about user capabilities in the WordPress Codex.)

There are other annotations too, like @menu and @submenu which serve to create administrative menus and menu items from your plug-in actions.

For more examples of annotations in action, have a look at the WPCI Plug-in Administrator, ./application/controllers/admin.php.

Early adopters beware

The current release is ALPHA and so you should expect the core API to change with the next release, and possibly even break your application in complicated ways. You have been warned.

This software is not warranted in any way.

So, have you tried it out yet?