irishetcher

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.

I have. Sent plenty of feedback to the Gutenberg team, like many others, only to have it fall on deaf ears.

Some of my criticisms:

____

The whole Classic Editor plugin approach is very clumsy and unnecessary considering that Gutenberg is in effect just a react override of the current editor, much like enabling a builder plugin might work. The only difference is that Gutenberg takes over the whole backend interface.

Fom my understanding all the workings of the current editor will be extant in WordPress 5 with Gutenberg activated as the de-facto default editor. It is feasible therefore that only new installs would activate Gutenberg with a switch in writing settings to trigger a Gutenberg -> true/false filter.

There is in fact a filter that can be dropped into the functions.php file of a theme that prevents Gutenberg from being active on all posts. At the moment the folks behind Gutenberg have stated that that filter will get a name change once Gutenberg is folded into core. To date that name change has not occurred and no guarantee that there will even be a name change. This suggests an element of control in the Gutenberg camp. Having a concrete filter would make it feasible for theme vendor to use it saving their users being dropped into Gutenberg.

I have been using and testing Gutenberg for a while now and some plugin developers have gone to great efforts to make blocks that potentially could be very useful. What lets them down is Gutenberg itself. The bugginess of the configurations, especially if you use it on a theme that wasn’t built for Gutenberg suggests that a complete separation of only using Gutenberg on new builds with Gutenberg specific themes and plugins is the only route.

I use Divi for work and this make Gutenberg redundant for me. But I do see a better built Gutenberg being a good starting point for those new to WordPress, web design and development. My understanding is that Gutenberg was supposed to be unifying in that it would provide a common foundation for content and make changing theme less painful. In many respect it does none of this because it has gone in the opposite direction of layout towards micromanaging more granular elements.

And there are many other issues that need to be resolved like where do all the custom fields go if metaboxes are an after thought. There is a all in blocks solution which potentially could work down the road. Providing a mechanism to only have one classic block for basic content creation and/or a de-block mechanism to take everything back to a singe classic block are two other important pr-requisits to making Gutenberg more usable.

The biggie though is something that Gutenberg share with the current editor and that is the lack of a proper code view. its a big bug bear for me and always has been. I like the fact that in Gutenberg you can target the html in each block. The big let down is that it is often not human readable. It needs to be more like an IDE as a work environment with colour syntax highlighting, proper formatting with nested indentations and perhaps code completions and code folding. We see how this achievable with Froala editor and Code Pen. Recently WordPress introduced Code MIrror and what we need is further development of this and for it to be used in far more places other than the HTML block. This would go some way to making working with blocks and how it handles delineation with comment tags more useable and palatable.

_____

On the bugginess and block disintegration, to be honest I have been hammering Gutenberg switching between themes etc… I wouldn’t be too worried at this stage as a lot of these issues should be ironed out with time. I am sure that Gutenberg will become more robust. In the meantime…they shouldn’t make it default and I don’t mean this in a bad way. There is always a place to push out new software to make it grow, take feedback and improve. We had this when OS X replaced the older mac operating system. it took up to five years for Apple to get the new operating system mature enough to be adopted by most users.

A few quick things on the interface in you block settings. You have the three device (desktop, Tablet, Mobile) selectors a the top. I would expect that when clicking these would animate the content down to reflect previews for those breakpoints. Maybe that’s something that is coming in phase two for the customiser in Gutenberg? I am not sure if you are familiar with Divi. In the visual builder on the front end in the settings panels, each section operates like an accordion, only the settings you are working on are open, all others are closed. It affords a less busy workspace and makes it easier to find what you are looking for. Again, probably something for Gutenberg to get right.

Also, very annoying that if you enter a post then navigate away you get a warning to update, even if you made no changes.

Thanks. Sometime in the Winter months, if we get snowed in again, I’ll have a look through the workings of custom blocks.