Gutenberg 8.9 Brings Block-Based Widgets Out of the Experimental Stage

On Wednesday, September 2, Gutenberg 8.9 launched with a set of new features, enhancements, and several bug fixes. The development team took the block-based widgets system out of its experimental stage, making it the default experience for all plugin users.

Block-based widgets have taken months upon months of work. The team has surpassed some of my expectations by essentially sticking a square peg into a square hole, granting the power of blocks to the sidebars/widgets system. On the whole, the system works. However, the team still has a lot of work to mold this feature into the shape it needs to be in for the upcoming WordPress 5.6 release in December. It is important that the community at large test, provide feedback, and contribute where possible.

Gutenberg plugin users who have not yet enabled block-based widgets via the experiments screen in past versions will be in for a surprise. The new system will have some of the familiarity of the block editor. However, it is a much different experience than traditional widgets.

The big questions we must answer is whether the feature is currently usable and whether it can be ready for WordPress 5.6.

New Widgets Screen

New block-based widgets screen in Gutenberg 8.9.
Block-based widgets screen.

Gutenberg completely replaces the old Appearance > Widgets screen in the WordPress admin. The plugin no longer has an option for end-users to disable it, which was expected. The goal is to begin getting users accustomed to building their sidebars with blocks rather than traditional widgets.

For the most part, the new widgets screen handles block-based widgets without issue from a usability perspective. Adding blocks is little different from working with the post-editing screen. It should feel relatively natural for users who are accustomed to the block editor. If anything, the experience seems scaled down in comparison.

Unlike widgets in the past, blocks cannot be collapsed (the sidebars themselves can be). As a long-time WordPress user, this feels uncomfortable. However, it is the sort of uncomfortableness that will simply take some adjustment time.

Core legacy widgets worked well. However, I could not get legacy widgets to work from several third-party plugins. Sometimes, they disappeared from the editor. Then, they would later appear, seemingly at random. Eventually, during testing, I completely broke the page to the point where it did not display anything. Fortunately, I was able to fix it by clearing out a few widget-related rows from the database.

As a developer, I want to simply wipe the slate clean and leave the old widgets system in the dust of history. However, doing so may very well alienate many end-users. For this feature to be successful, we need to carry them along and allow them to easily transition from their current tools to the new system.

Widget Blocks in the Customizer

Widget blocks section in the WordPress customizer.
Widget blocks section in the customizer.

While the primary widget blocks screen was generally solid, that was not the case with widget blocks in the customizer. At best, it was sub-par.

We may finally be at that point where I agree with all those earlier complaints of the customizer control panel being too narrow. The most obvious issue was that the block toolbar was too wide for the control panel, hiding pieces of it off-screen. For some blocks, there are buttons that users cannot access.

That is not the end of the issues. Block options are unavailable, so users cannot even add something as basic as an image alt attribute. The core legacy widget blocks are not editable. The “more options” button popup has a transparent background, making the text unreadable and, for all intents and purposes, not worth attempting a use.

I understand that WordPress is still far from launching widget blocks in the customizer, but the feature was practically unusable. It is still very much in an experimental state and probably should have remained optional for another plugin update or two or three. I cannot recommend using this within any sort of production environment. Stick with the widgets screen in the admin.

Widgets/Blocks Styling Issues for Theme Authors

HTML code view of block-based widgets.
No structured grouping of “widget” HTML.

One of the largest changes that theme authors need to be aware of is that blocks in sidebars do not have the typical widget HTML wrappers. This could present some issues with styling widgets in the traditional fashion. For example, themes usually register a widget wrapper element and a wrapper for the widget title. This allows theme authors to build consistent styles for each widget. With blocks, this becomes much tougher because the theme author loses that control — this control is passed to the end-user.

The great part of this system is that users can do some really interesting things and have the flexibility to style their sidebars in any way they want. The bad part is that if a theme author has any sort of intricate styles, such as a boxed widget design, there is no easy way for the end-user to simply drop widgets into place and have them all use that boxed design. There is no standard class name for the theme author to target with CSS, which is what is required for consistently-styled widgets.

This is not necessarily a good or bad thing in and of itself. It is simply different.

With that said, I would have much preferred the Gutenberg development team created a new and separate system from the old sidebars/widgets system. Leave that in place, then build and promote “block areas” as a new system for theme authors to take advantage of. In the long run, it would allow theme authors to make the transition and even potentially support both systems in their themes. Theme authors are down in the trenches, working with their users on a day-to-day basis. They are in a much better position to handle the transition from old to new.

Theme authors who are not prepared to go all in with block-based widgets in WordPress 5.6 can add the following line of PHP to their theme’s setup code to disable the widgets block editor:

remove_theme_support( 'widgets-block-editor' );

Over time, theme authors will want to fully transition to the new system. However, this will provide additional time for them to make any adjustments that may be needed with how widgets are handled.

20

20 responses to “Gutenberg 8.9 Brings Block-Based Widgets Out of the Experimental Stage”

  1. Andrei says:

    A very good coverage of the current situation with Block Widgets. It’ll be very interesting to see how the widgets screen will end up looking for the customizer. Seems like there are some open issues about this right now in the Gutenberg repo and is something that’s being actively worked on.

    Report

  2. When I go to Appearance –> Widgets, the new block-based Widgets appear

    When I go to Visit Site –> Tibesar Family Archives –> Widgets, the old Widgets appears

    Does anyone know if this was planned so that we can use the old Widgets while getting used to the new Widgets?

    Report

  3. Rodrigo says:

    Unfortunately, adding remove_theme_support( 'widgets-block-editor' ); does not bring back the “Widgets” section on the customizer right now. Clearly a bug.

    Report

    • I tested this, and it works for me. What hook did you use? Typically, you would want to do this on theme setup in a function hooked to after_setup_theme.

      Report

      • Rodrigo says:

        Typically, you would want to do this on theme setup in a function hooked to after_setup_theme.

        I added just the way you described, in a bare-bones theme. I also tried without hooks. Nada. Only the legacy “Widgets” menu in the admin (under Appearance) is triggered by adding it.

        Report

  4. Peter says:

    For me, this is utterly broken and unusable!

    None of my custom, self-coded widgets work, and I am confident that they are all properly coded with the modern API calls, so they should.

    I understand the need to modernise, but it shouldn’t break backwards-compatibility. These block widgets should honour the CSS classes that old widgets use so that themes don’t instantly break.

    Like the previous commenter, remove_theme_support( 'widgets-block-editor' ); does not restore the widget editor to the customiser.

    There is no way that this is anywhere near being ready for inclusion in Core.

    So, for now, I have had to deactivate the Gutenberg plugin.

    Report

    • Gary Taylor says:

      I had a similar issue a few months back when refreshing my site theme. Turns out that not all of my self-rolled widgets worked using the block, and some built-in blocks had different functionality compared to the old widgets (tag list, for example, no longer has a title).

      In the end I converted them all into shortcodes.

      Report

  5. Penny Suarez says:

    I find this new widgets screen very confusing. I had the idea that one would be able to use all available blocks in the widget areas. For example, I would be able to add a Jetpack feedback form or a custom reusable block to the sidebar or footer. But that doesn’t seem to be the case. And if it is, then it’s all very unclear how to implement. I see very few widget blocks right now. The Gutenberg team should add a BETA tag to the plugin.

    Report

    • I did not even think to check reusable blocks. I did a quick test and didn’t see them listed in the inserter. I am guessing they are currently limiting what can be inserted into the sidebars/block-areas while this is in beta or for the “1.0” of this feature.

      I’m not sure why Jetpack forms do not appear. I’ll have to do some digging to see if third-party blocks are not shown at all or if it’s specific to the plugin.

      Report

  6. That really is a feat, but glad to see this:

    remove_theme_support( 'widgets-block-editor' );

    Fantastic to support this for new themes but could be a nightmare for old themes doing sophisticated things with widgets.

    Theme authors really can totally opt out, right?

    Report

    • Yes, at least at this point, theme authors can opt out. I am assuming the old system will be supported to some degree for a long while, sort of like how the old post editor is still supported.

      Report

  7. Lucy Ng says:

    We can use Gutenberg as a page builder, and now use it instead of Customizer widgets option. I just imagine one day Gutenberg can do everything.

    Report

  8. Rhys C says:

    I like the progression but it would be nice if more than the ‘core’ blocks would work. Also has anyone else experienced the drag and drop not working since the last few updates!?

    Report

  9. I added a Buttons block to the new Widgets block editor’s sidebar area, and the primary/secondary colors chosen for the button’s background do not work. The button remains as a black background instead of the selected primary or secondary color.

    Report

  10. TimH says:

    Maybe you can help me out and explain widgets in the new post-Gutenberg world.

    I get that there will need to be a path for legacy widgets to keep working but aren’t sidebars and widgets an old-world construct?

    In the new world isn’t a “sidebar” just a fixed area for content or content embedded in content? And in that case isn’t a widget just…well…a block?

    Report

    • Essentially, yes widgets are just blocks.

      However, there is a vital difference between how their HTML is output, which changes a consistent standard that theme authors have relied since WordPress 2.1 (maybe 2.2 — it’s been a while). Taking away that structure means rethinking how sidebars work, or at least rethinking how theme authors approach styling them. There is a definite backward-compatibility issue at play here.

      I have some ideas though. New post coming in soon.

      Report

      • TimH says:

        Cheers Justin…

        I won’t look to perpetuate the discussion here and wait for your new post…but I leave you with this thought…navigation containers and sidebars (a.k.a Widget Areas) appear to fulfill the same function in a post-Gutenberg world…to contain blocks in a fixed area of the page. A number of legacy themes have supported Widget areas in Headers and Footers. A Navigation widget was common. So this is not a radical new idea I am floating.

        I accept your comment that this is a change to the HTML that theme authors are used to…but…come one…as a theme designer myself I can safely say that horse has left the paddock when it comes to maintaining pre-Gutenberg coding conventions ;-) I’m not sure why widgets / sidebars, of all things…would be a legacy metaphor that is retained moving forward. For my part I have moved all my legacy theme code into a plug-in and assume it is all dead code. I am starting fresh with a blank theme canvas that assumes it is a thin veneer on the core Gutenberg functionality.

        Other than retaining a “legacy widget container block” I would be disappointed if there was not a new Gutenberg version of the “widget area” (Fixed Group Block!) within which everything is a block (including block wrappered legacy widgets…however that would look).

        I look forward to your new post. I enjoy your writing immensely…you are an excellent writer with excellent WordPress knowledge and design ideas. A pleasure to follow :-)

        Report

Newsletter

Subscribe Via Email

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

%d bloggers like this: