Editor’s note: the opinion in this article is Iain’s and is not necessarily shared by the rest of the Delicious Brains team. Iain had a lot to say on the topic 🙂

I’ve been loosely following the noise and #wpdrama surrounding Gutenberg for as long as it has been around and honestly for the most part I’ve had negative feelings around it (I don’t like change at the best of times). However, I recently dived in and tried it out and you will never guess what happened next!

But seriously. I came to two conclusions:

It’s a lovely piece of software It does not belong in WordPress. (Yet. Or WordPress as we know it today)

Let me explain.

What is Gutenberg?

As a customary catch-up for those who don’t know, Gutenberg is the new way to edit content in WordPress. It replaces the tired TinyMCE post content editor and can do a lot more too – think shortcodes, widgets, menus, and even custom fields. It is a client-side interface built with React that uses a block based system to build up content:

It is being developed as a feature plugin over on GitHub and it has been scheduled to land in core in the next version of WordPress, version 5.0 estimated for the first half of 2018. Here’s a great roundup of Gutenberg information.

Gutenberg is an important step forward for publishers, reducing the visual difference between how content is crafted in the admin and how it is rendered on the frontend. It also opens up the possibility of unifying all the various different parts of the site building process, like the customizer and widgets.

So What’s the Problem?

I’m not going to beat around the bush here, I’ve got some issues with Gutenberg, the motivations behind it, and how the implementation is being handled. And I’m not alone.

Motivations

Gutenberg is an obvious reaction to competitors of WordPress; the writing experience of Medium, the quick and easy site builds using Wix and Squarespace.

Clearly a project the size of WordPress needs some strong leadership and a clear roadmap. However, when that roadmap starts to be clouded by outside factors such as financial pressure to compete with the market, decisions aren’t made in the best interest of everyone. Don’t forget that whatever is implemented in WordPress.org is being built for WordPress.com (one of the main money-making arms of Automattic) and no doubt their biggest concern when considering losing customers to competitors. Gutenberg is a clear attempt to attract new users to the platform.

But in doing this is WordPress stepping away from the values that make WordPress WordPress? This is a move away from one of WordPress’ key philosophies, ‘Clean, Lean, and Mean’, which states that the “core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way.”

Given that Gutenberg is basically a very advanced page builder plugin (like the many premium plugins on the market that do a similar job and will likely suffer because of Gutenberg), albeit with more scope, it is questionable why this feature plugin has been given the green light for a merge into core.

We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. WordPress Philosophy

Interesting. So who decides what will be useful for 80% of end users (a wide demographic), and on what basis?

In Gutenberg’s case, this is quite clearly the Benevolent Dictator For Life of the WordPress project and Automattic CEO Matt Mullenweg, after confirming at the State of the Word 2016 that he would now be project lead for 2017, and that the visual editor would be one of the focuses for 2017. Early in 2017 he also established himself as the project lead of Gutenberg and moved a couple Automattic employees on the project to drive it forward. Matt is making executive decisions, not options.

Things Will Break

WordPress has always been a project that prides itself on backwards compatibility, a choice that has left the codebase large, outdated, and full of technical debt. WordPress allows the software to be run on a version of PHP (5.2.4) that has been unsupported by PHP since January 2011! Developers have been calling for this to be raised for some time but it has been postponed under the banner of backwards compatibility and the ‘Design for the Majority’ philosophy because the “average WordPress user simply wants to be able to write without problems or interruption.”

But Gutenberg is quite a departure from this stance. The goal of the project has dictated the need to use modern technologies (React, REST API), and therefore it circumvents the problematic parts of core. Matt Mullenweg views this as a positive, perhaps not willing to admit the double standard here:

Core developers will be able to work in modern technologies and not worry about 15 years of backwards compatibility. We Called it Gutenberg for a Reason

For years developers in the community have fought to bring in modern PHP standards to the codebase, refactor, reduce technical debt, bump the minimum PHP version supported, and help to make WordPress easier and better for future contributors to work on. They have been pretty much quagmired by Trac ticket ‘discussions’, core committers who don’t agree, and a lack of interest from Matt to get on board and challenge the status quo. Change seems to be something that WordPress can pick and choose.

The major part of backwards compatibility is not breaking things, or doing everything possible to avoid it. Gutenberg simply will break sites. This won’t be white screening, or breaking appearance on the frontend, but as soon as a site is updated to 5.0, a user will have a broken experience the next time they edit a post, if the site relies on custom meta boxes. For example, a site I develop uses Advanced Custom Fields to capture data for specific parts of the page and looks like this on WordPress 4.9:

With Gutenberg installed to show what it will look like when updated to WordPress 5.0, things don’t look right and the site’s editors will be left scratching their heads:

The onus is on each site owner or developer to prepare the site to prevent this and protect their clients. That sucks, particularly for people who manage more than one site, or have forgotten about sites they may have worked on in the past.

Impact on Agencies, Site Owners & Developers

The percentage number of sites on the web that are powered by WordPress is often touted and this number will be made up of a variety of different types of sites and site owners. A large number will be developers, freelancers and agencies who have built sites in the past, manage sites currently, and build every new site with WordPress. From experience, these developers typically don’t use page builder plugins but a combination of custom fields and meta boxes to give clients the ability to add all the data needed to be displayed on the site in a controlled and prescribed style.

These people will need to prepare for 5.0 (more on that later) to make sure their clients aren’t affected by Gutenberg. This will come at quite a cost to this portion of users, and many sites will slip through the cracks and remain in a broken state. Briget Willard makes this point in an excellent issue created on the Gutenberg repository calling for extended timelines for the implementation to help factor in the sheer effort and cost to cope with a change of this magnitude.

Higher Barrier to Entry

Out of all the modern frontend frameworks, React was always the first choice for Gutenberg, even after some token debate, and weathering the storm of patent clauses. But adding a shiny new framework to a critical piece of WordPress core is highly problematic and we’ve seen it before. WordPress 3.5 was released with a new media manager, built with Backbone and landed without documentation, no clear extensibility model, and a steep learning curve for core contributors and developers with media-related plugins.

Gutenberg has the potential to go the same way, but undoubtedly it will reduce the amount of people able to contribute to it, without learning React deeply. It also places a burden on plugin developers (in a short timescale) to learn, adapt, and get their plugins ready.

Of course this is possible for the big guys like WooCommerce (Automattic owned, large team) and Advanced Custom Fields (independant small team, huge user base), but this will affect any plugin which registers a custom post type, or meta boxes. Most developers simply won’t have the time, inclination or skills to make them compatible with Gutenberg. We will likely see a lot of plugins broken which just won’t get fixed. That will have a detrimental effect on user experience and the WordPress ecosystem in general.

More Technical Debt

The way in which Gutenberg stores its data is, at first glance, a neat approach alongside the existing WordPress data structure. However, Eric Mann makes a great point about how this isn’t the right way forward and exposes the double standard with backwards compatibility I mentioned earlier:

Gutenberg reimagines and reinvents the way WordPress is built. This is a good thing! But we shouldn’t be shoehorning the newer features into older structures because we’re afraid of breaking backwards compatibility on the back-end. Gutenberg already sacrifices backwards compatibility on the front-end!﻿ Gutenberg and the Road Ahead

He quotes John James Jacoby who suggests a different underlying database model for Gutenberg:

Gutenberg should have its own database tables, or existing tables need to be altered to store and retrieve individual blocks in a more logical and performant way. • blocks

• blockmeta

• block_relationships

• block_relationshipmeta Never gonna happen, though. — ʝ³ (@JJJ) December 13, 2017

Update: A big concern with the new React based editor from the outset has been about accessibility (a11y). Many have felt, as is typical with a11y work, that it’s a secondary design decision and treated as an afterthought. Despite the best efforts of the WordPress Accessibility Team, Gutenberg’s accessibility is severely lacking, and frustration around its development and communication between the wpa11y team has led to Rian Rietveld resigning as lead of the WordPress Accessibility team.

This is sad news for the WordPress community, but unfortunately it seems it will be one of many examples of collateral damage as WordPress implements Gutenberg.

What Should the Approach Be?

With hindsight I feel it would have been better to be upfront about the scope of the change. This is not just an editor replacement but a paradigm shift in how we edit in WordPress. This would have allowed the community more time to give feedback and understand the ramifications of the change.

Was it needed? WordPress has limited means of garnering feedback from users, so it feels like a lot of decisions are based on assumptions. WordPress claims to work off the wishes of the ‘Vocal Minority’:

When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe, this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.﻿ WordPress Philosophy

I would guess the majority of people if polled at a WordCamp would be excited about Gutenberg but worried about the implementation timeline we face now. I would also guess that if asked what they most wanted from WordPress, the equivalent of Gutenberg would not top the list. From my own experience and talking to users at the meetup I help organize, a sample wishlist would feature a simplified admin dashboard, native custom fields, improved developer experience, Composer support, PHP version bump, and an improved media library.

Nevertheless, Gutenberg is a steam train that likely can’t be stopped, but I think the approach to its integration could be adjusted.

Core should leave Gutenberg as a feature plugin for longer. The timeline is just too short for people to prepare. It is too great a change to be rushed. I think the decision to be merged should be rethought and only merged when a certain level of plugin adoption by users is reached. Let’s not forget Matt Mullenweg gave that same restriction for the merge of the REST API when it was a feature plugin and didn’t want to rush a merge (which it eventually was):

@Krogsgard No one is against iteration. It's: iterate in plugin with low stakes, or iterate in core, shipping to tens of millions of sites? — Matt Mullenweg (@photomatt) February 8, 2016

Update: Since this article was published, the Gutenberg team have released version 2.0 with a mammoth changelog, to me indicating it is not yet a stable and mature enough product to be considered for a merge.

If instead a merge has to happen, then Gutenberg should only be on by default for new installs (but the issue has since been closed) of WordPress 5.0. This would remove the possibility of breaking legacy sites, giving them time to prepare and the choice to switch from the classic editor. Sure, adoption would be slower but I believe the alternative could have a far greater cost in the long term.

Eric Mann suggests soft forking WordPress, leaving the 4.x branch Gutenberg free and allowing the 5.x branch to really go to town taking new approaches from Gutenberg across WordPress as a whole. Morten Rand-Hendriksen also suggests drawing a line in the sand and forking. Forking would also have the same benefits as my previous suggestion.

How to Prepare

The best way to prevent sites breaking for users when Gutenberg lands, is to enable the Classic Editor plugin now and configure it to revert to the old editor. This will mean come 5.0 things will work as is, and will be the approach I take for now.

If you have a site with custom post types (CPT) or develop a plugin with them registered, you can stop Gutenberg hijacking the usual UI with a couple of things. Either ensure you edit the registration arguments to explicitly set show_in_rest to false, or if you need to use the REST API for your CPT, then you can use the following filter to turn off Gutenberg for your CPTs:

add_filter( ‘gutenberg_can_edit_post_type’, ‘my_gutenberg_can_edit_post_types’ ); function my_gutenberg_can_edit_post_types( $can_edit, $post_type ) { If ( in_array( $post_type, array( ‘a_post_type’, ‘another_post_type’ ) ) { return false; } return $can_edit; }

You can learn more about preparing your plugins for Gutenberg from this more in-depth guide. A more drastic measure is not updating to WordPress 5.0 and only update to any security releases of 4.9.x.

The Future of WordPress

This is undoubtedly going to be a powerful feature for WordPress and could very well elevate it above its competitors even further and drive the market share even higher in the coming year. In essence, it could be a rejuvenation of WordPress, one that Matt hopes will see it through for another 10 years. But the impact of the Gutenberg project could potentially be a negative one with a far-reaching effect.

What does this mean for WordPress in the long term? The steps taken above to disable Gutenberg will lead to two different WordPress admins, creating a fractured experience which Kevin Hoffman believes has little hope of future convergence.

For me, Gutenberg highlights the larger problem with WordPress. WordPress needs to evolve and grow. It wants to create a new way of doing things (see views and blocks, not posts and pages). But you can’t do that and carry the legacy of almost 15 years worth of code and technical debt. Is Gutenberg papering over the cracks?

For many, especially in the enterprise WordPress space, Gutenberg is another nail in the coffin for WordPress. People have spent years using WordPress with plugins to turn it into the CMS they really need. In their eyes Gutenberg is undoing all that work and WordPress is, for them, ultimately no longer fit for purpose. This thread from Ben Furfie is an interesting take of how many view WordPress and Gutenberg:

I think we will look back at 2017 and see it as the year the #WordPress project started to fracture. As much as the community desperately wants to see WordPress as an enterprise CMS, projects like #Gutenberg show it is anything but. — Ben Furfie (@frontendben) December 28, 2017

When people talk of leaving WordPress and finding a new CMS I do wonder where they will go. There is a raft of options out there (our Matt reviewed three last year), but it feels like there is room in the market for a new competitor, albeit a huge project. Who knows, 2018 might be the year WordPress, like b2 before it, is forked into something new.

Update: ClassicPress is a fork of WordPress specifically without the Gutenberg editor, looking to modernize the WordPress codebase and remove certain aspects from the code:

The most requested feature for @GetClassicPress so far is to remove the Hello Dolly plugin from new installs. Feels like the start of deMattifying WordPress. https://t.co/E19zw4W6kM — Iain Poulson (@polevaultweb) September 8, 2018

Conclusion

If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it WordPress Philosophy

Time will tell if the Gutenberg project is a success. It certainly is powerful software and could be a gamechanger. Although I joked about not liking change, I see the value in it. It is necessary to grow and push forward. But only when the change is well thought out, initiated for the right reasons, and adopted in a sensible fashion.

I’m hugely impressed with what the Gutenberg team have accomplished so far and look forward to seeing it improve. However, I can’t help feeling that other parts of WordPress are suffering because of the drive to implement Gutenberg, and I hope perhaps full time Automatticians are similarly assigned to other much needed parts of core development. It would be great to see WordPress pushed forward with more than just Gutenberg in 2018.

What are your thoughts on the Gutenberg project? What would you like to see in WordPress in 2018? Let us know in the comments.