Gutenberg 12.9 Adds Block Lock UI, Template Autosave, and Full Theme Exports
Gutenberg 12.9 landed in the WordPress.org plugin directory today, and it’s a beefy release, packed with a little something for everyone. Even after tinkering with new features over the past few days, I still haven’t explored everything as much as I’d like. Given the practical limitation of time, I won’t be able to go into everything in this article, but I will try to give you all some of the highlights.
Here are a few select items I haven’t been able to dive into, but I still encourage readers to check out:
Block lock UI
Gutenberg 12.9 introduces a new UI for Lock Blocks. Under the “more options” drop-down list on the toolbar, users can select the lock option, which will bring up a screen with two options:
- Disable motion: Prohibits the movement of the block itself. However, sibling blocks can be moved around it.
- Prevent deletion: Prevent block deletion.
Andrei Draganescu noted the following in announcement post 12.9:
When a block is locked, users cannot move it, delete it, or both. This is especially useful with site-level blocks like Post Content which many themes will want to lock down.
However, this definition does not fully explain block-level locking. There is one caveat: this new UI gives end users the key to the lock. Technically, they already had this functionality through the code editor, but now it’s available through the interface.
From a theme development perspective, block-level locking simply requires additional steps from the user to move and/or delete blocks. This is not a “forced” or “permanent” lock. It’s a welcome feature, but themers should understand its limitations and that this new UI gives users more power, not less.
Update: there is a hook for site builders to override that. See more in the comments.
Block discard support for galleries…Kind of
One of the features that I was most excited about with this release was the addition of support for spacing between gallery images. Theme authors have relied on specialized block styles to give users choices, usually limited to the default and “no-space” options. The latter would remove any spacing between images.
Unfortunately, the feature is broken in 12.9 when users manually set a gap. Checking the source code, it outputs a
Array instead of valid CSS. On the front end, the following warning is displayed:
Warning: preg_match() expects parameter 2 to be string, array given in ...wp-content/plugins/gutenberg/build/block-library/blocks/gallery.php on line 51
I’m sure this will be fixed in 12.9.1. Until then, I suggest not using the “Block Spacing” control.
Disclaimer from theme author: This is a radical change for themes that target the
--gallery-block--gutter-size to control the default spread of galleries. This previously trusted CSS custom property no longer exists in code. It’s unclear why this variable was removed altogether, and there was no mention of it in the ticket.
--wp--style--unstable-gallery-gap variable seems to do a similar job. However, as the
unstable part of his name indicates that he may not always be there. It is also defined on the
.wp-container-* class instead of the gallery itself. I haven’t done enough CSS testing yet to figure out how to override it for the default gap. If anyone has a solution, please post it in the comments for others.
Default Collapsed Children in List View
I’ve often avoided the list view in the editor for most real-world scenarios, at least for pages with lots of nested blocks. With each level open by default, it was a bit of a nightmare to navigate and locate a specific block. It was easier to try my luck by clicking in the content canvas.
However, the latest version of Gutenberg might just change my usage. Version 12.9 collapses all child blocks by default.
Auto-save templates for themes
Theme authors can now let Gutenberg handle template registration for them. They just have to follow a few rules:
- Add block templates in PHP files in a
- Add pattern data to the file header.
- Add template content, of course.
Individual signature files should look like this:
Slug header fields are required. Each option corresponds to a
register_block_pattern() function argument.
Theme authors who want to use this feature now but offer backwards compatibility with WordPress 5.9 can check for the existence of the
gutenberg_register_theme_block_patterns() a function. That’s the name of the function for now, at least.
This change builds more on the existing standards for block themes. Authors now have clear guidelines on registering most functionality via standard files and folders:
/parts– Block model parts
/patterns– Block patterns
/styles– Global style variations
/templates– Block models
theme.json– Global settings and styles
Aside from custom block styles and variations (not to be confused with global style variations), almost everything is covered. This well-rounded package lowers the barrier to entry for would-be theme writers. Even seasoned developers should appreciate the simplicity of how to name things and where to put them. It’s one less worry. It will also continue to simplify WordPress.org’s theme review system.
Exporting themes and creating templates
Speaking of lowering barriers, creators can now create an entire theme from the site editor. Well, assuming they start from an existing block theme.
Gutenberg 12.9 introduces two essential features to the site building process. The first allows users to export a copy of their active theme directly from the editor:
The ZIP file downloaded from this export is a fully functional theme. It includes all user customizations alongside each file that already exists in the original.
There are still a few things that are not yet possible from the editor, and these will need to be adjusted manually before public release. The theme name and other data in
style.css will remain the same as the original theme. There is also no method to capture a screenshot of the custom build and bundle it into the ZIP.
This is a leap forward for the democratization of design, but other flows will have to be considered. Users should be able to export as a child theme with only their customizations or even as
*.json file (global style variation).
But there is a more immediate and practical use case. Users can download their custom themes and upload them to another site.
The second crucial development update within the site editor is support for more templates. Users can now create the following items from the template management panel in addition to the existing ones;
The new templates are welcome additions, but the template creation functionality still has limitations. There is no way to create variations on these templates through the UI, like
taxonomy-genre, or dozens of other possibilities. However, it will happen one day.