Gutenberg 9.7 Improves User Experience, Updates Reusable Blocks, and Brings Page Templates to FSE Themes

Gutenberg 9.7 landed yesterday with several updates and improvements. Users should expect to see changes to the interface for block variations, transforms, and patterns. Reusable blocks are being worked on after what seemed to be a hiatus. Developers can also now add custom page templates to their block-based WordPress themes.

This release had the fewest number of bug fixes I have seen in a while. The development team only pushed eight fixes into the update, which could signal that things were more stable than usual after the 9.6 release a couple of weeks ago.

Most of the work in 9.7 dealt with new features and enhancements. As expected, Full Site Editing got its fair share of time. However, even this seemed dialed back a bit for this release. Many of the updates are to the post-editing interface.

User Experience Improvements

The team pushed out several updates to how features work in the editor. Some of them might seem minor but improve the overall editor experience.

Block variations received a welcome enhancement. Variations are when one underlying block is used to create multiple variations of the same block. For example, the Embed block has YouTube, Twitter, and other variations. In past versions, the block inspector in the sidebar and block navigation would show the generic name, icon, and description. However, Gutenberg 9.7 will now show the details for the variation in use.

Example of using the YouTube Embed block variation and showing its details in the sidebar.
YouTube variation for the Embed block.

When transforming a block, users can see a preview of what the block will look like. This is a small improvement. However, it might save a few headaches when before deciding to transform one block into another.

Transforming a Quote into a Pullquote in the block editor.
Preview when transforming Quote block into a Pullquote.

Gutenberg 9.6 introduced a drag-and-drop feature for blocks in the inserter. The team has now extended that feature to block patterns. This is just another rung on the ladder for those looking for more drag-and-drop capabilities.

Reusable Blocks Updated

It has been a while since I tested reusable blocks. The feature has seemingly taken a backseat to other, newer features in the past year or so. It never felt much better than an initial prototype. There is still no way to easily manage them unless you know where to look. However, it appears the Gutenberg development team is actively developing this almost-forgotten feature.

Users can expect more in future releases. “Based on these changes, the UI for reusable blocks is most likely going to see some iterations on the upcoming weeks,” wrote Riad Benguella in the announcement post.

I ran an initial test to see what the feature looked like in Gutenberg 9.7. After clicking the “Add to reusable blocks” button, the editor did a quick flash. Then, a notification appeared at the bottom of the screen that the reusable block had been created. Because I did not have my block options sidebar panel open at the time, I saw no way to edit the reusable block’s title. My immediate thought was that the team took an already half-baked feature and made it exponentially worse.

Upon further digging, I found that users can edit the reusable block’s title in the block options sidebar. However, the team did not stop there. They added several improvements to the feature.

Editing the name of a reusable block in the WordPress editor.
Editing the reusable block name in the sidebar panel.

Reusable blocks are now editable within the post editor itself. Users can drag an image out of the block, for example. The inspector sidebar is available for the inner blocks. Reusable blocks now look and feel like any other part of the editor. Any edits will reflect across all instances of the reusable blocks on the site.

The big difference is in how they are saved.

Saving the post and reusable blocks at once in the block editor.
Saving a reusable block along with the post.

Reusable blocks are now a part of the “multi-entity” save system. When clicking the editor’s update button, users will have an option to save the entire post and/or individual reusable blocks.

Custom “Page” Templates for FSE Themes

Block-based themes now support what has been traditionally known as page templates. All post types are technically supported with the feature. However, the team seems to be sticking with the “page” terminology after some discussion.

It took some digging because there is no existing documentation and the original example in the ticket did not reflect the end result of the code that passed. However, I managed to suss out how the feature works. For theme authors who want to test this feature, use the following example code of adding a “contact” template. Place it at the root level of your theme’s experimental-theme.json file. You will also need to accompany this with a block-templates/contact.html template in your theme.

"pageTemplates": {
        "contact": {
                "title": "Contact",
                "postTypes": [

This feature does not do anything particularly groundbreaking right now. It merely adds the custom template to the drop-down select on the edit post/page screen. It is the equivalent of the current page template system available to traditional themes.

Selecting a page template from the block editor.
Selecting a custom page template from FSE theme.

While this is a nice development, traditional page templates may not make much sense in the block theming paradigm. There is no way to change the visual output of the page in the editor based on the selected template — users must still view the page on the front end to see the result of its application. The block system is about instant visual feedback. Page templates need to be rethought for the new era.

“In terms of UI and integration with the template mode, we can do a lot more than the old select box,” said Benguella, who was the developer behind the pull request. “We can show a preview for templates and offer a modal or something like that for folks to pick from…We’d need some design thinking and explorations there. This PR just sets the technical requirements to make it work.”

Much, but not all, of what page templates were needed for in the past decade can now be replaced by block patterns.

In the long term, I would rather see page templates that behaved more like predesigned block layouts. This is how block templates for custom post types work today. However, that is on the post-type level rather than the level of the individual post.

Traditional page templates are dated. Themes rarely offer more than a few. One to remove the sidebar. One to move the sidebar to the left or right. Another to make the page content area wider.

What is clear is that we need more exploration on what page templates of the future will look like. Are they necessary in the block system? Are there better ways of handling what traditional themes are using them for? How will they work in an interface that needs visual feedback?


9 responses to “Gutenberg 9.7 Improves User Experience, Updates Reusable Blocks, and Brings Page Templates to FSE Themes”

  1. Hi!

    Can someone give light to my confusion? Is the “Gutenberg plugin” is different from the “Gutenberg” that you’re talking about here? I’ve tried installing the Twenty Twenty-One theme and the “Gutenberg plugin” is not installed by default. However, the “Gutenberg” blocks are present in the said theme.

    • Yes, Gutenberg is a plugin. It is the ongoing project behind the block system where users can test the features that will eventually land in WordPress.

      What you currently see in WordPress, regardless of your theme, matches an earlier version of what’s in Gutenberg. The last few versions of Gutenberg have new features that you can test and use that are not in WordPress.

  2. Hi Justin, thanks for the posts. I wanted to add some clarifications around the page templates feature.

    While this is a nice development, traditional page templates may not make much sense in the block theming paradigm. There is no way to change the visual output of the page in the editor based on the selected template

    The page templates that were introduced in Gutenberg 9.7 have nothing traditional aside the fact that they’re being applied with the same existing UI. Actually, you can m make changes and see the visual output in the editor based on the selected template. You can do so by relying on the “template mode” that was introduced in Gutenberg 9.6.

    So they are already what you suggest they should be: Block Layouts the user can choose from when starting a page/post but at the “template” level and not the “content” level.

    This is not reflected in the UI clearly yet but the work on the interface often takes some time and iterations.

    Thanks a lot for all these updates.

    • Thanks for chiming in. I see that you can edit them via template-switching mode now. Yeah, the UI will definitely need some work. :)

      My point about doing it similar to CPT templates is that some theme authors would like the ability to create a specific content-level layout for the page template. For example, they might want to create a front page template that had all the blocks in place. Then, the user sees that in the post content canvas itself without having to switch over to template editing. Template-locking options would be nice for this too.

      In talks with various theme authors and agencies in the past couple of years, I think this is what many of them were imagining the block system would let them do with page templates. And, maybe as we continue merging interfaces, this is what it will ultimately look like.

      As block patterns have emerged, I see those as perhaps an alternative (better?) solution for that, just without the ability to lock the blocks in place.

  3. Unfortunately, there are no FSE templates yet.

    In your chosen WordPress Admin area, go into Themes, Add New, open the Feature Filter and select Full Site Editing. See how many themes get returned…

    I know the themes are out there because they’re highlighted by the Tavern (thankfully!) but until they make their way into the themes repository do they really exist?

      • Hopefully the Feature Filter will be updated (or the themes updated, whichever is at fault) so that we can give FSE a better test. Not everyone visits WP Tavern, so even if they’d heard of FSE and wanted to give it a go wouldn’t have found any themes to test.

        Thank you also for the name-check in the TT1 Blocks story ;-)

        • I chatted with the Themes Team about what was going on there. It was the theme authors who hadn’t added the full-site-editing tag. They’ve been asked to in their respective Trac tickets. Q, at least at last check, has the tag in its GitHub repo but hasn’t been updated on .ORG yet.

          Thanks for bringing this up though. Before your comment, I hadn’t realized the filter wasn’t showing any themes.

  4. I apologize for some nonsense terms I may use, I’m a Designer, not an advanced developer, but I really want to contribute in some way.

    I agree, Page Templates as used before in the page editor seem redundant with Patterns coming in.
    But I think keeping the Template Hierarchy is fundamental for building dynamic Websites/Apps/PWAs.

    I also think WP can have two kind of users:
    A) the ones who want to build single pages with blocks.
    B) the ones who want to fill fields to feed a Database – that would feed the template-pages & blocks.

    A) could be divided in Normal and Advanced users. See structure below..

    Thinking on a data structure, I believe some kind of CPT and Custom Fields are still essential to build Complex Queries. And as data gains more value it’s important to control it. Of course, with blocks the way it’s organized it’s different but I think the a good approach could be:

    |__ Dashboard
    |__ NEW
    |     |__ Page (page-template.php) – Pattern X, Y, etc
    |     |__ Product (product-template)
    |     |__ Post (etc)
    |     |__ Etc..
    |  EDIT Templates/Patterns (Advanced User level)
    |     |
    |     |       |__ Pattern X (Header A + Sponsor A + Etc)
    |     |       |__ Pattern Y
    |     |       |__ Etc.
    |     |__ Product
    |     |       |__ Pattern X
    |     |       |__ Pattern Y
    |     |__ Post
    |     |__ Etc..
    |     |__ Header A (header-template-a.php)
    |     |__ Header B (header-template-b.php)  
    |     |__ Sponsor A (sponsor-template-a.php)
    |__ Media
    |__ Etc..

    Where “Templates” option would only show in Dev or Advanced user level, controlled on WP installation and after in some kind of on/off switch.

    Blocks themselves should be simple templates, dynamic = PHP (dynamic HTML).
    HTML isn’t more user friendly than PHP – a user will never touch code anyway. Why not having PHP doing the heavy stuff – fetching, parsing, embedding, using custom-fields, etc..?

    PHP is so strong now. It had its down momentum with the appearance of new systems and languages but it’s being updated more than ever, it’s quicker, safer and it is a super SS language. With the evolution of CDN’s, Cache solutions (functions?), etc.
    Isn’t it a strong option to keep it alive?!

    I would prefer go 1 step back now then 2 or 3 later.  

    I hope it wasn’t to confusing or absurd.


Subscribe Via Email

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

%d bloggers like this: