I’ve fallen into a routine when building WordPress plugins; a few general rules are:

• Avoid creating new PHP globals.
• Avoid executing PHP code in the global scope.
• Generous use of Actions and Filters.

I’ve decided to name the pattern I use Slash, which stands for:

• Singletons
• Loaders
• Actions
• Screens
• Handlers

Singletons

I didn’t love singletons in PHP at first, and I’m still not convinced they are ideal, but they work well at avoiding yet-another-WordPress-related Global variable. bbPress is a good example.

The benefit of using PHP singleton’s in WordPress is they don’t create an additional PHP global to worry about getting stomped. They also allow your plugin to always exist in memory, without another plugin being able to unset it, while still working like a traditional PHP class.

Loaders

These are basically bootstrap functions. Their only responsibility is to jumpstart a singleton, and put it in a place for easy access. See the bbpress() function in the above bbPress link. Loaders allow you to reference your Singleton without needing to use a global variable, or pass an instance around into functions and method calls. Used like: bbpress()->foo = 'bar';

Actions

By hooking everything into WordPress core actions, bbPress never runs any code inline in the global scope, other than the above loader function. Also, bbPress comes with it’s own sub-actions to piggyback WordPress’s, making writing bbPress specific plugins safe and simple.

• Actions
• Sub-Actions

This also includes WordPress Filters. The major difference with Filters is that they are generally more risky to use; you have to assume other plugins are already using them, and those same plugins aren’t designed to handle whatever you’re trying to do too.

Screens

Derived from BuddyPress, screens are basically “Views” if you’re familiar with MVC. They are how we output markup to the browser from inside PHP, WordPress, and our plugins. Screens can be modular (again, see bbPress) allowing them to work with shortcodes, widgets, and template parts. Screens typically contain all of the translatable strings and HTML markup, and sanitize any variables for output.

Handlers

Handlers are the equivalent of controllers in MVC. They are responsible for containing the logic that comes from requests like forms, AJAX, JSON, XML-RPC, etc… They “handle” whatever the request is, performing capability checks, validating input data, and also checking for nonces.

Why not use MVC?

Honestly? No reason. Slash isn’t intended to compete or replace anything, and like anything else it’s constantly evolved over time to become what it is today, and will likely change tomorrow too. MVC and other architectures work really well, and Slash is just an approach that’s worked well for me. Putting a name on the routine should help it grow, or educate me on better approaches.

It’s also worth noting that Slash isn’t really anything new, but rather an assembly of separate methodologies combined into a single process that helps me translate my thoughts into code.

The best way to see the Slash approach in action is to browse through the BuddyPress and bbPress codebases. If you’re an experienced developer, I’m always looking for feedback. If you’re just starting out, maybe give the Slash approach a try. Take what’s in bbPress and remix it for your own use, and let me know how it goes.