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.

Gutenberg editor preview
Preview of Gutenberg editor

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.

Gutenberg minimalist UI
Gutenberg minimalist UI

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. 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:

Extended Settings for meta boxes
Extended Settings for meta boxes

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.

3 thoughts on “Gutenberg and the future of Meta Box

  1. Great post, thanks for writing it.

    I’d like to address a few misconceptions. First off — I don’t personally see Gutenberg merged into WordPress core being a done deal. I see that as a blessing we wil receive if, upon presenting this project as a feature plugin to be merged into core, people like yourself and the whole community agrees that Gutenberg is a good thing for the future of WordPress.

    This is key. I’ll get to in a bit how backwards compatibility can be maintained. But obviously, and as you note, it’s not going to be the same, and so our focus with Gutenberg right now, is to ensure that *if we have to lose some backwards compatibility, it has to be worth it*.

    Gutenberg, as of version 0.8 (which I’m super excited about, by the way, I hope you give that version a spin, it’s really coming together), is *not yet worth it*, in my opinion. But what you see when you load up 0.8 came together in 4 months. The first 3 months of the year were spent prototyping, to inform what to actually build. WordPress 4.9 is in November, i.e. 4 months from now. I don’t know when WordPress 5.0 is, but presumably it’s another 4 months. I.e. if Gutenberg is to reach WordPress 5.0, we have twice the time to get there, than the time it took to build the beta version we have now. And again, merge into 5.0 is not written on stone tablets, it is predicated on Gutenberg improving to a point where the community will love it enough to want it there. That is my approach, and it’s the approach of the entire Gutenberg team right now.

    We haven’t yet prioritized metaboxes, and what you’ve seen so far when it comes to mockups, are just that: mockups. We are actively discussing how we can support them. I would personally love it if we could support metaboxes in exactly the same way as they are supported in the current editor — I hope we can. But even if that shows itself to be technically unfeasible, there are many alternate ways to support backwards compatibility for metaboxes. The most wide-ranging being to simply disable the new Gutenberg editor entirely if a metabox is detected on the page. You’d just get the current editor, with zero change at all. I think we might find better ways to do it than that, but nothing is off the table as far as I’m concerned.

    What I’m saying is, we are not trying to destroy metaboxes, and I expect once we reach beta 1.0. in a few weeks (or maybe we’ll call it version 0.10.0 stay tuned!), supporting metaboxes is likely going to become one of the priorities. So thank you for letting your voice be heard!

    1. Hi Joen,

      I’d like to address a few misconceptions. First off — I don’t personally see Gutenberg merged into WordPress core being a done deal. I see that as a blessing we wil receive if, upon presenting this project as a feature plugin to be merged into core, people like yourself and the whole community agrees that Gutenberg is a good thing for the future of WordPress.

      This is key. I’ll get to in a bit how backwards compatibility can be maintained. But obviously and as you note, it’s not going to be the same, and so our focus with Gutenberg right now, is to ensure that if we have to lose some backwards compatibility, it has to be worth it.

      Thanks for letting me know that. Personally I have no problems with the current editor. But if Gutenberg can provides something more than expected that can amazes users, I’m happy to go with it.

      I understand that it’s not ready to be merged in the WP core yet. It’s just some kind of panic when it’s introduced to the public at a huge event like WordCamp Europe. Users and developers like me “think” it’s at some stage that can be considered anytime to be merged. And there’s no official announcement about that from WordPress, except the announcement from Matt (the introduction). That scares us and I hope you can understand.

      Gutenberg, as of version 0.8 (which I’m super excited about, by the way, I hope you give that version a spin, it’s really coming together), is not yet worth it, in my opinion. But what you see when you load up 0.8 came together in 4 months. The first 3 months of the year were spent prototyping, to inform what to actually build. WordPress 4.9 is in November, i.e. 4 months from now. I don’t know when WordPress 5.0 is, but presumably it’s another 4 months. I.e. if Gutenberg is to reach WordPress 5.0, we have twice the time to get there, than the time it took to build the beta version we have now. And again, merge into 5.0 is not written on stone tablets, it is predicated on Gutenberg improving to a point where the community will love it enough to want it there. That is my approach, and it’s the approach of the entire Gutenberg team right now.

      I tried Gutenberg and follow its development. There are some issues that I don’t like it now. But I see it’s being developed and it’s getting better and better.

      I hope you’re true about that. I (any many developers) think Gutenberg (at the current stage) is not ready yet, and thus “not yet worth it”. Even Matt said so (I don’t remember where, but I saw his comment about this). What we need is when Gutenberg is considered to be merged into core, it should be awesome! And awesome means it can satisfy most of us, developers and users.

      We haven’t yet prioritized metaboxes, and what you’ve seen so far when it comes to mockups, are just that: mockups. We are actively discussing how we can support them. I would personally love it if we could support metaboxes in exactly the same way as they are supported in the current editor — I hope we can. But even if that shows itself to be technically unfeasible, there are many alternate ways to support backwards compatibility for metaboxes. The most wide-ranging being to simply disable the new Gutenberg editor entirely if a metabox is detected on the page. You’d just get the current editor, with zero change at all. I think we might find better ways to do it than that, but nothing is off the table as far as I’m concerned.

      I see. But we all expect it to be awesome when it’s merged. In my personal opinion, maintaining 2 editors is not a cool thing. Especially when the old editor gets a lot of improvements over years. I opened a ticket regarding the editor API some days ago addressing this problem: https://github.com/WordPress/gutenberg/issues/2391. Core developers spent a lot of time improving the editor, and now do that again. It will double the work load and if we can get the new thing better than the old one, keeping 2 versions is a bad idea.

      I just hope the development team can resolve these issues or think about it before coding. You know sometimes doing the architecture thing is much harder than writing code. And I see some serious concerns are posted on Twitter about “does it worth it”.

      What I’m saying is, we are not trying to destroy metaboxes, and I expect once we reach beta 1.0. in a few weeks (or maybe we’ll call it version 0.10.0 stay tuned!), supporting metaboxes is likely going to become one of the priorities. So thank you for letting your voice be heard!

      That’s a good news :). I’m happy to test when it’s released.

  2. Joen, it is naive.

    To disable Gutenberg in any post type using just one (old) Metabox. All native, custom post types use at least one Metabox. Except static Pages maybe. It means Gutenberg will not be used at all, by your statement.
    You spread confusion around with statements like this.

    Second thing, you give power to people who hate or do not like Gutenberg for any reason. They will ruin anything you do, and out of this feeling force old Metabox(es) all the time.

Leave a Reply