This weekend I enjoyed WordCamp New York City as well as a gorgeous 6-hour drive through the Adirondacks to get there. Setting GMaps to avoid toll roads brought me south along the Taconic State Parkway as the sun was setting over colourful fall forested mountains. For Ontario drivers’ reference, it happily mixed a 6-lane version of the 401 with the hills, curves and forests of smaller northern 2-lane highway. The wordcamp was held in an excellent location in the heart of city, had great food / beverages (mini-smoothies FTW), presentations, sponsors and hallway track.
While the presentations on deploying WordPress in a Hybrid, Serverless or Headless approach were what caught my attention going to New York, it was Andrew Roberts session on the What and Why of Gutenberg which piqued most of my thoughts and subsequent conversations during the weekend. His slides are available at https://speakerdeck.com/androb/the-what-and-why-of-gutenberg and hopefully WordPress.tv link is available shortly.
In this post I want to share my refreshed perspective on Gutenberg as well as show some of the reasons why I would encourage everyone to balance their healthy skepticism / fear of substantial change for the platform we know, love and work with a moderate dose of optimism for the potential of what-could-be if Gutenberg gets its’ evolutionary ambitions for content editing right.
For context
- I am definitely in the developer-centric camp; contributed a couple minor patches to core.
- Meta field frameworks (ACF or CMB2) are involved in vast majority of projects I implement.
- First tested Gutenberg a few months ago and found the premise intriguing but lacking. The plans communicated via GH issues at that time suggesting the first core implementation would not include support for drag & drop, columns/nested blocks or meta boxes felt short-sighted to me.
- Based on Twitter re-tweets, one might believe I strongly agreed with core concerns shared by Greg Schoppe. See The Gutenberg that could have been for a notably different vision than the current development path.
I’ve tried to consolidate my thoughts into common areas / approaches to working with WordPress in a post-Gutenberg world.
The Sensational Sous-Chef
I recall thinking when WordPress 3.0 first provided a standardized way to register custom post types that some form of sharable set of post types which themes could highlight support for would be invaluable. That never really manifested – the closest might be Jetpack content types – and CSS was the lowest common denominator point where most design integration between plugins and themes met in the middle.
When WordPress 4.7 brought starter content into core with the 2017 theme my first reaction was, “That’s great, but what about sites that already exist? How can they prepare for a theme conversion?” I’m now optimistic that Gutenberg can provide a strong method for themes (and plugins) to template or control what block(s) will be available by post type, what content is pre-populated into blocks when added to editor. As a developer, this would standardize and reduce a number of pain points I hear from content authors related to not knowing where to start or ensure that every entry has the appropriate fields. It would also address many meta-box use cases where ACF is handling complex design structures that custom theme code converts into presentation markup.
Theme control is on patrol
It will be interesting to see how themes adapt to Gutenberg in the design capacity. Andrew showed an excellent example of the Gutenberg editor displaying errors in the Table of Contents settings when heading types were included out of order. He also talked about how it can balance a designers’ goal to have all content “stay on brand” with the happiness content authors find in the ability to “change all the things”. The best example of this was a filter for colour selections that could address WCAG color guidelines. CSS may still end up as the lowest common denominator but I now expect a series of filters to enable / disable or adjust functionality of blocks to be an accessible part of blocks for “design control”.
Demystifying the Meta Monster
Photo from Ryan McCue Talk Loopconf – https://www.youtube.com/watch?v=1QWhOfebp2A
Andrew had several slides dedicated to dispelling myths of Gutenberg. One myth and a large part of the Q&A portion that followed focused on impacts on meta data / frameworks. He confirmed the ability for plugin developers to define/control where their blocks’ data will be saved (post content, meta, options, etc) is part of the launch scope.
Core has such excellent support for registering custom post types and taxonomies that tools which build upon it, like WCK or GenerateWP, are mostly UI to simplify the process. I think meta is such a concern to so many because, by contrast, the core meta data functions have a substantial gap which requires much boilerplate code to achieve advanced use cases. Frameworks like ACF, CMB2, FieldManager fill that gap so their upgrade path with Gutenberg is large concern to any site developer / admin which uses WP as CMS / application framework.
Not surprisingly, the meta data / framework issue on GH repo is the most commented one. The team is working hard to address the concerns and Gutenberg 1.5 includes initial support for keeping meta frameworks within the editor window without requiring plugins or site developers to re-write entirely into Gutenblocks / JS framework based approaches. There is still much work to be done to offer comparable versatility to hook into for editor experience with meta today, but what I learned this weekend about Gutenberg and meta data made me feel a lot better.
Mitigating Migration Madness
Today, imagine you have a site that you want to change themes but you make extensive use of theme-specific shortcodes. When you activate the new theme, all [those] [wonderful] [codes] show up in the site output until you hunt down and convert them. In a Gutenblock world, at a minimum any blocks that are no longer active due to theme change would not be visible to page as its’ data is stored into html comments that do not render.
Additionally, like the heading warning, content editors would receive notification if they attempt to save a page with non-active block content. Andrew was also of the impression that Gutendata would have an appropriate set of parameters accessible to the WP_Query. This would offer developers a number of methods to search for inactive blocks that would feed nicely into a bigmig migration path.
Making Headway with Headless
Andrew spent some of his presentation highlighting how much Gutenberg is relying on the recently merged Rest API and leading to feature improvements in it. This certainly answers one of the success metrics for Rest API (#4 – Core development and feature projects). But more importantly, the Gutendata should be accessible as a separate endpoint – see Adam Silverstein’s PR #2649 which updates the Rest API with endpoints for Gutenblock data. So, the post content will have the rendered output from blocks and developers can access to the structured data for use well outside a PHP-driven platform. Everyone will benefit from the enhanced content editing experience Gutenberg will provide.
Overall impact to you when Gutenberg comes to core?
As conversations with Andrew Roberts, Josh Pollack and Adam Silverstein in particular highlighted, how much impact Gutenberg will have on your workflow could vary a LOT based on your use / involvement with WordPress:
- Andrew explored how many plugins which integrate through the TinyMCE editor today should still be accessible tomorrow to “content blocks” without notable plugin re-development.
- Josh outlined that for Calderra Forms to be “Gutenberg ready”, the bare minimum would be to change its’ Add Form button + shortcode into a single block.
- Adam shared some details about how minor releases could continue with small(er) incremental development on non-Gutenberg functionality for 4.9.X series of releases to give 5.0 a chance to cook a little longer.
- Hopefully that affords plugin authors and theme developers in the high-impact areas that provide page builders, meta frameworks, complex shortcodes, widgets, etc. more time to transition their code to “Gutenberg ready”.
Prior to the weekend, the biggest concern / confusion I had about Gutenberg was probably related to the (primary) storage of block data being in post content as html comments. Now, as someone who implements sites for clients and does small plugin development, I realize that particular aspect should have about as much impact on my development workflow as the term splitting transition of WordPress 4.2+ which was next to none. There will be updates to existing APIs and new APIs added that adequately abstract the data storage layer below my threshold for concern. I would similarly hope that to be the case if a WP 5.0+ release did migrate data into a more structured format.
Many thanks to everyone who helped organize or attend Wordcamp New York this year and all those who are working to make Gutenberg Guten-great! The path to production for it may metaphorically be just as adventurous as the Taconic State Parkway I drove to get to #WCYNC; I hope the trip is just as worth it!
