WordPress Core Fields API Project is Seeking New Leadership
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.
9 Comments
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.
Report
Fields API is an ambiguous project as it affects all the things that relate to data in WordPress. And data is the foundation of a CMS. But people are focusing on Gutenberg at the moment, which is the presentation layer of the CMS. In long term, I think Fields API will get its attention and be a high priority in WordPress.
It’s sad that Scott is stepping down. He’s done a good job with that.
Report
The Fields API should have come before Gutenberg and the customizer so that the future of WordPress would have a stable base to pivot on. But now we have a two large projects that are evolving in problematic ways and it will hamstring WordPress for the next decade (that is, the customizer and gutenberg). Javascript development was the moment to look at WordPress’ mishmash code foundation and take a more sustainable approach as a whole new layer of code is added and it seems to me like we’ve blown it.
It’s shiny object syndrome gone wrong, despite the best intentions of the developers who’ve put in a massive amount of work to make things happen in core which is no small feat. Someone with a sense vision should have steered this in a different way, but it’s become clear to me that the leadership is failing and falling for the wrong kind of aims.
Take the perverse instinct to dominate in terms of market share and raise it to ridiculous levels. Take the longing to be a modern JS centric webapp that looks in total deference to how the big boys do things (Facebook and Google). And the sad irony is the contradiction there, trying to be a giant of the web while utterly failing to do what the behemoths do, which is to do things their own way.
As WordPress transforms into a half baked React app that serves mangled code, compiled and built while denying normal users an comprehensible look in, it has totally forgotten what WordPress was and how it came to be. Attempting to be a giant while being too shy to be its own quirky self – a code base that could be easily played with with an API that was distinctly its own. Instead it is ashamed of its own PHP foundations and desperately wants to conform to what’s happening elsewhere. It is now instead shaping itself in the image of projects pushed out by developers working for corporate giants who are merely looking to impress each other with their optimisations as they ignore what damage their employers are doing to the wider web and the fabric of society. And that thing that takes hold of these developers, that constant urge to look for better technical solutions with ever more complex tools mandates that new projects are started and old ones abandoned, because you can’t impress with mere maintenance of a project.
All this to me is antithetical to what WordPress has come to mean to me over the last decade. It now seems like it’s in a hurry to cast away its roots. So in a rush we are, despite enjoying market dominance, we never even considered the ramifications of the code we’re pushing out today. We have Gutenberg that is going to break hundreds of thousands of lines of code written by thousands of developers and self-taught webmasters. We have the customizer that shovels so much clientside code down the throat of a users’ browsers that it has become the most sluggish, slow loading part of the UI while not even offering a clear way of intersecting back with Gutenberg. And it’s really painful to write that as someone who was a big fan of the customizer and has spent hundreds of hours creating custom functionality in the customizer.
In hastily embracing javascript and the REST API it seems like not one thought was spent thinking about how we could port over WordPress biggest strengths in terms of how the PHP code base empowered developers of all levels. A true market leader wouldn’t have tried to shoe horn what others are doing in terms of code, functions or features into the project. It would have decided how to be more of itself in a more modern way. Now WordPress is turning into something very different. It may continue to be the market leader, but it will have lost some of its DNA along the way. And it’s a damn shame.
Report
/signed.
Your comment deeply mirrors my thoughts in a much calmer way.
cu, w0lf.
Report
/signed
It’s sad as we build more and more complex projects based on WordPress but still miss out on a solid Field’s API that would make many things just more interoperable or would add options how we store data and still work with other Pluigns …
I hope this get’s some awareness and traction! Thanks Scott Kingsley Clark that you tried it! It’s no shame to admit that things could have be done different – looking back this is always easier!
Bernhard
Report
Yes best comment I’ve read in months.
Fields should have come first to provide logic and structure around data (which is essentially what a cms is about)
Instead it’s been done completely arse about face, this mess will either cause a stack of wasted time, lead us into obscurity, or be walked back in time.
Report
So all this talk about “decisions are made by those who show up” is just feel-good speech after all.
Report
Yup, that is total and utter B.S.! (and has been for well over 4 years methinks)
Report
It’s true as long as your vision aligns perfectly with what WP core people think
Report
Comments are closed.