By this, I’m not talking about third-party dependencies such as jQuery, FitVids, or whatever libraries Bootstrap, Foundation, or what’s contained within the frontend framework you opt to use when building your theme – instead, I’m talking specifically about code that we write in order to get things done within the context of our work.
When it comes to procedural programming in WordPress – think working in
functions.php – it’s expected that we’re going to be naming our functions with a unique prefix in order to prevent conflicts with other functions that may exist within plugins, third-party libraries, or even in WordPress itself.
For anyone who is just getting started in working in WordPress, this can be a hard lesson learned depending on if you’re one of the “read-the-documentation-first” type of people or not, but the thing is that the global nature of PHP mixed with the wide array of functions included in WordPress, PHP, and third-party code can lead to naming collisions that will either break the overall application or cause erratic behavior.
Most likely the former, but whatever.
title element’s text (again, a weird, contrived example, but hang in) and you opt to name your function
Clearly, this can have unintended consequences.
A Potential Solution to an Anti-Pattern
Another alternative would be to wrap all of the functions within an anonymous function that you can invoke when the script is loaded, or define your functionality within a closure.
The problem that I see with the above – and this is coming from both writing code like this myself as well as working with code from others – is that if the code has too much functionality (a weird thought, I know), then it can become really difficult to trace and to debug.
That’s exactly what we should want to avoid.
To keep the remainder of the article short, I’ll talk specifically about doing something like this in a plugin, but the idea can still be implemented within theme’s, as well.
Get Out of the Mud
For those who have been writing plugins for sometime and who are comfortable with jQuery, it’s not at all unlikely that your source code normally starts off with the
ready function, contains a ton of functionality wrapped within it.
Perhaps you then define some functions in the file that are called from within the anonymous function when the script begins its execution, but generally speaking, this is a format that’s popular.
The problem with this is that it can lead to a massive amount of code within the
$( document ).ready function as well as a number of different functions defined throughout the file that are invoked at different times.
Whatever the case, it can quickly start to feel like a big ball of mud. Ew.
A Potential Pattern
I’ll show some example code in a minute, but all of this has got me thinking about creating a definitive pattern that can be reused whenever we’re working on WordPress plugins (or themes). That is, there’s a bit of structure that can be reused and followed in order to prevent anti-patterns, to prevent spaghetti code, to prevent confusion when working with the code, and to prevent naming conventions.
Here’s how I’ve been thinking about it in its very simplest form:
public.jsthat’s responsible for, say, defining the
readyfunction, instantiating the rest of the variables that we need an setting things in motion.
wpnamespace. Instead, go with
Acmeor whatever the name of your company or plugin is).
- A Unique Object Name. Within the context of writing plugins, let’s say that you’re working on a widget – then perhaps the unique object name would be the name of the widget and it would be defined within the namespace.
The Implementation of the Pattern
So, practically, what would this look like?
Yesterday, I shared that I’ve been working on a really simple plugin. In the codebase or this plugin, I decided to put the aforementioned approach to work and ended up with something like this.
Obviously, I’ve truncated the code for ease of readability but the point remains. I’ll show the implementation of this particular pattern in reverse, because I think it makes more sense to read it that way:
First, the unique object. Note that this is contained within an outer object, one that serves as a namespace:
Secondly, the namespace:
And finally, the bootstrap file:
Is This Enough?
If not, I’m all for discussion as this is something that I’d love to improve if for no other reason than personally get better at what I’m doing. To that end, I’m open to whatever comments you have to offer about the above approach.
Right now, though, this is what I’ve got.