Skip to Main Content

Misconceptions about Gutenberg are not valid criticism

I am generally seen as a critical voice to WordPress’s Gutenberg editor.  It is true that I feel there are many places where criticism of Gutenberg is valid, such as in timeline, scope of initial releases, and methods of post storage. However, there has been a lot of criticism of Gutenberg recently that is based on misunderstandings or miscommunication of the project goals and the definition of a “block.” To that end, I’m going to try to distill down what the “block” paradigm is all about, and why it is crucial to WordPress’s future.

Note: I am not a core part of the Gutenberg team, and have as much chance of misinterpreting things as anyone else.  To that end, upon publishing this, I will be reaching out to the team leads, Matias Ventura, Joen Asmussen, and Tammy Lister to fact check me and correct anything I have gotten wrong.

Blocks are not the visual editor

Blocks, conceptually, are not a visual way to represent and edit post content, they also don’t have to be part of a content-picker menu, or drag/droppable. They can be used for those things, of course, and that is the workflow that much of the visible parts of Gutenberg have highlighted. However, ignore what you know about that paradigm for a moment, and instead look at it this way:


Blocks are meant to be a fundamental control structure for the site, regardless of interface or storage.

  • Widgets are slated to become blocks. That does NOT mean that they will exist in the editor and be saved in post_content. It simply means that they will be controlled with a system built in a JavaScript framework, with a single, common API.
  • The Customizer is slated to be replaced with blocks. The interface will probably remain (roughly) the same, but the sections of the Customizer will be controlled by the same API.
  • The plugins page, the theme editor, the dashboard itself, are all slated to eventually become blocks. If the idea of these sections, exactly as is, is impossible to imagine recreated with a common API, then you probably have some misconceptions tied to what a block is, in WordPress parlance.

I know that seems completely counter to commonly cited design posts and project announcements, but I assure you, that has been the plan espoused in numerous track tickets, slack conversations, and in Matt’s State of the Word address, for several years.  This miscommunication is the root cause of a lot of the anger that I have seen.

Blocks are the basic, common framework for the next WordPress Admin

Blocks are the starting point for a common UI framework that will eventually encompass the entire admin interface, and they were a major driving force behind the focus on the REST API. They serve as a single concept to base an extensible JavaScript-based admin. You can picture them as a system, like php hooks (actions and filters), that present developers with a way to modularly add or modify portions of a JavaScript UI.

All metaboxes CAN become blocks

As such, the idea that metaboxes and Blocks can’t mix is not accurate. The issue is not that metaboxes can’t be recreated inside the block paradigm, in fact, non-front-end blocks that are added programmatically to a post type, locked in place, and store to post-meta instead of post_content are slated for the WordPress 5.0 release.(GB Team: please correct me if I’m wrong)

In essence, that covers all the needs for trivial meta-fields like textboxes and selects. You could exactly duplicate that interface in blocks, if you want, or you could possibly streamline some of it, based on the new visual language that blocks supply… that would be entirely your call.

The issue is not that metaboxes can’t ever be blocks. The issue is that right now, there are interfaces made in metaboxes, that are not yet supported in blocks (either by WordPress or third parties), and re-implementing that work is a herculean task for developers.

However, the current state of affairs also hurts developers.  Metaboxes are currently implemented in a hodge-podge manner that directly modifies the DOM of the page, and enqueues resources into the global scope, in an ad-hoc, unmanaged way. This can lead to complex and hard to debug issues. For example, if you use Visual Composer, along with Piklist for fields, Piklist will override many of your admin styles, making VC very difficult to navigate. Visual Composer is somewhat at fault for not scoping their styles and making assumptions about what the admin panel would style for them, and Piklist is somewhat at fault for applying their styles globally to all inputs on the page, however the user and the developers both suffer because of this. If you are using WooCommerce along with any plugin that enqueues the new version of the Select2 Library, one or the other will break your admin interface, with a critical JS error. The same thing can happen if two different plugins rely on different versions of the CMB2 framework. These issues are non-trivial, and have been one of the core causes of plugin compatibility issues.

Blocks intend to solve these issues by introducing a common framework around the various page additions. Some of this framework will be focused on offering wiz-bang drag and drop visual stuff to the editor, but the majority is not actually tied to that. It is just making sure that things that appear in admin are managed in a common way.

The Fields API, and an abstract common config

The fields API is a proposed common structure for building complex metabox UIs in code, that has been at trapped in limbo for a while. The timeline for Gutenberg has rekindled the lack of the Fields API as a touchstone. For some design/developers it would be a stand in for tools like CMB2 or ACF. However, for those who want the management interface of ACF, or some of the advanced features of CMB2, it would more likely become the backbone that these plugins use to communicate with WordPress.


The major benefit to the Fields API is that it would abstract the concept of an admin interface from the actual code used to output it. with a clean separation of design, a developer could smoothly transition from PHP/HTML/JS metaboxes to JS/REST blocks, without ever noticing the change (aside from a nifty new design).  Fields designed in such a way would even be able to smoothly transition from contexts that use Gutenberg, to contexts that don’t, without any re-coding. Unfortunately, the lack of such separation at the moment has caused a huge amount of concern about having to maintain two different UIs for each situation, or needing to rebuild entire codebases for Gutenberg compatibility.

For most designers, the Fields API won’t matter

I don’t say that because it’s a bad idea or unnecessary, but because most designers already utilize an abstraction layer to create their fields. As such, that translation to a Block mentality becomes an incredible amount of effort for ACF, CMB2, Carbon Fields, Types Toolkit, PODs Framework and others, but not for the designers using those tools. They may have to go through a brief transitional period where their plugin developer works to update his/her rendering code, but at the end of the day, they will be transitioned to blocks relatively smoothly.

For plugin developers, the Fields API matters A LOT

Producing a Fields API would massively simplify the work required to retool plugins that use Metaboxes to the new Block standard. It would also protect these plugins, to some extent, from future changes, by providing a way for them to be sure they are “doing it right”. To that end, it would be great to see members of the Gutenberg team and members of the plugin community come together to drive a release of the Fields API before the release of WordPress 5.0. I know some of these meetings are happening informally on slack and github, but a concerted public effort would massively assist in easing the worried of smaller developers, who may not have the time or experience to formulate the tasks to move forward with confidence.

There are valid arguments that the Block interface will not reach anything close to widespread dev adoption before release. There are even valid arguments that the current block API is a bit naive, and doesn’t take into account many common workflows, making it impossible to adapt plugins until those capabilities are created and documented, all these could be countered with a combined effort between plugin authors and the core team, to get Fields API finished, and to drive adoption. If this doesn’t happen before 5.0 release, I believe it should be the absolute first push thereafter.

The case against ANY framework

There are valid arguments that WordPress has thrived on a Wild West development attitude, that catered to developers at all levels of experience. If you didn’t know the Settings API, for example, or found it too limiting, you could simply shove a form into the page, and directly handle the POST data sent back.  It is a dangerous process that has the possibility of breaking in some circumstances or with some plugins, and can potentially weaken security, but it had an extremely low barrier of entry. It is also a fact that this common framework raises the barrier of entry for developers who don’t know react or other frameworks or advanced JavaScript.

There are valid arguments that prototyping within a framework takes longer and costs more to produce the tools you need, if the framework isn’t built with your UI needs in mind. However, there are countering arguments that for common use cases a framework will take much less time, and for all use cases it will be safer.

These are ideological arguments that are hard to settle, but the view of the core team is that a UI framework is necessary to move forward safely and to remain relevant against many more structured competitors like Ghost and Ember. It is true that there are many dissimilar frameworks controlling parts of WordPress at the moment (menu API, Widget Classes, Image Library, Customizer, etc), and a common framework would massively lower the learning curve to work in all these areas of the site.

All that said, arguing that the Metabox free-for-all, as it stands, is the best solution and must be preserved for eternity doesn’t offer a great path forward for anyone. For WordPress to be able to offer better options for all users, devs included, some sort of control needs to exist over the complete Wild West we have now.

The Gutenberg team is NOT an Automattic-based Cabal

If you read through the major public posts about Gutenberg, that target the editor aspects of the project, it is easy to believe that the team is saying one thing and doing another. However the decisions being made are discussed in weekly slack meetings, in the public making-wordpress slack team. They are also openly discussed on github and in the comments on the Gutenberg plugin, and on WP Tavern. Many of the public posts made are aimed not at developers, but at casual users, who would be lost and confused by deeper-dives into the underlying philosophies behind the changes being made.


The misunderstanding comes from the fact that there isn’t currently a middle ground between summaries for casual users and a firehose of mostly irrelevant data for the team itself.  I believe a really valuable team role would be a communications liason, who would summarize meetings and results, and any decision-making moments into an organized living document that could be used as a reference for the team and for outside developers. Something as simple as “Question, Decision, Date, Link to discussion, Pending/Decided, Tags”. It would be much like the issue tracker, but rather than being open for comments, it would simply be a link to the locations where discussion is occurring, that would serve as a single point of truth for the project.

Of course, this is not a task anyone actually wants to take on, as it means digesting and distilling a huge amount of data, and would be a focus for the ire that many people in the public feel towards the project.

Often, when people say “This wasn’t decided in public”, they really mean “I don’t feel my voice was heard”. Sometimes they don’t even realize that the place they are posting IS the discussion. Clearer communications would help with that, but also more patience and understanding from the community as a whole. Of course, there is a pathological version of this on both sides, and it is often hard to tell the difference between calling out lack of transparency and calling out lack of attention on your own part. I’m certain I have been guilty of this in some cases.

The Gutenberg team is working very hard on a very difficult problem

The Gutenberg team has been tasked with creating a paradigm that will become the basis for WordPress’s entire admin experience, within constraints that only allow them to demonstrate its effectiveness in one small corner of the interface. That is an incredibly difficult place to find yourself. While they are still trying to build an internally consistent solution for the WordPress admin, they are fielding implementation questions about interim solutions for specific components.

This doesn’t invalidate these concerns in any way, but it is a herculean task, and the end result looks promising. the WordPress 5.0 release will probably be a bit rough, but they are setting up a better interface for WordPress 6.0, and they are generally doing an excellent job.

I am still critical of those things I feel will be damaging

All that said, I am still strongly in favor of Yoast’s proposed interim solution, of scaling back the initial release of Gutenberg to focus only on the editor itself, rather than the edit page. I believe it is the best real-world way to move towards an eventual common UI.  I also remain critical of the choice to store post_content as comments, as I feel that it sets up a false sense of structure for something that is, in essence, unstructured.

However, all of that said, I want to make sure we are critical of facts, and not misunderstandings. Gutenberg is a big project, and it is in my mind, crucial to the long term future of WordPress, not only as a blog, but as a relevant CMS.


  1. Tammie Lister's profile image.

    I wanted to add a note of personal thanks for writing this. I also want to be sure to note that from respectful, polite, critique will come a far stronger Gutenberg. We all care about WordPress, the passion comes from caring. It’s how we interact as humans though.

    What Gutenberg does is lay a foundation down with a new editing experience. What is being set in place is a foundation, both in design and technology. Worth noting there will always need to be a management area in WordPress. You could think of a comment stream on a site as a block and in the same editor. You could think of menus as blocks – that opens a lot of possibilities. As you start to think in this way it gets really interesting and a lot of potential opens up.

    One thing that personally excites me a lot about Gutenberg is also the changes it can have for themes and the experience for users of themes. Themes could become much more like a styleguide, with this a lot of theme switch issue vanish. That’s incredibly powerful. Think on from that to suites of blocks, to a block market place.. it adds up to an exciting new developer market.

    An important thing I tend to think of when looking at the future is that posts, pages, they don’t matter anymore – they never mattered to users. It will all be content. Users will be able to create and interact with ease to any content they want. At the moment users are really confused over the split we have and confusing terms – metaboxes, custom post types.. it all adds up even more confusion. This comes up in usability tests, forums and we’ve all seen how much learning WordPress people have to do. As a user progresses they get used to the ‘WP way’, but that’s not a grounds to keep things as they are.

    All metaboxes can become blocks, or at least most things that use metaboxes right now can either become blocks or use extensibility of Gutenberg. I think it’s important to say that some plugins will remain just that, that’s up to the developer. As a designer, solving the usability issues right now of metaboxes is a huge step forward through blocks. It’s about education too, you are right this can’t happen magically over night.

    As far as communication goes, as a team we can be better at that and thank you for the suggestions. Would you be willing to help in that role, looking over meetings and providing a summary in a living doc? I would be happy to help you do that.

    It matters to hear all voices for Gutenberg. Everyone making Gutenberg cares and thank you for taking the time to clear up some misunderstandings. Ultimately, everyone cares that WordPress succeeds, that’s a powerful bond that unites us.

    • William Patton's profile image.

      Hey Tammie!

      I posted criticism of Gutenberg early in the public dev cycle and you personally responded to my posting in the forum. You responded with assurances that I was being listened to, my concerns were being worked on and with suggestions I make my voice heard in the repo as well if I didn’t feel they were going the right way. I posted criticism – it was accepted and taken on board.

      For anyone who believes they are not listened to: It may not seem like what you say has had an impact but I assure you that the team has been hearing what you say and acting on it in the best way they can. I know this because some of my initial concerns are already non-issues. The other concerns are in the process of being worked out 🙂

      We all think we could do it better, that’s the entire idea behind Gutenberg, right? To make the editor experience better. We all put our minds together and come up with the best solution for everyone, not every use case is covered yet but huge progress has been made

      • Tammie Lister's profile image.

        Thanks William for such kind words. It is so important we get all voices heard and thank you for speaking up. You are so right, what we are all trying to do is make WordPress better, in any aspect. That very rightly includes the community and the product.

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>