Gutenberg 7.0 Launches Stable Navigation Block, Post Blocks, and Template Parts

On November 27, Gutenberg 7.0 landed with several features, enhancements, and bug fixes. Most notably, the navigation block is now a stable feature. Theme authors can also start using block template parts and testing the post title and content blocks.

The update addressed several bugs with the block editor. It also introduced new developer features such as the card component and the ability to internationalize strings with safe HTML.

Gradient classes are now used for the cover block. Classes are a nicer solution than the inline styles used in earlier iterations. Note that gradients are still an experimental feature.

For developers, there is a new backward-compatibility document that outlines how the project preserves compatibility in its public APIs. This should be useful for all developers working on the project in the future.

Navigation Block Now Stable

Screenshot of the navigation block in the Gutenberg plugin.
Creating a nav menu with the navigation block.

The navigation block is now a stable feature and no longer considered experimental. The interface is much improved over earlier implementations. For quickly building a menu of links, it does the job. Users can manually type a link or search for an existing link for the site.

A user interface for nav menus in the block editor is no easy beast to tame. The Gutenberg team managed to fit in the most common features without making it feel confusing. For users, theme integration may be limited until their themes are updated with full support. The default Gutenberg design may not be ideal or work at all in the context of the active theme.

The navigation block also comes with both light and dark block styles. Theme authors can design these how they prefer, add additional styles, or remove the styles altogether. More than likely, theme authors will begin adding several variations to their themes as a selling point in the long run.

The Gutenberg team dropped the background color option from the navigation block. Instead, users are encouraged to place it within a group block and add a background to the group. It is possible to change the link text color directly within the navigation block.

Currently, there is no parity between normal nav menu HTML classes and navigation block classes. This could result in bulkier theme CSS, at least in the transition between how themes currently work and the full site-editing era. Inconsistent classes is an issue that should be handled with a design framework.

Post Title and Content Blocks Added

Screenshot of using the post title block with a hero background image.
Customized post title block output.

As part of the experimental site-editing feature, Gutenberg has introduced the post title and post content blocks. These blocks act as placeholders and will output either the title or content. Both blocks are foundational elements for true full-site editing. Eventually, users will no longer be as limited to how their posts are output on the screen.

Currently, the post title block simply outputs the post title inside of <h1> tags. There are no classes for customizing the design. The other missing element at this point is the post byline or meta area that often accompanies the title. In the long run, Gutenberg needs to have a method of handling post header and footer areas.

The custom post header feature has plagued theme authors for years, long before Gutenberg was around. There are dozens or more implementations in the wild. Some of them work with the block editor. Others use custom post meta or the featured image. However, users are often left with sub-par implementations that don’t always work in the context of a specific post.

One of the features I have wanted to implement within Gutenberg is the “hero” image with text set over the top. By using the built-in cover block and the post title block, I was able to accomplish this. However, it was still missing the post byline. Therefore, I put together a quick filter to output the post byline when the post title block is in use.

Any theme author who wants to test it out can modify the following code. I would not recommend this in production since this is an experimental feature, but it is good to start thinking ahead about possibilities.

add_filter( 'pre_render_block', function( $block_content, $block ) {

    if ( 'core/post-title' === $block['blockName'] ) {

        $post = gutenberg_get_post_from_context();

        if ( ! $post ) {
            return $block_content;

        if ( 'post' === $post->post_type ) {

            $block_content = '<h1 class="entry__title">' . get_the_title( $post ) . '</h1>';

            $block_content .= sprintf(
                '<div class="entry__byline">%s · %s · %s</div>',
                get_the_term_list( $post->ID, 'category' )

    return $block_content;

}, 10, 2 );

Block Template Parts for Themes

Gutenberg 6.9 introduced block templates that resolve from a theme’s /block-templates folder as part of the site-building experiment. Version 7.0 takes that a step farther and introduces a block template parts system, which resolves from a theme’s /block-template-parts directory.

This new system allows top-level templates to house smaller, reusable template parts. This is a rather standard method of template-part handling that has become a part of the normal theme-building experience.

It will be interesting to see how this works in the long run. WordPress’ current template part system for theme authors (i.e., get_template_part()) is a bare-bones implementation with little flexibility for handling features like hierarchy and passing data. Thus far, the new feature seems to be a melding of blocks and old templating ideas, but it is too early in the process to see where it goes or whether theme authors will have to make customizations to bend the system to their will.


21 responses to “Gutenberg 7.0 Launches Stable Navigation Block, Post Blocks, and Template Parts”

    • Hi Caroline,

      This is a great observation and my wording on the release post can be misleading.

      It should be noted that features in Gutenberg go through three main phases:

      1- Experimental: For early adopters and developers, they can enable the feature by going to the “experiments” page of Gutenberg.
      2- Beta: Plugin users (beta testers) are invited to test these features extensively and provide feedback. Iterations and fixes will be applied based on that feedback.
      3- Stable: That’s when the plugin gets merged into WordPress Core. It usually happens with WordPress major releases.

      Gutenberg 7.0 Moves the Navigation block out of the experimental phase into the beta/testing phase where we invite all plugin users to test and provide feedback. It is still an early version that will receive a lot of improvements and bug fixes.

  1. With these continuing changes of Gutenberg (block editor) which is really becoming a page/builder, has anyone speculated what is going to happen with marketplaces like Theme Forest? We know themes in general are going to be obsolete in the near future.

    • All 20 plus WordPress pagebuilder plugins can easily be rendered useless the way Gutenberg is progressing in the terms of functionality.

      I do not see themes being useless unless they are full Gutenberg compatible.

      Still possibly a year or two off.

      • “We know themes in general are going to be obsolete in the near future.”

        hey, would you care to elaborate a little on this?

        My take is that the main question is what kind of page/site is being developed and what kind of complexity with respect to design and data-display is taking place at which part of development using which technologies.

        For a mainly data-driven site, let’s say an event calendar, the additional features of Gutenberg over tiny_mce are mostly useless in my opinion, as the important content of the page is ideally saved in reusable post-type data-blocks and displayed according to list templates/search-logic. Adding page templating to Gutenberg merely changes the way the site’s frame is developed or how a loop is integrated in a page.

        (sidenote: I think there are still a couple of conceptual aspects unresolved with respect to now having two basic units for holding data in wordpress (and how they’re saved): pages/posts (data in various types, metadata) and now blocks (data serialized in one field).)

        For many corporate pages, added flexibility in terms of design is something to be avoided not to be offered to editors/authors. Here, again, there’s no added benefit derived from a complex templating engine available on every page, quite the opposite: removing blocks and limiting styling options will become the more important aspect of customizing gutenberg.

        That said, for a single, landing-page-style page, the added flexibility does make sense, because something like that takes tooo long and is too complex for classic template/coding to be economically viable.

        So, basically, I think it’s the underlying requirements of a page that will determine the most efficient way of developing and displaying data. Page builders/future Gutenberg are nice for front- and landing-pages, but usually much less important for second-level content pages, corporate pages with required design, that strive for editing simplicity, and data driven pages.

        Changing the way the templating is done doesn’t obliviate the need for it, it does, however, introduce a phase of uncertainty for certain clients who could be insecure if they should hire someone for expertise or go it alone, since, now, the technology allows them to (like page builders in general).


  2. This is awesome! These features are very similar to connections in Beaver Themer and dynamic tags in Elementor, which allows developer to connect settings (from posts like post title, post content, or from other part of the website) into a module (block/widget). And that opens a lot of possibility with the content building.

    I’m looking forward to this and more similar great things added to Gutenberg.

  3. I would really want to understand the community’s view on the future of Gutenberg? After WP 5.3, there were about 5 updates released to 7.0? This rate speaks about how serious their vision is at Automattic with Gutenberg and it’s very impressive. But, the point is that will it be able to keep up with the intuitive and ingenious advancements that other page builders are bringing into the market?

  4. Really excited to see when we will be able to set a block template with placeholders for the default post headers. Especially if you could assign different post formats to specific saved block layouts with featured imagery, etc in them. We’ve been using reusable blocks on our client sites a ton.

    I want to see a block template section that you can assign for headers/footers. It can’t be that far away at this point. That and post header/footers are the only things that we still use PHP templates for at this point, and it’d be a whole lot more flexible if we could use Gutenberg for universal site elements too.


Subscribe Via Email

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

%d bloggers like this: