Note: Like the last article, this one is also reprinted from my Medium account. But hey, given TAZ is a community of web developers and forum admins, I thought they'd like to hear a bit more Gutenberg and its issues too.

It’s time to return to Gutenberg, and see how things have changed.

Cause a month or so ago, I reviewed it in a lengthy review. In said review, I went over its pros and cons, the bits that were there and needed work, and the various use cases the editor had. In that post, I said Gutenberg had a lot of promise, and that with a bit more polish it could truly be turned into something great.

But now those months have been and gone, I feel it’s time to look at the editor again and see how things have shaped up. Is it now usable by normal people? Are the bugs now a thing of the past, or at least rare enough to be worked around?

Well, the news ain’t good. After a few months, Gutenberg is still unstable. It’s hard to use, and it’s still got a long way to go before it can become the tool it desperately needs to be.

So in this instalment, I’m gonna go over the reasons why Gutenberg still isn’t ready, and why said issues will need to be sorted out before the tool can truly hit the mainstream.

Starting with usability problem number 1:

The interface for nested blocks. Put simply, it’s terrible

And that’s because actually selecting the blocks is an absolute nightmare. Seriously, nest two or three levels of blocks in Gutenberg, then try to select one of the outer ones. It’s absolutely hell due to how fidgety and awkward the editor feels to use, and how bad the ‘click detection’ is for each block there.


Nested blocks get annoying extremely quickly

And that’s the reason my more ‘ambitious’ attempts at block based building in the editor (like letting people use it to place down Bootstrap columns and rows) got put on the backburner. In theory it’s possible to implement, but in practice it’s makes for a maintainability nightmare.

Which in turn brings us to issue number 2. Namely, how easy it seems to be to accidentally create empty paragraphs in Gutenberg.

Just add a paragraph block inside a container block, then click out to edit something else. A good 50 or so percent of the time, you’ll be unable to actually click the paragraph block you added to type in the text.

Which in turn means you need to go through hell and high water to fix it. Like say, looking through the post content field in the database for that one tiny p tag with nothing in it, then entering in some dummy content just so you have something to select later on. It’s annoying, and an issue that makes you realise how poorly done the interface for selecting blocks actually is.

And the issues don’t stop there either. Nope, shortly after testing Gutenberg on my site, I actually had the whole editor crash with an error message, and then continuously fail to open any more posts after that. That’s not acceptable for a piece of software that’s supposedly ‘gone gold’, and it makes you question how the team and community thought this was an acceptable state to release the new editor too.


What the hell is this? What does an ‘unexpected error’ mean?
It also illustrates a huge issue with modern day JavaScript based development too. Namely, the tendency for systems using JavaScript frameworks to fall to pieces the minute there’s anything resembling an error or edge case.

Unfortunately for us, Gutenberg is no exception. Indeed, if any block used in a post has a scripting error in it, the editor will just fall over and die.

Just like that. No error message, no redirect, no fallback to the standard editor… just a random white screen with an error in the console. Yeah, brilliant UI design there guys. Truly something that all those grandmas and mummy bloggers will be used to in no time!

Hello? The reason the internet took off to begin with was because errors weren’t the be all and end all. People and systems could make mistakes, and things would keep running.

That’s why XHTML failed to catch on. People didn’t want their pages to die on an error message whenever a tag was incorrectly formed and XHTML was pushing towards that becoming the default setup.

Yet it’s become the norm for JavaScript based sites and apps in recent years, including for a system like WordPress where many plugins are written by amateurs, conflict with each other and fail to work on various operating systems.

It’s a disaster waiting to happen, and a system that’s sure to lead to many, many angry phone calls and emails from clients and customers alike.

And it’s a problem that’s only made worse by the way block validation works with Gutenberg. That’s because Gutenberg’s blocks will break the minute the underlying setup is changed, or where the setup the block expects doesn’t match the content of the article.

That’s not a bad idea on the face of it. There are some instances in which you want to check that the content in the database matches the block setup in the editor, and it probably does stop a few issues in a few edge circumstances.

But it also adds a ticking time bomb to every website using the system. That’s because while in theory a developer can add code to let content written for old blocks degrade gracefully, it’s likely a good many won’t.

This means that thousands of casual users are probably going to update their Gutenberg block plugins, go back to a post they’ve made, and be presented with a few hundred blocks that look something like this:


That looks horrifying if you don’t know what it means, and even if you do, the merge/redo options generally don’t merge the content to the new block format at all (instead giving you a basic HTML block). This again means web developers are going to get hundreds of angry emails and phone calls from clients whose sites seemingly broke after an update or two.

However, the Gutenberg support woes don’t end there. No, you see, Gutenberg’s blocks are not stored as unique rows in a database. There’s no ‘registry’ of blocks listing which ones are in use in each post and mapping them to the content.

No, instead all the block content is stored as commented chunks of HTML in the content field of the post table. This means that if a block is edited by the developer, all existing uses of said block will not also change along with it.


This is how blocks are stored in the database
This means fixing display issues becomes an absolute chore. First you have to fix the code for the blog, then go into the post, then fix the broken block now you’ve changed the source code, and finally then replace it with a new one using the new code. In turn, this puts a lot of pressure on developers, since their blocks basically have to be perfect the first time around, otherwise they’ll be going back and editing every single post using said blocks on the client/company’s website.

It’s annoying, it’s archaic, and it means that fixing small issues in blocks is a huge hassle that takes far longer than just editing the content in the database or a template would. And this is supposed to be more convenient how exactly?

It’s not. It really isn’t.

Which is especially noticeable when combined with the lack of organisation the tool has to begin with. For instance, what order are the blocks here listed in?


Give up?

Yeah, we don’t really know either. It’s clearly not in alphabetical order, some sort of number order or based on their level of importance. In fact, the only remotely plausible guess we could give you is that it’s based on how often they’re used by the user, an order which doesn’t make writing posts quicker or more convenient in the slightest.
Worse still, you can’t sort it either. Nope, there’s nothing to sort it to you liking here at all. No category drill downs, no order selections, no search field, nothing. You’re just given a big list of random blocks with little to tell them apart and no easily apparent way to find the one you actually need.

It’s incredible really. It’s like they take all that built up expertise from building the plugin list and media library, then tossed it out of the window. It’s 2018 people! Being able to search for options is expected by this point.

And it’s non presence here just confirms something we already knew. Gutenberg was not ready to go live. It just wasn’t, the testing wasn’t finished, the bugs weren’t ironed out and the UI wasn’t fixed up to a modern standard.

The practical thing to do would hence been to delay the release, fix up the issues and only add it to core when it was ready. You know, like Shigeru Miyamoto used to say. A delayed game may be good, but a bad game is bad forever.

That’s why Nintendo generally avoids rushing their products. For them, a bit of patience is important to making a good product, and having a good first impression is vital all round. It’s why Mario and Zelda games take a long tme to make. Why Breath of the Wild got pushed back a year or two. It’s frustrating for the short termers and bean counters, but it creates a better experience for everyone else.

Automattic didn’t do this with Gutenberg, and (like a depressing number of companies in the modern games industry), decided that pushing an unfinished, buggy product on consumers was a fine way to make money/get hype, consequences be damned.

And it’s a real shame, cause Gutenberg has potential. As I said in the last article, the editor has a lot going for it, and if it was polished up just that bit more, it could be as revolutionary for WordPress as custom post types or metadata were before it. A finished Gutenberg could easily put Squarespace and Shopify to shame, and with the push to get other CMSes like Drupal and Joomla using it too, could provide the de facto standardised editor for CMS systems the world over.

But it needed more time first, and Automattic didn’t give it that time. Hence for now, I’d say to skip Gutenberg and just go with the Classic Editor. It’s got potential and it’ll be worthwhile in the future, but it’s just not ready for prime time just yet.
  • Like
Reactions: zappaDPJ