35 Comments

  1. Gary Taylor
    · Reply

    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é…

    Report

    • Andrew
      · Reply

      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.

      Report

  2. Sally G
    · Reply

    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!

    Report

    • Ciprian Popescu
      · Reply

      I stopped using widgets a long time ago. I even de-register them on my themes and hide the widgets screen. I find the Reusable Blocks better suited for this, coupled with custom option to show specific Reusable Blocks in specific areas.

      Report

    • Justin Tadlock
      · Reply

      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.

      Report

      • Sally G
        · Reply

        Thanks; that makes sense. I guess determining where that point is, to release, is more of an art than a science.

        Report

      • Patrick B
        · Reply

        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.

        Report

  3. Anthony Hortin
    · Reply

    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.

    Report

    • Tom J Nowell
      · Reply

      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?

      etc..etc..

      Report

      • Anthony Hortin
        · Reply

        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.

        Report

    • Justin Tadlock
      · Reply

      I’m involved with several projects that will need classic widgets but not the classic editor. For such sites, it makes sense to have a separate plugin.

      Report

      • Anthony Hortin
        · Reply

        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.

        Report

    • Ben Ditto
      · Reply

      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.

      Report

      • Márcio Duarte
        · Reply

        Changing a plugin’s name is a big deal, specially this one.

        Report

      • Anthony Hortin
        · Reply

        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.

        Report

        • Tom J Nowell
          · Reply

          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.

          Report

    • Daniel Richards
      · Reply

      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.

      Report

  4. Garima
    · Reply

    Hey I am using Classic Editor and Gutenberg but when I update WordPress and which I click to add a new post, page, and its soo blank wp-admin/post-new.php, please help me why

    Report

  5. Otto
    · Reply

    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.

    Report

  6. Andrei Draganescu
    · Reply

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

    Report

  7. Patty
    · Reply

    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.

    Report

    • Sally G
      · Reply

      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.

      Report

  8. Niall Flynn
    · Reply

    Funny but 50% of the plugins I already install are to disable/de-bloat WP. It has needed a features dashboard for years, the ability without plugins to turn on and off things like Comments, heartbeat, tags etc.

    Report

  9. Robin Barton
    · Reply

    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.

    Report

    • Tom J Nowell
      · Reply

      Can you report this on WP Trac? https://core.trac.wordpress.org/

      That sounds like a serious bug, any information you can provide would be super helpful, particularly for reproducing the situation

      Report

      • David Cloyd
        · Reply

        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.

        Report

  10. Lasha
    · Reply

    On some websites, there is still an old widgets interface after the 5.8 updates. What could be aproblem?

    Report

    • Justin Tadlock
      · Reply

      My first best guess would be that your theme has disabled block widgets. Some theme authors got ahead of this and added the code for disabling them before WordPress 5.8 was released.

      Report

      • David
        · Reply

        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.

        Report

Leave a Reply to Anthony Hortin Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: