With the Gutenberg 8.9 release, WordPress developers removed the ‘experimental flag’ from the new block-based Widget Screen and it will take over the default way of managing widgets.
Not to be a spoiler, but the widget screen is still experimental. If you use the Gutenberg plugin in a production environment, you might be accustomed to a polished interface with great workflows and smooth transition. In its first iteration, the block-based widget handling is – as expected – not there yet.
Riad Benguella wrote the September 2nd meeting:
“Unfortunately, the screen has been there for a long time now but received very little feedback, and since we’re approaching WordPress 5.6, making it default + call for testing post is the best way to ensure we receive the necessary feedback before landing it on Core.”
Riad Benguella, #core-editor meeting September 2, 2020
Table of Contents
- TL;DR: How can I Switch off the block-based Widget Screen?
- Getting Familiar with the New Screen.
- Using Regular Blocks in the Widget section.
- Testing Third-Party Legacy Widgets: bbPress and Jetpack
- Block-Based Widget Screen and the Customizer
- Unordered List of Issues
- This Month’s Focus
- First Conclusion
- Widget Screen in Open Floor at Meeting September 9, 2020
- Block Patterns for Block Areas
TL;DR: How can I Switch off the block-based Widget Screen?
Funny you should ask that! The Gutenberg developers learned during the last three years that every new feature they add needs code to switch it off or opt-out.
If you or your customers want to change widgets in the next few weeks, wait until the next Gutenberg update. You add this line of code to your theme’s function.php
remove_theme_support( 'widgets-block-editor' );Code language: JavaScript (javascript)Note: Due to a bug, the legacy widget section won’t be available in the Customizer after adding the opt-out code. Marcio Duarte filed this GitHub issue.
Getting Familiar with the New Screen.
For those interested in testing the Block-based Widget Screen, welcome to my tour.
My test environment: Local Site with WP trunk (5.6-alpha-48937), Gutenberg 8.9, Twenty-Twenty theme.
After you installed Gutenberg 8.9, go to Appearance > Widgets in your WP-Admin menu. You see this new screen with your theme’s registered Widget Areas – now called Block Areas.
In the content section, you see all your widgets already set. In the sidebar you see the Block Areas screen with the list of your widget areas.
“Block Areas (also known as “Widget Areas”) are global parts in your site’s layout that can accept blocks. These vary by theme, but are typically parts like your Sidebar or Footer.”
At first, I was a little lost in the new screen. All these empty title boxes didn’t mean anything to me. As soon as I clicked on a title, I could identify which widget type I had selected and then it all became oddly familiar.
When you click in the section, you see the outline of the block, the widget title, and the form fields to adjust the setting. As the block-editor for posts, the interface feels kind of busy.
Instead of empty titles, adding widget name as the default title would have helped to avoid the feeling of disorientation on an empty screen with empty title boxes at the beginning. This needs some helpful guidance for first time users.
Using Regular Blocks in the Widget section.
My first task was to add a list of quick links to the footer. Doing it with conventional blocks should work. I wanted to add a heading block and a list block with links.
It feels there would be enough real estate on the screen to add the left sidebar with the available blocks/widgets. The + button seems to be a residue from the pre-5.5 Block UI and will be updated in due time. The preview in the widget screen is bare-bones. It doesn’t show how the widget area would look on the front end.
Testing Third-Party Legacy Widgets: bbPress and Jetpack
For this first iteration, these first impressions might not be all that important. Those of us who use the Gutenberg plugins are expecting new features to be a little rough around the edges, especially concerning the UX experience.
Jorge wrote: “Yes even if the UX may be improved in the future, testing if the screen is reliable, if it works with third-party widgets, does not crash, etc. is very useful.”
For now, the team needs testing on backwards compatibility and third-party widgets. So let’s see if I can get myself some of those. We are expecting a “Call for Testing” from the Core team in a few days and I will update this post with the links at the time.
bbPress Widgets
First I installed bbPress, the WordPress forums package, to get to the bbPress widgets. I had to create a forum and a topic to fill those widgets with content.
For comparison, here is a screenshot of the old widget screen.
My expectation was that I would see the array of bbPress widgets somehow in the inserter. Not so, though. The solution for now is to use a block called “Legacy Widget.”. It’s a block wrapper rendering the old-style widget code. When added to the block area, it shows a drop-down box with a list of all registered widgets.
Note: The “Legacy Widget” doesn’t come up in the search of the Inserter if you use “Widget” as keyword. Start the search with “lega”.
As mentioned, the widget screen doesn’t have a preview screen, so you need to open a second tab on your browser with your website to see how the widget looks on the front end of your site.
The settings for the widgets appear within the block, similar to the old widget behavior.
Jetpack Widgets
After installation, we need to enable the widgets in the Jetpack Settings > Writing and switch the toggles into the ‘on’ position.
Again, let’s take a quick look at the old widget screen again, where we can see some of the widgets available.
We are adding another “Legacy Widget” block to the block area, and open the dropdown menu for the list of all the third-party widgets available. The list has now become quite long and unwieldy. We will use our Twitter timeline and our Flickr account.
Adding the two Jetpack Widgets worked easily through the Legacy Widget for now.
According to Mark Uraine, the next version of this process is already in the works and will be much better, “All those third-party widgets would show as blocks under the Widget category in the Inserter.” The legacy widget functionality would still exist but it will be hidden from the content creator. They would just see all the blocks in the widget section, as they do now in the block editor when editing posts or pages. You can follow along on GitHub Issue #24870
Here is the latest design prototype for the future block-based widget screen as visible and discussed on GitHub.
Block-Based Widget Screen and the Customizer
Being curious, I also switched over to the Customizer as that’s what many people used to manage their widgets today. As you can see in below screenshot, the screen real estate for the block-based widget handling is much smaller, then the one via WP-Admin. It basically shows a mobile version of the widget screen.
My personal preference is to use the WP admin widget screen for menus and widgets. I found the Customizer a bit too confined and claustrophobic to get comfortable. At this point it’s not sure what will happen with the Customizer when the block-editor is moving to full-site editing. And that’s definitely a conversation for another time.
Unordered List of Issues
Meanwhile, here is the list of issues, I found while spending the better part of yesterday morning testing. One way or another, these issues will make it to the GitHub repository. The list it by far not complete. I am sure the upcoming call for testing has a few more use cases, too.
- Soften the interface switch for first-time users.
- Use widget name as “Title” placeholder or other form of identifying the widget type.
- Legacy Widget block doesn’t work in Customizer (Error message about not enough permissions).
- After you delete them from the Block Areas, Core Widgets disappear and are not visible in the inserter. You only see the block-editor version of the widget blocks, but they are not working in the Widget Screen. (Example Recent Posts ⇾ Latest Posts, Sidebar controls don’t work).
- Needs a similar preview screen as the block-editor for post, or somehow be able to handle theme styles in the widget screen.
- When changing the title of bbPress widgets, the title of the widget following disappeared (needs further testing).
- Customizer “Widget Blocks” is empty when first loading and takes a bit until the widget areas and blocks appear. Could use a “Loading… ” spinner since it’s empty at first.
- Drag & Drop is missing. (#25243)
- Widgets don’t move from one block area to another. (#25243)
- Block Navigator (List of Blocks) only shows the first block area. Footer #2 is missing
This Month’s Focus
Anne McCarthy posted What’s next in Gutenberg? (September), outlining this month’s focus work on the Gutenberg plugins. For the block-based widget screen she lists the following links.
- Creating updated designs for an improved user experience.
- Enabling the Global Inserter to be open by default for the widget screen.
- Exploring how third party widgets can be integrated.
- Refactoring the widgets screen to use the sidebars endpoint.
- Fixing the legacy widgets preview experience.
- Ensuring only superadmins can store HTML using the new API endpoint.
- Addressing a11y feedback around proper labelling, improved navigation tool, and more.
In her post, Anne also included links to getting started as a Core contributor. There is a plenty of work to be done and the team appreciates all contributors.
First Conclusion
After using the block-editor for a couple of years to create posts and pages, using it on the widget screen feels like time travel into the past. The block-based widget screen is in its early stages and needs a lot more people testing it to get the kinks out. The workflow could use a bit more innovation and design. Functionality definitely needs testing for backwards compatibility and for any conflict with existing plugins. I am looking forward to the next iterations to come. The Legacy Widget compatibility with 3rd party plugins widgets performed well. I have yet to use the block-based widget screen with an existing site.
Linus’s law: “Given enough eyeballs, all bugs are shallow.”
Watch for the “Call for Testing.” You can also bookmark the “Keeping up with Gutenberg: Index” from the reference section of the Core Handbook.
On this GitHub project board, you’ll find all the discussions about a new design flow and other widget screen related discussions. Chime in!
Share your experiences in the comments, so we can get more information on how this new widget screen works on existing sites and with your set of plugins.
Widget Screen in Open Floor at Meeting September 9, 2020
During open-floor section of the #core-editor meeting on Slack, I raised my hand. I referred to a new issue, @paaljoachim: The answer: This theme developers can target the block in the block area with class names. Example: .my-widget-area .wp-block-latest-posts –
On another issue, in a comment I tried to explore what I know now and what will change for widgets. “I am utterly confused on what the future widget handling entails in respect to widget registration, functions” and if there is a goal of feature parity.
“The APIs you raise are probably something to look at and see whether support is possible, but we shouldn’t be expecting 1-1 parity”
- The widgets themselves should work as close as possible with the new editor. The registration and other widget related functions should also be unchanged.
- There will be incompatibilities in hooking into the widget editor itself as the new screen uses a completely different architecture
- If there is anything that cannot be implemented then that will break backward compatibility. If it is possible to support things it should be attempted to be supported
- It’s a different paradigm since it will just wrap the whole list of blocks. Widgets don’t map to blocks.
- Core Widgets vs. Core blocks, if a core widget like recent posts has a block equivalent, the core widget doesn’t appear in the inserter for the Widget screen. “Authors have the option to hide widgets if block equivalents are provided”.
All “clear evidence that we should be cautious with opt-in opt-out in Core” wrote Riad.
Block Patterns for Block Areas
My takeaway from the meeting was that, things are still in flux as to the end vision of widgets. Ultimately, a theme developer’s work will get much easier, as they don’t have to create widgets at all. They can now create block patterns to fit into the newly declared block areas. The only time it’s important to consider widgets would be plugins, creating widgets that need to be accommodated and the team is working to provide the legacy widget functionality.
Justin Tadlock explores this idea on block patterns instead of widgets in his post: “Addressing the Theme Design Problem With Gutenberg’s New Block-Based Widgets System” with Widget Block Patterns.
2 Comments
This is really confusing. I’m surprised they rolled it out with these two issues:
– The titles are not displayed by default, like you said, which makes the whole interface much more confusing
– You really have to hunt to find the “Legacy Widget”, it is not discoverable.
Thank you, David for stopping by. That’s certainly a valid question. It’s not rolled out as a finished feature. It’s definitely needs more testing and additional design changes are on their way, but it hasn’t had enough testing for backwards compatibility or 3rd party plugins, and that’s what is also needed for the successful merge into Core next month. The Widget screen also need a lot more people be confronted with it, and so they chime in on some decisions made.
By Post Author