The new Gutenberg block editor is coming with WordPress 5.0 which is scheduled to be released later this month. It’s introduction is controversial to say the least. I’ve been asked on numerous occassions about my stance on Gutenberg and there’s no better time to open myself up to the world than with the release imminent.

A few months ago I started writing a blog post about the introduction of Gutenberg. It was titled “The Case For Gutenberg”. It goes without saying that this is not the title of this article. Gutenberg really has brought out some of the worst in the WordPress community.

Is Gutenberg good for WordPress?

In my opinion, Gutenberg will be fantastic for WordPress.

• The barrier for entry for WordPress development will be raised, resulting in better quality plugins.
• Developers will be forced to learn new skills that are more in line with modern development practices.
• The editing experience should become more consistent between sites and there should be less need for page builders.
• Front end editing should be easier to implement in a consistent manner.

So what’s the problem with Gutenberg?

The issue with Gutenberg is that it doesn’t actually yet create a better editing experience. It’s very clear that part of the reason Gutenberg has been developed is to compete with Medium, and also platforms such as Squarespace. As a result of this, Gutenberg is fantastic for building long form rich content. Unfortunately, this isn’t what the majority of WordPress users need. Gutenberg is too complex for very basic blog writing, and not advanced enough to substitute for an established page builder or custom development.

This flies in the face of the 80/20 philosophy WordPress claims to follow when implementing new features. I think it’s pretty well known that the 80/20 philosophy is a complete fallacy now and is only really brought out when someone on the core dev team wants to win an argument, but the impact is the same. It’s clear that Gutenberg, in it’s current form, doesn’t meet the needs of most WordPress users.

There’s also the political aspect due to Automattic’s involvement with WordPress. Developing an editor to compete with Medium and Squarespace is an obvious marketing strategy to bring in users from the other platforms that compete with WordPress. But not just WordPress, but specifically WordPress.com. Unoriginal branding aside, WordPress.com is a proprietary platform for users to build hosted WordPress sites, run by Automattic. However both the WordPress software project and Automattic are run by the same person, Matt Mullenweg. When you put the pieces together, it starts to look like Gutenberg has been built less with the WordPress community in mind and more with the intent to simply make Automattic more money.

The reason why Gutenberg is being built is one problem, but how it has been implemented is another. Not only does it have more bugs than a David Attenborough documentary, the transition to the new editor is far more problematic than it should be, which is where more of my concerns around Gutenberg lie. Good software is still good software regardless of political issues behind it, but you can’t cover up software that doesn’t work properly.

What Gutenberg should look like

In reality, Gutenberg should only have replaced the content editor WYSIWYG. This would have completely avoided any issues with meta boxes and any other problems with other parts of the post edit screen.

To be fair the Gutenberg team have done a pretty good job of preserving the content formatting in posts created in the classic editor, however if your posts rely on custom fields and meta boxes this is where issues can arise.

Funnily enough, the concept of Gutenberg has actually been around for more than 4 years. It started out as the Content Blocks feature plugin which extended the TinyMCE interface, allowing users to add blocks inside the editor.

While it was never really usable as it never got beyond a buggy proof of concept, I strongly believe this approach was a better way to implement any new block based editor. A new powerful content editor and the rest of the post edit page remains unchanged. The best of both worlds. Right now, meta boxes don’t always work properly and the edit interface feels alien compared to the rest of the admin.

Accessibility concerns

The WordPress Accessiblity team recently released a damning analysis of the accessiblity of the Gutenberg editor. To put it succinctly, the Gutenberg editor is very difficult and overly complex for users with assistive technology. While it would be unfair to call it an accessibility regression as the editor is quite different, there are a number of operations in the editor which have now been made much more difficult to do the same thing in Gutenberg. This really is not okay.

Recently, Queensland Rail and the Queensland Government introduced the New Generation Rollingstock trains onto the rail network. Unfortunately for them, the trains violate the Disability Discrimination Act, and therefore their operation is illegal. Other parts of the network are also not accessible, but are okay because they’re not a new thing being introduced. Any new developments must be compliant. This is a fair and reasonable approach to accessibility, and one that should be applied here. 

This doesn’t just affect users relying on assistive technology. I consider myself a power user of the editor, I heavily rely on keyboard shortcuts and markdown to format my content. Many shortcuts from the classic editor have not been ported over, and keyboard navigation between blocks and their contextual menus is clunky, inconsistent and time consuming. Gutenberg is far too reliant on using the mouse to navigate and interact with the interface, even for me.

How Gutenberg should be introduced

My advice for people wondering how they should start implementing Gutenberg is to leave the classic editor on existing sites (unless the content is really simple), and start with Gutenberg on new sites.

This is also my recommendation for how the implementation for Gutenberg should be rolled out. Either Gutenberg would only be the default on new installs similar to how the starter content works, or only the default for new posts and existing posts would be edited using the classic editor. Existing posts or installs could easily include a prompt on the post edit screen suggesting migrating the post to the new editor. In my opinion, this is a far better approach as it allows users to upgrade to the new editor when they are ready rather than forcing them to install the Classic Editor plugin just to keep their existing workflow.

Unrealistic deadlines and double standards

Speaking of forcing things on users, isn’t it funny how the stance went from “major releases won’t have a set schedule and will be released when they’re ready” as announced in the State Of The Word 2016, to now “WordPress 5.0 is shipping on November 19 with Gutenberg regardless of the thousands of still unresolved bugs and extremely difficult for users who rely on assistive technology”. This change of standards has not gone unnoticed and clearly demonstrates that the leaders of the core development team have become out of touch with their user base, which is extremely dangerous when you consider WordPress powers around a third of the web.

And if the disconnect wasn’t obvious enough, checkout the Gutenberg Stats site. They’ve somehow managed to track an approximate number of posts that have been created with Gutenberg on sites using Jetpack. I’m using Gutenberg to write this post and I have Jetpack active on this site. Not once have I been prompted to opt-in to tracking my posts made with Gutenberg, so presumably this is happening behind the scenes. Not only does this mean that Jetpack and potentially also Gutenberg are blatantly violating the WordPress Repository Plugin Guidelines, it’s also violating the much publicised GDPR. In other words, it’s illegal in at least 28 different countries. Will Jetpack and/or Gutenberg be suspended from the plugin repository like any other plugin committing these violations would? Of course not, they’re Automattic projects.

7. Plugins may not track users without their consent. 
In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent.

Some examples of prohibited tracking include:
– Automated collection of user data without explicit confirmation from the user.

 The WordPress.org Plugin Directory / Detailed Plugin Guidelines – developer.wordpress.org

Update December 5, 2018: Despite Matt’s refusal to adress these concerns when confronted directly, he mentioned in an interview today with Adam Preiser that they are only tracking 300,000 – 400,000 sites. If this is the case, then they are likely only tracking users who have opted in. While this is good news in this regard, Matt’s refusal to actually state who is being tracked also highlights just how poor his communication skills are.

In Summary

Regardless, I’m still excited about Gutenberg. It has the potential to completely revolutionise how WordPress sites are built, and one particular advantage I can’t wait to see is introducing front end editing. It’ll introduce modern front end development as a standard for WordPress and (hopefully) raise the quality of the code that plugins and themes are written with. I have no doubt that the issues around Gutenberg will be ironed out and it’s introduction will be beneficial for WordPress.

But it’s time that the development team take a good, hard, long look at the project and admit that it is absolutely nowhere near ready for being merged into core. I opened a number of bug reports discovered just in the writing of this post. It’s counter intuitive for users who require assistive technologies. They’re currently violating their own plugin guidelines to monitor usage.

With great power comes great responsibility, especially when you are the foundation of a third of the web. Use it wisely.