Jake Intel

The folks working on the next WordPress update have lofty ambitions for their new, block-based content editor known as Gutenberg. It will be standard with the release of WordPress 5.0, currently scheduled for late November 2018. The goal is to create a new web page editing interface that will provide the average user more ability to create rich page layouts.

One of the core limitations of traditional WordPress has been its reliance on a single field for nearly all of the content associated with each post (i.e., web page). To engineer more sophisticated content structures, many website programmers and plugin developers have leveraged “metaboxes” to add individual custom fields to posts. These fields are used not only to create more complex page layouts, but also make data available on a more granular basis throughout a site, thereby significantly extending the capabilities of WordPress.

In this article we will focus on how post content meta is handled with the new Gutenberg paradigm. Regardless of whether you tend to rely on trusted plugins like Advanced Custom Fields to handle your post meta, or you prefer to roll your own metaboxes, you’re going to want to become familiar with the Gutenberg way of handling these important bits of information.

Two Uses for Meta

The needs for meta data vary, but they tend to boil down to two major categories of use. The first use case addresses the need for structure within a page, post or custom type. Meta values of this kind are used along with custom page templates to place information in specific layouts, something that would be tedious to repeat from post-to-post using the single content field currently provided by the WordPress classic editor.

The second use case for applying meta values to a post occurs when those values are needed in more than one place across the site. For example, imagine a real estate site that has a carousel of featured properties on the homepage. You’ll want the price and perhaps a few other details about each property displayed in the carousel. This scenario would be a nightmare if those values had to be scraped out of the content field from each post. So instead they are stored individually in the database as post meta and retrieved with the get_post_meta() function when and where needed.

Meta the Gutenberg Way

So how does Gutenberg handle these two use cases? And will it make your life easier when dealing with post meta?

With regard to the need for structure, the answer is simple. For the most part, you should no longer need these values to be stored as meta. Using Gutenberg blocks rather than a single content input means that important pieces of content can be edited individually and placed right where they belong on the page. As an added bonus, this means that you’ll probably find you need fewer custom-built page templates, as blocks will provide much of the layout needed to place these values how and where you want them.

The second use case deals with values that you want to use outside of the page or post to which they are applied. You’re still going to need that value stored separately in the database — but don’t lament the loss of your metaboxes just yet! Once you learn the ins and outs of creating your own custom blocks, you’ll be able to control your metadata through them too.

Add Meta to a Gutenberg Block

Gutenberg attributes are used to define what values can be added to a particular block and how those values are to be handled. Check out the section on attributes in the Gutenberg handbook to learn about how they are implemented in a block. Each attribute has a source, which determines how the value is extracted from the rest of the page content. Applying a source of “meta” to an attribute is the first of two steps you’ll need to take in order to move that value out of the compiled content and into its own post meta record in the database.

The code below shows the attributes array of a block with the single attribute of “price”. The source for this attribute is “meta” which means the value will be placed in the database instead of within page content. Following the source parameter is the meta parameter, the value of which determines the name of the meta field.

attributes: {
    price: {
        type: 'string',
        source: 'meta',
        meta: 'price'
    },
},

Step two involves getting the server to do its part. As blocks are typically rendered with javascript on the client side, we need some PHP to get our meta values into the database. You can do this by adding an action hook to your functions.php file.

function gutenberg_my_block_init() {
    register_meta( 'post', 'price', array(
        'show_in_rest' => true,
    ) );
}
add_action( 'init', 'gutenberg_my_block_init' );

And that’s really all there is to it. Your meta values will now be available for use across the site. To familiarize yourself further with this process and to learn how to use these values from within other custom blocks, check out the documentation on meta found in the Gutenberg handbook, which will be an invaluable resource for developing this new skill.

What’s Next

MUCH has been written elsewhere about Gutenberg, the opportunities it represents and the challenges it may pose to pre-existing ways of working with WordPress. There is still some work to be done before it launches. But that doesn’t mean you can’t start getting your hands dirty right away.

Gutenberg already exists as a plugin that you can install in a test environment to start learning how to use the interface, build your own custom blocks and see how meta data can be integrated. We don’t recommend using this on a live site yet, but do your experimentation now so that you’ll be ready when it does launch.