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

28 responses to “Gutenberg 1.5 Adds Initial Support for Meta Boxes, Makes Gutenberg the Default Editor”

  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.

  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.

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

  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.

  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.

  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”?

  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.

  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.

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

  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.

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

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

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.