The new navigation block and navigation and widget screens that were originally planned for WordPress 5.5 have been pushed back to the next release. These projects are currently available in the Gutenberg plugin experiments screen but are not yet ready to land in core.
Converting the widget-editing areas and updating the widgets UI to use the block editor is a project that has been under development since January 2019. The issue tracking the project and the dedicated project board seemed to have stalled out for the time being, so core editor contributors recommended removing it from the priority features for 5.5.
Similarly, the navigation block and screen have several dozen outstanding issues and discussions that need more time before shipping.
“We’re still missing a few key components: drag and drop in the block and in the sidebar, a couple of PRs that lag and are important for feature parity (#22600, #22697) and the ongoing work to support more block types in Navigation,” WordPress contributor Andrei Draganescu said regarding the remaining items necessary to ship the navigation screen.
“I believe we’re in a place where a Gutenberg release after 5.5 will include this new screen, but maybe in the next two weeks some acceleration will occur and prove me wrong.
“I believe that it is wiser that this lands as a part of the plugin first, gets some feedback, and then is shipped into core.”
Despite the navigation and widgets screens getting removed from the 5.5 milestone, this release is set to deliver an impressive array of new features for the block editor, including block patterns, block directory search, a new block inserter panel, expanded design tools, and improvements to block movement capabilities. Beta 1 is expected July 7 and the target date for the official release is August 11.
While, all these new additions are to be lauded in terms of ambition, I would like to see WordPress more focused on getting the block editor properly implemented and polished. Yes, the upcoming improvements in WordPress 5.5 will be a big step up for the block editor.
But, now that we are getting used to the benefits of the block editor such as saving without having to reload the UI in the browser, is it not time for Auttomattic to give us these benefits on the back end of WooCommerce products?
WooCommerce opperates primarily in the realm of metaboxes. That’s all you need for data entry. So, I don’t see too much work to done there. Just strip out the the block building side of things. The front end should be provisioned by templates in any event: build once, use many times.
I have, in fact built a rudimentary plugin (for personal use) for custom posts types where the purpose is to just show the associated custom field groups in metaboxes in the block editor. It’s designed for clutter free data entry. The client can’t screw things up by a sudden urge to add loads of elements in the block editor part because I have that part of the block editor styled out. In any event, disastrous creations would not appear anyway because a template is slapped on the front end to ensure uniformity and correct layout of elements and data provide via the custom fields.
There is nothing wrong with the block editor in and of itself. It is quite a good solution out of the box but suffers from things like a plethora of third party block solutions to add extra functionality to things like headers fo example. The result is many blocks doing the same thing but different interfaces to apply things like padding. The danger, down the road is that the third party plug is disabled, not developed anymore or, and other myriad of issues leading to the block malfunctioning. If third party block solutions were designed to override core blocks they are disabled, the core block and content is not effected.
The beauty of overriding blocks is that it would also address the whole question of page builders. To use or not to use? By providing an API to override block elements, builders such as Elementor, Beaver Builder or Divi could integrate over the block system by adding their own functionality and interfaces. If any of these are not to anybody’s taste, at least if they are disabled the content would remain intact.
I suspect though, anything as sensible as this is not considered by the people behind the Gutenberg project because the agenda there is to deprecate what they call the mystery meat of things like short codes and and metaboxes and to create something proprietary in the vain expressing an opinionated view on how things should be done. The problem with this is it doesn’t take into account many practicalities and in a funny way introduces it’s own new world of mystery meat.