Gutenberg Best Practices, Version 1

Every complex tool has multiple ways of doing things. A table saw, for example. Out of the box it is a big machine that may have come with a single saw blade to help you get started. The table saw industry has a number of add-on providers that offer a very wide variety of blades, some for general purposes, some for specialty purposes. None of these add-ons are intended to fill in missing core functionality – they enhance the experience. With the current version of the Gutenberg block editor this is not the case. It was shipped missing core functionality – equivalent to shipping a table saw without a core feature such as a power cord, or a wrench for attaching and holding blades on the shaft.

An example of Gutenberg’s missing core capability that has been back-filled with an add-on (plugin in the vernacular) is adding color to individual text contents e.g., words, letters, and numbers. As shipped the block editor will let you paint the entire contents of a block any color you want. But not individual characters or words. So naturally, someone has created a plugin that will do this and that is all very fine.

I anticipate (and am aware that an early attempt has been made available in a block suite plugin) that plugin developers will create a very useful block that allows nesting and arranging other blocks within it, and that each nested block will allow the author to place the blocks into an ad hoc arrangement that would allow the creation of a live object as illustrated below and which was possible to do in the 1980’s. Every element was a letter or white space block border (currently possible with CSS) made within the tool and fully editable (no images were required to produce this and it could be made into a re-usable and shareable template). And each plugin author working independently will plop such a block into a plugin that is a suite of blocks unaware that dozens of other authors are working at the same task, and that there will be endless functional replications of blocks littering the block selection tool – this is an applied form of chaos.

It is early in the Gutenberg experience and many people with the capability are rushing out various block plugins. But do we want to depend on good will over the lifetime of our pages and posts on a Samaritan’s hard work to create and maintain these plugins? And is it fair for these plugin authors to make these available and to generate a bit of income by accepting donations for what they do only to later see WordPress add the functionality to core?

And ignoring what is or isn’t fair, is it best practice for our businesses that depend upon these plugin authors because the essential components are missing from the WordPress CMS? I for one submit it is bad practice to depend upon volunteers from outside the WordPress organization for core (essential) features and I will not be caught up in installing endless plugins to bring essential features into my tool kit. And that is why the words “bad practice” above are not bold and red. I’ve decided to not install a plugin that will let me do that. Gutenberg himself would do the same.

Another best practice for any dynamic tool is to watch the trajectory the developers have made public. This is necessary if that trajectory does not match our individual future needs and which might necessitate changing tool vendors. So to that end, here is what WordPress.org says about the future:

“I’m not saying it always has to be me, but what I want is a strong, opinionated, thoughtful leader setting a bold direction, taking experiments and being willing to fail, comfortable with failure, is I think what you need to create great software”

— Matt Mullenweg