Gutenberg 8.0 Merges Block and Pattern Inserter, Adds Inline Formats, and Updates Code Editor

The team behind the Gutenberg plugin shipped version 8.0 yesterday. The update adds some nice user-facing changes, including a merged block and pattern inserter, new inline formatting options, and visual changes to the code editor. Over two dozen bug fixes were included in the release, along with several enhancements.

Designers on the project updated the welcome box illustrations to match the current UI. Because the welcome modal should already be dismissed for current users, only new users should see these changes.

For theme authors, the post title and placeholder paragraph text for the block appender will inherit body font styles. Previously, they had specific styles attached to them in the editor. The current downside is that the post title is not an <h1> element so it cannot automatically inherit styles for that element. However, that will change once the post title becomes a true block in the editor.

The editor also now clears centered blocks following a floated block. This is an opinionated design change, but it should not negatively affect most themes. However, theme authors should double-check their theme styles to be sure.

Updated Block and Pattern Inserter

Screenshot of the block and pattern inserter in Gutenberg.
Patterns available in the inserter.

The development team added patterns to the existing inserter. Now, both blocks and patterns have an individual tab within a unified interface. This is yet another step in the evolution of the pattern system that should land in core WordPress this year.

Right now, the experience is a two-steps-forward-one-step-back deal. The inserter’s behavior has improved and it is great to see patterns merged into it. However, all blocks and patterns are within long lists that require scrolling to dig through. Block categories are no longer tabbed in version 8.0, which is a regression from previous versions. I am certain this will be resolved soon enough, but it is a little frustrating locating a block in the list at the moment.

Merging patterns into the inserter is an ongoing process. There is still a lot of work to do before the final product is polished and included in core WordPress.

The following are some key items that need to be addressed in upcoming versions of Gutenberg:

  • Patterns should be categorized the same as blocks.
  • The block search box should switch to a pattern search box when viewing patterns.
  • Pattern titles should be reintroduced in the interface (removed in 8.0).

Of course, there is a host of other minor and major issues the team will need to cover to nail down the user experience. For now, the interface for patterns continues to improve.

Subscript and Superscript Formats

Screenshot of inserting superscript text into the block editor.
Adding superscript text to the editor.

Gutenberg developers added two new inline formatting options to the editor toolbar: subscript and superscript. These options allow users to add text such as X2 and X2. They work the same as bold, italic, inline code, and other options.

The two formatting options represent their respective inline HTML tags, <sub> for subscript and <sup> for superscript. With the addition of the elements, the toolbar now covers most of the widely-used inline HTML tags. The only other tags that are low on my wish list are <abbr>, <del>, and <ins>, but I could live with those remaining firmly in plugin territory.

Improved Code Editor

Screenshot of the code editing view in Gutenberg 8.0.
Updated code-editing view.

The code editor received a much-needed overhaul in the 8.0 update. Everything from the post title to the content is set in a monospace font, and the width of the code editing box spans the editing area. It should be a welcome change for those who need to switch to code view once in a while.

The next step to polishing the code editor (and the HTML block) would be to add syntax highlighting. In the current version, the HTML output is plain text. Given the extra markup that the block editor produces, it can be a bit of a jumbled mess to wade through. Basic syntax highlighting would improve the experience several times over. There is a GitHub ticket for adding the feature, but it has not seen any movement in several months.

8

8 responses to “Gutenberg 8.0 Merges Block and Pattern Inserter, Adds Inline Formats, and Updates Code Editor”

  1. I’ve been creating patterns and the process works really well. I can see it
    being very useful for clients to assemble pages out of sections or to manage a CPT with very little code. Do you think it’s too early to use patterns on client sites? Is there a risk much will change and the patterns I’m creating now will break?

    Report

    • Patterns should be just fine for use in production right now. Because patterns are just custom groupings of blocks, even if the Pattern API changes or old patterns are removed, any changes won’t mess up the content.

      This should go along with following good dev habits, such as checking if ( function_exists( 'register_pattern' ) ) , which is not yet officially a WordPress function. Other than that, I see no reason not to use patterns liberally at the moment.

      Report

  2. Block patterns I have no use for yet – but if everything becomes a block I guess it’s best to keep an eye on how they develop ;-)

    What’s bugging me at the moment as I delve deeper into Gutenberg (about 70 versions too late) is the inconsistencies in how blocks are applied to HTML tags – and tags to blocks. For example:

    div.wp-block-image > figure.aligncentre
    figure.wp-block-image.alignwide

    Why not just one or the other? Audio and video are wrapped in figure tags, so it’s just ‘regular’ images that are different. Except that wp-block-media-text is also wrapped in a div tag, not figure.

    But then we also get perfectly good tables being wrapped in figure tags (figure.wp-block-table). And the verse block being a class in a PRE tag, of all things (and with no default styling in the Gutenberg .css file I looked at… I wonder why). It’s annoying because you have to look at how each block is formed in order to apply styles – you can’t assume they’re all div.wp-block-whatever or figure.wp-block-whatever.

    Or am I being overly grumpy (again)?

    Report

    • Rolling out consistent handling of block HTML is a rallying cry I can get behind. I end up having to write extra CSS code to handle alignments like you mentioned. I’d love for the team to pause for a moment from feature development and focus on these smaller issues that affect theme developers in the day-to-day stuff.

      Report

    • Agreed that alignments are one of the biggest issues right now on the editor and we’re trying to find a solution.

      We have a solution but at the moment we don’t know yet how we can introduce it without breaking changes.

      We’ll make it work though.

      Report

  3. Please take care of the performance and speed standards of the new editor. I started working with him, themes, plugins and lighter and optimized resources this year, due to problems with other tools (you may already imagine which ones). With some blocks I am having good results. But with some third-party blocks, not always. Success in the project. It’s my wish. Many small professionals and businesses depend on it.

    Report

  4. Is it just me or does anyone else still find block navigation selection and insertion cumbersome and often infuriating. In particular in/out of the group block. There was some improvement with a high point being WP v5.3 however WP v5.4 has undone most of that and this v8 release of the plugin seems to be the worst of the lot

    Report

Newsletter

Subscribe Via Email

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

%d bloggers like this: