I have a confession to make. I really like the new Gutenberg editor for WordPress.
I know, I know. Developers aren't supposed to like massive, intrusive changes like this. As of the time of this writing, the plugin stands with 2.6 stars on the plugin repository – at least 133 of those ratings are 1-star critiques.
As a writer, though, it's an incredibly slick interface.
As a developer, I can also see the promise behind the block structure for taking over the rest of the WordPress admin. The customizer could easily use the block structure for things like widgets and navigation and content layout. Even settings pages could be updated to leverage blocks for different sections.
Also as a developer, I can see why so many are hesitant to dive in with the new system. It still has a few rough edges, but nothing that's impossible to polish as development moves forward. It's also a massive deviation from the interface we're all used to.
The Problems Ahead
Having worked both as a WordPress freelancer and with a larger WordPress agency team I admit this new editor does give me pause. Several of the systems I've built or worked with feature rich, custom interfaces – all built atop the standard WordPress editor screen.
While I plan to leverage Gutenberg's newer interfaces with any project I build atop WordPress 5.0 or later, this isn't a solution for everyone.
Not that long ago, a friend of mine who works with an established non-profit reached out to me for some WordPress help. The team had hired a developer to build out their site, but they'd since parted ways. Unfortunately, the developer had left a large banner on the front-end of the site pointing out the design was new and soliciting user feedback.
The team wanted to turn off the banner, but didn't know how. They also couldn't ask the original developer to take care of it for them.
My point is that many existing WordPress users are working with platforms built by outside parties or powered by themes and plugins that they cannot update on their own for whatever reason. Switching to the Gutenberg editor for posts (and pages and other CPTs) is going to pull the rug out from under a lot of businesses who've grown to trust our product to build their business.
A Potential Solution
Two roads diverged in a yellow wood,
The Road Not Taken, Robert Frost
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth
About four years ago, I suggested that WordPress should fork itself for the sake of updating its PHP requirements and empowering developers to leverage newer features in their code. Several other developers chimed in and supported the idea, but we didn't tread down that path because, honestly, it wasn't a good fit for the project as a whole.
Now, though, everything is different.
Gutenberg is great, but it's not a good fit for the project as a whole. WordPress is not just a blogging platform. It's not just a tool for the creation of prose. It's a rich content management system with support for both prose and media and, thanks to the power of custom post types, anything else a customer might need.
I strongly believe that Gutenberg, and its block-based approach to building webpages is the way of the future. I strongly believe that Gutenberg should be part of WordPress – perhaps not just a part but should take over the WordPress interface entirely.
I just as strongly believe that the broader WordPress community isn't ready for Gutenberg and won't be for quite some time.
For the time being, I propose that WordPress create a "soft fork" of the project. Maintenance, security, and minor feature improvements should continue on a 4.X branch (with a 4.10 release coming next, followed by 4.11, etc). Gutenberg should (and will) be the default editor with WordPress 5.0, but no one necessarily has to upgrade to the 5.X branch until they're ready for it.
This would give developers the time to upgrade their plugins and themes. It would give users the time to familiarize themselves with the newer interface. It would also allow for faster, broader experimentation with the new block-based approach.
Rationale
WordPress' overarching development principle has been to always maintain backwards compatibility. It's one of the reasons why we target PHP 5.2 as a minimum. It's one of the reasons why I can click "upgrade" on an older 3.X site and bring it up to speed with 4.9.1 without anything breaking.
It's one of the primary reasons why WordPress has been so successful as a platform.
Unfortunately, Gutenberg is such a deviation from what we've used in the past that it's all but impossible to maintain backwards compatibility without ugly hacks.
- Meta boxes, one of the core ways plugins extend the WordPress admin interface, are included in Gutenberg by way of iFrames. It's a buggy implementation that has many developers arguing over best practices and approach.
- The page editor is missing the concept of "page templates" entirely. Up til now, templates were the key way site owners customized the appearance of their content – this doesn't fit within a Gutenberg model. Leveraging a page template requires deactivating the plugin, selecting the template, then re-activating the plugin to build content.
- Blocks are added to post content using HTML comment tags – the content isn't actually broken up into separate blocks and the blocks themselves don't function as standalone objects. This reminds me too much of media within WordPress, where media items are inserted by way of HTML tags into content rather than as references back to the original media item.
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!
A soft fork of WordPress would allow us to:
- Update all the JavaScript used within the admin interface
- Update the database to better house blocks as objects that can be reused and references across content
- Reimagine the media library as a catalog of reusable media blocks
- Update other components of the WordPress admin to leverage blocks (a "settings" block perhaps?)
All of this would be possible without breaking the functionality of highly customized sites if they remained on the 4.X branch. They'd still get security updates, maybe performance updates, and possibly even minor, non-Gutenberg-related feature updates moving forward.
Maintaining both the 4.X and 5.X branches in parallel would also provide developers (both on the larger agency and smaller freelance side) the ability to seamlessly upgrade from a legacy to a Gutenberg environment.
Soft-forking isn't unheard of. Microsoft followed this pattern when they replaced Internet Explorer with IE Edge. Firefox did it with the new Firefox Quantum.
Gutenberg is the road ahead for WordPress. It's a road I want us to take. But it's a road that not everyone will be willing to tread. We should respect that and plan a way to help those who can't follow to keep up.