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.
- 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
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 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.