Gutenberg 16.9 Lets You Rename (Almost) Any Block, Adds Experimental Form and Input Blocks

Delivering on an highly-requested feature, Gutenberg contributors have made it possible to rename almost any block in the List View. Version 16.9 was released this week with the new feature, which builds on Gutenberg 16.7‘s introduction of the ability to rename Group blocks.

It works in a similar way to naming Photoshop layers. Users can now open the list view, click on the ellipsis menu, select “Rename,” and enter a custom name.

video credit: Gutenberg PR #54426

“Allowing users to distinguish between blocks in the List View is becoming increasingly important as the scope of the Site Editor grows,” Automattic-sponsored contributor Dave Smith said in the original ticket proposing the feature for the Group block. “Given that all blocks are currently labelled by the block name (e.g. Group) it can be difficult to distinguish between them. This is especially important if your Groups represent distinct ‘sections’ of a given page/template.”

Every block can be renamed with the exception of these four:

  • core/block
  • core/template-part
  • core/pattern
  • core/navigation

More renaming capabilities have been added in 16.9, including the ability to duplicate and rename patterns, as well as pattern categories.

This release introduces new experimental form and inputs blocks to allow building basic forms. It’s a feature that has taken many by surprise, as few would have predicted WordPress core would be adding form building. A very early version is available under Gutenberg > Experiments, under the “Form and input blocks” experiment setting.

“Why has there been no proactive outreach to the many developers of longstanding WordPress form solutions currently used by millions and millions of WordPress sites?” Gravity Forms co-founder Carl Hancock commented on the PR.

“It seems like proactive outreach to people who are experts in this space and who could do the most to help drive adoption (beyond comments/search/etc.) would have been a good thing. On many levels. Trying to get them on board with contributing, learning from their shared historical knowledge, and even more important of all… building on top of it and adopting it instead of introducing a point of more fragmentation.”

The forms feature is still in the very early stages of experimentation, and more information may be published to the November edition of “What’s New For Developers?

A few other notable highlights from this release include the following:

Check out the release post for Gutenberg 16.9 to see the full changelog and more details on bug fixes and enhancements to performance, tooling, documentation, code quality, and accessibility.


3 responses to “Gutenberg 16.9 Lets You Rename (Almost) Any Block, Adds Experimental Form and Input Blocks”

  1. Good!

    How far we’ve fallen far from the initial golden state of WordPress, where there was common ground for developers, servicing a standardized user base. Today, there’s actually not a single form builder that doesn’t either force you to use the classic interface or hijack the Gutenberg interface in some way with their own. It’s created a fragmentary UI/UX, where each developer reinvents the same basic functionality, and each user re-learns WordPress for each plugin. The core mission could focus solely in countering the unintended consequences of such “development,” reducing the ever increasing inaccessibility and inequality of external and competitive contributions.

  2. I’ve been playing around with the Query Loop. I used the filter for keywords to display an abstract from specific pages and posts. However, when I save the changes, the contents of the loop revert to placeholder text. So, at the moment, this functionality is still buggy.

    Ideally, I’d like to be able to enter the page or post ID into a form field in the Query Loop block so that I can reliably display what I’d like.

  3. I’m so pleased to see the Gutenberg Team is tackling creating a Form API for WordPress core.

    Forms are an essential part of nearly every WordPress site, yet this key web component has previously been left to plugins to deliver.

    The result is large range of WordPress form plugins, both free & premium, (including some of the biggest plugins on WordPress) with little consistency & no cross-compatability.

    WordPress form users need to learn the unique approach to form creation taken by each form plugin. If they switch form plugins, their previous form work is lost & they need to learn it all again.

    I see the Form API as an opportunity to bring forms directly within the Block Editor in a way that is properly accessible & also extendable by the current crop of WordPress form plugins.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Subscribe Via Email

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