Matt Mullenweg, CEO of Automattic and founder/director of the WordPress Foundation, recently wrote a blog post entitled “We Called it Gutenberg for a Reason”, which attempted to address the widespread concerns voiced about the direction of the new WordPress editor. In general, the post made a lot of big promises about how Gutenberg would solve everyone’s problems. Unfortunately, many of those claims don’t live up to reasonable scrutiny. So, I find myself writing a response to the post, voicing some of the issues I find with what I see as an overly optimistic view.
I’m going to base this post around addressing the various bolded sections in Matt’s post, so if you haven’t read it, you may want to.
Developers and agencies will be able to create interactive templates that clients can easily update without breaking things or dealing with custom post types: Imagine a custom “employee” block that you can add to an About page that includes a picture, name, and bio. They’ll be able to replace most meta boxes, and they’ll get a chance to update old code or clients to work in this new paradigm.
This response fundamentally misunderstands the value that Custom Post types and Metaboxes provide agencies. They serve to provide separation between structured data and design. For example, a ‘staff’ custom post type would have a totally different interface than a generic post, requiring the user to enter the structured data, like name, position, and photo as raw text or image fields that are completely decoupled from the page’s design. This stops content editors, who are not on the design team, from deciding that certain staff pages should look different or behave differently.
physically separating the interface for these post types from each other serves to enforce the idea that they are separate concepts, and that one shouldn’t make a random post a child of a staff page, for example.
There has been talk on github of making metabox blocks, which would allow for feature parity on this front, but I fail to see any benefit from the changeover. Basically, Matt is touting the ability to create unstructured blocks of data, in an ad hoc manner, when Agencies and Developers need structured data, instead. This decoupled structure protects the data attached to a post through the process of a complete redesign of the front end, and providing a more design-centric interface just begs content editors to try to make it “look good”, rather than leaving that to their design team.
In addition, lots of metaboxes store data that isn’t shown on the single post view of a page. It might be open graph metatags or data for a filterbar, or enhanced keywords for site search. Moving this data into a view that is integrated with the post_content just blurs the line between unstructured content and structured data, and will confuse users.
Plugin developers will be able to completely integrate into every part of WordPress, including posts, pages, custom post types, and sidebars without having to hack TinyMCE or squeeze their entire feature behind a toolbar button. Today, every plugin that extends WordPress does it in a different way; Gutenberg’s blocks provide a single, easy-to-learn entry point for an incredible variety of extensions. Some folks have already begun to port their plugins over and finding it easier to build and to have a much improved UI, I’m looking forward to highlighting those stories as we get further along and more people write about them.
Matt uses the term hack to describe integrating with TinyMCE. This is very telling, as WordPress has been tightly coupled to TinyMCE for a decade, yet still thinks of their API as a hack. It exists as such, because almost no documentation exists in the WordPress codex for this tightly coupled component. TinyMCE has a poorly documented API that needs a lot of attention. However, TinyMCE is remaining a core part of the new editor. What Matt is saying is “This full-featured API is badly documented, so we built a new API around it, rather than write the documentation”.
Perhaps Gutenberg will be different, but maybe some effort should be made to improve the documentation we have, before creating a whole new kettle to document. (and it should be noted that the current Gutenberg documentation, although in beta, is definitely not up to the standard necessary)
It should also be noted that when Matt talks about a “single entry point”, he’s really over-simplifying the issue. Gutenberg adds the need to write React components, to interface with WordPress via the API, but the API isn’t the core code. Any sufficiently deep integration is still going to be rooted in PHP, so really we just added the necessity for every project to incorporate JS and CSS components as well as the aforementioned PHP, complicating scope, and narrowing the field of competent developers who can work on it.
Theme developers won’t need to bundle tons of plugins or create their own page builders. There’ll will be a standard, portable way to create rich layouts for posts and guide people setup right in the interface, no 20-step tutorials or long videos needed. Every theme will be able to compete with multi-functional premium themes without locking users into a single theme or compromising their experience.
This would be wonderful, if it was even close to what the actual core team is building. In actuality, there is an eschewing of “theme builder-like features” going on, as the project goals focus on “a vertical river of content” and continually push off such fundamental needs as a common interface for nested blocks. What will happen in actuality is that Gutenberg will launch and page builders will take one of two routes, either they will implement custom blocks to fill in these basic needs that Gutenberg left off, continuing to contribute to theme lock-in, and leaving free themes behind as they don’t have the manpower to create all the necessary custom blocks, or they will continue to completely ignore the post editor and go on with their custom solutions. As long as custom blocks are necessary to create a full page builder in Gutenberg, there really is no improvement here over any of the awful shortcode-based builders we’ve seen in the past.
This is a major turning point for WordPress. Either they are creating a common page builder or they aren’t, but this is not a pool they can continue to dip their toes into, advertising one thing, and developing another.
Core developers will be able to work in modern technologies and not worry about 15 years of backwards compatibility. We’ll be able to simplify how menus, widgets, and the editor work to use a common set of code and concepts. The interface will be instantly responsive.
This is possibly the largest and most bald-faced lie of the entire post. Developers are saddled with 15 years of poor decisions with regard to the WordPress editor, and they just keep digging deeper with every iteration. Let’s consider a few:
- wpautop – post_content isn’t really stored as HTML. Instead it is stored as some sort of monstrous combination of structural white-space and HTML. This persists into Gutenberg, although there is an automated function to abstract it away. This is a significant hurdle to developers, as the conversion from one to the other fundamentally cannot maintain all the data contained in the raw HTML, so things are lost in translation, in unexpected ways.
- shortcodes – these were a hack to allow for inserting dynamic content into static posts. They use a non-standard format that is parsed out of HTML via regular expression (a task that is fundamentally buggy and ideologically flawed)
- flat HTML image storage – images are stored in the media library by ID, but stored in the post as HTML tags with src attributes. This means that deleting or updating an image that is used in many posts will not update the images themselves, leading to broken image resources. You also cannot update thumbnail sizes used in posts in bulk, for the same reason.
- wp_kses – a filter that is run to purify post_content, stripping “dangerous tags and attributes”… once again, this is based on regular expressions.
- RICG source sets – These modifications to image tags happen at render-time, once again powered by regular expressions
- capital_p_dangit – This is a perfect example of how data purity is misunderstood by Matt and several players in the core team. In version 3.0, Matt added a filter to core that changes the spelling of WordPress on render, to correct the capitalization. What should have been a spelling suggestion in TinyMCE was implemented as a hard filter on post_content, using regular expressions. This has the potential to break urls and embedded code that needs to have accurate naming conventions. All this was brought to the core team’s attention at the time, and despite widespread and detailed explanation of the issue, was retained as a completely vanity-based change to core.
- And now we add comment-based post structure – Rather than learning from the misstep of creating a new structured data standard in shortcodes, the core team has doubled down, and is creating a second structured data standard, based in HTML comments,that is,
once again, parsed using Regular Expressions(it appears i was incorrect about this point. it is parsed using PEG, which is theoretically a parser capable of handling HTML parsing… HOWEVER, the PEG parser for PHP is generated by a project called Peg.js, which is at version 0.1, and does not promise stability until version 1.0, and a project called phpegjs, which is at version 1.0.0beta7 and has only one contributor.. this does not inspire faith). There is a universal standard for flattened structured data storage that almost every other service uses, called JSON. There is even a standard for storing block-based documents in JSON, called MobileDoc, which is currently being used by Ghost. Rolling your own, to try to preserve back compatibility with unstructured posts is a horrible misstep. In a logically developed system, there would be a conversion step, from which point, all posts would be stored in logical, structured data. The plain-text editor would simply be a new endpoint to produce MobileDoc with a different interface, similar to how Ghost supports Markdown. This would make the single source of truth a real structured format.
These are all issues that are going to continue to hinder core developers again and again. In addition, WordPress is built on old PHP, you cannot argue that the core is going to soar ahead with React and API without considering that there are serious flaws in the foundation that remain unfixed. WPDB still fails to provide proper binding for variables, passwords can still be saved in some monstrous MD5-derived format, plugin downloads are unsigned, XMLRPC remains a security risk… these are only a few of the thousands of core issues that exist, which have not been repaired in many years. Pretending that a new coat of React paint will allow the developers to ignore these issues and work with an API abstraction is a misstep in the extreme, especially when trak tickets involving these issues are being closed as “not related to the core focus of 2017”
This claim is a lot like the original goal of making WordPress database-agnostic, via pluggable Database engines. It seems like it might be possible on the surface, until you realize how many hooks there are to old, bad decisions.
Web hosts will have better signup rates, as Gutenberg opens up WordPress to an entirely new set of people for whom WordPress was too complex and hard to set up before. (Remember our goal: to democratize publishing.) Their churn rates will go down: they’ll stop bleeding customers to Wix, Weebly, and Squarespace, and fewer people will abandon their sites because it was too hard to make things look they way they wanted.
You cannot please everyone all the time. The idea that WordPress can win back the Squarespace crowd shows this lack of knowledge of the competitor’s client base. There are a million concerns, from domain to SSL, to just FTP that WordPress cannot address, and that will never be as simple as they are on a fully-integrated hosted environment. Users who do not need anything more than what these WYSIWYG builders offer will continue to go there, and their SEO, page speed, and ability to add custom features will suffer as a result. Trying to focus the WordPress experience on this lowest tier is simply going to cause the ecosystem to bleed the power-users who build interesting things with it by bringing the downsides of WYSIWYG builders into WordPress to cater to those who will never spend a dime on their own sites.
Users will finally be able to build the sites they see in their imaginations. They’ll be able to do things on mobile they’ve never been able to before. They’ll never have to see a shortcode again. Text pasted from Word will get cleaned up and converted to blocks automatically and instantly. (I pasted the first version of this post from Google Docs and it worked great. 👌) They’ll start manipulating their sites in ways that would have taken a developer. They’ll be able to move from blogging to using WordPress as a CMS without missing a beat. Editing posts will just work; they’ll write more. They’ll learn blocks once, and then be able to instantly use and understand 90%+ of plugins.
This is a very interesting statement, beyond the overly rosy assumptions that are low on facts, because it highlights a common use case: writing elsewhere and pasting into WordPress. Many people go this route because they either don’t trust, or don’t like the WordPress editing experience. Many reviews of Gutenberg by writers have stated that their issues with the interface actually got worse, rather than better, due to the constantly changing controls and lack of consistent interface elements. Given those facts, I find it somewhat telling that even Matt Mullenweg, champion of Gutenberg as the future of writing, chooses to do his writing elsewhere.
(People were worried when the printing press was invented, too. A Swiss biologist warned against the “confusing and harmful abundance of books,” but I’d say it all worked out in the end.)
Statements like that serve to denigrate those with legitimate criticism, despite Matt’s statements to the contrary. But that is mostly what we are hearing these days. There is a lot of “listening” and “considering”, but those with meaningful concerns only hear platitudes back.
At the same time, releasing meaningful usage data is prevented by Matt, claiming that it will only be used as ammunition. Knowledge is not ammunition. It is the basis of informed decisions.
Making decisions in the absence of knowledge, based on platitudes and mandates is the basis of religions, and pardon me, but I don’t want to join up to the religion of Matt. I want to work in a modern, data-driven, open-source environment.
Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready, not vice versa.
This highlights one of the major flaws of the entire Gutenberg project: The lack of a metric for failure. If version 5.0 is determined by Gutenberg, and slated for a Jan 2018 release, there is no time for the team to fail and re-evaluate core decisions. At the beginning, when the data structure was first being designed, it was highlighed that comments were a poor solution, and that nesting needed to be addressed as early as possible, and that react posed concerns for certain companies running WordPress. Those who raised concerns were told “this is a prototype, it will all be rebuilt before moving forward”. Now, we see that all of those poor decisions are cemented in code by a lack of time to refactor, and many of the issues that will highlight these core flaws are being pushed off as “not part of the scope of the 1.0 release”.
Scope is a word we hear a lot, and there are a lot of problems with it. Gutenberg was originally a codeword for the new editor, which would add block support, and basically replace the existing editor block. From there, the scope has changed to first encompass the customizer, then metaboxes, and now full page-building and the entire “WordPress experience”. The project began without a tight scope or definition of success and failure, and now is naturally suffering from scope creep. But everything it moves to now encompass comes at the expense of further development and iterations on the core idea.
Gutenberg is quickly becoming the complete interface for WordPress 5.0, but is still the size and scope of a team tasked with a new feature for the editor, working from poorly scoped and roughed in ideas about data storage and interface. This is a huge problem, that is not related to “fear of change” or “lack of visibility”. They are systemic problems stemming from severely lacking project management, metrics, and priorities from day one.
Matt called it Gutenberg for a reason, but I find it a fairly ironic one. The real innovation of Gutenberg’s press was good planning for the future (a durable alloy that would hold up under abuse) and a flexible data structure (type cases, leading, etc) that could handle unforeseen use cases. Gutenberg’s press didn’t try to imitate full-plate presses, and it didn’t try to be back compatible for existing woodblocks. It was revolutionary because it rebuilt the press from the ground up, with future-safe techniques… and yet here we are, staring down the barrel of HTML comments as an ad-hoc datastructure and an editor that still relies on content-editable wrapped in a hacky API, in 2017.