Classic Widgets Plugin Disables WordPress 5.8’s Upcoming Block-Based Widgets System

Yesterday, WordPress released a core plugin named Classic Widgets. Core contributors Tonya Mork and Andrew Ozz created the plugin under the WordPress Contributors account. It allows end-users to disable the upcoming block-based widgets system. Support is expected through 2022 or as long as necessary according to the plugin description.

Decided last month by a small group of core leads following a demo, WordPress 5.8 will ship several sub-components from its Full Site Editing project. FSE encompasses several self-contained parts that grant users broader control over the design and layout of their sites. One of those pieces is an overhaul of the widgets system.

Widgets will one day become a legacy feature of the platform. However, they are not disappearing any time soon. During the transition from the pre-block era of WordPress to the eventual incorporation of all the sub-components of FSE, users and theme developers will sometimes need smaller stepping stones. Block-based widgets give users more ways to work with blocks outside of the post content area without diving head-first into an entire block-based experience.

This is the first time many in the larger WordPress user community will be exposed to blocks in a new context. The editor that launched in WordPress 5.0 focused solely on the post content. The widgets system in 5.8 turns classic sidebars into block containers.

In short, users will be able to stick any block in any sidebar.

Widgets screen that turns each theme's sidebar into a block container.
Block-based widgets screen.

This is a welcome step in transitioning users in the long run, especially those who use classic themes, which is still the majority of all users. However, there are cases where the Classic Widgets plugin will be necessary. The biggest will be:

  • Broken themes or quirky output.
  • Users simply preferring the old system.

Whatever the case may be, the plugin handles the switch.

For those wondering why the core development team is not making sure block-based widgets work with all themes, it is because the two systems are not exactly alike. Plus, every theme design handles its sidebar output in its own way. There is no way to ensure 100% coverage.

Many themes will have no issues at all. Some sidebars, depending on the design, could entirely break down. More likely than broken, custom sidebar and widget designs could simply look “off” on the front end.

For example, compare a Heading block followed by the Archives block (first image) against the classic Archives widget (second image) when using the Twenty Fifteen theme:

The typography of the Heading is different, and there is too much space below it. That is not an end-of-the-world scenario. It is the sort of quirk that may be common with many themes, at least until theme authors have had time to push out updates.

What Happens When Activating the Plugin?

The traditional WordPress widgets screen with draggable widgets and sidebars.
Classic widgets screen.

Classic Widgets has no settings screen or anything to configure. It is a set-it-and-forget-it plugin. Its goal is to simply return users to the traditional widgets system in which they are familiar.

If you start using the new block-based widgets system, you will lose all of your widget blocks upon activating the plugin. There is no going back, so be sure this is what you want. The former blocks will not reappear if you change your mind and deactivate Classic Widgets.

However, if you add traditional widgets to your theme’s sidebars while the plugin is active, you will not lose them. They will still appear on both the front and back end if you deactivate the plugin.


35 responses to “Classic Widgets Plugin Disables WordPress 5.8’s Upcoming Block-Based Widgets System”

  1. This reminds me of the issues I had with Widgets in my new theme (last year). Some of the built-in widgets didn’t act correctly (fonts, spacing, missing headings/titles) as blocks and my own-rolled ones didn’t always behave as expected. In the end I converted them all to shortcodes and used the Shortcode Block to insert them.

    My next worry will be whenever someone decides that shortcodes are passé…

    • whenever someone decides that shortcodes are passé…

      They are slow, limited, buggy, old tech, but don’t think they will ever go away for the “sidebars” that hold widgets. Would be really nice to stop using them and replace with stuff that has nice UI and doesn’t slow down on the front-end.

  2. Is seems to me that the block widgets are not really ready for prime time yet; shouldn’t they have been an option, rather than automatically installed, until they can yield the proper finished results?
    New options often don’t work properly at first; I guess it can be difficult to decide when to send them out. As an amateur, I am feeling what little I know shifting under my—well, not feet; fingers on keyboard? Paddling madly!

    • The feature works pretty well, and even the customizer aspect of it is better than what I thought it’d be. At a certain point, you just need to put software into the hands of users and iterate based on their feedback. Otherwise, you’re just building within a bubble of like-minded developers. The biggest known issues (like the theme issues) were always known, and they’re going to come down to theme authors addressing them on a case-by-case basis.

      Personally, I plan to mostly skip over block widgets and start moving toward full block themes with “block areas” instead of sidebars/widgets, at least on projects where I can.

      • What’s the difference between Widget Areas (with the new block-based widget screen) and Block Areas? Do you mean essentially adding your own template of blocks through the FSE template interface? When I switch to doing all my site build in the block editor I also got rid of the widget as well and rolled my own implementation, which I also call block areas. But that was mostly because the new block-based widget screen wasn’t available yet, even though I am rarely using them for sidebars.

  3. Why was this functionality not included in the Classic Editor plugin!? If someone is using the Classic Editor (plugin), they obviously don’t want to use Gutenberg, so it makes sense to automatically disable the new Blocks Widget Screen as well. Instead, people who are using the Classic Editor are now forced to install yet another plugin.

    • Because if you want to use gutenberg to edit posts, but aren’t ready for the new widgets screen then you would have no options.

      Maybe your widget was built in a very fragile way and you don’t have the budget to fix it?

      Maybe you need to write up client documentation before moving to the new widget screen?

      Maybe you built a plugin that modifies the classic widget screen or repurposes it for conditional sidebars?


      • Having this feature included in the Classic Editor plugin doesn’t stop any of this functionality. The Classic Editor plugin already has an option for selecting the “Default editor for all users”. It would be a simple addition to add an extra option for selecting the “Default editor for all Widgets”. It makes sense to keep like functionality (i.e. disabling of Gutenberg) all in the one plugin.

      • As I mentioned above, having this feature included in the Classic Editor plugin wouldn’t stop you from doing this. With a simple option for selecting the “Default editor for all Widgets”, next to the other existing options, would allow you keep using Gutenberg while also disabling Gutenberg for the Widgets screen. I think it makes sense to keep like functionality (i.e. disabling of Gutenberg) all in the one plugin. It certainly helps end users, in particular those millions of users that are already using the Classic Editor plugin.

    • I think what Anthony is trying to say is that it should have been an option on the Classic Editor plugin rather than a separate plugin entirely.

      The plugin’s name would then have to be changed, but it would create a more unified, coherent experience.

      • Thanks. That’s exactly what I’m suggesting. The Classic Editor plugin already provides a couple of options so there should be no issue in adding an extra one to select the editor type for the Widgets screen. I don’t think the plugin would need renaming either. You’re still effectively using the Classic Editor when using the “old” widgets screen. It would be a much better experience for the existing 5M+ users who are already using this plugin, to not have to now install yet another plugin to also remove Gutenberg from the Widgets screen.

        • This leads to several problems caused by the default setting problem.

          If it disables the widgets by default then that can be undesirable. Some people use the classic editor to avoid the block editor, but some user it for compatibility reasons, e.g. custom functionality from when they built their site they don’t have the budget or knowhow to replace.

          If it doesn’t disable widgets by default then that means it’s not enough to install the plugin. The first reaction will be that it doesn’t work.

          On top of that, automation can’t rely on installing and activating the plugin, which makes automating it much harder and beyond the scope of some users until they gain certain developer skills, gatekeeping the feature.

          There’s also the argument that the two plugins are not very similar, and that the only thing they have in common is that they disable something block related. The block post editor is not the block widgets screen. But if they are the same, and if that’s the case then why not make the classic editor a checkbox in the Gutenberg plugin? And merge the plugin that disables block patterns? What about the overhead of the code that manages all these settings?

          In the end, a simple plugin with no UI that you install and activate is the simplest, fastest, and most efficient solution. There’s also nothing preventing an all in one bundle plugin being put on the .org repo.

          A final note, the classic editor does not contain the classic editor. It’s just a chunk of code that removes block support from the default post types and deregisters some scripts. The actual classic editor itself is still inside WordPress core. I expect the widgets screen plugin is the same.

    • I think the issue more than anything is what happens when the classic editor plugin is installed. By default it disables the post block editor. For users who only want to disable the widget block editor it’s a less than ideal experience to install a plugin, realise it disabled more than they desire, and then have to look for the settings to get it back to the way they want it.

      It might be ok for an experienced WordPress user, but for most it’s a bit easier to use a plugin that enacts the desired behavior upon installation.

  4. I wish transtional plugins like this were not needed, but given the scope of the changes, I do understand them. There will be a period of adaptation. Plugins like this are a good thing, they keep the lights on while the new systems are built and improved upon. Good article.

  5. Great article! Covering the opting out mecahism and the rationale behind it is very helpful with such a visible UX change. Thak you!

    If you start using the new block-based widgets system, you will lose all of your widget blocks upon activating the plugin. There is no going back, so be sure this is what you want. The former blocks will not reappear if you change your mind and deactivate Classic Widgets.

    I think this was a bug, it’s definitely not the intended behaviour. Opting out of the block based Widgtes Editor and then opting back in should preserve all data, no matter how many times one does it :)

  6. Glad this new Classic Widgets plugin is available. I certainly don’t mind spending 30 seconds to download and install another plugin — not sure why all the whining about that. I have a lot more control if the two plugins are separate.

    • We users hear so often about possible plug-in conflicts, about older plug-ins maybe being security risks, that it seems sort-of automatic to prefer fewer. I am with you, however, I have a number of plug-ins on which I rely and am glad to have functional, well-maintained ones in my site.

  7. I appreciate this plugin so much! I inherited a website with 8 custom widget areas on three different page layouts. All the widgets were disconnected from their areas when I upgraded to WP 5.8. Downgrading did not help, as they were still disconnected. So at least I was able to reconnect everything the way I was used to doing it, plus my areas didn’t show up in the new block editor.

      • I’ve had the exact same thing happen to me on several sites. It kicks the old content out the widgets, rearranges the content, and sometimes it appears as unusable inactive side content listed above inactive widgets. I am having several different situation happen in different sites using the same thing (Bridge by Qode) and in the worst cases, I can’t get to ANY of the old widget content to reorganize. It just looks like it disappears. Sometimes it stays in the site, sometimes it doesn’t. I agree with something I read above – I don’t think Block Widgets were ready for primetime, and I disagree with the idea that you are forcing all users to rebuild this functionality Blocks. I personally have found Blocks to be terrible, I can’t get behind that.

      • I know the theme hasn’t blocked them, because it brings up Block Widgets until you install Classic Widgets. But even then, upon theme update, the widget content gets shuffled around and reassigned, and I’m unable to save them even if I get them reorganized – I get an error that says “There was an error. [object Object]” I didn’t see anything in server php error log directly related to this. I’m waiting on the theme developers to look into it a little bit more.


Subscribe Via Email

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

%d bloggers like this: