What is Gutenberg?

Gutenberg is a new editing experience coming to WordPress in the release 5.0, probably in a month or two.

But, above all, Gutenberg is Javascript. More specifically, Gutenberg is (made with) React. And yes, this is why I wrote editing experience and not just editor: Gutenberg is a SPA (Single Page Application) inside WordPress, this means, by the way, it uses Ajax calls to drive any interaction.

This is huge.

Remember when in 2015 Matt Mullenweg said to learn Javascript deeply? Gutenberg is the natural following of that statement.

Huge change, indeed. But how will it affect existing projects? The answer is, less than you think. Almost everything will work fine. The entire content of the post is still saved to the post_content column in the wp_posts table. What will change is the way content will be thought about.

But let’s dive a little bit deeper!

Metaboxes

They will work with almost no pain.

Metaboxes in WordPress are defined invoking the add_meta_boxes hook, that fires after all built-in metaboxes have been added. Since in Gutenberg there are no more built-in metaboxes – and, to be honest, no more PHP executed – the add_meta_boxes hook is now linked to the admin_head hook, that is triggered in head section for all admin pages. This way, we can still register metaboxes without any problem.

What about saving content from our metaboxes? Gutenberg, again, has it covered.

Remember that when defining a metabox, we usually tie the function to save the content to the save_post hook, as shown in the following example from WordPress Codex:

function wporg_save_postdata($post_id)
{
    if (array_key_exists('wporg_field', $_POST)) {
        update_post_meta(
            $post_id,
            '_wporg_meta_key',
            $_POST['wporg_field']
        );
    }
}

add_action('save_post', 'wporg_save_postdata');

What then happens is that, when we hit the “Publish” or “Update” button, the post form is submitted, WordPress saves the data and right after triggers the save_post hook. This is when metaboxes content is saved in the wp_postmeta table.

With Gutenberg, however, all of this doesn’t happen at all: data is saved using JavaScript and the REST API. So, Gutenberg collects the values from all the metaboxes and sends a POST requests to post.php. This acts like a submit post request, and so all linked hooks are triggered as always.

For a more detailed description of what exactly happens with React during all of this, you can read [this reference].

Custom Post Types

They too will work with almost no pain.
Almost, because you need to make sure you have show_in_rest set to true , as a register_post_type argument.

function create_post_type() {
  register_post_type( 'acme_product',
    array(
      'labels' => array(
        'name' => __( 'Products' ),
        'singular_name' => __( 'Product' )
      ),
      'public' => true,
      'has_archive' => true,
      'show_in_rest' => true,
    )
  );
}

add_action( 'init', 'create_post_type' );

Blocks

The purpose of this post is to describe how metaboxes and custom post types will work with Gutenberg and to reassure that, after all, they will work. This has not been always so clear during Gutenberg development, but at this point we can relax.

The fact that metaboxes will be supported does not, however, mean that they will still be the future way to manage content in WordPress. The Codex clearly suggests to convert them to blocks. They are the new content building pillars, and we’ll need to come to terms with it.

The main thing to know about the blocks VS metaboxes topic is that block content is saved in the post_content column in the wp_posts table and there’s currently no way to save it to wp_postmeta. This means that we can’t retrieve data associated to a post from another post. To solve this problem we can, however, take advantage of the WordPress REST API and get from there everything we need almost hassle-free!