WP Tavern › Forums › Create Topic
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.
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.
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
