Gutenberg and the Future of Meta Box

In the State of the Word 2016, Matt Mullenweg said that one of three main focuses of WordPress in the next year will be the editor, which will be block-based and unify widgets, interface for shortcodes. The result is the new the Gutenberg editor, which was first introduced to the public at WordCamp Europe 2017. However, it raises many concerns with the existing meta box API. In this post, we'll take a deep look at those problems and the future of the Meta Box plugin (and similar plugins/frameworks).

What is Gutenberg?

Gutenberg is a new editor developed with the aim to improve the user experience in creating and writing content. It has been developed since early this year and first introduced to the public at the Q&A session at the WordCamp Europe 2017.

At the moment, Gutenberg is being actively developed. You can download it from WordPress.org repo and test how it works. But it's not recommended to use on the production sites.

The development team expects to create a revolution in creating content by minimizing the editor UI and making predefined content blocks. Gutenberg might replace the current TinyMCE editor and/or widgets, shortcodes interface. It aims to make the experience of writing content the same wherever you are.

The Gutenberg development might involve with other publishing platforms such as Medium or Wix. Those platforms are considered to have more advantages in composing content than WordPress (although WordPress has more things than just content). This is a huge plus for news, media or blog websites. Many people have switched to Medium instead of WordPress because of this. And Gutenberg is an effort to pull them back to WordPress.

Gutenberg is planned to be added to WordPress core in version 5.0, which is 2 major versions (4.9 and 5.0) ahead.

Gutenberg Characteristics

Before going into the problems of Gutenberg that might make developers' lives harder, let's see what it does and why it's a good reason to use Gutenberg to write your posts.

Minimalist UI

The content writing area takes most of the spaces and it previews the content similar to the frontend. All the post attributes such as published date, author, categories, tags are moved to the right-hand sidebar and minimized. The editor toolbar is completely hidden and only displayed when you editing. This UI looks similar to the distraction-free writing that WordPress used to have.

I love this minimalist UI. It helps preview the content better while writing. And what we see is almost what we will see in the frontend. Besides, removing UI elements makes the content highlighted and helps us focus on the content.

In my opinion, simplifying UI is an important part of improving writing experience.

Content is a Combination of Blocks

Gutenberg introduces a new concept for creating content - block. You can call it element if you want, but the true term is "block". Blocks for content are similar to bricks for your house. Every single element in the content like a paragraph, image, blockquote, list is block.

The whole UI of Gutenberg is built based on the concept of blocks. The developer team expects blocks help to create content easier and more homogeneous across the whole WordPress website. If you're a developer and want to create new blocks for Gutenberg, the boilerplate from Ahmad Awais is a good start.

Developed with React

Gutenberg is not developed by the combination of PHP and JavaScript as WordPress and plugins. Instead, it's developed by React and Webpack. If you don't know React, it's a JavaScript framework from Facebook to build the user interface (you can learn React here). At the moment, React is the most popular JavaScript framework.

And it's worth noting that there's a hot discussion on choosing JavaScript framework to use in WordPress core. And of course, React and Vue are the best candidates. While the discussion is not over yet, Gutenberg might be a push for choosing React. It just doesn't make sense if WordPress core uses Vue and the main editor uses React.

Developing on React helps improving user experience a lot. All the interactions are smoother, the post data is auto saved, the changes are previewed in real-time, blocks are rendered in real-time. You almost don't need to think about press this or that button to setup your posts. Instead, just focus on writing.

Gutenberg and the Problems with Meta Box API

There are many concerns about Gutenberg, including:

• The compatibility with plugins that add buttons / elements to the editor toolbar or near the old media button. This might include page builder plugins as well.
• How the block data is handled.
• If the number of blocks increasing, what will be the UI?

But the biggest concern at the moment is the meta box API. As we know, developers use meta box to add more information to the posts. Sometimes, it's not just the content, but also settings and arbitrary data (think about a real estate website, where users add info for a property). With the current UI version, there is no place for meta boxes. And because Gutenberg focuses on the content, not on custom fields, the meaning of custom fields will no longer exist. Some popular plugins such as Yoast SEO and WooCommerce won't work because of this.

Although WordPress is a publishing platform ("word" + "press") and content is its heart and soul, but WordPress has grown beyond this to become the most popular CMS. One of the reasons that WordPress can serve many types of websites is the custom post types, custom fields, and custom taxonomies. The content is no longer just about post content, but it can be anything from a testimonial, a job listing to an event. Creating Gutenberg for publishing content is great, but it would be much greater if it can work for custom post types and custom fields. Is that the purpose of Gutenberg that can be used anywhere?

There are a lot of comments on the discussion about supporting meta box in Gutenberg. There are 2 main things that need to be resolved:

• How to adapt the UI for meta boxes, and
• How to make Gutenberg work with the existing PHP functions (meta box API)

The Meta Box UI for Gutenberg

Regarding the UI, at the moment, Gutenberg development team wants all meta boxes to stay in the right-hand sidebar. But this raises a lot of objection from developers because that area is too small for meta boxes. Especially for custom post types that don't have an editor (like WooCommerce order) and the whole data are custom fields.

To resolve the UI problem, Joen Asmussen proposed an Extended Settings panel for meta boxes, below the main editor:

However, this removes all the contexts that meta boxes currently have (normal, advanced and side). Maybe the developer team needs to find a way to allow meta boxes in both Extended Settings and sidebar. Or simpler - keep the existing meta box UI and context, where each meta box is a collapsible panel as Jason Adams proposed. I think this is a good solution.

Besides, for custom post types that don't support editor, does Gutenberg work well? Or more important, what's the role of Gutenberg for those custom post types? And for custom post types that have secondary editors (like product short description in WooCommerce), is Gutenberg enabled and does it work for them? Or leave them as they are now? Will that make the UI inconsistent?

In the UI problem, understanding the Gutenberg term "block" is important. Weston Ruter emphasized "we should move away from thinking about adding metaboxes and instead think about adding blocks. Fields that you would formerly be putting into metaboxes you will now moving forward instead be putting into blocks". However, differentiate the blocks for content and blocks for settings (or any arbitrary data) has the same priority. While Gutenberg focusing on creating blocks for content and let users preview them, custom fields for settings are not content and don't require preview. This leads to the need of separating the blocks for content and for other things and treat them as different UI components.

Backward Compatibility with Meta Box API

Regarding the compatibility with existing PHP functions, Joen Asmussen proposed to rewrite all the meta boxes by JavaScript. Of course, for the backward compatibility, the old API on PHP still need to work. While this makes sense and doable at first, it affects a lot of plugins, including Meta Box, by forcing the authors to rewrite them completely. My concern is that it does not only take a huge amount of time to rewrite the code but also does not offer any new value to the existing users. Does it worth spend a year to rewrite the plugin just to make it act exactly like it is?

Tim Hengeveld from Yoast team worries about if the rewriting can maintain the same functionality of the plugin. In other words, after spending a whole year rewriting the plugin, is it possible that the results we get are not what we expected?

Rewriting in JavaScript also creates a new issue when the data handling process is now 100% on JavaScript. In that case, the WordPress hooks such as save_post or wp_insert_post_data won't work anymore. Or maybe we'll create a new hook system on JavaScript? (Update: Darren Ethier just sent me a Trac ticket created 5 years ago that implements JavaScript hooks).

Not to mention that this rewrite is highly likely to ruin backward compatibility, one of the strengths of WordPress, and will put many websites in jeopardy because users are unaware of what is going on when they update.

To keep the old API working, Weston Ruter proposed to use an iframe to load meta boxes. However, using iframe might cause problems when accessing the data of custom fields to do other actions (such as conditional show / hide the fields). Or it's not compatible with screen readers as Andrea Fercia pointed out.

Dave Kiss gave a comment that I think is important: "these "legacy" metaboxes also provide plugin and theme developers a natural mounting point for self-contained React/Vue/other apps to provide additional functionality to the edit page". Many developers already use React or similar JavaScript framework to create an app in the admin (like page builders or the Meta Box Conditional Logic extension which uses AngularJS). Does using Gutenberg with React breaks that?

And not everyone needs a new editor, especially there are many big things that need to be done. So Steve proposed to add post type support for Gutenberg like 'supports' => array( 'gutenburg' ). If the post type doesn't support the new editor, we'll use the old UI and API. This comment has gained a lot of consensuses since it's a safe way to move forward without breaking backward compatibility. And if the developers need to update their code, they will do it much easier.

Or another solution is using Gutenberg only in the distraction-free writing mode as Keven Miller proposed? This way, we can use the advantages of Gutenberg while keeping custom fields and meta boxes for data entry.

While the discussion about backward compatibility is gaining more attention, a question on the true nature of Gutenberg is raised and clarified. While Gutenberg is only an editor with the ambition to offer a better writing experience, changing the whole screen (not just the editor) is a step beyond its scope. Obviously, meta boxes don't belong to this scope. And because of that, many developers such as Kevin Hoffman, Andrey Savchenko, Aaron Jorbin suggests Gutenberg should leave other things that don't belong to editor scope as they are.

At the moment, there's not a final solution for this problem yet. However, the development team is listening to the community and has started collecting information about meta box plugins to understand how they work. And they really need help from the community to create a better solution for both users and developers.

The Future of Meta Box Plugin

In the case of Meta Box, I have received some emails from my customers asking about Gutenberg. They have good reasons to ask and worry about the huge change that potentially completely ruins what they build on Meta Box. And I fully agree with those concerns.

Meta Box has been a framework for developers to build data for not only posts but anything in WordPress. And it will have to ensure to do that job well when the change comes.

At the moment, our team are watching closely to everything happened to Gutenberg and learning how to work with blocks and more important - React. We're preparing everything necessary. Just in case the WordPress core team decides to rebuild everything on JavaScript, we can do that as soon as possible. I also created an issue for Meta Box on Gutenberg GitHub repository to help the development team understand about Meta Box and how it works. Hope that helps to make the integration easier for both of us.

Finally, we hope that the WordPress core team consider this issue carefully and keep what has made WordPress a great CMS. As I said above, rewriting entirely with JavaScript is a reluctance because it will take a lot of time and may not bring new value to customers.

• Gutenberg and the Future of Meta Box
• How to Disable Gutenberg and Use the WordPress Classic Editor
• Meta Box is Now Compatible with Gutenberg
• An Update on WordPress 5.0, Gutenberg and Meta Box
• How To Disable Gutenberg Without Using Plugins
• Introducing MB Blocks - Creating Gutenberg Blocks Now Made Easy
• Build Gutenberg Blocks Visually With Meta Box Builder
• Top 7 Plugins to Add Extra Blocks for Gutenberg [2021]
• Full Site Editing (FSE) - All You Need To Know - P1 - Overview
• Gutenberg vs. Page Builders - What is Better & Faster? In-depth Comparison
• Review Quadrat - A WordPress Block Theme
• Full Site Editing - P5: What Are Block Patterns in Gutenberg? How to Create Them?