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.
So the idea here is to try to limit the breakage as much as we can. Globally, the plugins listed above work in Gutenberg but some of their field types may break, in particular, the field types heavily relying on JavaScript DOM events and/or the TinyMCE API. If you experience a breakage for a specific field type, please open an issue.
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
post_meta
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.
Demonstration
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
43 responses to “With Gutenberg, what happens to my Custom Fields?”
Are those meta blocks draggable? What if they aren’t meant to be displayed as part of the flow on the front end? Will that not confuse users?
> Are those meta blocks draggable?
Drag and drop support in Gutenberg is being worked, it will land in some releases.
But I suppose you’re asking if they can be moved or not. In the example I demo above, I select the highest lock level which means the blocks are can’t be moved and you can’t add/remove blocks. But that’s up the template creator. You can decide that you can move blocks but not add/remove. It’s flexible enough. Fine-tuning per block is also coming.
> What if they aren’t meant to be displayed as part of the flow on the front end? Will that not confuse users?
In the example I show, these blocks do not produce any markup, they do not show up on the frontend, they behave exactly like ACF custom fields for instance. But you’re right blocks can produce markup. In fact you can do both at the same time (save to meta and produce markup), it’s up to the block author. In my Plugin all blocks do not produce any markup though.
Thanks, Riad. That makes way more sense to me now. I hadn’t understood the ‘locking’ mechanism before and that’s really important.
What about the need to query meta? For instance: if I have an event that occurs on multiple dates and the event is displayed in a calendar listing page which is sorted by date (showing the event on every date it occurs). Will that be possible with the locked blocks?
Yes, if you have blocks saving to post_meta you can query those, the exact same way you do currently.
Thanks for the quick reply 🙂 I’ve been waiting/hoping for this answer since I heard about Gutenberg, I’m glad I finally got it!
> 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..
..and that’s what >29% of all existing websites already are: Familiar and happy with the existing WordPress concepts.
These millions of users don’t want a new editor which forces them to do/learn unfamiliar things and will cost them time, money and happiness.
And that’s why Gutenberg in core is a bad idea. It is a breaking concept, so it should come as plugin, maybe even pre-installed at hosting-companies like wordpress.com which seem to forget what their success is based on.
> ..and that’s what >29% of all existing websites already are: Familiar and happy with the existing WordPress concepts.
Is this a good reason to maintain the status quo? Shouldn’t we try to make it easier for new users because existing users? or should we avoid any change because existing users will have a hard time to adapt?
I feel your pain and it’s not an easy change but it’s necessary if you care about WordPress’s future. The users of WordPress of Tomorrow are not the same as today and if they find simpler alternatives they’ll just use those. Even existing users will switch if WordPress fails to adapt to these new challenges.
> Shouldn’t we try to make it easier for new users because existing users?
Why not both? Provide Gutenberg as optional plugin instead of core. Done.
> because existing users will have a hard time to adapt?
Many existing users simply can not adapt. These users are e.g. secretaries who once in a while add some “news” as post or a new employee via custom made CPT to the website. They do not know anything about WordPress’s future and they also do not care.
There are hundreds of thousands of sites which are built with complex custom themes or finetuned pagebuilders or with very powerfull ACF backend with fields exactly for the users needs. These sites won’t allocate any budgets to “change a running system”. These sites will use a plugin like “Classic Editor” forever and leave WordPress as soon as this will not be possible any more.
It should not be a secret that WordPress is more than “my-fancy-new-blog” at wordpress.com where the admin is the only user. WordPress is widely used as full featured multi user & custom roles CMS, where a concept like Gutenberg is way too complex for the end user.
Hi Riad!
Really nice blogpost and impressive demo!
Could you publish the source code of this demo?
Would be interesting to go trough your code.
Thanks in advance!
Thanks and the plugin is available on GitHub here http://github.com/youknowriad/gcf
Thanks for the demo Riad. Whilst I’m still not completely sold on how Gutenberg’s been “sold” to us so far, I think this kind of demo is exactly what we (WP developers, site owners, “webmasters”, etc) need to reassure us.
More please! 🙂
THANKS A LOT!
Using your Book example, can I use a Relationship field type to link a Book to Authors?
If Gutenberg implemented this React select control (https://github.com/JedWatson/react-select) would help with creating a relationship between two different custom post types.
The relationship field type is not available in the plugin I showcased yet, but it should be fairly easy to implement (once you understand how to create blocks saving to meta). I might add at some point.
Thanks for the post and this is encouraging to see that this sort of thing can be done with Gutenberg. However I can’t help thinking that the plugin you have created with Gutenberg here is only doing what the current suite of meta box plugins such as advanced custom fields etc. are doing?
You mention above about the current plugins.
Is this solution any different? What are the advantages of doing it this way as oppose to using, for example ACF?
True, I’m not stating the opposite. I’m trying to demonstrate how Blocks can be used for Custom Fields as well. As I said, the idea of Gutenberg is to use Blocks for everything related to content creation. The same way it’ll be better to have blocks instead of shortcodes, blocks instead of widgets, it’s better to have blocks instead of meta boxes. The user/developer have to learn only one concept.
Could you outline the reasons for this please?
The reasons are simple: consistency. Because the developer have to learn one API to do things and the user have to learn one way to insert content. WordPress has evolved by adding features on top of others over time and this ends up with bloated UIs. The user experience is not great. It can’t continue to grow this way indefinitely while competitors achieve the same thing in a simpler way.
Thanks for you post, it alleviates a lot of concern for us when it comes to Gutenberg. There are a lot of users/developers very upset by this and its hard to see past their comments and see what is really going to be possible with Gutenberg, possible a missed opportunity by the team over there to fully explain on the project and peoples dislike of major changes which I can understand. But without improvement and evolution of WordPress it will become irrelevant. We just need to adapt with the changes. Again thanks !
Hi Riad,
Thanks a lot for your post. I’m the author of the Meta Box plugin. What concerns me a lot right now is how the existing fields work with the Gutenberg. They are heavily rely on jQuery and DOM objects. Do you have any suggestion?
Another thing is I see that the Gutenberg team is trying to do server rendering for meta boxes. It might break all of our JavaScript code. What do you think about this?
Thanks,
Anh
Hi Thanks for the comment!
So, yes metaboxes heavily relying on DOM events could break, we try to limit those breakage as much as we can, if you find some specific issues, please open an issue on GitHub.
That said, some breakage is inevitable (documented here https://wordpress.org/gutenberg/handbook/reference/meta-box/#common-compatibility-issues). In this case, you’ll have to adapt your code a little bit or declare “incompatibility” temporarily.
> Another thing is I see that the Gutenberg team is trying to do server rendering for meta boxes. It might break all of our JavaScript code. What do you think about this?
Gutenberg renders meta boxes same as the classic editor (server side) and when the client loads, the JS enqueued will be executed.
Hey Riad,
Thanks for putting this together! Seeing this demo and reading the source has been really helpful in understanding what can be done with Gutenberg.
Now that I’ve started digging into it, this does open up a few new questions for me. Say I wanted my custom field blocks to be a bit more flexible, are there currently public APIs for deleting blocks, transforming blocks or removing the template lock via JavaScript?
I’d like to experiment with a few different approaches and being able to do those things with JavaScript (instead of the mouse) would be really helpful.
Thanks again for putting this together!
Justin
Hey glad you like it. I already answered some of these in slack but copying here.
> deleting blocks
Possible with the block using `onReplace( [] )` (`onReplace` is a prop just like `setAttributes`)
> transforming blocks
Yes, `onReplace` as its name suggests replace the current block with the provided array of blocks
> removing the template lock via JavaScript
Not yet, but having a list of templates you can toggle on the editor is something we’re interested in adding in the future.
Would it be possible to save the meta blocks to a custom database table rather than wp_postmeta?
Mmmm good question! I’d say no for now and probably not for the v1 of Gutenberg (merge) but I think this is a nice idea worth an issue on GitHub
Storing Gutenberg meta blocks in custom database tables –
https://github.com/WordPress/gutenberg/issues/3759
Hey Riad, thanks for the insight.
Plugin version numbering might be a bit messed up atm – 1.0.0 vs 0.2.1?
“`
$ [-] sudo -u nobody wp @cxli plugin install gutenberg-custom-fields
Installing Gutenberg Custom Fields (1.0.0)
Downloading installation package from https://downloads.wordpress.org/plugin/gutenberg-custom-fields.0.2.1.zip…
Unpacking the package…
Installing the plugin…
Plugin installed successfully.
Success: Installed 1 of 1 plugins
“`
Yep, I noticed this bug. My experience with the plugin repository is small so I’m not sure what I’m doing wrong since my readme.txt already contains the right version 🙂 I’ll have to check the docs carefully.
I also found it curious there is no apparent way to subscribe to articles here, until you start posting a comment.
I guess if you have a WP.com account you can follow my blog or use RSS if you prefer https://riad.blog/feed
> This was commonly misunderstood, and thus it was hard to see why we’d want to emphasize blocks instead of just relying on existing.
It wasn’t “misunderstood”. That’s exactly how Gutenberg has been described and marketed, up until now. As a block editor.
Matt’s own post from June this year even said “Right now the vast majority of effort is going into the new editing experience, and the progress has been great, but because we’re going to *use the new editor* as the basis for our new customization experience it means that the leads for the customization focus have to wait for Gutenberg to get a bit further along before we can build on that foundation.”
And even the very first sentence in the description for the Gutenberg plugin on .org up until December 12 this year was “The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.”
So no, don’t blame everyone else for misunderstanding it when that’s exactly how Matt and everyone in the Gutenberg team marketed it.
Allow me to disagree.
If you read the sentence you just said, it explicitly says: “but because we’re going to *use the new editor* as the basis for our new customization experience it means that the leads for the customization focus have to wait for Gutenberg to get a bit further along before we can build on *that foundation.*”
It says explicitly that this is just a s start and we’re going to move to Customization and use the editor’s as a foundation. And that’s exactly what I’m saying, I’m just being more technical.
That said I can admit communication issues as it’s a difficult task, we try to do our best but we probably fail to deliver the message especially since people “see” an editor changing their habits and asking them to invest time in it and the normal reaction to this (like any change) start with denial, anger, and can lead to acceptance at some point. I’m not blaming any one, it’s a natural reaction to change which makes it hard to see beyond what’s delivered.
I learned WordPress three years ago and started working with ACF a two years ago. Now I build custom themes full time. Is activating the Gutenberg plugin on a site the best way to test what will break?
I found this course by Zac Gordon called JavaScript For WordPress, https://javascriptforwp.com. Learn about the plugin source code and implementing it in plugins and themes. I just started on it, but it is good so far.
What are developers telling existing and new customers about this change to core?
Test Gutenberg on a staging site to see how it reacts with your theme. As a theme developer you should take Gutenberg on head on as you could hold the place of the first themes that fully support and utilise Gutenberg when it is released.
I’m still very interested in how Gutenberg will work with page builders but apart from that I think the change is welcome.
Hi Everyone,
Will there be an option to update or is the update going to be auto update?
I assume you’re talking about WordPress 5.0 where Gutenberg will ship. Since it’s a major version, it won’t autoupdate unless you explicitely enabled autoupdate for major versions.
It’s early, but my first impression is that since I work in an industry that creates websites for clients, and those clients are used to robust interfaces that all them to do things like sell products through woocommerce (just an example), I can see that a lot of us may abandon WordPress. With the potential to break a very large amount of plugins, Gutenberg may just be the one thing that kills WordPress. It’s one thing if you just want a cheesy little blog, or you don’t know how to code so Gutenberg dumbs things down for you enough that you feel special, but this is a huge pothole in the middle of the design and development road.
I heard a lot of diverging opinions, let’s wait and see. If WordPress doesn’t disrupt itself, it will die anyway.
As a designer i am really annoyed, that gutenberg makes me a lot of unneccesary work to my nearly finished theme. I am using custom post types, taxonomies and custom fields a lot without plugins (there are a lot but way to complex). But now switching to gutenberg my custom fields won’t work.
How could developers remove such an easy and powerful feature in favor of having blocks?
Adding css to an theme that it looks nice is responsive and works among all browsers is way more easy to establish for everyone than adding php in funcions.php or a plugin that works and won’t open up a lot of security issues.
You have to dive very deep to get things work. Also there are few tutorials like yours that help a non developer to achieve their goals.with gutenberg.
In my case you could do me favor and implement the possibility to add the custom fields to more than one (custom) post type into your plugin.
Thank you.
Greetings cas
> But now switching to gutenberg my custom fields won’t work.
Gutenberg supports metaboxes if that’s what you’re referring to. There might be some small changes to do, but in general they just work.
> How could developers remove such an easy and powerful feature in favor of having blocks?
First, it’s not removed, second, what makes you think blocks are not more powerful?
> Also there are few tutorials like yours that help a non developer to achieve their goals.with gutenberg.
That’s normal for a new technology, it will change over time.
Enjoy!
How can I enable Gutenberg for custom post type? I am trying to do this but having an error in code
register_post_type( ‘portfolio’,
// WordPress CPT Options Start
array(
‘labels’ => array(
‘name’ => __( ‘Portfolio’ ),
‘singular_name’ => __( ‘Portfolio’ )
),
‘has_archive’ => true,
‘public’ => true,
‘rewrite’ => array(‘slug’ => ‘portfolio’),
)
);
}
Can you help me to resolve this error as I have seen the code here https://www.cloudways.com/blog/gutenberg-wordpress-custom-post-type/
Hello. Let me know if I understood correctly: I can create a Gutenberg block template that could be used anywhere (any page, any post, any Woocommerce single product and so on), but using custom fields (I am referring especially to ACF pro), I may have different content on these posts, but the same block template (including custom css), am I right? Thank you!