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.
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.
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.
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:
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:
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.
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.