Organising WordPress plugin/theme code: Part 2 – Single Class

Last week we looked at the most common method of organising WordPress code. Today we’ll look at the method many consider the one and only true way of coding WordPress plugins – namely, the Single Class method.

People advocate this method for many reasons, some of them valid, some of them not so much. The few main reasons are:

  • Lack of conflicts with other plugins
  • Neater function names, and
  • Multiple instances.

Before we jump into an analysis of those merits, and also of the disadvantages of this style of programming, let’s take a look at our friend Bacon Widgets Ultimate, this time in a much leaner, one-file flavour. Grab it here to view in your favourite text editor. Click here if you missed last week’s version.

 

Serve with a pinch of salt…

OK, so the first thing you’ll notice here is that the whole thing is wrapped in a class, in this case BaconWidgetsUltimate. I’m not going to give you a tutorial on how to write a plugin in a class, there are plenty of them out there already. What I am going to give you is reasons why you would do it. Ready? Let’s go.

Whoop whoop, bacon fat and fries!

Obviously there must be plenty of good parts to this approach, seeing as it’s the one people keep advocating as the one you should use. Here’s a quick rundown of the main ones:

Lack of conflicts

This one’s pretty obvious – if you package your plugin in a class, you run a much smaller chance of getting naming conflicts with other people’s plugins. Sure, they could still name their class the same as yours, but that’s why we check for the class’s existence before declaring it. However, what’s more likely, that someone else will make a class called BaconWidgetsUltimate, or that they will make a function called sidebar_init()?

Neater function names

This one also flows directly from the lack of function prefixes – you’re much more free to name your functions whatever you like, which certainly makes for a more pleasant development process, as you don’t have to keep re-typing all those function prefixes. It makes keeping track of your functions easier, and lets you concentrate less on naming a function, and more on writing it.

Multiple instances

This one is only applicable to a certain category of plugins – namely ones that are designed to be used more than once in a page/post. Having your plugin in a class allows you to create multiple instances of it, each with separate states and data – you don’t run the risk of cross-contaminating variables like you would if you used the prefixed function approach to this. Keep in mind that it’s likely that you’ll need a manager class that creates these instances in response to a stimulus (for example a shortcode) and keeps track of them.

Waah, my bacon’s burnt!

So everything’s all great, but there has to be a catch, right? Of course. As well as the many advantages this method has, it also has a big shortcoming.

PHP, unfortunately, lacks partial classes. Therefore, if you put your plugin in a class, your entire plugin has to be in one file. This, obviously, means that you can’t split your plugin between multiple files, which makes it a pain to find a specific piece of functionality to work on, and even more awkward to track down bugs. This is somewhat alleviated by the ability to use more descriptive function names, but it still doesn’t compare to the convenience of splitting your code across multiple files and folders. This becomes even more of a nuisance if there are multiple people working on the codebase – a good source control system can help here, but it’s still much more convenient to have one person working on a file at a time.

Another thing that this approach prevents you from doing is easily disabling or swapping out bits of the codebase – in the case of prefixed functions, it’s sometimes just a matter of changing/deleting an include. It also makes working on a few parts of the code simultaneously quite annoying – a good text editor with a split-view functionality can help here, but it’s still handier to be able to have the code spread over multiple smaller files, which don’t require 30 seconds of scrolling to get to the part of code you’re looking for.

However this shortcomingcan be addressed, and this method can be improved upon. Stay tuned until next Thursday for the final article in this series, where I’ll write about the best method of writing plugins, combining the advantages of both of the previous methods, as well as a short and snappy table summarising the advantages and disadvantages of all three.

Until then, stay hungry for bacon!