Developers and web agencies make extensive use of Custom Fields to add structured data to their Custom Post Types (and regular post types as well).
By leveraging the Meta Box API, plugins like ACF, CMB or Pods Framework address this concern. They all work similarly: you define fieldsets, a list of fields with different types and configuration where fields can be text, images, galleries, HTML editors, etc. Once you open the editor's page for the assigned post type, it's initialized with a list of Meta Boxes allowing you to fill the content of these fieldsets.
Gutenberg, the new WordPress Editor, aims to change the way we create content in WordPress. And without a surprise, this could have some impacts on these plugins. Legitimately, developers and users shared their concerns about the way this would impact their existing websites.
How does Gutenberg address this? Will these
MetaBoxes work in Gutenberg?
Short answer: mostly yes!
Long answer: due to the fact that the Meta Box API has no restrictions, plugin authors started using this API in all sort of ways, using selectors to reach DOM nodes displayed in the editor page, relying on DOM events not officially stated as official extensibility APIs etc., which means any change made to the editor's page can break existing Meta Boxes.
Plugin authors might not have the time to update their plugins if there are incompatibilities, so Meta Boxes can also opt out of Gutenberg leading WordPress to fall back to the classic editor.
If you're a plugin author working with Meta Boxes I invite you to take a look at the handbook page describing how to test, convert and maintain these.
Aren't those Custom Fields Meta Boxes just blocks anyway?
The main goal of Gutenberg is not to replace the editor. This was commonly misunderstood, and thus it was hard to see why we'd want to emphasize blocks instead of just relying on existing APIs. But the real goal of Gutenberg is way bigger, it's trying to change the way we create content in WordPress in general around this unique concept of Block. The final user does not have to learn about all these concepts: Shortcodes, Widgets, Menus, TinyMCE, Meta Boxes to understand how to create and edit content in WordPress. It might seem natural to someone already familiar with WordPress but newcomers are struggling to juggle those and often prefer simpler alternatives offered by Wix, Squarespace, and others. (If not convinced, I encourage you to see this talk)
So how can these custom fields relate to blocks? If you think about it, a custom field is nothing more than a block saving its content
And with the new Gutenberg Template Feature, you can provide a Post Type with a list of blocks that will be automatically added when the user creates a new post. Templates can also be "locked" which means the user can't add/remove new blocks or move existing blocks.
With the combination of the blocks saving to post meta and block templates we can pretty easily recreate what the custom fields plugins are offering: a way to structure the post's data.
To demonstrate this, I created a plugin called Gutenberg Custom Fields which offers the exact same experience the plugins listed above provide (an admin page to create and assign fields to a post type) using Gutenberg Native APIs.
In fact, I think most of these plugins will certainly upgrade to these new APIs to provide a smooth upgrade path for their existing users.
This post is brought to you by the new Gutenberg Editor