Gutenberg 1.5 Adds Initial Support for Meta Boxes, Makes Gutenberg the Default Editor

Gutenberg 1.5 was released this morning and introduces several major changes to the plugin. This version takes the new editor off the back burner and makes it the default for creating new posts. The team has also included a way for users to create posts with the Classic Editor, but this requires knowing where to go to access the dropdown (All Posts » Add New).

Version 1.5 adds initial support for meta boxes in an Extended Settings panel beneath the post content. Users won’t see this bottom panel unless they have a plugin installed that includes meta boxes. The sidebar Settings panel must already be toggled open for the bottom panel to appear.

The Extended Settings panel slides up to reveal accordion toggles for plugins that have meta box settings available. The design could use some improvement, especially for navigating back to the post editor. The panel takes over the entire section. On installations with lots of legacy meta boxes it is easy to get lost in all the open/closed toggles.

Gutenberg design lead Tammie Lister said this is the first step towards supporting meta boxes and that there will be iterations to follow. She also warned that it is possible some advanced meta box uses will not work as expected. The Gutenberg team is eager to receive feedback on these cases and will work to find solutions for them. Testers who discover issues with meta box support can post an issue on GitHub or via the plugin’s feedback form, describing the setup and how to reproduce what is breaking.

Version 1.5 also adds a new inserter button between blocks, which Gutenberg engineer Matias Ventura demonstrated with an animated gif in the release post:

This release adds a dropdown to the Publish button. It currently supports visibility and post scheduling features.

There was a great deal of discussion on GitHub surrounding the UI for the publish button, whether it should be a split button dropdown or a single button that provides slightly more friction to prevent accidental publishing. The general consensus was that introducing a bit more friction is desirable, as contributor Davide Casali noted there are many cascading actions that are often tied to the Publish button:

“Some automated publishing actions are irreversible: pings gets sent, emails get sent, Facebook and Twitter gets updates, etc.,” Casali said. “This is very very important for a lot of people and businesses, and nobody wants to send out such actions by accident.”

Contributors are looking for feedback on this implementation and are willing to explore some alternate design options as well. They agreed that it is more important to make the Publish button area pluggable and to work on adapting it based on feedback.

For those who want to completely disable Gutenberg, a new plugin called Classic Editor is available on WordPress.org and ready for testing. It requires WordPress 4.9-beta2 or newer and Gutenberg version 1.5+. Classic Editor comes with two modes that give users the option to fully replace Gutenberg or allow access to both the old and new editors:

  • Fully replaces the Gutenberg editor and restores the Edit Post template.
  • Adds alternate “Edit” links to the Posts and Pages screens, on the toolbar at the top of the screen, and in the admin menu. Using these links will open the corresponding post or page in the Classic Editor.

A setting for switching between the modes is available at Settings » Writing. Other plugins for turning Gutenberg off will likely pop up the closer the it gets to being included in core, but Classic Editor is the official one recommended by core contributors.

The timeline for the merge proposal is not yet set in stone but the Gutenberg team aims to get it more widely tested before writing the proposal. The plugin is currently active on approximately 3,000 WordPress sites.

“The plan is to still have the plugin ready by December, but with holidays the actual merge proposal might be next year,” Tammie Lister said. “It’s important that we get as many users and as much feedback as possible at this point. All of that impacts what happens going forward.”

28 Comments


    1. It’s not there yet as in I’d still call it a beta software. But many of us are using it on live sites. I do too. The risk is the loss of content while you add it and publish it. But that was way back then.

      You should def. try it out.

      Report

      Reply

    2. If you are using a real page builder theme like DIVI you have no reason to use this plugin.

      Report

      Reply

      1. Divi is completely different to Gutenburg, even with Divi there is still a use for Gutenburg on standard posts.

        Report


  1. Metabox support does not seem to be enabled on custom post types yet, correct?

    I’ve just tested a few sites of mine using metaboxes (using the excellent https://wordpress.org/plugins/custom-field-suite/) that I picked to be the least trouble migrating to Gutenberg. Currently, there are issues (for example: a WYSIWYG field renders as HTML) that would make this unusable for the client.

    Overall, though, after months of concern it’s an immense relief to see metabox support is finally starting to get some practical attention.

    Report

    Reply

    1. Not metabox related, but… something else that struck me as odd was seeing the featured image appear in a block. I remember seeing this noted previously, but having now experienced it for myself it feels so wrong.

      Report

      Reply

    2. Your CPTs might not have REST enabled. We’ve run into some parts of the API that don’t match with what an editor needs and will fix them up, but in the meantime try enabling REST for them and see if that fixes it.

      Report

      Reply

      1. Thanks, Matt. Enabling REST did the trick.

        Report


  2. Tried it before and after installing a test site for WP 4.9, I saw the big notice in the admin about Gutenberg. So I decided to try it (again), but honestly, this editor is not user friendly, efficient, nor is it well thought out in respect to a content editor UI as it should be.

    Things are spread out everywhere, hidden to a point you have to go searching for elements of an editor (or try to remember where something was), little popups that intrudes on the content area….to much eye movement needed, clicking, and right clicks.

    For posts…took me almost 8 minutes to find the more tag insert…only after I went to search for google on where it is.

    This is definitely not an editor if you have complex content and layouts within a page or post, or a mix of different media elements….simple text based posts, maybe. But it still doesn’t have an efficiency about the whole writing experience with everything in one spot and easily accessible editor components as you create content, such as the standard toolbar of an editor.

    I gave this editor 3 hours of my time to create a variety of pages, posts, and a mix of simple to complex content. Definitely not an editor for me. As for the masses? I have to say no.

    Report

    Reply

    1. I would sure as hell hope that the team is testing a variety of standard tasks in both the current editor and Gutenberg so they can measure this.

      I get all of the excitement about what it could enable in the future but clients will rage if something that takes 5 minutes now takes 25 in the future.

      Report

      Reply

  3. I think the current design does metaboxes a real disservice. The current layout and the section heading, “Extended Settings”, makes it look and feel like a bit of an afterthought . Undoubtable many metaboxes uses will be able to be moved to their own block, but their will still be situations where whats contained under Extended Settings is essential to putting together a page but isn’t appropriate as a block. In that case, Extended Settings, Just doesn’t feel right and seems easily forgettable. That could create an awkward publishing experance, especially when those fields are required to publish.

    Same goes with requiring the settings sidebar to be active for the metaboxes to be accessibly. Why? It seems that most of the extended settings wont interact with the sidebar, so why tie them together rather then allowing Extended Settings to remain sticky to the bottom of the screen.

    I would also add that the minimalist white section headings for each metabox makes each section really hard to distinguish when editing. I understand this is early stages, but if it’s not being considered I would say the design of this section needs a lot more work. Metaboxes now feel overwhelming and indistinct.

    Report

    Reply

  4. I wonder how the success of this feature will be measured.

    WordPress.com marketshare decreases year after year, even though WordPress is growing.

    I predict both trends will continue, Gutenberg or not.

    Report

    Reply

    1. Post Gutenberg I think WP.com will see increase in market share because now Automatic can market to users who usually go for Wix type services.

      Report

      Reply

  5. Looks really good, I’m enjoying the writing experience.

    For people that manage their website content but don’t know what Gutenberg is, I think they will be confused with the dropdown that says “Gutenberg”.

    How about just call it “New editor”?

    Report

    Reply

    1. The “Gutenberg” name is just for development and internal purposes, it won’t be labeled as such once it’s fully integrated into core.

      Report

      Reply

  6. We use WordPress as a CMS for building headless web apps with React and ACF. So not everyone uses WordPress for writing stories which is what Gutenberg is designed for. We really hope that Custom Fields are better integrated in the new editor.

    Report

    Reply

  7. With version 1.5+ Gutenberg is finally in a state where it is usable for the first time: with added Meta Box support and other refinements. I am pleased the Gutenberg team has listened to at least some users who gave feedback. Please keep on that route! :-)

    I would still prefer and recommend to use as a plugin first for at least 6 more months. This thing is so huge, it just needs more time. The worst thing would be to ship it as alpha/beta software to millions of users and the reputation of WordPress goes down the hill… No one could want that to happen.

    Otherwise, now for the first time really the full potential Gutenberg has shined on us a little bit more with 1.5+. Imaging “templates” or Themes just built for Gutenberg will bring a whole new chapter for WordPress. This all makes a lot of sense very soon.

    But please always remind: don’t force anything on users which is not ready for prime time. Just give this thing more time – the better the “product” will be and much more of a success in the end.

    Report

    Reply

    1. Thank you for keeping an open mind and trying the new betas as they come out. I completely agree we don’t want anything forced on people that isn’t ready for prime time, and I’m really looking forward to getting a lot more usage once the code of Gutenberg catches up to the vision more.

      Report

      Reply

  8. I think this is looking great so far considering it is just the first iteration.

    I am guessing that before the final version will be released the Gutenberg team will polish the parts that might be confusing (like for example “Extended Settings” and “Gutenberg” labels mentioned earlier).

    Hopefully, in register_post_type() function we will have the ability to disable editor using supports param, then this screen will be useful for post types where the description is not that important.

    Report

    Reply

    1. Exactly my thinking. In many cases we don’t even use the description/content field with our custom post types. Currently the editor takes too much screen space but definitely a step in the right direction.

      Report

      Reply

  9. This definitely is a great step forward. Hoping to see more and more improvements over the time. Excited!

    Report

    Reply

  10. I’m ecstatic about Gutenberg, yet I’m developing themes using Visual Composer’s API (now WP Bakery Page Builder). I’m curious to learn the process in transitioning to the native editor, Gutenberg. For example, I use Visual Composer mainly for creating custom shortcodes and including them within Visual Composer’s content elements list. Client’s can then choose the custom shortcode and apply it on any post/page/cpt. I would love to see a similar feature with the upcoming native editor :-)

    Report

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *