Recently, I was having a conversation with a friend about some of the various ways to serialize the values that are present within a collection of meta boxes that are defined for any type of post – be it a post, page, or a custom post type – within WordPress.
For example, imagine that you have a custom post type that has, say, four different meta boxes that are available below the main content area.
These meta boxes can be laid out in one of two ways:
- The meta boxes can be listed individually with each meta box having its own set of values. Think of WordPress’ Excerpt field, Discussion field, and and Sharing Field.
- The meta boxes can all be contained within a single container accessible by individual tabs.
The question is does the way that the meta boxes are displayed influence how the values are serialized in the database?
How to Save Meta Box Data
To be clear, I want to lay out the ways in which multiple meta boxes can be displayed.
As mentioned above, there’s the standard way in which WordPress displays its default meta boxes where each piece of information is contained within its own meta box.
But then it’s also possible to display multiple options within a single box and display the contents in, say, a tabbed interface like this:
In this particular post, I’m not making a case for which is better or which is not – I think they each lend themselves to their own use cases – but I do think the way that we serialize information depends on how we’re displaying in our meta boxes.
Standard Meta Boxes
When it comes to serializing information within a standard meta box, I tend to treat each element as its own set of meta data.
For example, if I have a meta box with a single
textarea, then I’m going to serialize the value of that text area into a single meta key and meta value. That’s a given.
But let’s say I have a
input[type="text"], and an
input[type="checkbox"], then am I going to serialize those values as an array or as their own rows in the database? Generally speaking, I still lean in the direction of serializing each value into its own row in the data base (that is, each element into its own set of key or values).
I realize that there’s an argument here for treat each element in the meta box as an array, but some point, I think that you get into the territory of deciding whether or not break out each option into their own meta boxes or into a tabbed view.
Tabbed Meta Boxes
When it comes to tabbed meta boxes, I tend to take a different approach because although everything contained within the meta box is still part of that single meta box, the options are contained within their own tabs.
That is to say, the options are logically grouped in such a way that although they may fall under the same umbrella of options, they are under another set of similar options in that they are part of the options contained within a tab.
When it comes to serializing the options in tabbed meta boxes, I tend to take the approach of storing the options in an array. That is to say, let’s say that the meta box contained four tabs. In that situation, then there will be four rows of meta data associated with the given post, and then each row will store the array of values that are represented by each individual tab.
Then Again, It Is Just an Opinion
To me, it all comes down to having your data model map to your user interface as much as possible.
I realize that this approach is but one of the various options that are available; however, this is how I’ve been approaching development on a number of contract projects, and how I’ve found it to easiest to work with the data from both a serialization perspective and a code perspective such that the code that retrieves the information reads in such a way that it maps to the user interface in the administration panel.
But that’s just my take. If you’ve got alternative ways to saving the information based on the user interface, I’m all ears. I’m interested in hearing the ways in which you’ve found useful, as well.