Is Gutenberg the End or a New Beginning for WordPress?

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:

  1. It’s a lovely piece of software
  2. 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.


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 is being built for (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.

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.

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!

He quotes John James Jacoby who suggests a different underlying database model for 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.

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):

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;

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:

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.


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

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.

About the Author

Iain Poulson

Iain is a WordPress and PHP developer from England. He builds free and premium plugins, as well as occasionally blogging about WordPress. Moonlights as a PhpStorm evangelist.

  • gatchaman

    I’ve already gotten push-back from some clients about this. Many don’t want to pay for additional work to solve this when the time comes, a few claim it is a bug I should resolve since I suggested WordPress in the first place.

    I will do what I have to update the projects I’ve built, but am moving on to Craft for future projects. I will not suggest WordPress at all in the future. I may stop bidding on WordPress sites altogether. Its never been an ideal CMS in my opinion, but this is a bridge too far for me.

    • Jonathan Nicol

      I think it is too early to be warning clients about Gutenberg. We don’t know yet how it is going to impact on metabox plugins like ACF, or what short and long term options will be available to developers who want to disable Gutenberg and retain the classic editor.

      • Good point. Which is why it is too early to be thinking about merging and pinning it to the next release!

  • Mat Gargano

    I’m still part-way through the article, and I am going to do what I hate most, comment on the entirety of the article before finishing it but…

    This whole Gutenberg idea appears, to me, as knee-jerk reaction to Wix, Squarespace, etc. as you mentioned. If Gutenberg is going to work it is basically going to need to strip the entire idea of themes from our vernacular. I have not tried many page builders – but one that I did try was Beaver Builder — which, I could be wrong, but ostensibly shoves bootstrap 3.X into your project no matter what you are using. So if I want to add a full width module containing an image, it better had not be in a container that is not full width or you won’t get what you are expecting. Note that I got frustrated and moved on rather quickly so my testimony to Beaver Builder may not be 100% correct and may be factually incorrect in that event I will eat crow.

    I can’t imagine this being implemented outside of a toggle and if Gutenberg is enabled the theme must be something specific that will work with Gutenberg… I had a brief discussion with Morten Rand Hendrickson — and after his response my uneducated opinion is that themes will be completely turned upside down.

    Again my opinion is rather ignorant – and I’d love to change that and will devote some time to getting up to speed — but until that happens, to quote Principal Skinner – “prove me wrong children, prove me wrong” …!

    Is it me or does this sound more appropriate for a fork of WordPress than an enhancement? Though that would be considered heresy!

    • Wozn2

      I don’t think Gutenberg forces you to use specific CSS/a certain framework on the front end, in fact, quite the opposite – it’s supposed to allow more of a separation between data and presentation.

      • Mat Gargano

        You’re right it doesn’t – I never said it does- beaver builder does I believe.

        That being said – if you have a Gutenberg block that is controlling a div- it has no idea of the divs context. So if you set the block to be full width but the div has a width of 33% Gutenberg block and actual frontend will be totally different.

        So Gutenberg may have require very vanilla, “Gutenberg compatible” theme

        • Wozn2

          Yes it will be up to the theme to decide how to render the data. This is how it should be and is entirely logical (then when you change theme, nothing breaks when you new theme which uses shoelace 2000 instead of bootstrap 3).

          The problem is though that not every theme will provide support for every Gutenberg block type and so some plugins that add blocks will include their own styling. This however is exactly the situation we are in now already.

          I use CPTs & custom fields + custom CSS and themes to create a Gutenberg-esque approach right now and it will probably suit me down to the ground. It won’t be so easy for people who want to download a theme from a store and throw in a few random plugins to build their site, but it probably won’t be much worse than now.

  • I’m interested in the work being done around JAMstack, NetlifyCMS & Serverless. Some great work has been done in the last year, as is evident from the launch of Smashing Magazines new website, and NetlifyCMS coming out of beta recently. Of course, I’m still dabbling with Gutenberg to ensure it’s a potential tool in the toolkit, but I doubt WordPress is going to be the CMS of choice for me anymore.

    I still do not understand why WordPress is years and years behind, supporting PHP 5.2 for backwards compatibility, but are happy to release Gutenberg knowing the issues it’s going to cause. Just madness.

    • Ladislav

      NetlifyCMS has a long way to go. Moreover, they don’t have a multilingual support in scope. For a small, one language website – seems perfectly legit. Don’t get me wrong, I like JAMstack solutions.

      • Luke Cavanagh

        CraftCMS is worth checking out.

        • Ladislav

          I am familiar with CraftCMS, very, very solid project.

        • Gonna check CraftCMS out, keep hearing about it, but never really looked at it. Thanks 🙂

      • Oh definitely, it’s a new project, it 100% has a long way to go. For me, of the 100 or so site’s I’ve built in the last few years, there have been 4 that need multilingual support, so it’s not a big issue for now (for me at least).

        I don’t think size is much of an issue, although I’ve never run anything huge from NetlifyCMS. Just basing this on the size of Smashing Magazine, and the speed of tools like Hugo.

        Theres always Contentful or DatoCMS as a content API if NetlifyCMS isn’t suitable 🙂

    • AlexDoom

      We switched to using WordPress headless and it just servers as a CMS for clients that need it while we build the front end with static site generators.

      • Doing that too on a recent project, but I don’t want Gutenberg markup with my static site generator. Haven’t actually explored this yet, my gut feeling is that Gutenberg makes headless WordPress less desirable (haven’t yet looked into this of course)

        • Not if you use Gutenberg only as a metabox replacement. Then you won’t need any of the `post_content` markup and can instead get everything from the postmeta.

    • I have started to build some sites with Grav (free) and doing my first with Kirby (premium) now.

      Every new project I am getting in the first half of 2018 for which I previously would use WP with ACF, is no longer WP.
      And do you think the client cares?
      Of course not! The client just wants a working website, that loads fast and where they can edit content if they have to.

      Both Grav and Kirby have an admin panel, and both of them are way faster than WP, so win win for all.

      No regrets, but I feel the time with WP has come to an end for me.

    • Good point about NetlifyCMS and Smashing Magazine ( I agree, the more WordPress changes like this, the more developers will look for better more suited solutions to what clients need.

  • Kyle Kranzo

    So will sites developed with Advanced Custom Fields and/or Custom Post Type UI be broken with this update?

    • Me

      No, they may be in better shape (faster) than completely bespoke sites. As always, just make sure the plugin is up to date. If you don’t personally have your own license but it instead comes bundled with a plugin or theme then I guess you’ll have to wait on that.

      More info here:

      • Kyle Kranzo

        Thanks for the info!

    • Anthony Hortin

      I disagree with the other reply. Yes, there’s a very good chance your site could break if you’re currently using ACF and/or other plugins that use custom meta boxes. At the moment, ACF isn’t working properly in Gutenberg and although Elliot is confident that he’ll have it working by the time WP5.0 ships, there’s obviously no guarantee. The best thing to do is to thoroughly test the site in your own dev or staging environment before updating the live site. You may find that you’ll need to install the plugin to get the classic editor back.

  • Johan Östling

    The way I use WP, I think its a good move to make the editor more block based. However, I only use WP in small projects combined with a page builder like Visual Composer. In more complex applications, where a CMS feature is needed, I go for Drupal.
    My clients are also well informed about the lack of LTS releases in WP, so they know things might break.

  • I’ve been watching Gutenberg from the sidelines for quite a while. After reading this it’s clearly time to look deeper into how it’s going to affect my business. We’ve built so many sites with custom post types, ACF, and more recently Beaver Builder. How will Gutenberg affect these sites, many of which I no longer manage? Better get testing…

    lain you’ve raised quite a few legitimate questions here, thanks for your opinion.

  • I get that this is a complete departure from the core plugin, and the update would break many websites and plugins. My primary plugin, Easy Beer Lister is going to be hit pretty hard, and I’ll probably have to re-write entire chunks of it to get it to be Gutenberg-compatible.

    If we’re planning on adding Gutenberg to the site moving forward, I definitely think it should just be added to core. Rip off the band-aid and make the leap, however, there should be some way to enable “compatibility mode” or something like that. It could be in the form of a separate plugin (like you linked above), or a single option to enable/disable Gutenberg.

    It’s simply unrealistic to expect all WordPress users to update all of their code to support this new system within 6 months. Most of my clients don’t have the budget in-place to make this transition, and probably don’t really value the upgrade enough to make the jump anyway.

    Which means that if we force this TinyMCE change in the way that it looks like it’s going to be implemented, people will simply avoid upgrading.

    Then a security flaw will be exposed in that version, and suddenly WordPress gets an even stronger reputation for being an insecure platform to work from.

    However, if we phase out TinyMCE over the course of 2-3 years, and remove the option to disable Gutenberg at that time, that changes a bit.

    Most of my clients are on a 2-4 year window for a website refresh. If I knew 100% that Gutenberg was going to be in core, and TinyMCE would be deprecated, I would start building my websites with that in mind. That means that most of my clients would be on Gutenberg before TinyMCE is removed from core.

    This also gives me plenty of time to re-build my WordPress plugins to be Gutenberg-ready.

    • Update: I just installed Gutenberg on my sandbox environment with my current Easy Beer Lister implementation, and I was pleasantly surprised to find how well it worked without any code changes. I’m sure that other plugins will have different experiences, but overall, from what I’m seeing it will be less of a complete rebuild and more of a plugin refactor.

      Mostly just some Javascript fixes to work with Gutenberg appropriately. I currently have a PHP-based template builder for my post metadata that pretty much follows similar paradigms to React anyway, so most of those changes shouldn’t be too bad.

      Either way, I think if you hugged WordPress core tightly, and followed good coding standards, you too will be pleasantly surprised that your site is in better condition than you expected it to be post-upgrade.

      Of course, that’s specific to plugins. I’m sure themes are going to be an absolute nightmare.

      • Update: I just installed it on a customized theme, and it appears to run fine. Like the blog post mentions, ACF is broken but I’m sure Elliot and his team will have something to make this work properly before Gutenberg comes to core.

        Also, I was surprised to find that the editor currently has support for a way to use the classic editor on any given post (which I think is even better than what I suggested above, honestly) so I guess I don’t see what the big deal is.

        I’m sure I’m missing something, right? Or is this just a classic overreaction by the community, most of which have never actually taken the 30 minutes or so to look at Gutenberg and develop their own opinion?

        • Luke Cavanagh
        • jasonyingling

          ACF did a good job quelling some of my fears in their looking forward blog post.

          Essentially promising to have ACF work with Gutenberg day one. I’m sure there will be plenty of bugs considering the Gutenberg spec isn’t final yet and ACF is a huge plugin to adapt to it. But I’m more confident now in being able to migrate 5+ years of client sites over to Gutenberg.

          I’m still formulating the plan for our agency to handle this with clients. But as of now I’m considering alerting them to the change with the plugin to disable Gutenberg active until we can review sites that want to make the change now.

      • This will vary from plugin to plugin, site to site.

    • Thanks for your thoughts. I agree, we need a more sensible timeline!

  • Me

    Using Gutenberg without a mouse is not a fun experience. Keyboard accessibility is getting better though. Using a Touchscreen on phones, tablets and actual computers is not possible with so much of the Gutenberg UI hidden. Voice control? Forget about it. Gutenberg is an improvement in many ways but TinyMCE is still more accessible than it’s supposed successor.

    With mobile first becoming increasingly important, I want to see hover functionality reduced to the point of near elimination. It has it’s place but not in something like Gutenberg that’s supposed to be open to everyone regardless of their disability or choice of input device.

    That said, my plugins have already been made compatible with v1.9.x and I’m waiting the 2.0.0 release now.

    • Are you plugins in the .org repository? – If yes, let me know your .org username and i include them in our “List of Gutenberg ready plugins”

    • Great point! Accessibility is a real concern, and this highlights how far off Gutenberg is and therefore should not yet be considered for a merge.

    • Paul Aswad

      Setup a USB OTG on your touch screen device and you go yourself a mouse and keyboard on it 😉 Most new devices are OTG compatible.

  • jacobajjarapu

    Great article. Thanks for the breakdown.

  • “when you’re putting your business behind something that is not 100% in your control, you can expect to see situations where you have to adapt to keep up with that thing. If you don’t like that, then you’re better off building your own thing. To me, it seems like an absurd idea that investing the time and resources necessary to completely switch to another platform can be comparable to installing an extra plugin, or learning a new piece of the software you’re using. ”

    This. 100% on board with this.

    If you make a decision to use a CMS, you’re committing to using that CMS. All CMS’s change to keep up with modern paradigms, or they simply disappear.

    Additionally, the biggest thing Gutenberg does from a learning standpoint is it forces you to understand how to use React in-order to build customizations to the WordPress interface. Think that’s hard? That’s probably because you don’t use React, and have some kind of heavily customized setup that allows you to work with adding metaboxes and post meta without ripping your hair out.

    Yes, this will cause some short term pain, but if you’ve been paying any attention to the community at all, you absolutely have to be aware that it’s worth your time to take a course or two on React and Webpack. It’s been coming since 2014. We still don’t know what form it will take, but it’s only a matter of time. You’re a programmer. Adapt. It’s what you do.

    • Luke Cavanagh

      Classic Editor works, but requires an extra setting step to be changed by default, which seems like one extra step that you should not have to make.
      Settings > Writing > Classic editor settings

      • Yep. In any other case, especially from a 3rd party plugin, I would see the Matt and the core team being staunchly “opt-in” vs. “opt-out.” Too bad their are “do as we say not as we do.”

      • I also noticed that already. I guess we need to fork that plugin or fork WP; whichever is easier 😉

      • Agree – it should be install + activate. The reliance on a third party plugin is a shame and brittle.

    • rick gregory

      “If you make a decision to use a CMS, you’re committing to using that CMS. ”

      And I can uncommit. WordPress has been an excellent choice for what my clients have needed to do. If I feel I can no longer trust that it’s a good choice, I can and will leave. I’m not going to be, or have my clients be, locked to WP forevermore simply because that’s what I started with.

      • Of course you can uncommit. But to me(from my point of view – after 7+ years of using and learning WordPress) it seems like not a great deal to throw away all of the expertise one has built using WordPress in order to go and start something completely new. Especially in order to potentially end up in the same situation.

    • Not all agencies, freelancers and development shops pay close attention to the community and WordPress as a whole. It’s a tool that is used, one that historically tries hard not to create these situations.

  • Luke Cavanagh

    Have tested Gutenberg on local dev, but the UI and UX is poor and makes what should be easy to add content in, harder than it needs to be.

    • Totally agree with this… My take:

    • Anthony Hortin

      Totally agree! The current UI is horrible. I’ve lost count of the number of Github issues I’ve raised in regards to issues or difficulties in trying to do things. The average user is going to have quite a job on their hands, getting up to speed to create even the simplest of pages.

    • Especially that silly double button click when hitting update (or whatever it’s called, it’s too late now to check an environment with GB installed). In the current scenario Publish and Update are just that. In the new scenario it seems it is assumed that the user is stupid (why else would it use blocks to communicate?) and there seems to be a need to double confirm…

      • Luke Cavanagh

        The UX is dire on the publish part.

    • Hey Luke, I’m sure the Gutenberg team would love to hear UI/UX feedback ->

  • We host and manage hundreds of WordPress sites. With this being part of the core, I can only imagine the implementation nightmare this will cause for us. Maybe they should consider doing with Gutenberg what they do with Akismet; include it as a default plugin, and give the user or developer the opportunity to activate as they see fit. Slowly implement it and maybe by version 6 they could activate it by default or give an option in the Writing settings to turn it on/off (mirroring the response from Alex in the comments already).

    On they could activate it automatically, if that’s the direction they want to go, but for businesses that have their livelihood resting on building WordPress sites it could be problematic at best, and a crushing blow at worst, as many clients don’t have a budget to update their site, and we would be on the hook to keep it working properly. I am, right now, going to have to test how it works with X, Divi and Avada, as the majority of new sites and migrated sites to our hosting use one of the three of these.

    THANK YOU for pointing us in the direction of the Classic Editor plugin, that would be an ideal solution if it preserved shortcode capability and allowed for theme builders running on top of the admin dashboard to remain working.

  • Paul Aswad

    Let compete with wix and the others. Leave alone…

    Anyways they both have different markets, and the looks are completely different….

    I’m actually very surprised that Automattic is not listening to the community on this. After all, the community is what makes WordPress WordPress…

    • That’s a good point. Is it time for and to diverge. Different goals, different users.

      • Paul Aswad

        Right? I mean now that they have their business plan, with premium themes and plugins, it is obvious they are competing with the likes of Wix and Squarespace. So if a user wants everything managed by WordPress based on their plans, go right ahead, this is what you get.

        Now if someone wants to get someone to take care of his site, a freelancer, an agency or whoever, this is where comes in, and Automattic should pay attention to the needs of the community, and not make decisions based on competing with Wix etc… I mean I know for certain Wix is not my competition, since none of my clients would go somewhere to build their own sites.

        I am aware also that some freelancers would build client sites on Wix and others, but we’re not talking about professional things. Freidns don’t let friends use Wix ;-p

  • Ian Wilson

    As an official plugin or otherwise parallel development Gutenberg is great, sure it’s a big fuck you to a lot of plugin developers, but that’s okay, evolve with the times and all that. A great boon to people who can’t code!

    But as a piece of core it’s philosophically opposed to what WordPress was supposed be.

    At the end of the day, we’ll all adapt, in whatever form that takes- a sea change like this could be just what the CMS world needs to shake things up. Disruption will breed new innovation! Maybe we see a forked version of WP thats more geared towards us enterprise developers, while the hobbyists get self hosted Wix alternative, who knows! Change is what you make of it, your success is independent of how WP core is developed 🙂

  • Pierre Balian

    Great post, and really hits the nail on the head with all of my concerns. I too see this as something that will lead to a lot of fragmentation in the wordpress space. As if it isn’t bad enough having clients land with us that have horrible page builder websites (looking at you visual composer, divi, and beaver builder).

    WordPress’s editor is deficient. I would live a better editing experience, especially on the frontend. But I dont think the way this is going is necessarily the right way. And the average wordpress user doesn’t care about Automattic’s concern with competing with wix, squarespace and the like.

  • andrewnimmo


    Finally a sober analysis of Gutenberg for developers, not soaked in groupthink.

  • Mitch Brown

    Good article. I am new to WordPress. I have been watching Gutenberg because I see potential tat it could be used to program our data collection device and communicate with it over the internet. The barcode reader working directly with Woocommerce.

    I have built a couple of sites but would not consider myself a developer. I have run up against Wix and easily overcome the ease of use argument with site ownership. However, every person that chooses Wix was one of our potential end-users.

    In my attempt to learn I have attended two WordCamps this fall. I have found it difficult for some to transition from being blog site to web site developers to web-application developers.

  • “If instead a merge has to happen, then Gutenberg should only be on by default for new installs of WordPress 5.0”

    I think this sums up my position. As you say, it’s a great piece of software and I really admire the team building it – they’re doing a great job, and the editor will only continue to get better in the months to come.

    But retro-fitting this is going to be SO painful: for users, for developers, for support teams, for plugin makers.

    • > But retro-fitting this is going to be SO painful: for users, for developers, for support teams, for plugin makers.

      Can you clarify this with specifics? I’ve heard this more than once. For all of us trying to mitigate the pain, it would be incredibly helpful to track down relevant details.

      • Peter Tasker

        Probably the biggest issue is with meta boxes. There is support within Gutenberg for meta fields, however, if you’ve customized and admin UI for a client, Gutenberg being enabled by default will cause all sorts of issues.

        As of now there isn’t any strategy for how to handle this sort of thing, other than ‘install the legacy editor plugin’, which obviously isn’t ideal.

        There’s an issue that brings up this point with some reasoning:

        Also, if you’ve got custom metabox logic going on, or really anything that specifically references the post editor DOM at all you’re gonna have a bad time.

        ACF and seem to be on the ball, but if you’ve got custom stuff it’s a whole other ball game.

        Not to mention adding custom blocks for Gutenberg is not _that_ straightforward, and it’s not a trivial amount of work to convert any bespoke code to Gutenberg blocks.

        Further, this isn’t even covering training less technical clients on the new editor…

        • I also have user interfaces that have been built using Meta Boxes that I’ve created documentation/training for. If I update them to be blocks, which as Peter says is a substantial task, then I’ll have to re-do documentation/training as well.

      • Yeah. Don’t have time to go into details now. But I’m basically referring to the process of meta boxes breaking/changing and then needing to be fixed.

      • What approach are you taking to mitigate the pain, Daniel? Are you a dedicated resource on the project now?

  • Jonathan Nicol

    Good on you for zeroing in on the business motivations behind Gutenberg. It seems to me that Gutenberg is primarily aimed at customers, and the poor handling of metaboxes in the beta rollout has makes me think that WordPress’ developer base were not properly considered during Gutenberg’s planning phase.

    I think that Automattic and Elliot Condon will work together to ensure that the transition is relatively painless for ACF users, but this whole mess makes me very concerned about the future direction of WordPress and it’s guiding philosophy.

    After all of the work that went into positioning WordPress as a content management platform rather than simply a blogging tool – custom fields, REST API, etc. – Gutenberg feels like a step backwards. I hope that Automattic can reconcile the needs of these two distinct user bases, but honestly I think it might be time for WordPress to fork, something that would have seemed unimaginable six months ago.

    Like many others I have been considering my escape strategy and looking seriously at Craft…

    • Would be nice to imagine that a consortium of influential power thinkers are considering a potential fork.
      Is this being done for the good of all or for the good of few? Greed is always predicable.

    • Thanks Jonathan, and thanks for your thoughts – I agree that it’s a step back from a developer POV.

  • I like the idea of forking WordPress, preferably an “official” fork where 5.0 gives up backwards compatibility and implements a new database structure and all the big changes that have been held back by the need for backwards compatibility. The 4.* fork could keep backwards compatibility but still get security updates. Or if there is enough interest to move it forwards, new features. Forks are often seen as a bad thing in the open source community, but there are enough examples of successful forks.

  • As a web developer for well over 15 years, I get pissed every time someone wants a non-blog site in WordPress. There are so many superior tools/CMSes out there to use, but people insist on using the speedboat as a luxury yacht. If Gutenberg can help WordPress not rely on so many plugins to attain basic CMS features, I’m all for it. Too much adherence to backwards compatibility gets you things like Windows.

    • It’s a shame WordPress doesn’t see the value in those sites using it as a fully fledged CMS and support it further, instead of prioritising the blog/smaller site users on

      • That’s just the thing—WordPress isn’t a fully-fledged CMS. It’s a fully-fledged blogging platform that’s essentially infinitely extendible. That extendibility, however, gets sites into trouble with over-reliance on third-party plugins for basic CMS functionality.

        I’ve used (and fell in love with) a CMS that has what Gutenberg looks to achieve—Craft CMS with its Matrix field. Matrix and, from the looks of it, Gutenberg aren’t a replacement for the basic CMS feature of custom fields and entry types—a feature WordPress still needs in core before it can properly be called a CMS.

        Rather, they’re an excellent replacement for the overly-ubiquitous WYSIWYG field, allowing users to add whatever content they want, in whatever order they want, while encapsulating said content in a consistent structure that allows developers to reliably implement the style guides set in place by the designers.

        • True – it’s extended to become a CMS. But that still needs to be embraced and not potentially impacted.

  • Malcolm

    So how does this affect sites that already use a page builder plugin like Visual Composer?

    • It will either make it redundant, VC will need to be made Gutenberg friendly, or those sites need to disable Gutenberg. I haven’t seen any official word from WP Bakery on their stance.

  • If anyone here agrees that “Gutenberg should only be on by default for new installs of WordPress 5.0” then there’s now a discussion about how Gutenberg should be enabled going on on GitHub. Please go and add your voice to the discussion. Maybe we can influence how this gets added to core:

  • Thanks for your thoughts and raising the point about disabling for meta boxes.

  • Mat Gargano

    Yes I did, glad i saw some comments on forking — though not exactly endorsing it at this juncture 🙂

  • David Skarjune

    But who are they that decide and what are their goals? The Growth Councils had private meetings last month after being announced over a year ago. No records of anything at the Foundation or on or Slack channels, though a member has reported to me that video meetings of the Enterprise Council and Consumer Council were held in December.

    Maybe they’d appreciate a fork, since that would help drive away smaller agencies not in their fold, if perhaps ‘Growth’ is not about users or developers but rather about the profit chain of the ecosysem. When I read the comments on Gutenberg by Tony Perez and Chris Lema, it’s more about the business ramifications than the code.

    If we look back at the history of other CMS platforms, Joomla failed at forcing developers to play along with rapid (and somewhat desperate) iterative upgrades, while Acquia has succeeding commercially by maintaining tight reins over Drupal with major upgrades over multi-year cycles.

    Just sayin’ there’s more to know that we don’t know.

  • I use for my personal blog. I am not a developer. Just a super user.
    Gutenburg would be best for someone with also very good basic visualization and graphics design skills with strong usability design experience.

    It will be valuable for organizations and businesses who need to repeat same content in various posts and widgets.

    I appreciate the design of block templates but for a someone writing content and whose focus is on excellent writing and relevant photos/videoclips, etc., figuring out the block template seems 1 additional barrier or design thing they may need to consider.

    It is better as a business model which I so strongly Automatic needs think: business model NOT as a design/developer model: have Gutenburg as a separate option to activate. Leave present WSWYG the same. Otherwise there will be a lot of angry or worse, departing client blog administrators as en masse exodus.

    I’m at

  • Scott Foster

    My big fear, along with the technical arguments, is the ramifications of the ecosystem that you touched on n the article. I understand the premise of WordPress has always been “Democratizing publishing”, but when you follow suite with the new visual editors and do-it-yourself platforms you empower the end user at the expense of those developers and designers that helped the platform grow into the massive community that it is today. I have noticed already over the last few years a shift in the clientele we build sites for. Its akin the the economy in general with the disappearance of the “middle class” where we either have people with little budget asking for sites or we have the larger size projects between $15-30k. The bread and butter jobs for many small agencies was in that $5k-10k range and I had quite a few people agree with me at Wordcamps as well. How many people with need companies like Themeforest, or custom site and plugins developed if they can largely do most of it themselves in the future? The argument already exists when trying to pitch a custom site for a few thousand bucks when the clients ask “Well I can get a really nice site set up faster for free, how are you different?” Free is hard number to battle when the economy is how it is. I can try to talk about the importance of branding or how they might be limited in what they can accomplish with seo on a proprietary locked down codebase, but they likely don’t care or eyes glaze over if you get too technical. Whats more concerning to me was Matt Mullenwigs response when I spoke with him at World two years ago and asked him this question. He said “I wouldn’t worry about it too much. If less people start needing custom sites then you can shift and offer complimentary services like SEO.” I wanted to say “How many people that do not see the value in a custom site and would rather build their own for free likely have anywhere near a decent monthly budget for SEO aside from farming out to a weak penalizing web 2.0 plan?” But I didnt feel like arguing. Maybe im just being a pessimist, but I see many web shops like myself turning into maintenance services to fix whats built by the “new wave” of web designers. Anyone else agree?

    • Thanks for your thoughts, Scott. Unfortunately, it seems Matt has always had an apathetic attitude to others making money from WordPress.