Gutenberg, Shortcodes, Shortcake, and Metaboxes

While I was working for Daniel & Hong at Fusion, our engineering team produced a number of quality open source projects in a short period of time. Shortcake & Shortcake Bakery were two plugins we released designed to improve the experience of using shortcodes in WordPress. Gutenberg is concerned with the same problem, as stated in the project’s FAQ:

How will shortcodes work in Gutenberg?

Shortcodes will continue to work as they do now. However we see the block as an evolution of the shortcode. Instead of having to type out code, you can use the universal inserter tray to pick a block and get a richer interface for both configuring the block, and previewing it. We would recommend people eventually upgrade their shortcodes to be blocks.

Should I move shortcodes to content blocks?

We think so. Blocks are designed to be visually representative of the final look, and they will likely become the expected way in which users will discover and insert content in WordPress.

We think so. Blocks are designed to be visually representative of the final look, and they will likely become the expected way in which users will discover and insert content in WordPress.

Gutenberg FAQ

This post is my attempt to synthesize both efforts in my own head, so I can offer some practical thoughts on the way forward.

Things Gutenberg Has Going For It

  1. Snappy UX, makes the editor feel more fluid.
  2. Clean UI, similar to the distraction free writing mode.
  3. Modern tech stack, implementing React & Redux.
  4. PhotoMatt’s attention, consumer blogging is obviously a huge part of A8c’s business, and SquareSpace/Weebly/Wix have continued their investment in consumer friendly product development.
  5. Fresh start, I was jarred by little things in the UI like the different placement of the Save button, but I can see how this is an opportunity as well.

Shortcodes, Shortcake, and Metaboxes – oh my!

Noticeably absent in Gutenberg at this point are shortcodes and metaboxes. The metaboxes discussion on Github is Gutenberg’s most active issue. We know that shortcodes would ultimately be supported in Gutenberg to ensure backwards compatibility and Weston has reached out to Shortcake contributors for their thoughts on the project.

Human Made’s Matthew Haines-Young (a main dev on the Shortcake project) responded with some notes on what TinyMCE features Shortcake uses, as well as some performance and query issues related to Shortcake previews. Automattic’s Matias Ventura noted that a shortcode textarea could be provided to handle an MVP version of shortcode support.

This is all well and good, and a user going from a non-Shortcake shortcode to Gutenberg wouldn’t notice a difference. But the user going from Shortcake to Gutenberg would – not just because the preview was gone, but because the entire “admin” for the shortcode would be gone too. This is not a regression I’d be willing to introduce to a newsroom

We also need to talk about metaboxes for a minute. There are two parallel schools of thought in Gutenberg it seems: the first is that metaboxes should be moved into blocks; the second is that there will always be a place for “non-content” metaboxes. Both views seem equally valid, and both have prior art in the WordPress ecosystem.

For content-related metaboxes, I agree that “blocks” represent a natural destination for those fields. But Gutenberg does not support a generic field declaration syntax in its register block command. This is an area where Shortcake hints at a possible path. Compare how Weston had to self-implement fields in the recent posts widget block to how a Shortcake shortcode can declare the inputs it expects.

This ability to declare fields using simple configuration objects is also why projects like Alley’s Fieldmanager, WebDevStudios CMB2, and Advanced Custom Fields have become so popular in recent years. You have probably heard the startup advice to find the spreadsheets – custom metaboxes are how we achieve this in WordPress.

WordPress Core has made advances in this space through register_meta(), but we are still missing a generic fields API. Scott Kingsley Clark’s work on the fields API feature plugin represents the state of the art, but momentum on that project has diminished significantly over the last year.

Just as custom post types launched a major wave of enterprise WordPress adoption, I believe that custom fields represent a similar opportunity. The discordance between widgets, shortcodes/shortcake, and metaboxes represents an opportunity for improved developer experience and, hopefully, improved user experience as well. Should one of the existing meta plugins be groomed for feature plugin inclusion? Is a simpler pattern, like the one in Shortcake, sufficient for most needs?

My biggest concern right now is that these questions are not going to seem immediately relevant to Automattic and PhotoMatt. These topics are decidedly unsexy and controversy prone due to the legacy nature of these concepts. But I think that on the other hand, a simplified fields API could help bring the type of value-add we’ve seen in the enterprise to the hands of small and medium businesses, and that ties directly to the Rebrand Cities initiative and possible revenue growth through WooCommerce.

Hit me up in the comments, would love to hear what other people think!

Posted Jul. 15 2017, 11:51 am by davis