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

For anyone who has does any kind of work with WordPress meta boxes, you know that it generally consists of the following steps:

  1. Define the meta box
  2. Define the callback functions responsible for displaying the markup

Pretty simple, isn’t it?

Of course if you’re looking to introduce a more advanced functionality into your meta box then you’re likely going to want to introduce stylesheets, JavaScript dependencies, nonce values, and perhaps even tabs to logically separate the options.

Given the fact that I’ve recently looked at some of the various ways to save data in WordPress meta boxes, I thought it might be work sharing one way to help separate the business logic from the presentation logic as it relates to incorporating WordPress meta boxes either in themes or plugins.

WordPress Meta Boxes

Whether or not you’re working with the standard post types or custom post types, introducing meta boxes into the WordPress dashboard is a relatively simple thing to do; however, it makes for introducing some really powerful (yet complex) functionality.

Aiming for Simplicity

I think that most people are familiar with this Steve Jobs quote:

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

I’m certainly not comparing introducing a meta box into building a company that’s revolutionized the modern world, but I am trying to make a point that keeping things as simple as possible despite their complex operations can be challenging.

In fact, I’d argue that it’s one of the more challenging (and rewarding) aspects of modern web development. And though there are a number of ways in which this is applicable and can be discussed, one way that costs very little time goes back to a simple programming principle: Separation of Concerns.

To be clear, I’m talking about separating the code that goes into a meta box into two, possibly three, distinct areas:

  1. The Server-Side Logic
  2. The Presentation View
  3. The Helper Logic

In an effort to keep these posts on the shorter (and more focused on a topic at a time), I’m going to span the discussion over three different posts.

What Is Business Logic?

Before I actually talk about the sever-side code, the term business logic, as it relates to computer programming, has to do with the code or functionality that’s strictly related to solving a particular aspect of the problem domain.

There’s a difference in server-side code and in business logic:

  • Server side code contains any and all code that runs on the server that makes up part of the program. This can include any custom algorithms or code modules for doing something as simple as enqueuing JavaScript to something more complex like managing cron jobs.
  • Business logic is code that is directly related to the problem domain at hand and is responsible providing all of the code necessary to process and resolve the core problem.

The terms aren’t synonymous. Server-side code includes the business logic.

How Does This Relate to Meta Boxes?

In the the context of WordPress meta boxes, we’re looking at a number of different things:

  • Registering the meta box
  • Including the dependencies
  • Rendering the view
  • Setting up the code for serializing information
  • Adding any code responsible for processing the business logic the meta box represents

Make sense?

When you look at the code responsible for introducing a meta box, you notice that it accepts a number of different arguments one of which includes the callback function for rendering the meta box.

It’s not at all uncommon to see WordPress code that creates meta boxes and renders them by building a huge PHP string that contains all of the markup responsible for displaying the presentation of the meta box.

But this presents a number of problems:

  • The code is doing more than one thing
  • A large string of PHP is harder to maintain
  • It’s more difficult to work with the code over time
  • It makes it harder to introduce and work with helper functions
  • …and I’m sure there is more that I’ve missed

So in order to help make this process easier, I’m of the mindset that all code responsible for rendering the display of the meta box – whether or not it contains a tabbed interface – should be separated into separate files.

By this, I mean that:

  • There should be a core file responsible for hooking into `add_meta_boxes`,
  • A function that serves as a callback in order to render the view,
  • A file that actually renders the presentation (and optionally calls on helper functions),
  • And an optional class or collection of functions that serve to make the code more readable.

For example, here’s the basic file organization for a meta box with a single view:

Organizing files for a simple meta box

Organizing files for a simple meta box

And if the meta box includes a tabbed interface, then it should include a break down of even more files:

Organizing Files for a Tabbed Interface

Organizing Files for a Tabbed Interface


Perhaps this seems like a bit of micromanagement over something as simple as a meta box, but recall what was said about simplicity at the beginning of the article.


Micromanagement, this is not.

One of the problems with modern WordPress projects is that they try to solve a large problem, but they don’t necessarily try to break the problem down into significantly smaller, more logical components. Yo know, the whole divide-and-conquer approach.

Ultimately, we end up with god-classes, a mish-mash of languages, and code that is anything but malleable.

So starting in the next post, I plan to start sharing code as well as a rationale as to why it’s better to keep things separated in hopes that your next project will be easier to understand and more manageable that the work you’ve done previously.

And I’ll be doing this in the context of meta boxes not only because they are a common feature of WordPress projects, but also because they provide a practical approach to doing exactly this.

This Is My Problem (Not Yours)

For those of you who enjoy trying to read into something trying to figure out who or what I’m talking about, I’m can easily spell it out: Me.

This isn’t a critique on any one person, theme, or plugin.

If anything, it’s a critique on my own work, and it’s my sharing my experience in hopes that others can short cut their learning.