I read an article recently where the author told his clients that he will not support anything related to Gutenberg. He recommended they install the Classic Editor plugin so they can keep support up after WP 5.0 is released. This was pretty shocking to me, especially since we are recommending Gutenberg for (some of) our clients.
In college I learned that the year 2000 wasn’t the first year of the new millennium. This shocked me and caused me to realize that many things I know to be true aren’t actually true.
Back then 2k was a pretty huge deal. If you were around then you’ll remember there were a lot of doom sayers. The world was going to end in fire. The Y2K bug would cause any number of disasters including everything with a chip in it not working. Nuclear missiles would randomly launch; emergency services would go down; cars and household items would turn against their masters…
It seems quaint when we look back at it just a few years later but these were real fears. People stockpiled food, water, supplies, guns, and gas because they believed all the worst case disaster scenarios.
When it comes to news, nothing sells better than a disaster, especially something that can affect you and is just vague or technical enough that most people don’t fully understand it.
That is the state of Gutenberg.
There are a lot of people who are shouting “FIRE” but much of what they are worried about isn’t fully founded. I’ve heard worries that Gutenberg will:
- Destroy all of your existing content (it won’t)
- Cause developers to lose jobs (only if they refuse to add to their skills)
- Break page builders (only a few might be directly affected)
- Cause mass havoc on the internet (just hysteria if all the fear mongering takes off)
The Y2K bug was a very real thing and it was a thing that developers saw coming a good long way ahead. They worked to patch things and prepare for problems. They saw the worst case scenario because that is how developers and engineers think. Then they did what they could do to prevent it. Likely there were systems that had issue with switching over but for the most part the world didn’t end.
Gutenberg is the kind of thing we can see coming and prepare for. It isn’t a disaster, but if we don’t work to embrace it and contribute to its overall improvement, then it can be a big problem just because it is new and different.
That said, we are recommending Gutenberg for our clients when it is the right approach for them. Before explaining when it is the right solution, let’s look at some of the reasons why we are recommending it.
Gutenberg is happening
It’s a fact. We can stick our head in the sand; we can scream on the roof, or we can embrace it.
Just like Y2K there’s no way to stop it. This is the future of WordPress, so the question is, will we at Reaktiv be ready? We decided to embrace Gutenberg so that we will be ready.
Back at WordCamp US they announced a goal of having WordPress 5.0 in beta by April of this year. At WordCamp EU they gave some new dates that put us in the first beta in August. They push the timing back again, but it will come. When it does, we will be ready.
We already have one developer, Jay Hoffman, who has contributed to Gutenberg Core. We have been using it for an internal project and we are recommending it for select clients right now.
When WordPress 5.0 comes out we will be ready because we are putting in the work to get ready.
Early adopters will help drive innovation
Jay has already contributed to Gutenberg core, and we have been using it and providing feedback on things that are and are not working. By embracing this feature we can help address concerns.
This is more than just complaining or pointing out problems in public forums. We are using the tool and realizing just how great it can be while at the same time talking with key people about how we can use it best. Sometimes this exposes problems, like dealing with content that is also meta. It also means we can work with other early adopters to learn how to deal with those limitations or contribute to Gutenberg to help resolve them.
A new paradigm
Blocks provide a new paradigm in content creation that will make it easier to add custom elements without shortcodes.
A couple of years ago WordPress wanted to change how shortcodes worked. When shortcodes were first introduced they provided a great solution for creating dynamic content without requiring users to understand HTML, javascript, and other web languages. However, several limitations were discovered and worse, it became clear from the push to make this change that it was going to cause a whole lot of problems.
Blocks introduce a new and better standard for generating HTML and dynamic content. The system provides a UI feedback for users so they don’t have to remember the shortcodes and various attributes. It is not unlike the Shortcake Shortcode UI plugin, but provides a more native UI so edits do not happen in a box but as part of the content.
As developers embrace the block paradigm, more interesting tools will come out that will help users create content. For our clients, this means a more intuitive method for creating and editing content.
A bigger vision for the next ten years
WordPress just celebrated its 15th anniversary. When WordPress first came out, there was no visual editor. This meant people had to work more directly with HTML, just like using the text tab on the editor today.
WordPress 2.0 came out December 31st, 2005. That is over a decade ago. It introduced the TinyMCE editor to the community and is the foundation that almost every site has been building content with since. Here is what the release notes had to say about it:
WYSIWYG Editing — WP dev Andy Skelton and the TinyMCE team have done a tremendous amount of work to bring a smooth WYSIWYG editing experience to WordPress. As code purists, we are very picky about what kind of HTML is generated, and while it’s not perfect yet (for instance nested lists can cause trouble) for 95% of what you do post-to-post the WYSIWYG should save you time. And if it doesn’t, you can turn it off on your profile page. One note: Safari and older versions of Opera, both fantastic browsers, don’t yet support everything that’s needed to do WYSIWYG, but we fully expect new versions of those browsers will continue to improve their standards support, so it may just be a matter of time.
The article I had read, and others like it have similar concerns about the new editor. “HTML markup isn’t what it should be” and “mobile isn’t even supported yet.” I’ve even heard worries that we will lose the ability to turn off the new editor at some point, but here we are over a decade later and you can still use the text editor. That isn’t changing.
The future of WordPress is, though. A decade from now, when we look back at the release post for WordPress 5.0 with some of the same acknowledgements of potential shortcomings and the solution to keep the old editor, we will think, “Wow, did we ever worry about this?”
Missed deadlines are a good thing in this case
Earlier in this post I mentioned that they announced the target date for the beta at WordCamp US, and that time has come and gone. At WordCamp EU they gave a new plan for the target roll out and it is possible that will be missed.
There are several features being worked on and blocking bugs yet to be fixed, so this is not ready for everyone. It’s far better to miss an arbitrary deadline than enforce a launch timeline for a feature that isn’t ready.. The fact that they are not releasing Gutenberg in core right now means they are not going to release something that will break nearly one-third of the internet.
The delays mean that Gutenberg will be more polished when they release it. The fear that it will be a largely broken feature (which it isn’t, even before the official release) are as unfounded as the fear that the visual editor of WordPress 2.0 would be the end of WordPress.
Who should adopt Gutenberg now?
Not all of our clients will be going on Gutenberg in the near future. We have a lot of clients that have very structured page templates with complicated custom fields. While Gutenberg would have been a great solution for them had the site been built to take advantage of those features, the current site will not upgrade to Gutenberg seamlessly.
Those clients are going to either get the classic editor or the new ramp plugin so they can continue to use the site the way it was built.
However, other clients have more traditional posts and pages that use shortcodes for dynamic elements but limited and simpler custom fields. We are setting up staging environments to allow these clients to start testing Gutenberg. Where appropriate, we are moving it into production.
We also have new clients and talk to them about the risk and benefit of Gutenberg for building their sites. Not all clients are ready to embrace Gutenberg. For those clients, we set up a site that meets their risk acceptance.
The goal is to meet our clients’ needs. It is not to set a blanket policy that says we will not support Gutenberg. Each client is unique and we are positioning ourselves to be experts with Gutenberg just like we have been with “traditional” WordPress sites.
That is why we are recommending Gutenberg to (some of) our clients.
