WordPress contributors have not yet made a final decision on the JavaScript framework to adopt for core, but Gutenberg development continues on with version 1.2 released this week.
The update provides a better experience resolving block conflicts when switching between the “classic editor” and Gutenberg. Previously, if a user had created some paragraph blocks in Gutenberg but switched to the classic editor, the tags would get stripped out, making those blocks invalid when moving back to Gutenberg. Version 1.2 merges a pull request that detects whether the post contains blocks and then disables the wpautop behavior in the classic editor to prevent it from stripping the tags.
This release also offers initial support for postmeta in block attributes. Gutenberg contributor Gary Pendergast tweeted an example plugin for those who want to experiment with it.
Just between us, the new Gutenberg 1.2 release includes the first version of postmeta support! If you want to start experimenting with it, here's a sample plugin to get you going. 🙂https://t.co/O1GbKZ3xzt
— Gary (@GaryPendergast) September 29, 2017
Another new item you’ll notice in version 1.2 is the addition of word and block counts to the table of contents. The value of knowing how many blocks are in play on the page or how many headings have been used is not immediately evident. It strikes me as a rather large and obtrusive display of non-essential information, which for some reason has been given priority placement at the top of the editor.
Gutenberg is getting ready to support metaboxes and this release adds a placeholder for the proposed Extended Settings panel. The metabox placeholder shell currently sits beneath the content with a “coming soon” message.
Developer Ross Wintle commented on the pull request with a few concerns about the naming and placement of this panel with notes on how it might impact interfaces that have required meta fields:
a) Meta boxes currently have several places that they can live: in the sidebar, below post content with different priorities and contexts
b) I also have cases where I’ve improved the editing experience for my users by having meta boxes above or below the title because this fits with their content editing flow.
c) I really don’t like the “Extended settings” title. For some editing workflows the information in meta boxes is actually critical, core content/settings, not something optional/added-on/extended. Is this editable? Can developers add additional sections of their own like this?
Gutenberg engineer Riad Benguella acknowledged these concerns as legitimate and said the team is still exploring different options for the panel.
“For the first iteration, we’ll probably keep the collapsed state but have multiple areas,” Benguella said. “There are some good design proposals dropping the expanding area (for the content area) and replacing them with “separators,” which might be good as a v2.”
It may have seemed like Gutenberg development has been on hold due to the delayed JavaScript framework decision, but development is still ongoing. It slowed over the past couple weeks while most of the project’s chief contributors were attending the Automattic GM.
“The framework decision doesn’t affect most Gutenberg development work – because the framework is hidden behind a compatibility layer, the majority of development work (at least, the work that touches the UI) can talk to the compatibility layer,” contributor Gary Pendergast said.
“There are also large areas of code that don’t need the framework at all. For example, adding postmeta support was just about writing the glue between the Block API and the REST API.”
Pendergast said that even once a JavaScript framework decision is made, Gutenberg will only require one or two developers to work on the necessary changes, but all other contributors will be able to continue on without any issues.
The word and headings count actually is a very useful tool for editorial SEO and if it’s invoked by clicking that information icon I do think it has a place there.