WordPress Meta Boxes: Separating the Logic

This is the second post in a series on how to achieve simplicity with WordPress meta boxes.

In the previous post, I talked a bit about how working with WordPress meta boxes can be a bit of a hassle especially if you’re used to doing so in such a way the keeps all of the logic contained within a single file and a handful functions.

For example, if you’re working on a theme, then it’s likely that you’ve got a set of functions declared either in your functions.php file or file referenced by said file that is responsible for making a call to add_meta_box and all of the necessary arguments for rendering the meta box.

If you’re working on a plugin, it’s likely that this isn’t all together different; however, you may be approaching this from an object-oriented perspective. If that’s the case, then you may have a similar setup as above which isn’t really that different except you’re using classes and functions.

WordPress Meta Boxes

But here’s the thing: If you’re approaching the implementation of WordPress meta boxes as a straightforward way to introduce additional (albeit powerful) options into the WordPress dashboard, but you aren’t separating the logic, then you’re making the products that you’re building significantly more difficult to maintain over time.

And it doesn’t have to be that way.

Separating the Logic

In the previous article, I mentioned that there are different components to the logic that into go into constructing a WordPress Meta Box:

The Server-Side Logic
The Presentation Logic

In short, the server-side logic is responsible for any and all domain logic that communicates with WordPress and/or provides the code necessary for processing the serialization, validation, and business logic (though, really, a strong case can be made for abstracting that logic into its own component, but I digress for now).

The presentation logic, then, is predominately made up of markup that may or may not be styled, that may or may not have JavaScript dependencies, but that most definitely interfaces with the server-side logic.

At the very least, it will be displaying values returned from the server. In the more complex cases, it will be changing data based on what the user inputs, how the server-side code processes it, and what’s returned following the processing.

But regardless of what your setup is, remember that the whole point to this is to introduce simplicity into the potentially complex nature of working with WordPress meta boxes so that:

The code is easier to understand,
Holds up well overtime,
Is easy to read,
Maintains a strong separation of concerns,
And can be easily changed and modified by other contributors.

Naturally, this raises the question of how do we go about doing this?

Defining The Server-Side Logic

In this case, you’re likely to hear server-side logic but used synonymously with business logic. Though I personally don’t equate the two, I have seen it done. For purposes of this example, we’re going to be referring to it as the server-side logic because, y’know, that’s what it is.

In order to make this as easy as possible, I’m going to be introducing this code into twentyfourteen since that’s a copy of a theme that ships with WordPress and everyone has a copy of it.

Next up, let’s introduce a meta box that appears just below the post editor in the WordPress dashboard (where you’re used to see the excerpt, comments, pingbacks, and so on).

The first pass is going to look like this:

Acme Meta Box Example

But we’ll obviously be making this a bit more complex over the next few articles.

In order to make this happen, you need to define the following code (doing so in functions.php is fine):

This is about as basic as it gets when it comes to defining a meta box. All of the arguments are well-documented in the Codex, but the primary argument of concern is the callback that is used to render the display the content of the meta box.

In the code above, this function is named as acme_render_meta_box. Of course, in this example, it doesn’t do much.

Defining the Presentation Logic

Right now, the function responsible for rendering the presentation of the meta box looks like this:

This particular example is almost not even worth showing, is it? But in order to show where we’re headed, we need to go ahead and get the necessary files in place.

So rather than actually keep the display logic within the context of the function, let’s go ahead and do a couple of steps that will make the follow up article much easier to follow.

First, let’s create a file in the root of the theme directory called acme-meta-box-display.php and in the content of the file, let’s place a simple string: “TODO.”

Then, we’ll revisit the acme_render_meta_box function and update it to look like the following function:

Simply put, we’ve taken the first step is breaking the logic responsible for displaying the content of the meta box into its own file and telling the server-side logic to import the file that will be responsible for rendering the data.

But What About Rendering the Data?

In order to actually render the meta box’s presentation, we need to actually populate the code with something that’s more functional than a simple “TODO.”

On top of that, there’s a third component – a helper file – that can make certain operations much easier (such as making sure that we have permissions actually save the options) that can go along way to continue separating the concerns.

To that end, I’m working to keep each post in the series focused on exactly that – we’ve broken up the server-side logic and the presentation logic.

As I continue with this series, we’ll take a look at making the presentation logic a bit more advanced, as well as take a look at how we can incorporate yet-another-file to help us keep our files and/or functions focused on a single task.