I chatted with some prominent plugin authors, page builder authors, and Gutenberg contributors to understand how Gutenberg could impact the broader WordPress ecosystem. This article discusses how it can impact content authors, plugin authors, and page builder plugins in the near future.

Gutenberg is the proposed new content editor for WordPress Core. It is currently in beta development. It is a radical departure from the simple WYSIWYG (what you see is what you get) approach WordPress has traditionally had for content creation. As with any major change in WordPress, this will inevitably have ripple effects throughout the WordPress marketplace. With that in mind, here’s my take on how Gutenberg will affect the broader WordPress ecosystem.

The Awesome for WordPress Content Creators

From everything I’ve seen, the main motivation — primarily from WordPress co-creator Matt Mullenweg — is to dramatically improve end users’ experience with content creation in WordPress. With the advent of website builders like Squarespace and Wix, a cleaner WYSIWYG in Medium, and the plethora of full-featured page building WordPress plugins, the simple post editor has started to feel downright antiquated.

From all looks and appearances, Gutenberg is aiming to be the content creator of the future for WordPress. It’s not an interim improvement to the post editor — it’s a full-screen replacement for the entire post edit screen — en masse.

But will such a dramatic change actually help users or simply overwhelm them? Ideally, the Gutenberg editing experience should help users write better content with better search engine results. With that in mind, I asked a few folks who know what it takes to write great content in WordPress what they thought of Gutenberg and its potential.

Joost de Valk is the founder and creator of Yoast SEO — a plugin used by tens of millions of WordPress sites. I asked Joost if he thought this puts a giant wrench into his plugin or whether it opens new opportunities for the plugin and its users. In a word, Joost is excited.

Joost de Valk
Founder/Creator of Yoast SEO

“We love what Gutenberg means for the future of WordPress. The new editor experience comes with some new concepts around the publishing experience.

An example of one of the new concepts discussed for Gutenberg is a pre-publishing workflow, that allows for an intermediate step between being done with writing your post and actually having your post published. We’re actively thinking about integrating our snippet preview there.

The concept of “little blocks” also allows for a deep optimization of how we analyze post content, as instead of analyzing the whole thing, we can do it block by block. This also means giving feedback at a block level.

In all, we’re excited about the opportunity to reimagine one of the most important aspects of our plugin.”

This is good news for content writers, marketers, and advertisers. When each “little block” of your content can be customized you have more control and that ideally means better results as well.

Our own Marketing Manager, Bridget Willard concurs that if Gutenberg encourages better semantic writing, then it’s a win for content authors:

Bridget Willard
Marketing Manager at WordImpress/GiveWP

“Gutenberg changes how a user interacts with the CMS, not how the content is read by Google.

When a user is less intimidated by adding content (writing and publishing) there is potential for better and more frequently-published content. If the heading structure is more intuitive with Gutenberg, that would definitely be a plus for SEO — which is basically findability.”

But as they say, “with great power comes great responsibility.” Just because Gutenberg enables you to write all kinds of awesome things doesn’t mean you should either. SEO and Marketing pro Pam Ann Aungst warns that having more power over your content doesn’t replace the need for professionals like herself.

Pam Ann Aungst
President at Pam Ann Marketing

“I haven’t used it yet myself, but any kind of DIY functionality scares me from an SEO perspective. This could make it just too easy for clients to bloat their posts full of slow-loading ‘rich content’ and do things that go against SEO best practices like adding in multiple H1 tags.

I also am always weary of pagebuilder-type things like this because they tend to bloat the code, which also brings down page speed. And I can imagine that compatibility with AMP is either too far out in the future, or not even on the development radar — which is also concerning since most of what Google pontificates about lately is fast load times on mobile.

Overall, I’m a bit of a purist when it comes to technical SEO, so unfortunately, I’m more concerned about this than I am excited.”

Pam’s concerns are valid for sure. It wouldn’t be wise for WordPress to put a bloated page builder into core, or make AMP integration more difficult. Based on what I’ve seen from the code so far, Gutenberg doesn’t add anything additional to the front-end (except a tiny stylesheet as a basis for its layouts). Further, Gutenberg doesn’t make additional h1’s easier than currently with TinyMCE, so generally I think this will evolve to be something SEO Pro’s like Pam can eventually embrace. I think Pam and other SEO auditors and Pros are safe even if they might perhaps have more nuanced work to do; which also could be a win for them.

Generally speaking, it’s fairly clear that there is a lot of opportunity here for content writers and marketers. Gutenberg generally seems to be on track to meet these needs.

Reactions from Plugin Authors

While content authors might be already rejoicing, a lot of plugin authors are feeling hesitant and are experiencing trepidation. This comes primarily from the fact that they’ve been arm-wrestling TinyMCE into submission for years and they’ll have to reimagine how they can integrate their plugin into this new interface while supporting customers who might be totally lost. This doesn’t even factor the customers who are not on the current version of WordPress who also need support.

There is interesting insight on the Github repo for Gutenberg in this regard. The discussions around how it will support Custom Post Types and Custom Meta Boxes are complex and thoughtful.

Meta Boxes In Gutenberg

There’s no clear consensus yet, but the crux of the matter is that Gutenberg is written from top to bottom with Javascript and any plugin that does anything with the post edit screen or has a custom post type creates its own meta boxes in PHP. So how will Gutenberg manage to *not*completely ruin thousands of plugins that did everything right, but now in a language that won’t render?

This ticket is advocating for an “Extended Settings” section that will render all the PHP-based meta boxes in a static area at the bottom of the content screen. Personally, that would be a horrible user experience — but like I said, it’s the conversations around that question that are fascinating.

Gutenberg and Widgets & Shortcodes

Another big question is how will Gutenberg deal with widgets and shortcodes? This ticket  focuses primarily on the WordPress Core widgets but the implications for plugin widgets are pretty extreme. This quote from Joen Asmussen is particularly revealing.

Joen Asmussen
Code Wrangler at Automattic

“The block, combined with the inserter, are both intended to be evolutions of the shortcode interface.That is, the block can offer the same as and more than the shortcode can, and the inserter is a unified level playing field for inserting them in the content.”

So we might be looking at the end of hard bracket shortcodes as we know it. Personally, I say “Hallelujah!” Shortcodes are a terrible user experience particularly when a minor misspelling or missing character results in ruining the output completely. Generally speaking, plugin authors might question how much work it will be to re-code their shortcodes. I expect the Gutenberg contributors will ensure that registering new blocks would be as relatively straight-forward as registering new shortcodes. Meaning, it wouldn’t be all that much work in the end, only a matter of implementing your new block settings for the user to interact with in Gutenberg instead of memorizing shortcode attributes.

One criticism I’ve heard (and shared) from several developers is how Gutenberg identifies its blocks from a markup perspective. John James Jacoby first brought this to my attention. I expected well-defined markup; but instead, Gutenberg is using inline HTML comments to wrap block elements. What!? Here’s his summary of the problem:

John James Jacoby
Core Contributor & Lead Developer for bbPress and BuddyPress

“I feel very strongly that inserting HTML comments into post_content is a decision that would be deeply regrettable later. It’s extremely clever, and neat, but I am afraid of what problems plugins, themes, and core formatting functions will uncover… We’d be deciding that the very-best we can do is invest heavily in a bespoke data format with a loose set of conventions chock-full of compromises due to legacy schema restrictions, and we know how that song goes – it’s not good for anyone, and we’d have a hard time being convinced that it is a good idea if it weren’t our idea.”

He said it so well. But John’s solution is that each block would be saved like a child_post relationship and would have its own individual post_meta as well. Personally, I think that’s overkill, but I am concerned about the level of HTML markup not being consistent with either Best Practices or the WordPress Way. After all, Open Source is not just about democratizing publishing, it’s about educating future developers. This markup would be leading them astray, and that’s putting it mildly.

To get more insight, I contacted Weston Ruter. We both joined the WPwatercooler for a discussion on Gutenberg. I asked him afterward about the decision to go with HTML comments.

This is what he said:

Weston Ruter
Gutenberg Contributor & CTO at XWP

HTML comments are used for encoding blocks for the following reasons, that come to my mind:
(1) Shortcodes were extensively used in unanticipated places, including HTML attributes, because the bracket notation didn’t enforce any limitations. By using HTML comments, however, there is a guarantee that the tags will only ever appear outside of HTML elements and thus can be reliably parsed.
(2) There are existing HTML comments that are already used in post content in WordPress, including < !--more-- > and < !--noteaser-- >. So blocks are following that pattern.
(3) Plugins can introduce their own blocks. When these plugins are disabled, any of the plugin’s blocks will then just be hidden or rather the underlying fallback content contained inside the block will then be displayed. This is in stark contrast to shortcodes which then show up everywhere when the shortcode is no longer recognized.
(4) HTML comments are resilient when post content is manipulated by other editors, including the classic WP editor or editors in other apps. They won’t get stripped out, though they also will be invisible.

Overall, those are all fair and reasonable points that I wouldn’t have considered at all. Further, a big part of John’s goal with child_posts is portability of blocks. The discussion is already happening about how that might be accomplished as well.

Gutenberg and Plugin Authors

Generally speaking, the plugin authors I’ve spoken with dare optimistic about and eager to see how they can make the most out of what it has to offer. For example, Adam Warner of FooPlugins likes that Gutenberg will allow plugin authors to make their features more apparent via the Insert feature, saying that

Adam Warner
Co-Founder at FooPlugins


“Making sure we have our plugins tightly integrated will be key for our continued growth, but more importantly, it gives us the chance to offer our features front and center within a more cohesive content creation experience.”

Some plugin authors have serious concerns though. Gregory Schoppe raises seven “flaws” that leaves him confused about Gutenberg.

Josh Pollock said he agrees with everything Gregory says and added to the discussion in his own article at Torque. Josh’s overarching concern is that Gutenberg can’t promise the highest level of backward compatibility that has made WordPress as successful as it has become. If backward compatibility really is ruined with Gutenberg, then it would be detrimental to WordPress as a whole. At this point though, I have faith that the Gutenberg contributors still ascribe wholeheartedly to the WordPress Philosophy of backward compatibility 100%.

Page Builders and Gutenberg

The challenge Gutenberg presents to page builders is the elephant in the room. Will Gutenberg gut and destroy all these major page builder companies that have banked on being the end-all-be-all of content and layout customization in WordPress? My short answer is — it depends.

It depends largely on the page builder in question and how they pivot. When chatting with Weston Ruter he mentioned that the Gutenberg team has been intentional about reaching out to page builder authors, like Beaver Builder, in order to learn from their insight and experience, as well as to prepare them for what’s coming.

In terms of the conversation around Gutenberg and page builders, this Github issue is really instructive. You can see the questions generally revolve around either toggling between editors (meaning they would not be integrated with each other in any reasonable fashion) or that whenever a “text editor” block is used in the page builder that it would be a Gutenberg instance. As of today though, the mock-ups being produced are primarily about having an either/or experience with page builders.

I reached out to Robby McCullough from Beaver Builder and he had this to say:

Robby McCullough
Co-Founder at Beaver Builder

I like the idea of standardizing and modernizing shortcodes and widgets. I’m excited about it. I think adapting to change is always tough, but there’s lots of potential for us to leverage Gutenberg and vice versa. Shared blocks and such.

That part about “adapting to change is always tough” is the thing that will set folks like Beaver Builder apart from other page builders that will just die away.

Another factor is the nature of the builder itself. For example, Divi Builder has a huge user-base, but it’s also very tightly integrated with the Divi theme itself. With that amount of coupled control (functions inside a theme), they can do what they want with Gutenberg. But seeing it as a challenge and opportunity would be the smart move. The only problem with that is that I have no idea what coupling Divi with Gutenberg would even look like. Also,who in their right mind would want to work with that?

Tailor is a relatively new page builder that was developed intentionally simple. In many ways, it does what Gutenberg is now doing. I have a hard time imagining Tailor surviving Gutenberg — but I could be wrong.

Elementor is another one that has come to prominence recently. They have a relatively smart way of interacting with existing widgets and shortcodes. They could also easily pivot with Gutenberg, but it all depends on how they manage that pivot and that user experience.

Overall, Gutenberg could very well be a radically new content writing experience for many WordPress users. But that doesn’t mean everyone wants to use it or that everyone should be forced to use it. Allowing a natural and programmatic way for users to choose to edit their content with page builders instead of Gutenberg is a good idea. I hope that happens with finesse.

How to Stay Informed with Gutenberg Progress

If you’ve read this far, you must be really invested in Gutenberg — bravo! One thing you should have picked up through it all is that there still is a lot to be determined. It’s still very early in development of Gutenberg at this time.

Quite honestly, I think it would have been more helpful to call this release an Alpha rather than a Beta simply because many very significant and important features and code architectural questions have zero consensus still. That’s a really important aspect of this whole discussion. We are having this discussion now simply because of how much impact this new feature could potentially have on WordPress as a whole and that it might even make it into Core by the end of this calendar year.

With that in mind, if you are interested in keeping up on Gutenberg progress, here are the best places to do that:

  • Download and test it here but not on a live or production site. Updates are pushed there so you’ll get them as soon as they are stable and available.
  • Gutenberg Github repo is where actual code is happening and all issues are being publicly discussed there as well.
  • The Make WordPress blog is posting about Gutenberg regularly as well.
  • General discussion about all things Gutenberg is happening in WordPress Slack in the #core-editor channel.

Also, check out this episode of WP Water Cooler with the gang and Weston Ruter and myself. It was a really helpful conversation overall.

Matt is Head of Support and Community Outreach at WordImpress.com. He's the author of many free WordPress plugins, a popular blogger at his website, an admin of the Advanced WordPress Facebook group, co-organizer of the San Diego WordPress Meetup, and a frequent WordCamp speaker and attender.

Follow Matt:

Leave a Reply