Gutenberg 11.9 Focuses on Navigation Menus and Block Theming

Gutenberg 11.9 landed on Wednesday, and it is packed with dozens of enhancements. Contributors are speeding forward, getting in some of the final features before the release of WordPress 5.9, expected on December 14.

Version 11.9 is the last plugin release to include new features for the upcoming WordPress update. Bug fixes will continue to be ported over in the coming weeks.

Site editing and theme-related blocks take up most of the spotlight. WordPress 5.9 will ship with its first default block theme, Twenty Twenty-Two. For many users, this will be their first experience with template editing and global styles.

The Navigation block received a lot of attention, and rightly so. Developers solved some vital data portability issues and created a more well-rounded user experience.

There is still a lot of room for improvement on the whole, but Gutenberg has come a long way in the past few months. I am excited about what the new features will look like once they land in the general WordPress release.

Site Editor Scaled Back, Its Menu Moved and Renamed

WordPress site editor.  Template editing canvas on the left, global styles options on the right.
Site editor with Twenty Twenty-Two active.

The site editor has been scaled back to the point where it is no longer the feature that Gutenberg plugin users have grown accustomed to in these last few months. It is essentially a pathway to the global styles feature.

When it comes to templates, only the site’s homepage is accessible through the interface. Clicking the “W” icon in the top left of the editor no longer opens the familiar templates panel, which formerly allowed users to navigate, select, and customize individual templates.

Clicking the “Browse All Templates” button carts users away from the site editor to a templates screen. It looks like a posts list and includes no instructions on how to, for example, overwrite an author archive or other theme templates. I know the system well enough to understand what is happening, but I can only imagine this would be shocking for the average user.

Users can jump to the Header and Footer areas in the site editor by clicking those in the dropdown. The editor simply focuses on those template parts without switching screens.

However, I see no way of editing specific templates from within the site editor. The result is a watered-down index template editor with global styles, the one redeeming feature.

The site editor menu item has also now been moved beneath the Appearance menu in the WordPress admin. It is now simply named “Editor.” Of course, the “Theme Editor” submenu is still there.

WordPress theme file editor, showing another "Editor" in the same submenu list.
Two types of Appearance editors.

I do not expect this to be confusing to users at all…

Sarcasm aside, this is the appropriate place for the new site editor, which will only appear if a user has a block theme active. However, the two submenu names clearly conflict. Could there be a better place to move the Theme Editor? One proposal would see it dropped under Tools in the admin menu.

One must wonder how much use there will be for directly editing theme files in a block world. Templates can be overwritten via the UI. theme.json settings are handled through the global styles interface. That mostly just leaves functions.php as the lone holdout. It might just be time to disable file editing by default in WordPress, at least for block themes.

Pattern Explorer

Block pattern explorer as viewed from a popup overlay.  It features a left sidebar of categories and a right section with two columns of various block patterns.
Block pattern explorer.

Users on desktops and tablets can now enjoy a full-screen pattern overlay. Instead of endlessly scrolling through dozens or even hundreds of patterns in the narrow inserter, they can click a new “Explore” button to explore patterns in an interface with a bit more breathing room.

I covered this new feature in a full review earlier this week. There are still a few kinks to work out with the design, but it works well thus far. It also lays the groundwork for a more extensive set of features down the line.

Navigation block data is now stored in a dedicated wp_navigation post type. By saving it separately, contributors have now corrected one of the longstanding issues with block-based nav menus: portability.

In previous iterations of the block, users lost their carefully-crafted menus whenever they switched to a new block theme. They would have to recreate content that typically does not change often.

Alongside this improvement is a new Navigation Area block, which serves as a wrapper for Navigation. Theme authors will be able to define custom areas in their block theme templates with the following code:

<!-- wp:navigation-area {"area":"primary"} -->
<!-- wp:navigation /-->
<!-- /wp:navigation-area -->

The nested Navigation block is associated with a wp_navigation post. This will be the preferred format for theme authors going forward.

When a user switches themes and the “area” name matches their previous theme, the menu simply carries over and automatically appears. If they do not match, the user can assign a saved menu. The menu/area relationship is stored in the database.

One of the issues with the Navigation Area block is that it has no alignment controls. Technically, it does not output any HTML itself. However, its existence in the editor prohibits a user from selecting wide or full alignment for its inner Navigation block.

Duotone Filter Transparency

Duotone filters on blocks such as Image and Cover now support transparency. Users will now see a slider control beneath the color picker when adjusting either shadows or highlights.

The feature opens the door for a double exposure effect or image mask by layering an Image block over a Cover. Alex Lende showed a few examples of how this could work in the ticket.

Image with transparent duotone layered over Cover block.

Developers also noted possibilities for a tritone option and other filter types.

API For Accessing Global Styles

Theme and plugin authors should have fun with this new API for interacting with the global styles system. Previously, developers had to use the WP_Theme_JSON_Resolver class to pull data that they needed on the server side. Now, they have three new functions:

  • gutenberg_get_global_settings() – Returns settings.
  • gutenberg_get_global_styles() – Returns style settings.
  • gutenberg_get_global_stylesheet() – Returns the global stylesheet.

Presumably, these functions will be renamed before landing in WordPress 5.9 and not have the gutenberg_ prefix. Theme authors should wrap any usage of these in function_exist() checks to be on the safe side.

New Comment Blocks

Several new comment blocks have landed in the latest plugin update. The Comments Query Loop and Comment Template blocks work similarly to their post counterparts. However, the current result is a bare-bones feature that is not ready for production use. Nested comments are not shown, and there are not many options for customizing the output.

It is a step toward block theme authors and users (via the site editor) controlling post comments output. Gutenberg 11.9 also includes new comment helper blocks that will be necessary for templating:

For a while, comments have felt like an afterthought. Any movement toward rounding out these missing theme-related blocks is welcome.

7

7 responses to “Gutenberg 11.9 Focuses on Navigation Menus and Block Theming”

  1. As you say Justin, it’s good that you are accustomed to where everything is in FSE, but that just suugests that it really isn’t intuitive enough to users fresh to the experience.

    I’ve returned regularly to Gutenberg on each release and trying to exit the theme editor is as confusing as I don’t know what? So far the only avenue is the back arrow 🔙 at the top of the templates list on the left: back, back, back till you teach the dashboard. Unless I’m missing something it all seems like a time wasting exercise.

    I have been using the block editor in part, for post content, and for this task it is a brilliant replacement to the classic editor but, for everything thing else, relating to design and layout, I reach for my favourite page builder. I am agnostic about these builders, there are several good ones for people to chose from and there are some good block solutions too, if you are using something like Toolset. And, despite all that is being said, builders are keeping space of what is happening and are still ahead enough for people to use them… and this is the big mistake with the Gutenberg project, thinking it can blow everything else out of the water and create a unified system where fragmentation won’t happen anymore.

    The big mistake here was not setting a restricted set of blocks for layout and elements., allowing only these to be overridden by third party plugins and page builders, Turn off any of these or switch to another and at least the general content would remain intact. As it is, we now have a smorgasbord of block suites all reinventing the wheel and none of the them interoperable.

  2. Navigation block is something I look forward to. As a theme developer, I have stopped creating themes for sometime till I get the WP 5.9 ( Very excited ! ) The classic editor needs to go away asap from WP otherwise there will always be the discussion Page builder vs Gutenberg. People want to remain in a comfortable spot and that prohibits all innovation.

    • Discussion is core of democracy.

      Comfortable spots are felt as comfortable because other spots are not comfortable. Instead of complaining, make the other spots more comfortable, then people will chose your new spot.

      Democratize Publishing.

  3. When people ask “why are developers reticent to develop for modern WP” its due to this sort of weird shifting foundation. We are asked to build on a platform which has a cycle of inclusion and deprecation which is baffling.

    In the same release (Gutenberg 11.9) the core palette colours can no longer be removed. It’s marked as a bug but it was done intentionally. So a whole team decided to move forward with a nice new shiny feature that happens to cripple every site with a branded theme.

    It seems that every dev is so focused on their own tiny section of Gutenberg Development that we are seeing major deprecations for features which were only included months ago.

    A lot of the current Gutenberg work is in the theme.json sphere, but nobody seems to consider that it is completely unstable. As in: nobody sensible is building on this shifting foundation. Anyone who built a site for FSE in 5.9 is right now punching their desk. Anyone with sense is waiting a year to see what lasts these waves of inclusion/removal

    99.9% of sites which update to WP5.9 are going to be running PHP themes. JS devs in their ivory towers blithely erasing and re-doing each others work – as we in the real world of branded client sites look on in confusion and horror.

    What exactly are we meant to spec for, or on.
    What is the platform this week?

  4. When it comes to the Navigation Block the new feature and philosophy behind it is heading in the right direction. But I just discovered that the layout functionality has been changed. Used to add a .is-vertical class to the navigation. This has become problematic for our theme since we offer two different styles for vertical and horizontal layouts.

Newsletter

Subscribe Via Email

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