I have been very vocal in the WordPress community about the fundamental issues I see with the new visual editor being bundled with version 5.0. One response I keep hearing is “how would you do it differently?” So, I thought I’d outline a hypothetical roadmap for the Gutenberg that might have been.
Just for those who haven’t been reading my previous posts, my most fundamental issues with Gutenberg fall into just five topics (if you are familiar with the issues, feel free to skip ahead):
- WordPress posts should be stored in a universal Structured Data format
Block-based editing means that posts are structured into blocks (obviously).
post_content‘s current format is a series of hacks layered on top of the original plain-text implementation, which is fundamentally unstructured. This current format, by definition, cannot preserve all the details of the original data. the current format is literally incapable of supporting lossless, structured data, no matter how many new elements are introduced. Structuring data in a JSON/Mobiledoc format would have benefits to the existing data, as well as setting WordPress up for the next decade. Benefits include:
- Images can be re-rendered from ID on the fly, so if thumbnail sizes change or filenames get updated, or images get deleted, the post will be able to adapt. Oh, and say goodbye to mixed content warnings when a site gets migrated to https.
- Links can be re-rendered from the ID on the fly, so if permalinks change or posts get deleted, the post can adapt.
- Embeds can be modified to match the source protocol, and can be regularly tested for failure
- HTML structure can’t be accidentally broken in text-mode
- WordPress shouldn’t marginalize third-party admin tools, especially while touting the API’s ability to revolutionize editing
The new block-based editor provides a first class experience to the core editor, but leaves everyone else dealing with HTML comments, which (other than the existing more and page comments) will not be rendered at all by any HTML-based visual editor. Shortcodes, while a terrible long-term solution, are a structure all editors have had to deal with already, so they are guaranteed to not break their interface. This interface could be upgraded as new API endpoints are introduced, to consume the real, structured data.
- WordPress needs to actively reduce the number of hacks involved in the editing process, not increase them
As things stand, post_content is processed by several functions before being output. Here are a few of them, and how they could be implemented with real structured data
wpautopturns whitespace into paragraph and break markup. In a real structured format, each
brwould be stored as a separate node in the structure. This preserves whitespace, so it can be used to add clarity to certain views where necessary (like in
codeblocks, which can be an isolated nodes with raw text inside, or with poetry)
- shortcodes are parsed by a complicated and error-prone regular expression. In a real structured format, these could be stored as a custom type of node, massively simplifying the parsing process and allowing for a shortcake-like visual interface for editing them.
- capital_P_dangit just makes no sense. This should be a spellcheck option, not a filter on the content.
- RICG responsive images use yet another messy regular expression. Making images a type of node in the structure will make safe modification of image tags trivial.
- WordPress posts should be rendered differently in different contexts
WordPress search should only deal with the text of the content, and auto-excerpts should respect whitespace around blocks. Feeds and AMP pages need to render in a manner compatible with the limitations of the format. Emails need to render with ridiculous 1990’s era HTML. These are not secondary interfaces to be rendered from the “true” html version. They are equally important representations of the data, that should be able to be produced from the common structure. This also would support future, unknown formats.
- React is too problematic for the infinite use cases supported by WordPress
Many users have weighed in on the issue or non-issue of React’s Patent Clause. Regardless of personal opinions on the subject, some companies’ legal departments are unwilling to accept the terms of that license. This is an unacceptable limitation for the most widely-used CMS system on the market. WordPress will lose customers if they embed React. At most they need to choose Preact by default, and allow users to swap in React or another clone by dequeue/enqueue, if they so prefer. The core team claims this decision is still up in the air for Gutenberg, but with a react-based feature plugin rolling toward integration with core in the beginning of 2018, it’s clear that decision is being made by defacto usage.
Now that the issues and benefits have been laid out, lets talk about a potential path forward.
The Roadmap that Wasn’t
4.9 would be treated as a defacto LTS release, as it is the last version before Gutenberg changes begin, and it would continue to receive security updates for a minimum of 3 years. This would calm the nerves of large businesses worried about the fast changes that are to come, as well as supporting those who simply cant be served by Gutenberg. Baseline opt-in telemetry is introduced, as well as plugin and update signing, just to make sure we have a strong footing in security for our business users for the next few years.
WordPress 4.10 would be all about setting the stage for Gutenberg. Every connection to the admin from API to XMLRPC to WP_CLI to native functions are given an
update/create_post_content function or an
update/create_post function that sits between the user and the raw
post_content field. A new set of end points are also added on the back end to allow users to update or receive a structured view of the data. This version of the data will match the MobileDoc format, but for now will be rendered from the existing
post_content. Developers are informed that directly editing
post_content will no longer work as of WordPress 5.0, and that they should start updating their code to use these new end points. This would be about nine months out from 5.0 release.
In 4.11, the public would get their first taste of Gutenberg. It is a visual refresh to the editor that maintains feature parity, but now stores structured data through the standard structured endpoints. That structured data, however, still also ends up parsed into
post_content as our existing monstrous mishmash of formats, for now. However, there are new filters and actions available for rendering that structured data for feeds and excerpts. a ‘cache clear’ action allows existing editors to update the structured data from the unstructured data, as a temporary shim. We stress that Gutenberg is coming into its own in the next version, and plugins need to be updated. All plugins should be able to use the structured data alone to communicate with the database. A cron regularly checks the integrity of the structured and unstructured forms of the post against each other, and adds a warning in the admin panel if they get out of sync, informing them that some part of the code on their site is not ready for WordPress 5, and giving them the option to resync the structured data, by parsing
post_content. Eager developers could get started on alternative editors that consume the same MobileDoc format, as the format implementation is feature complete. This would be three months from 5.0 release.
Gutenberg launches with full block support, probably based on Slate.js and Preact. No TinyMCE or content-editable to be found! Gutenberg is limited in scope to the editor area, rather than the entire page, but has the ability to implement blocks that store to metadata or other custom storage, and default blocks can be locked in place on certain post types, making them just a standardized interface for custom metadata (although the existing areas are not removed.. deprecation of those can wait until Gutenberg has time to gain support). All standard post data is stored in the structured format, in a db field called
post_structure. The old
post_content is now a flat text version of the content that is used only to power search. It has a parser, just like html content, feed content, and email content, so search can get an optimized version of the keywords and phrases. A set of filters exists to allow users to save other fields into
post_content, so complex search structures involving categories and meta are now trivial to implement. A set of helper functions are introduced to parse blocks to/from the legacy shortcode format, using PEG parsers (generated by hand, not via beta versions of software). No comment structure exists in this compatibility layer, just legacy formats. These functions are slated for eventual deprecation, in favor of raw consumption of the structured format, but they will help third party editors get through the transition. The cron check for bad data in the post_content is retained for now, with more forceful wording.
WordPress 5.1.0 and Beyond
Gutenberg’s scope is slowly increased to incorporate other functionality on the site. Once the parallel metabox structure in Gutenberg has gained support, we gradually phase out the old style metaboxes. Next we integrate the customizer panel into Gutenberg. Eventually we might even see an entire admin interface based in Gutenberg components. However, we take that scope creep very slowly and reevaluate at every step. Even if that never occurs, the fundamental data structure of WordPress is far stronger, allowing third-party plugins to create entirely new Admin interfaces, and allowing core to try things out in various ways, to see what the market responds to. Of course, Telemetry is key in all of this.
To be clear, this is not the Gutenberg we’re getting, and to me, at least, that is deeply unfortunate.