Gutenberg: Still missing the essentials

Updated Gutenberg Review: Oct 2018

________________________________________________________________________________

CheckIng out the latest build of WP 5 and Gutenberg 4.1.1 and I have to say with a minimal configuration of plugins it does show some promise.

The good points first:

Using re-usable blocks as templates has some promise.
Likewise for custom post fields
Works best if you use it exclusively on its own and with a theme built for Gutenberg

As usual though there are some caveats.

The first thing I noticed is that the only way to disable Gutenberg is with the Classic Editor plugin. All other methods, simple one line filter in the functions.php file or a third party plugin will not work. For the filter we do know that it is the intention to provide a new version/name for this once Gutenberg is in core and perhaps the third party plugins depend on this filter somewhere in their code. It does beg the question though is the Classic/TinyMCE Editor still extant in core. It is a question that needs to be answered as we have been led to believe that this is what we have been told previously. Automatic core team has been a bit vague on this. Knowing what those options are going to be would be very helpful for those of us who need to continue working with the current editor for the foreseeable future

Of course the other caveats are my usual bug bears namely the lack of attention for the code view both in general and for each individual block. Code badly formatted, often minimised and could do with a bit of love by providing an IDE text editor like environment for it to be more useful. Code mirror was recently introduced to WordPress and it needs to be developed further and pushed into more corners of WordPress.

While blocks are useful they don’t always work well for many use cases, namely data entry and simple text editing. The current editor affords the ability to add custom field groups in metaboxes that can be arranged and hidden into whatever configuration suits the given workflow at the time. This includes the settings panels for Featured Image categories etc. To date the standard controls in Gutenberg are static; you can’t move Featured Image or Categories. And a bug remains whereby if there are no metaboxes below the content you can’t manoeuvre any from the right sidebar to below that location and likewise if you don’t have any no standard panel in the right side bar you can’t move a panel from below the content to that location. The only workaround at the moment is to edit the interface through the classic editor.

For simple text editing an option to allow users to work with a single classic block as default for a new post/page would go along way to winning over users who only need this basic method to add content and don’t initially want to go down the block route. On top of this the ability to de-block content to one classic block would be a convenience on many levels. One that comes to mind is where a developer wants to radically re-do the layout of a page.

On the layout side of things, Blocks need to do a lot more for structure, sections, rows, columns, flex etc. Some third party vendors have made some efforts but I have found these buggy and really it should be the purview of Gutenberg to provide a common foundation and API for theme, plugins and builders to sit upon. Too often I encounter the error block with third party blocks and the options never resolve the issue. It’s a case of discard and start over.

I’ll move onto the the features which are not bad. The new button in the tool bar does help a little to locate blocks but you should be able to find these directly in the content.
The columns block is now improved with padding on the front and now responsive. A bit more work though still needs to be done on spacing and the mind boggles why blocks haven’t had padding and margin strings from the get go.

My test site used Divi and while, as has been highlighted, many elements from third party plugins/themes that previously appeared in Gutenberg are missing, I found with Classic Editor plugin activated, that everything behaved nicely. I could opt to run with the Classic Editor for Divi pages and custom post types or just do a Gutenberg page. This separation of church and state works well which begs the question why Gutenberg is being implemented and introduced to WordPress users in such a crack handed manner.

The on-boarding tactic has been all wrong which, incidentally, falls under the remit of UX.
We would be better served if Gutenberg was only default on new installs, had a simple filter controlled by a switch in Writing settings to enable/disable Gutenberg/Classic Editor. There is no need for an extra plugin in the form of the Classic Editor plugin.

The one immediate issue that needs to be tackled is the on page UX. targeting and manipulation of blocks is rife with pitfalls which is a shame as it detracts from the usefulness of Gutenberg. From experience many of these hiccups lead to bad results and is the one reason Gutenberg will fail for the vast majority of users, either because they are not used to such esoteric interfaces or because it is perceived that Gutenberg is not as sophisticated or stable as the current builder already on the market.

It’s a shame as some of the interface and the ideas behind Gutenberg are quite exciting.

UPDATE: Disable Gutenberg is updated and now works with WP 5.

And, digging around in Classic Editor plugin I found the following:

add_filter( ‘use_block_editor_for_post_type’, ‘__return_false’, 100 );

Adding this to the functions.php file ( preferably a child theme ) disables Gutenberg in WordPress 5, no need for a plugin.

You can pre-populate this filter into current 4.9.8 versions so they are ready when WP is officially launched.

Caveats: the above filter won’t disable the plugin version of Gutenberg and we could see another name change to the filter.