As work continues at a feverish pace on Gutenberg, many developers throughout the community are engaging in discussions on how meta boxes will be handled in the new editor. The team is considering various solutions and some have suggested that a Fields API in core would have made the future of meta boxes less of an issue.
I reached out to Scott Kingsley Clark, lead developer of the Pods Framework and one of the main contributors to the Fields API project. Clark explains what the Fields API is, its current status, its relationship to the meta box discussions, and how to contribute.
For those who don’t know, what is the Fields API project? How would it impact users?
It’s a feature proposal for WordPress core to allow registering fields to different screens in the admin area through a single API. For posts, this would add new meta boxes and fields within them. For users, it would add new sections and fields to the profile screen. The goal is to integrate with all of the different admin screens including, Posts, Terms, Users, Media, and Comments.
Typical users would notice that the fields added by plugins they are using all have a similar look and feel. That’s really an oversimplification of what’s going on behind the scenes, but it’s one of the big benefits as well, since it shouldn’t really affect end-users beyond improving consistency of different screens and potential redesigns.
What has caused progress on the project to slow down?
I was out-of-town for a all-hands company meetup, lead organized WordCamp Dallas-Fort Worth 2016, and ran PodsCamp 2016 in Austin, TX, all in the span of about a month and a half. It was intense, but somehow last summer I thought I could manage moving too.
We were in the process of showing our house, almost all of the time, so that we could sell it. The buying process was full of thorns, with a move that was pretty fun. I also started a new job at Modern Tribe in February, 2017.
In retrospect, yes that was way too much but the challenge was met and the only thing that suffered was the Fields API project, which was no easy feat. It’s unfortunate, but I’m glad to be getting back into things again this month.
Are new contributors showing a renewed interest in the project?
Yes. We recently had a few people become interested in helping. When I’ve got help, I’m 300% more productive. It’s much easier to bounce ideas off of others with shared experience than it is going alone.
How does the API relate to how meta boxes could be handled in Gutenberg? If the API were in core, how would it influence the discussion?
Here’s where the irony sets in. If we were successful in getting a Fields API into WordPress before Gutenberg was a thing, the ability for Gutenberg to revamp as much as it has planned to revamp in the post editor, would not be as hindered as it is now.
The biggest problem I see facing Gutenberg is reining in the scope that covers meta boxes. They need to get things working for meta boxes that are already being registered and used by plugin developers.
If Fields API were a part of WordPress, they would still need to keep backwards compatibility but I could easily add a meta box with my fields into the proposed Gutenberg meta boxes (still in discussion) with just a few lines of code. Plus, my fields and meta boxes registered using the Fields API would work just fine on pre-Gutenberg sites.
Another parallel here would be the User edit screen, which has had much discussion about revamping the way it looks. It’s very difficult to revamp it and give it consistency without a Fields API already in place. It’s not impossible, but many problems come to the surface during any approach to ‘React-ify’ it, utilize meta boxes, or whatever it would use.
How can people get involved/contribute to the Fields API project?
I’m very excited to have others interested in moving the project along. I’m eager to gain more interest. They can join us in #core-fields on WordPress Slack if anyone is interested. They can also follow the project on GitHub where pull requests are welcomed.
Clark also says that the GitHub repository will be revamped soon to provide more focus on making the project a feature-plugin first instead of a core proposal.
The widgets API, the shortcode API and now Gutenberg all overlap and all have similar objectives. All of these efforts ideally would have sprung from work around the fields API. I do hope that all the different efforts come together so that in the end we get both a modern UI and a more consistent, easier and more powerful way to create and register components.
In an ideal world it should be fairly easy to create a component that can be adapted to work as a shortcode, block, widgets or meta field on any type of page, without having to use very different APIs.