In 2014, Pods lead developer, Scott Kingsley Clark, took over the primary lead role for the Metadata UI project. In 2015, the Metadata UI project was reborn as the Fields API.
The Fields API was developed to allow registering fields to different screens in the admin area through a single API. New meta boxes and fields within them could be added to posts while new sections and fields could be added to the profile screen.
The goal of the API is to integrate with all of the various admin screens including, Posts, Terms, Users, Media, and Comments and provide standardization.
Clark has been leading the project for three years and despite seeing renewed interest last year, announced in the project’s Slack channel that he is stepping down.
It is with a heavy heart that I must pass the torch on this project. After hundreds of hours of my time, I no longer believe I can effect change within WordPress core.
The Fields API vision was too big, too much of an undertaking for any one person. I believe so deeply that WordPress needs a Fields API, but the journey to where we are at with the Fields API has been long and arduous.
The truth is, I burned out years ago while building the first and second prototypes. Not everyone agreed on how to architect the code, it went through many revisions based on core contributor feedback. I just couldn’t get enough people excited about it, I couldn’t get enough companies and people interested in supporting it.
I need to let someone else have their chance, I am dragging it down. If someone steps up to lead in the future, then I would be happy to assist where I am able to. But I am unable to continue leading the Fields API proposal/project. I am sorry, please accept my apology and I hope you can forgive me for failing to take this project over the finish line. I still believe to be such a vital part of WordPress’ future success.
Scott Kingsley Clark
The Trials and Tribulations of Leading an Open Source Project
In the following interview, Clark explains why he feels personally responsible for the project’s lack of progress, why the API is important for WordPress’ future, and reflects on what he could have done differently.
Are you looking to pass the torch on to anyone in particular?
No, I’m not sure who would have the drive and the clout to see the project through. It’s a large scale project that should be approached with a long-term vision but in small enough increments to make it into WordPress core. It’s a lot to ask of somebody, it’s also not a priority for people right now since they are distracted by Gutenberg being released in the near future.
Why is the Fields API a vital part of WordPress’ future?
People look at WordPress today and wonder how they ever survived without the REST API. Well, at least I know I do! The same thing can be said about the Fields API even though it’s not there yet. There are so many cases where it’s frustrating to build solutions for WordPress across all of the different hooks.
For consistency, it’s the wild west out there. You get a meta box registered and you fill it with whatever you want. You need your own CSS to style the form fields and everyone has their own idea of how this interface should look. You are in charge of your own responsive layouts that are mobile-friendly, there’s just so much you have to handle on your own. You should be able to customize appearances, but every place you want to add a field or form to should really have a proper API.
Long-term, imagine registering fields to WordPress like you register post types. Imagine fields and their configurations being available to the REST API and accessible through the WordPress App or other custom apps.
The whole world opens up because you have a consistent API, the whole world make sense because you have a consistent interface for those fields across the various edit screens. Posts, terms, comments, users, media, even the Customizer would all have the same underlying API to add groups, panels, and fields to their screens.
If Gutenberg was done after the Fields API was in, migration for folks wouldn’t have been as difficult. Gutenberg could have automatically shown all of the Fields API interfaces like it does for the meta box backward compatibility. It would have looked so much nicer too.
Taking some time to reflect, what could you have done differently to get more core contributors to buy into the project and turn it into a higher priority?
I’m not sure, it’s a delicate balance of taking input and being confident in the end result. At first, the feedback was about how the API was foreign for WordPress, they asked if it could be similar in structure to other APIs such as the Customizer.
We scrapped the code and rebuilt from the ground up as a fork of the Customizer, it even supported having the Customizer utilizing the Fields API too. At the height of development, we had all areas of the Fields API implemented.
Core releases were moving pretty fast, there was a lot of code changes from WordPress release to release that we had to keep up with because we had essentially created a project that was a giant patch for WordPress.
There weren’t enough hooks in place to do what we needed to do, and many sections were not extensible because of code decisions that marked themselves as ‘final’, which means you can’t extend a specific class to customize how it works.
I wish I could have been at all the big WordCamps in the US and Europe, essentially lobbying for this feature. Gathering supporters and such, it feels like politics in a way. I hung around in Core dev meetings, trying to bring it up. I tried to legitimize the feature by having a dedicated channel in the official WordPress Slack, posting updates on https://make.wordpress.org/core/, and holding weekly meetings.
Ultimately, I prioritized my time for development over the time to gather the troops. That was the downfall, I began to burn out quickly after the first few rewrites as I had many other responsibilities elsewhere on top of Fields API.
It’s not like companies will easily want to pay you to work on a project like this indefinitely, even though both WebDevStudios and 10up gave me time to push it forward. It wasn’t a blank check, at some point I had to get back to billable work. From then on, it was all in my free time and that was difficult to manage during times of financial stress and house selling/buying.
There’s demand for a Fields API in core but not enough hands to build it. Why do you think that is?
Everyone is focused elsewhere. There’s a lot of areas of WordPress that need people’s attention. There are things like Accessibility that deserve a lot more attention than it gets. But the focus to me, seems to be on Gutenberg and REST API.
Gutenberg especially has been a huge time sink for people contributing and people implementing. It’s a really large feature. It’s definitely larger in scale than Fields API, it’s like a whole new app that lives in WordPress. Integration with it has required a lot of education and trial/error. People’s focus is where it needs to be right now. It’s just unfortunate that Gutenberg came before Fields API in terms of priority and interest level.
What advice would you give to the next Fields API project leader?
This is a big project, everyone will want to say it should be a certain way. You have to evaluate the options and put forth something bite sized for core to start with. Build upon that, but never lose sight of the long-term goal of integration across all of the WordPress screens. Even the front-end comment forms could thrive with the Fields API.
Why do you feel personally responsible for the project not being a core priority?
At one point, we had momentum. We had at least three to four people who were active. It fell apart because I ran out of time. It’s my shortsightedness, it’s my fault. I spent hundreds of hours developing the project over a couple of years. I should have left myself much more time for organizing the feature proposal text and keeping the fires burning in our contributors’ hearts.
Considering the time and effort you’ve put into the project the last few years, do you feel any sense of relief passing the torch on?
If the torch gets passed or picked up, I will feel a ton better. The main relief is that it’s officially not a weight I have to carry alone any longer. It’s okay to try and fail, it’s still sad though.
I hope that someone or some company steps up and puts time into this. They could even reignite the fire in my own heart that burned itself out. For now, I have one less major to-do item. I still have a hefty plate but it’s no longer as heavy of a burden.
While the immediate future of the project is unclear, those interested in taking it over are encouraged to read posts marked with the Fields API tag on Make.WordPress.Core to learn about its history. You can also check out the project’s Github page.
If you’re interested in taking over the project, you can contact Clark on Twitter, Slack, or through his website.
Yesterday I started the renewed evaluation of the whole spectrum of plugins for Custom Fields and just like I remembered it is still the Wild West.
Everyone is doing it in post_meta and even the good ones don’t give me a feeling of sustainability.
I always try to find a solution that will Make sense in two years and not be hopelessly outperformed by the next thing.
The Field API would finally be the foundation for redesigning the Settings API.
I really hope someone can pick this up and rise it from the ashes.
I really appreciate all the time that all contributors put into the WP community. Especially in this case – Scott.