Two weeks ago, the Gutenberg team put out an open call for block-based widgets feedback. I had already written a lengthy review of the new system earlier in September but was asked by a member of the team to share my thoughts on the most recent iteration. With the upcoming freeze for WordPress 5.6 Beta 1 just a week away, I figured it would not hurt to do another deep dive.
For reference, my latest testing is against version 9.2.0-alpha-172f589 of the Gutenberg plugin, which was a build from earlier today. Gutenberg development moves fast, but everything should be accurate to that point.
Ultimately, many of the problems I pointed out over a month ago still exist. However, the team has cleaned most of the minor issues, such as pointing the open/close arrows for sidebars (block areas) in the correct direction and making it more consistent with the post-editing screen. The UI is much more polished.
Before I dive into all the problems, I want to answer the question I am proposing. Yes, the block-based widget system will be ready for prime time when WordPress 5.6 lands. It is not there yet, but it is at a point where there is a clear finish line that is reachable in the next two months.
I will ignore the failure of block-based widgets in the customizer, which landed in Gutenberg 8.9 and was removed in 9.1. I will also look past the recent proposal to reconstruct the widgets screen to use the Customize API, at least for now. There is a boatload of problems that block-based widgets present for the customizer, and those problems are insurmountable for WordPress 5.6. Long term, WordPress needs to have a single place for editing widget/block areas. Users will likely have to live with some inconsistencies for a while.
Assuming the team does not try to throw a last-minute Hail Mary and implement full editing of blocks in the customizer this round, it is safe to say that block-based widgets are well on their way toward a successful WordPress 5.6 debut.
The User Experience
As a user, I genuinely enjoy using the new Widgets admin screen. The open-ended, free-form block areas create untold possibilities for designing my WordPress sites. Traditional widgets were limited in scope. Users were buckled down to a handful of core widgets, possibly some plugin widgets, and whatever their theme author offered up. However, with blocks, the pool of choices expands to at least triple the out-of-the-box options (I am not counting embed-type blocks individually). Plus, blocks provide a far more extensive set of design options than a traditional widget.
In comparison, traditional widgets are outdated. Blocks are superior in almost every way. However, there are still problems with this new system.
The biggest issue right now is that end-users can exit the Widgets screen without saving their changes. There is no warning to let them know that all their work is about to be lost in the ether. This is one of those OMGBBQ-level items that need to happen before WordPress 5.6 drops.
One nice-to-have-but-not-necessary feature would be the ability to drag blocks from one block area to another. In the old widgets system, users could move widgets from sidebar to sidebar. The current alternative is to copy a widget, paste it in a new block area, and remove the original.
I am also not a fan of not having an option for the top toolbar, which is available on the post-editing screen. One of the reasons for using this toolbar is because I dislike the default popup toolbar on individual blocks. It is distracting and often gets in the way of my work.
Legacy widgets seem to still be a work in progress. The Legacy Widget block did not work at all for me at times. Then, it magically began to work. However, Gutenberg does now automatically add registered third-party widgets to the block inserter just as if they were blocks.
This presented its own problems. The only way I managed to make third-party plugin widgets work was to insert the widget, save, and refresh the widgets screen. At that point, the widgets appeared and became editable.
The Theme Author Experience
One of my biggest concerns for theme authors right now is that there does not seem to be any documentation in the block editor handbook. There is plenty of time to make that happen, but there are things theme authors need to be aware of. Having a centralized location, even while the feature is under development, would help them gear up for the 5.6 release.
Some of these questions, which may be answered in various Make blog posts, should exist on a dedicated documentation page:
- How can a theme opt out of block-based widgets?
- What are the hooks to add custom styles for the Widgets screen?
- Can themes target specific sidebar styles on the Widgets screen?
- Is it possible to consistently style sections like traditional widgets on the front end?
- Can themes opt into wide and full-alignment within block areas, which could essentially be used similarly to the post content area?
These are some of the questions I would want to be answered as a former theme author. I am no longer in the thick of the theme design game and presume that those who are would have a larger list of questions.
One less-obvious piece of documentation should center on how to handle fallbacks or default widgets. Traditionally, themes that needed to show a default set of widgets would check if the sidebar has widgets and fall back to using the_widget() to output one or more defaults. While theme authors can still do that, we should start to transition them across the board to the block system.
Should theme authors copy/paste block HTML as a fallback? Would the starter content system be better for this, and can starter widget content handle blocks? What is the recommended method for widget fallbacks in WordPress 5.6?
There is still the ongoing issue of how theme authors should handle the traditional widget and widget title wrapper HTML in the new block paradigm. One patch added since the Gutenberg 9.1 release wraps every top-level block with the widget wrapper. If this lands in the 9.2 release, it will likely make the issue worse.
In the traditional system, both the widget title and content are wrapped within a container together. However, if a user adds a Heading block (widget title) and another block (widget content), each block is wrapped separately with the theme’s widget wrappers. The only way to rectify the situation as it stands is for end-users to add a Group block for each “widget” they want, which would require an extensive amount of re-education for WordPress users. It is not an ideal scenario.
Instead of attempting to directly “fix” this issue, WordPress should instead do nothing to the output. Blocks and traditional widgets are fundamentally different.
Let theme authors take the reins on this one and explore possibilities. However, give them the tools to do so, such as supporting block patterns.
Right now it seems that the idea is to add the option to opt-out in the Classic Editor Ref.
But, what if someone wants to use the block editor, but doesn’t want to add the block-based widgets screen? It’s quite confusing to me.