WordPress 5.0 is Not Ready

I didn’t plan to write this post.

Before it, I was working on a different one addressed to my clients about the upcoming changes to WordPress: In version 5.0, a brand new editing page design—code-named “Gutenberg”—will replace the Edit screen where site editors spend most of their time. I want them to know what’s coming, how it will affect them, and how I will support them through the change. Naturally, I wrote it in the new editor using WordPress 5.0-beta1.

It did not go well.

We always say that first impressions on the web matter, and WordPress is only going to get one new first impression with each site owner. As it stands, too many people will have a negative first impression.

tl;dr: WordPress 5.0 can and should be a positive change to WordPress, but if it is released in late November as planned, it won’t be. There are simply too many bugs in the editor, and the experience is not polished enough. This is because the rate of development has prevented systematic quality assurance (QA) and user testing. Both types of testing are required to ensure the editor is ready and to increase the community’s confidence in the update.


Big Problems. Small Problems.

I want this to be a constructive post, so here are some of the issues that lead me to this point.

Overall, it’s still hard to “just write.” Things pop up and flash and make it hard to focus. I’m not the only one who thinks so. John James Jacoby posted a great review of his first-impressions of the new editor:

There are grey and blue hover/focus outlines on blocks, toolbars pop-up, the buttons in them have tooltips that pop-up, and there’s a grabber UI [User Interface] for relocating blocks that comes and goes – it’s just… a lot going on.

John James Jacoby, “WordPress 5.0 Beta 1”

The overall experience of writing, editing, and saving still needs testing and polish to avoid first reactions like this. Specifically, I think more “progressive disclosure” will benefit users by giving more prominence to commons tasks and less to infrequent ones.

Looking closer, when you really start writing with this new editor, there are simply too many bugs that affect frequent everyday writing tasks. While writing this post and the previous one, I found a number of bugs just for making bulleted lists. In one extreme case that happened repeatedly, the editor deleted most of a bullet’s text. Some problems have been fixed already, but these types of bugs simply shouldn’t be popping up 3 weeks before launching a tool to 32% of the internet. And that’s not to mention the list of 10 or so bugs I still need to report.

I’m doing my best to give feedback, but it’s exhausting and there are so many little bugs that I struggle to isolate and replicate the one I’m reporting without running into another. How is it possible for me to find so many bugs without trying from just writing 1.5 blog posts?

One doesn’t realize how many small interactions are involved in writing a blog post until they suddenly stop working. Gutenberg has been eye-opening in this regard, as many of my subconscious clicks and key presses don’t do what I expect them to. For example, I find my assumptions for the behavior of ENTER, BACKSPACE, DELETE, and arrow keys are frequently violated. My cursor gets stuck in some blocks and I’m unsure of what combination of TAB, ENTER, or arrow keys will get me out.

Thinking about the useful concept of interaction costs—each decision, click, and keystroke is a “cost” to the user for using the interface—the editor is much more “expensive” to the user in WordPress 5.0. Some of that increased cost is worth it as a trade-off to gain more powerful features, but much of it feels unnecessary and maybe even erroneous.

What Needs to Come Next: Testing & Polish

At this point, I’m over my initial “it’s different” fears of these features. What’s more, I want them to succeed! My entire business is built on WordPress’s success. I even think that this next version of WordPress will be an improvement. BUT. IT’S. NOT. READY. YET.

The pace of development has been blistering. That speed has been great for developing a lot of features and iterating on those features quickly, but it hasn’t allowed for sufficient testing. What’s needed now is more time for people to find and report bugs with the editor features in their proposed final state.

In particular:

  • We need real-world published user testing—especially for accessibility—that validates the usability of key writing tasks and the overall user experience for focused writing. Simply stating how many sites have the plugin installed or how many posts have been written (less than one per site Update 13 Nov 2018: Thanks to Miguel for pointing out that the stats I link to are quite unclear. The count of posts created is only from a subset of the total sites with Gutenberg installed. It would be very useful if they could clarify how many sites the post count comes from as I do think the posts/site stat is interesting.) is insufficient evidence of readiness.
    After completing a draft of this post, I learned of this excellent testing work from Sarah James [wordpress.slack.com account required]. (PDF Summary of one test. Update 13 Nov 2018: 10up published Sarah’s recent testing today!) This is what we need more of! It should be publicly celebrated when it confirms successes and publicly addressed when it shows failures.
  • I would like to see the core writing blocks (headings, paragraphs, lists) “blocky-ness” de-emphasized to allow for better focus and flow when “just writing.” For instance, the “Paragraph” label that hovers over a paragraph block seems completely unnecessary.
  • Rather than making a solid experience for everyone, additional “modes” (Spotlight, Fullscreen, Block Navigation…sort of) were added, seemingly to satisfy specific complaints. Let’s take that feedback and improve the default experience instead! Any modes that remain need testing to confirm it achieves its stated purpose.
  • There also needs to be more QA testing of keyboarding sequences (the source of most of the bugs I’ve found recently), in browsers other than Chrome, for accessibility, for performance, and when paired with popular plugins.

Complete the Abandoned Audits!

As best I can tell, there has been no formal, exhaustive QA work done. This is a necessary step to ensure the editor features will work as intended for everyone. An effort like that has never been done in WordPress before, but WordPress has never released such a massive technical and UI change in a single release either.

One of the ways to facilitate this work is to complete the “audits” of each block type in addition to audits of other major features like the different “modes” and general formatting options. These audits seem to have started this summer but haven’t seen any work since early September, so they are now both out-of-date and incomplete.

As the audits are conducted, I would also hope for final reconsideration of each feature to determine if it’s truly necessary for a simple, easy-to-use editor that facilitates good web publishing. There are a number of tools and block types that are certainly useful for someone, but every feature and option competes for attention. I think there are some easy candidates for removal*, and doing so would increase confidence in the project by demonstrating that hard decisions are being made to streamline the interface and reduce its complexity.

Without working through a systematic review of what’s been built, I don’t know how anyone can be sure that the editor is ready for release. (If you know how that decision is being made, I’m eager to hear it!) Worse, there hasn’t even been a public explanation for why these new features are ready.

For the past 3-4 years, WordPress has required a “merge proposal” blog post for every major new feature added to the software. While I’m sure many people fear the negative comments that will accompany a merge proposal or feel it’s not perfectly suited to the job, this is also the wrong moment to make an exception to a precedent that’s intended to publicly establish a feature’s readiness for inclusion in WordPress.

Why Delaying the Release of WordPress 5.0 is Reasonable

My guess is that in the last two years, I’ve spent 40 hours on this project providing early conceptual feedback, closely following development, testing, reporting bugs, and even organizing testing at WordCamp Seattle 2017. And yet, I still feel like I’ve barely been able to keep up, much less to do meaningful testing and delivering feedback. I suspect this has been the same for many.

In its current state, WordPress 5.0 (Beta 3 at the time of writing) has features that don’t really work and small but obvious bugs. It’s not accessible nor a unified experience for anyone. Given the timeline so far, it’s impossible that enough testing has been done to confirm the overall experience is ready or that the features included are the ones that should be in the final product.

And that’s to say nothing of the broader WordPress ecosystem. Plugin developers need more time to ensure compatibility. Themers need time to wrap their heads around the final featureset to determine the best way to support it. Bloggers and trainers need time to update and create accurate materials to support the first users of Gutenberg.

If Gutenberg is released on it’s currently planned schedule, I will block it with the Classic Editor plugin from the ~30 sites I manage for my clients. I will block it not because I don’t like it, but because I’m not convinced I can promise my clients it will work as intended. That’s an important distinction.

Why 5.0.1 is Not the Solution

One likely response to the ideas in this post is that subsequent biweekly bug fix releases to WordPress 5.0 can address these issues. I disagree.

I suspect that if the above plan is completed, “breaking changes” to code and notable interface changes are likely. If my assessment of the issues with bugs and experience are even half-right, then there should be notable changes made to the user interface, and some features should even be pulled and released later. These changes must be done before WordPress 5.0 goes live.

Current users of the “beta” editor are tolerant to change in a way other users won’t be. So until 5.0 is released, there’s still time to fix mistakes and remove features without causing an uproar. The saying goes, “measure twice and cut once.” It’s not “cut once and measure ten times,” which is what a series of minor-point releases would be.

This is What WordPress Should Stand For

WordPress wants to “democratize publishing” by making the best CMS in the world that anyone can use. Its mission states, “WordPress is software designed for everyone, emphasizing accessibility, performance, security, and ease of use.” If all those things aren’t true yet for this landmark feature, we shouldn’t release it.

I don’t think Gutenberg should be trashed or radically changed. I just think that a clearly defined plan for testing and validating the final proposed featureset is necessary to increase confidence in the project and ensure the editor is actually ready for release. That requires more time than the current schedule allows.

Let’s just wait a few more months (how about February or March?) to test, fix, and let people better prepare for the change. I think the editor can be drastically better by then and ready to live up to WordPress’s grand stated ambitions.

* Appendix: A list of features that I think are  unnecessary for a solid core editor

Like I said, I think there are a number of features that are candidates for removal. Removing even a few features will help users focus better on fundamentals, reduce the amount of code requiring support, and streamline the overall experience.

  • Tables block – It’s begging for abuse. Using tables for layouts is a 10+-year-old bad practice, and in my experience, if you give users tables, they will use them for design.
  • Paragraph Background Colors – As highlighted in Jacoby’s review, paragraph backgrounds are a niche feature and also probably don’t meet everyone’s needs anyway. Waiting until Gutenberg has more robust support for nested blocks and then introducing a “Box” block that can contain multiple blocks feels like a much better long-term solution. This is a feature people won’t miss if it’s not there, but will complain about if it only half-meets their needs.
  • Spotlight & Fullscreen mode – I’m sure some people may like these…and they should be free to install them with a plugin.
  • Dropcap – A very prominent option for a very niche text formatting effect.
  • Verse Block – A block specifically for poetry was a nice proof of concept in the early phases of development, but we have since passed that moment.
  • Pixel-based font sizing – The developer-defined font sizes are sufficient for almost everyone and protect users from inconsistent font-sizing across their website. Further, pixel sizing requires inline CSS styles, something that should be avoided at all costs.
  • Columns – While I think columns are an important feature for eventual inclusion, they are still incredibly buggy and hard to use. If they can’t be drastically improved in time, they shouldn’t be in Version 1 of the editor.


I want to be really clear that this post isn’t targeted at any specific person or in response to any specific experience. I appreciate the truly incredible effort that has gone into developing Gutenberg. That effort hasn’t been wasted and I think the project is in its final stretches. But frustration sensed is real and stems from a lack of clarity around planning, testing, and a clear vision of how to know when the editor is complete.


A big thanks to Joshua Wold, Larry Swanson, Alfredo Rodriguez, and my partner, Emily, for providing feedback on drafts of this post.

15 thoughts on “WordPress 5.0 is Not Ready”

  1. Mark, as always I appreciate your carefully crafted analysis and sharing. All I can say is from your mouth to Matt’s (and other’s) ears! I haven’t had the patience you’ve put in. I’m simply buffering my clients from Gutenberg for the short term by installing the Classic Editor on every site. I sure hope they hear you (and others) and choose to delay. I so agree about first impressions.

  2. Mark, there are 600,000+ active installations of Gutenberg and only 500,000+ of actives for Classic Editor.
    Gutenberg > Classic Editor.
    All your points have been invalidated.

    /sarcasm off.

    1. Realworld Dev, I don’t think there are any sinister motives here. Rather, I think there are a lot of well-intentioned folks who desperately want see the good parts of this get out into the world.

      Like I wrote, WordPress has never seen anything quite like this before, so we don’t have systems and precedents to support a polished release that’s well-received. That’s nobody’s fault, but that also doesn’t mean we shouldn’t address it!

      If you’re concerned about the imminent release, I really think the best thing to do is identify and publicize problems that will impact users to help those in charge see that the tool just isn’t ready yet.

      1. > .. identify and publicize problems ..

        Been there, done that, more than a year ago, many of the issues still unsolved. One example, current REST API for editor is simply not capable to handle realworld sites with something like thousand customers = WordPress user accounts, several hundreds of taxonomy entries, a few thousand images, etc. – various workarounds and hacks have been tried by different GB devs to fix the mess, none has been sucessful yet, and existing filters to terms etc. simply are not implemented. Another example, some images like coverblock are included via background-url() CSS, by this can not have srcset etc., are not responsive this way, so even small screen iphone 5 will have to load the same image file as other devices with a 4k screen, just consider the bandwidth. Lower user roles could not even use coverblocks, because “unfiltered_html” capability, now some extra hack has been added to core which changes existing behaviour. Many more examples can be found in github and can be observed by anybody who simply tries Gutenberg for half an hour and tries to do some realworld “WordPress as CMS” things with it.

        Gutenberg is still in alpha stage, even desperate well-intentioned folks have to see this, the whole concept turned out to be flawed, now it would be time to go back to drawing board, but instead that release is pushed like nothing else has ever been pushed before. Time will tell, one day we all will find out the motivation behind this.

        1. I get the sense that this and all the other posts like it are finally starting to get through. This is the moment then to unleash as many small, reproducible, well-documented bug reports as possible so if a systematized review of everything happens they’re ready. I plan to spend much of my upcoming WordCamp weekend hanging out and doing just that. I didn’t think so before, but I think people are listening right now. For starters, there appears to be an upcoming make.wordpress.org/core/ post about the timeline.

  3. Thanks for sharing your concerns about Gutenberg. I just hope someone is listening. Many of us are tired of opening issues on GitHub to see them being closed days later. The editor still feels like alpha software to me. I installed it in a personal blog a year time ago to get used to it, but I always return to the classic editor. Decisions like creating a new block for every paragraph still make absolutely no sense to me. The constant UI showing and disappearing doesn’t help either.

  4. I keep coming back to the declared idea behind Gutenberg, which was to stop inexperienced people drifting to Squarespace, etc. I’ve been using Gutenberg since January and I find myself every day saying to myself – If I was new to editing, I would be lost. Simple things like highlighting a bit of text require finesse and patience. I like Gutenberg but it feels like someone put a wobbly bicycle between me and the page.

  5. Thanks for your detailed view on the new page editor something echoed around the web. They can’t force the update if it doesn’t work properly.

    I have only had a little play with the new editor and have found it a bit disjointed. I do agree there needs to be a page builder as building simple page layouts with columns isn’t easy at all without a plugin so it is the logical next step. However with most premium themes including a page builder of some type, which most people are used to now, I’m surprised they have tried to be so different. Maybe if they had of created something more similar it wouldn’t be such a big leap.

    1. Unfortunately that’s the plan right now, Jennifer. As someone who works mostly with nonprofits, the current launch date is on Giving Tuesday! Even if the launch were to be bug free, many nonprofit staff will panic when faced with an unexpected change this big.

  6. Hi, Mark. This is a thoughful post, but I wanted to point something out:

    > Simply stating how many sites have the plugin installed or how many posts have been written (less than one per site) is insufficient evidence of readiness.

    That stats page, https://gutenstats.blog/, lists total plugin installs across WP.org, but it can then only list posts written on WP.com or certain Jetpack-powered sites (since neither WP core nor Gutenberg collect this sort of data). Thus, the “posts written” count is expected to be quite larger than 670k — by how much exactly, that’s an important unknown, but in any case it’s not correct to associate the two figures into an average of “less than one post per site”.

    I’m sure there’s room for improvement in gutenstats.blog to make this relationship (or absence thereof) clearer, but it felt noteworthy.

    1. Thanks for mentioning this, Miguel. You’re totally right! I’m still unhappy about how opaque the launch-readiness criteria are, but you’re right that my initial interpretation was wrong. I have updated that section to correct and clarify along with a shoutout for the valuable comment :)

Join the Discussion

This site uses Akismet to reduce spam. Learn how your comment data is processed.