Diving Into WordPress 5.8’s New Widgets Screen

It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era.

After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today.

WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work.

Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere.

Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par.

Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes.

I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many.

With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist.

It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets.

Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container.

Adding a Gallery block to the footer sidebar in the WordPress block widgets screen.
Widgets screen with a Gallery block in the Footer sidebar.

The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves.

Adding a latest posts list via the Query Loop block to a sidebar.
Custom post list using the Query Loop block.

Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets.

Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart.

Editing a Heading block in the customizer controls panel in WordPress.
Editing a Heading block in the customizer.

Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches.

Problems Remain

In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme:

Widgets and blocks not matching when used in an OceanWP theme sidebar.
Mismatched headings and colors.

The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately.

This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme:

Heading block treated as separate widget from the content that follows it in the Twenty Twenty-One footer sidebar.
Block treated as widget in Twenty Twenty-One footer sidebar.

Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets.

To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some.

Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended.

I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken.

Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks.


15 responses to “Diving Into WordPress 5.8’s New Widgets Screen”

  1. Transitioning widgets to blocks seems to me like another of those oddities in how the block editor is being used. But first let me go over my observations and experiences with the editor so far.

    Despite my criticisms of the the block editor, in it’s in post and page capacity for adding content, it definitely has become the better way forward over the older editor. Once it starts to stray into becoming a solution for other parts of WordPress it has become less successful.

    In all of this we need to examine how well the block editor has been received by the WordPress community, barely making it to two stars in reviews. Two stars is a bit harsh I would say. If you take the new editor on its own merits it should do better. Its slow acceptance maybe partially be down to optics and how the block editor has been transitioned in as opt-in by default only. I agree that the opt-out option allows users to ignore new features but, forcing opt-in via plugins (Classic Editor and now, another plugin to retain the older widget system), is a bit cack-handed when some simple switches in WordPress settings would easily do the job. As it is all you need is the following in your function.php file to clobber the block editor all together:

    add_filter( ‘use_block_editor_for_post_type’, ‘__return_false’, 100 );

    I actually remove this from my child theme on new builds because I want the block editor active for some of the benefits it brings, outside of actually using the editor itself.

    The first benefit is as an editor that works asynchronously on save which means none of this interminable page reloads, when you are on a rather slow 3.8Mb connection. (500Mb connections will appear at some stage in the next year if National Broadband Ireland actually happens!) This way of saving is also the case with how I use Divi on the front end. I gave up on Divi’s backend builder because it is tied to the classic editor’s need to reload on save. It is just as easy to use this builder on the front end.

    The second benefit relates to the structure of posts and how end users and clients may want to add and edit their own content. In this respect the block editor reigns. The Divi builder would be overkill for these users. To facilitate this I build the layout for posts in Divi and drop in the post content module which will pick up the post content from the block editor.

    A third scenario is for custom post types. With the type of work I do, focused on large inventories and directories, the whole layout is mainly realised via templating and the data entry aspect of this is treated in in a similar fashion, with the back end restricted to a set of custom fields. This keeps things consistent and makes sure users don’t stray into free form content creation. To deal with this, and retain the asynchronous aspects of the block editor, I created a rudimentary plugin that strips out the block building parts of the editor and to just leave the custom fields. For me, having the ability to remove the block area, on a per post/custom post type basis, in WordPress would be more beneficial than some of the other rudimentary features brought to the table with the block editor.

    Moving onto full site editing, in context to the above, having tested it I found it very frustrating and nowhere as easy to use as post type and category type templating offered by page builders and the likes of Toolset Blocks plugin. Working in patterns into the discussion here, for casual, ad-hoc, layout I see the merits. Ramping up to a larger scale scenario, in context to a large directories, I see less benefit with these patterns.

    Eventually, widgets? Do we actually need these anymore? I rarely use widgets as the flexibility and layout possibilities afforded by builders and plugins like Toolset obviate the need to use widgets. From a usability and novice user point of view, even the terminology around them is a bit deceptive. In the article above one of the images is captioned:

    “Widgets screen with a Gallery block in the Footer sidebar.”

    The fact that we are calling this the sidebar in a footer is confusing. Surely a footer template area would suffice and for this wouldn’t implementation in full site editing be the place to set up the footer layout?

    The whole block editor/Gutenberg project has certainly thrown up some interesting challenges and discussions on how to make WordPress more user friendly and optimised to perform better. In context to Core Web Vitals, the fact that using the the block editor addresses any issues around this hot topic has meant that page builders will have to up their game. From what I hear my builder of choice is working on this by implementing a version that will only load modules required in a layout, optimising stylesheet loading, reengineering the foundations by removing the shortcode soup used to render layouts and replacing it with something akin to what underpins the block editor.

    Where this journey takes us maybe as much governed by push back against what core WordPress stakeholders dictate we need in the CMS. To put this in context, if I look back to the transition from Mac OS 9 to Mac OS X, the first iterations of X were very rudimentary and lacked much of the functionality that was present in 9. Apple had to really push the boat out in terms how the OS looked and worked. It took them about five years to persuade a big majority of veteran users to convert and, in the process, implement new things that would really impress when it came to a new way of doing things. There is an almost messianic zeal in all these transitions (would you call this opinionated?) but eventually things give way to accommodate what is necessary.

  2. It’s amazing how much we once relied on widgets. That screen was always so detached from the site’s design, but it did the job.

    I can imagine that, once full site editing takes hold, they will be pretty much a dead tool. The entire look of a site will be much more tightly integrated, which is a big step forward.

  3. The block editor itself is great. But when testing block-widgets, it feels like a square peg in a round hole. It just doesn’t work well. It’s the wrong use of the block editor IMO.

    I think it’s best to let the-old be the-old, and let the-new be the-new. When the-new is good enough, people will use it, and be excited about it.

    Defaulting (and somewhat forcing) people to use the-new by shoehorning it into the-old causes problems all around for everyone (users, devs, community trust, etc).

    I believe these are easily avoided problems if the approach could be changed.

  4. A few weeks ago, I tweeted, “Really (really) looking forward to the #WordPress 5.8 release. In fact, I have never been this anxious about an update.”

    While I look forward to working with the new blocks (site logo, site title, site tagline, etc), I am really excited about the block-based widgets screen I understand that it is merely a stepping stone for users/theme developers right now, it still is extremely useful for certain use cases.

    Using sidebars/widget areas to display/output footer widgets has always been such a clunky experience. I know this because of the years I spent at StudioPress, we had to be creative in how we chose to use them.

    Now, we can register one widget area and let blocks/columns do their thing. Such a simple, yet beautiful, way to move things forward.

  5. Whenever I need to put a widget into a post or page I thinks twice. It’s so unpredictable – sometimes it works only to break page later, sometimes it doesn’t. Depends on widget, WordPress Theme, WP version – unpredictable.

  6. It’s funny, widgets were already a blocky way in WP. You had a block (widget) to use with a lot of functionality.
    Now, it’s time to retirement. It has accomplished a lot.

    But I feel this new switch could be an opportunity to go further. Since so many users will have to adapt, why not in a big way?
    I’m thinking on CSS Grid.
    Maybe it’s a good time to implement it in WP as core? (sorry if any term is a bit displaced, I’m not a big structure expert)

    As it is useful to have a widget anywhere, eventually it will be very useful to switch blocks around.
    We have a ‘header’, a ‘footer’, a ‘content’, why not a ‘left’, a ‘right’ or even a ‘my-favorite-spot’?
    And they can be anywhere we want with the specific blocks we want in each.
    And in different locations according to media-queries (desktops, mobiles, print, etc)
    With Grid (grid-template-areas) we can have these powerful way of constructing blocks.
    Maybe it’s too soon to implement but never to soon to talk about it.

  7. I’m digging into WP 5.8 RC at this time with a new theme I am building. I wanted to see how this new widget screen worked. What is funny is that I suddenly realized there are no title/heading fields to the block widgets. I’m like, no, really? seriously? If I use the new Classic Widgets plugin to revert back, the title fields are still not there.

    I also discovered a nice feature I put into my themes which allows the user to change the blog post excerpt word count, rather than do a global function that cannot be changed. Unfortunately, this overrides the Recent Post block excerpt setting.

    I can say that I like the fact the widgets have more options, such as the recent posts and comments, including post thumbnails–now I don’t have to code these into the themes. However, I still might have to do this until the Block Widgets are bug-free.

    There are a few other quirky things that I am discovering, but I am not sure how to proceed with theme development when it appears the new widget screen method is buggy and missing some important things.

    • I’m just skipping this phase altogether and going 100% blocks. That’s obviously not an option for folks making a living from themes right now.

      For your excerpt issue, this Gist might be of some help if you want to make sure that you’re only targeting the main query on the page.

    • No change. The block-based widgets system is just a layer over the existing sidebar/widgets system.

      In the future, block themes will not use sidebars or widgets at all (not the current APIs anyway). So, themes will not register them. They will just add blocks wherever they prefer.

  8. Problem I’m seeing is that scripts are being loaded once for every single widget in every sidebar that you have. For example, I get WPfeatherlight script loaded 20+ times when I load my widget page. The same thing for almost every plugin I have that loads a script. Optinmonster, Rank Math etc.

  9. So, my question is what about the widgets that had been setup before updating to wp 5.8. I know longer see where my widgets are at. Everything on the frontend is still there, but what If I need to change content in my widgets where is it? Anyone???

  10. Broke 100% of the sites it was activated on. I was looking forward to maybe being able to use Guts for this kind of thing. Stuff clients rarely touch and is meant to be coded/reusable. I thought tbh blocks would make sense and in ways it was already the only true use case for reusable blocks, if SEO is a concern in any shape or form. There is never a good idea to bake copy into HTML. But I cant get this to work while disabling Guts in the editor. Its most likely not worth investing time in now. But I mean widgets for me for the last decade have been simple things, copyright notices, maybe a search box for a side bar. Categories for WooCommerce. So not really sure what this is meant to do? Many builders already have the reuseable idea and block templates you can pre make/buy etc. Anyways another 5-15 hours wasted, explaining to folks why the CMS I constantly used to praised has now gone off its meds yet again.


Subscribe Via Email

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

%d bloggers like this: