15 Comments

  1. Stephen Vaughan

    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.

    Report

  2. Eric Karkovack

    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.

    Report

  3. Phil Johnston

    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.

    Report

  4. Brian Gardner

    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.

    Report

  5. Joan

    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.

    Report

    • Francesco

      Never use latest version of “rapid release” software on live websites before extensive testing on staging.

      Report

  6. Adekiya joscor

    I still prefer the old editor to this.. Find it hard to navigate.

    Report

  7. Ricardo

    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.

    Report

  8. Andre

    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.

    Report

    • Justin Tadlock

      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.

      Report

  9. Carrie Dils

    With the addition of block-based widgets, do you know if there will be a change to the way we register sidebars?

    Report

    • Justin Tadlock

      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.

      Report

  10. DC

    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.

    Report

  11. Jo

    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???

    Report

  12. Niall Flynn

    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.

    Report

Comments are closed.

%d bloggers like this: