#89 – Scott Kingsley Clark on Why the Time Is Right for the Fields API

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, why the time might be right for the Fields API.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you all your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox. And use the form there.

So on the podcast today, we have Scott Kingsley, Clark.

Scott is a WordPress developer who has been working with WordPress since 2007. He’s well-known for his work on the Pods Framework, a popular content and custom fields plugin.

Scott’s goal is to find ways to enhance the WordPress experience, particularly in terms of working with different types of data. He’s currently involved in the WordPress Fields API project, which aims to provide a better solution for developers looking to wrangle their data. And that is the focus of the podcast today. As you’ll hear, Scott is determined to contribute to the continual growth and improvement of WordPress, and to make the Fields API a reality.

Scott came from a background using Drupal, which is an alternative CMS. When he first ventured into WordPress, he found certain features were lacking. Things which were baked into Drupal Core were not available in WordPress, a notable example being custom fields.

We know that WordPress has a myriad of plugins, which can take on the burden of creating custom fields, but Scott has concerns about the interoperability of these plugins, and he wants to create a more solid structure within WordPress itself. Wouldn’t it be nice if there were ways for developers to create custom field plugins so that you weren’t locked into one or the other. Scott imagines a future in which you could move from ACF, Metabox Toolset and more. A future built on top of the Fields API.

Throughout the conversation, scott talks about his passion for incorporating the block editor, React and other technologies into WordPress. He shares insights on controlling block settings, making them extensible through PHP.

You might know Scott from his work on the popular Pods Framework plugin. This plugin allows users to create custom content types and fields in WordPress, and certainly speaks to his credentials in trying to push the Fields API project forward.

We talk about what the Fields API might become. The aim is to simplify the process of working with custom fields and content types in WordPress. With the Fields API, Scott hopes to unify the different methods and APIs for managing custom fields, making it easier for developers and non-developers alike to add their fields to different screens within WordPress.

It’s a complicated undertaking and we get into some of the areas of WordPress, which might benefit from his work. Scott sheds light on the challenges faced during the development of the Fields API, the need for shared storage standards among plugins, and the potential for better integration with the WordPress Admin UI.

Towards the end of the podcast we talk about the future of the Fields API project, and how gaining support from people in the WordPress community will be crucial to its success.

If you’re interested in how WordPress can be used as a fully featured CMS, this podcast is for you.

If you want to find out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Scott Kingsley Clark.

I am joined on the podcast today by Scott Kingsley Clark. Hello Scott.

[00:04:53] Scott Kingsley Clark: Hey Nathan, how’s it going?

[00:04:55] Nathan Wrigley: Yeah really good. Thank you for joining us on the podcast today. We’re going to get into the weeds a little bit with WordPress code and all sorts of things. We haven’t had one of these episodes for a little while so this will be nice and refreshing.

Scott, given that we’re going to be talking about something technical I suppose it would be a good thing right at the beginning to learn about your technical expertise. The various different projects that you’ve touched in the WordPress space during the time that you’ve been in that. So just yeah a little moment for you to offer up your bio really. So over to you.

[00:05:24] Scott Kingsley Clark: Well sure. I started working with WordPress in about 2007 or 8. I used it briefly once before with a one click install from cPanel before that, but I didn’t really like it at the time. And I was doing many other things.

But ever since that point I have been really involved with trying to make WordPress the best that it can be. And that has evolved through plugin development. One of the plugins I’m more known for is the Pods Framework. And that is a content type, a custom field plugin for WordPress. But I’ve also tried to find ways to make it easier for other developers to build things without needing a plugin. Because a plugin like Pods existed before custom post types had a real API.

But now that it has a real API you don’t really need a plugin like Pods to just make a custom post type. And the goal for me is, I’d love to see a better way to work with those types of objects inside of WordPress that have very different APIs, or in some cases no API at all. You just have to output your own markup and hook into some hooks. And it’s not really great.

Especially in this day where we have everything exposed to the Rest APIs. And you want to build really cool blocks, but you can’t leverage some data from different structures that don’t exist. So that’s where I’d love to find ways for WordPress to level up.

In this particular project of mine, is the WordPress Fields API. There is a group of us who have kind of rebooted it, but it existed in 2000 and, I want to say 14, 15, 16, 2017, all through those years. And we had made some progress, made a few different proposals and it just got stuck up in the process of getting the block editor and Rest API.

And there was just so many more bigger features that were getting the priority, and it kind of burned me out. And I didn’t find anyone else to carry the torch so it just went away. And just the start of this year we started up again.

[00:07:30] Nathan Wrigley: What was the reason that it went away? You mentioned there that there were a whole variety of different things going on at the same time. So was it that the community’s focus just seemed to be more interested on other things? And so despite the fact that you were putting in the time, and you obviously just described that it burnt you out a little bit. There just wasn’t enough interest because attention was being put elsewhere.

[00:07:53] Scott Kingsley Clark: Right. Well Fields API owes so much to WebDevStudios and 10up who offered a lot of my time on the clock. They donated my time towards developing the Fields API and pushing it forward. And at 10up we were really, really close. We got the closest we had been at that point because at 10up we had a really awesome contributor for WordPress. A core committer, Helen Hou-Sandi.

And that got us really close, but I think it just was that I was practically speaking for Fields API and saying, we should do this, we should do that, and it just wasn’t hitting. It wasn’t hitting right for them. Or the people who were involved in making decisions on what was going to make it, or what was going to get the attention or whatever, just didn’t feel it yet.

And I can understand that. I mean there’s so much that everyone is trying to do for each release. And I kind of assumed that if I built as much as possible and showed it as a really thoroughly working prototype with tests and everything else. And I just handed it to them and said hey here it is. Can you help me make this part of WordPress Core? Do you have any feedback? And when I did that I guess the biggest problem was I hadn’t really involved all those same voices at that point prior to actually doing the development of it.

So I had some input from a few different core contributors and committers and such. But as soon as I pushed out that final proposal in 2017 we got so many detractors and people saying, oh we should have done this differently or, why is it like this? And I would have done it this way. And it kind of did not get the consensus that I was needing for it to gain further traction. So we’ve kind of approached it differently in this reboot.

[00:09:42] Nathan Wrigley: Okay, right. So you did a lot of the work, you put it out there but the feedback that came back didn’t exactly encourage you, let’s put it that way. There were people who just would rather it had been done in their way. I’m guessing that that’s because there are loads of different ways that this type of problem has been tackled I guess on a more or less on a per plugin basis. There’s probably hundreds of plugins out there that do something similar. They do it their way. And so they presumably think that their way is the way that it should be done.

[00:10:15] Scott Kingsley Clark: Right. I mean there’s so many plugins like ACF and Pods and Toolset, so many more at comparewp.org slash cck. Which is like a really cool comparison list of all these different types of plugins. But there’s so many that each one has their own baked in API for managing fields in WordPress.

And it’s just bonkers that everyone has to build all these APIs, and in the end they’re almost it’s forcing the need of having to build their own APIs because they won’t accept anything else other than the one that they built. And I think that it’s tricky with developers and egos and everything else. We all have to kind of find a way to, you know, what is the minimum bare essentials API that we could build for this and find a consensus on that.

[00:11:01] Nathan Wrigley: So I guess this time around the community involvement is going to be there. You’re going to do this much more in the open. So that as you are going along presumably ideas are chipped in, rather than it just being one great big release at the end where everybody gets to either agree or disagree.

[00:11:18] Scott Kingsley Clark: Right yeah. We tried to do that before but I think the challenge was we moved so quickly. I built so much code and I had made a specification ahead of time. But really the time wasn’t spent in the research specification side to get a consensus at that point, with not just the people who were involved but everyone else. Making sure everyone else had a moment to do that.

I guess when people just look at a specification like oh, I’ll just look at it later on when he has something for me to look at. And so it just gets delayed. And I’m hoping that this time I can find ways to intuitively make it so people will actively and proactively be part of that process and give feedback

[00:12:01] Nathan Wrigley: So given that you’ve restarted it, what reinvigorated it for you? Where did your curiosity for something that has been dormant for quite a number of years now. What on earth was it that brought you back to seeing this as a worthwhile use of your time?

[00:12:16] Scott Kingsley Clark: Since 2017 I’ve had kind of dark years in my contributing to WordPress Core, and just feeling like, well I can’t get anything big done so maybe I shouldn’t spend my time on it. And just the amount of time I’d spent on it had taken away from my full time work and my side projects.

I’m just like, well if I’m going to do this I really need it to be something I believe in. And up until the start of the year I just didn’t really feel like it was going to be possible. And then Joe Dolson, from the accessibility team was talking about how their team was looking at trying to revitalize the settings screens.

And one of the biggest challenges were their setting screens are hard coded in a lot of ways. And there’s not really an easy way to just like, here let’s try out this different interface. Let’s try this interface, this markup. We’ll change this markup here. And it’s very difficult to produce different markup inside of WordPress Core right now for a lot of screens really.

And more importantly for them, it’s not even using the Settings API the same way as most people are building things with the Settings API. And they hooked up with me because Courtney Robertson, a really awesome Dev Rel person, has just connected me with Joe at the end of last year I believe. And we just started talking about it, like hey this would be really cool if we had this Fields API stuff that you were thinking about before.

And I was like well I don’t know. And then as they discussed it with really the focus on accessibility I was like, you know what accessibility is such a big priority to me that I think it kind of overrides my initial thoughts about well I don’t know if I can get this into Core. Because I thoroughly believe in spending more time on accessibility for lots of different plugins. Especially for WordPress Core and the block editor. And if I can help push that forward I feel like I’ve done something better with my time.

And at that point I was like yeah I’m in. We’ll focus on the Settings API, just on that. And we’re not going to like build all the different screens and API prototype that we had done before. Until we get the Settings API, let’s focus all of our energy on doing that for the Settings API itself.

[00:14:26] Nathan Wrigley: So that all kicked off again at the beginning of this year, 2023. And I’m staring at a page on the Make WordPress Core blog, which you wrote right at the beginning of the year, january the 9th. You’ve posted a video there of you, and I think the four other people on the call. So right at the very start of this year, five people involved at the very least.

How has the project been growing? Has it caught the attention in the way that you’d hoped? Have there been people coming along to assist? One of the enterprises of this podcast episode is obviously to swell the number of people, but it would be quite nice to know how it’s going just prior to that.

[00:15:04] Scott Kingsley Clark: So as with a lot of these kinds of initiatives it all depends on the time you put in, as someone who has the vision and leads it. And my time on the Fields API had been kind of reduced, just right after this. The economy started having some challenges in the tech space, and job security was a concern in a lot of areas for a lot of people, especially me.

And so I didn’t have as much free time to focus on that. I was focused on my work, keeping my head down and making sure I was doing all my things. And I just didn’t have enough headspace for it. But I knew that if I could really spend a great deal of time this summer on the Fields API, getting it prepared, getting it to the next phase, so that we have something solid. By the time it is time for Community Summit contributor day for WordCamp US we have a solid chance.

And then something came out of nowhere. On the Make WordPress dot org core, blog I saw a post come through. And I’ve been watching posts there all the time and sometimes I’ll provide feedback. But this one was unique. This one was talking about revamping the Admin UI. And now I’m getting all sorts of excited and I’m thinking to myself, oh this is my time.

Like, if I can get the Admin UI perspective on the Fields API, I think this could even help us further, pushing this forward. Because if you want to approach redoing the Admin UI you have to expose these kinds of fields and forms and screens in a way that is more dynamic than it is right now. And that is a sweet spot for the Fields API.

So I posted on that blog post. I asked Matias, hey can we have Fields API? Please, please, please be part of this conversation. I would love to talk to you more about it. And so we’re probably going to talk about it at WordCamp US, some time during that week. And my hope is we’ll get this really pushed further. Because it takes buy in from the vocal people in WordPress. And I think I’m beginning to see more buy in. And that is really a positive thing for me.

[00:17:12] Nathan Wrigley: Sounds like a really nice bit of serendipity there. Couple of things happened, and the chance of the Admin UI being overhauled kind of sits perfectly doesn’t it. That really would be the moment.

It is a dramatic change that’s being proposed. And so I guess if you’re going to go all in on changing the Admin UI, well now would be the time to get all of the fields work done as well.

It just occurs to me that given the audience that listen to this podcast, there’s a fair smattering of developers no doubt. But also there’s people who are just into WordPress. You know, it’s a hobby. They perhaps do it as a side gig or something.

So maybe we should rewind and do some explanations about what on earth an API for fields would even do. Why is it even needed? I’m suspecting that many people log in to their WordPress website, certainly since the advent of Gutenberg. And more or less everything that they want to do, publish posts, schedule posts, that’s possibly the extent of it all. It functions.

So I’m imagining there’s a proportion of people listening to this going, well, what even would this be needed for? Describe a scenario where this would be useful. So, let’s cover that out. What is the Fields API? How would it change what WordPress does?

[00:18:25] Scott Kingsley Clark: Sure. So let me preface my answer with, there’s a reason why there’s so many plugins out there doing content types and custom fields. There’s a reason why Advanced Custom Fields has millions of active installs. And tons of people have paid for the pro premium versions of these kinds of plugins.

Now I’ll get into the real answer. This is an incredibly complicated dance. Whenever you want to go add a custom field to a post, or let’s say you’re building a site, a hobby site. I use the book analogy a lot, but let’s talk about music, because I love music too.

So you’re setting up a site for your music and maybe you’re an artist, a solo artist or a band. And you’re trying to set up a list of albums. And so you’re like well, how do I add albums? You could add that in the block editor. No problem, no issues there. But then what if you wanted to make it more data oriented.

So if you wanted to do that you’d have to go register a custom post type for album, for instance. Maybe a custom post type for tracks, if you want to relate them to albums in some way. And maybe a custom post type for other things. Maybe custom taxonomies for other items that you want. But the challenge there is not really in the content type. It’s in the custom fields you want to add to that.

Inside of WordPress, I counted it up recently, there’s somewhere between 16 to 17 different APIs and hooks that are totally different from each other, to add custom fields or settings to different areas on all the different screens, and different objects inside of WordPress. That is a lot. So adding a custom field means you have to go add an action inside of PHP.

First of all you have to know PHP and kind of know where to put it. Second of all you have to then go add action to add a meta box. Then you have to add your code to render all of your fields markup. So you have to add your HTML in there and have it do that. Then you have to add an action to handle the saving.

And then at that point you’re probably going to be looking at doing more things for taxonomies possibly. So you have to work with another action there. You have to add things there and it doesn’t look great. So then you have to add more markup. And it’s a lot for someone who just wants to build.

So you just mentioned that there’s a number of developers listening to this right now. But there’s a lot of people who aren’t really considering themselves developers. They’re just people building sites and they don’t really have time to dig into the code. Or they don’t want to tell their client they can do this if they can’t build it custom, they would have to pay someone else to do that. And they want to avoid that cost. So they’re going to use one of these off the shelf plugins, like Advanced Custom Fields.

Why would you spend five hours building your albums and tracks and things like that in PHP? The trial and error and figuring out the markup and, why is this not working? And then coming back to it later on and spending another few hours trying to debug something that happens. And then displaying it all on the front end. Why spend all that time when you can just install a plugin and just click a few buttons? And boom, you have another post type and then you have your fields already displayed. And by the way they look really nice. Why would you spend that time?

So this is more of a feature, or more of a project geared towards developers so that it makes them spend less time on their side of things. And it unifies all 16, 17 of these methods and APIs to work with all these different screens.

But what the end result would be is anyone using WordPress could then be using a plugin, or potentially use code snippets very easily without having to have a whole lot of knowledge. And be able to add a field to different screens without a whole lot of code, or whole lot of PHP experience. And these types of plugins like ACF, and Pods, and Toolset and various others, they could then leverage the Fields API if they’re supporting that WordPress version that includes it. They could leverage this Fields API in a way that reduces the code that they actually have to have inside their own plugins.

And at the same time that makes it so WordPress itself, the REST APIs, everything that talks with the Fields API, then knows about the structures you’re registering.

It’s a hand in hand, win-win scenario for end users who benefit from the stability, and the flexibility, and extensibility of those APIs in place. And developers who want to be able to utilize those things.

[00:22:54] Nathan Wrigley: Have you any experience with other CMSs? We could probably list off half a dozen or more other CMSs. But certainly some that I have used in the past, a lot of these kind of features are baked into the core product. So the ability to add custom fields to, well it may not be called a custom post type over on that particular platform but you get the idea. It is already built in, if you like.

You mentioned that you want to have this pushed to Core. Do you see that other CMSs are potentially stealing a march on WordPress? WordPress has traditionally been very good at giving 80% of the people what they want. So there is some argument as to whether or not some things should be added or some shouldn’t. But do you feel its been lacking this? And really a lot of other rival CMSs have been doing this for years.

[00:23:42] Scott Kingsley Clark: That’s a very good point. The plugin Pods was one of the first ones that did custom content types and custom fields for WordPress in a way that mimicked, and this is in 2008, the end of 2008. It mimicked Drupal at the time.

Drupal has a major feature called, what they called CCK, which was Content Construction Kit. I think that was what it was.

And so what value that API had for Drupal was that it would let you do the kinds of things you’re seeing be possible with plugins like Metabox or whatever else, you can use code, and ACF to register your groups and fields, and you can use code to register custom post types.

So you don’t have to use the UIs. You don’t have to provide a bunch of JSON. You can just register those things through PHP. And Drupal has had this for many, many years. It’s coming up on almost 20 years now that it’s had a feature like CCK. And that is not really that Drupal is ahead of WordPress, it’s that WordPress is severely behind. Because it hasn’t really prioritized these kinds of unifying APIs for its screens. I mean obviously WordPress hasn’t.

If you look at it, it really hasn’t changed a whole lot until block editor. The interfaces and screens really kind of have been what they are. The structure of where things are has been mostly the same outside the block editor.

Multisite was a big thing, but the screens themselves they really haven’t changed a whole lot. And I think that is just because we’ve been focused as a project on building features and not looking back at what we’ve done, and finding a better way to represent that. A project like the Admin UI revamp, or even accessibility revamp, could give us that time to kind of be introspective. What are we doing with these screens, and how do we make these things better?

And backward compatibility doesn’t have to be a hindrance in the Fields API because it can be backward compatible too. It’s just if you want to register the new way you can do that and that is the officially the way that we recommend you do it. It’s just, it works. I really hope that more people see things like Drupal, and there’s so many other plugins, or so many other CMSs out there that have their own kind of CCK situations.

Because it’s just, you’re building a CMS? Well you’re not going to want to do that the way the WordPress did it way back when. No one’s going to want to do that on purpose. And I think that they all already have their own forms and Fields API processing abilities, because that’s the bare minimum. As a developer, when you’re building something like this you build that. You don’t build all the markup and everything hard coded anymore.

[00:26:24] Nathan Wrigley: Yeah I was a big fan of Drupal, and I used Drupal exclusively more or less for many years. My first interaction with WordPress was an endeavor to move away from Drupal for a variety of different reasons. And I do remember opening up WordPress and almost being incredulous that I couldn’t achieve some of the things that I was simply able to achieve with a vanilla install of Drupal.

So custom fields was just trivially easy. It was there, it was baked in. And so I had this expectation, well everybody’s using WordPress it must have, you know, a similar feature set. And so, just flabbergasted that it didn’t exist.

Of course very quickly found out exactly what you just said. That commercial and also free, there’s plenty of free options as well, Pods being one. That you had to go and find a solution for that. So rather than it being baked into core you’d go out and you’d purchase ACF or you would download Pods or whatever it may be.

But this sort of feeling that well that’s interesting because I wonder how they’re doing that and if they’re doing it differently than the other one, so if ACF is doing it differently to how Pods is doing it, you could make that spaghetti go in any direction. How am I going to be stuck in the future? You know things that I create with Pods, is that interoperable? Could I start using ACF at a future date on the same website?

So there’s all of that thrown into it as well. And I guess the endeavor here is to create that basic structure so that everybody can approach it and everybody can start creating these things without the reliance necessarily on a third party plugin.

[00:28:03] Scott Kingsley Clark: Right. Like if you’re using a plugin like that and the Fields API comes out, there could be a migration thing, or exporting plugin created that exports from Pods or ACF or whatever into the Fields API structure. Much like ACF and some of these other plugins have the ability to kind of export. Maybe the biggest one is Custom Post Type UI. Where it’s just simple. Add custom post types, you add custom taxonomies and you can export that to code.

And that code works without the plugin. So it just tells it, here is what you tell WordPress to do what you want to do here. That kind of ability to export into just a Fields API code would take your code, your plugin usage of ACF or Pods or whatever, and you could easily switch out into just pure WordPress.

But also because if it has that ability to use the Fields API at that point you have more interoperability. So you can go between these different plugins more easily because there’s a similar structure we’re all using. And when you’re registering through Fields API you can potentially set like a source, like this is coming from ACF, or whatever you want.

And then a Pods plugin could say oh hey I recognize you had these ACF fields, do you want to bring them over? The Fields API opens up the door because everyone’s talking the same talk. And we can all talk about things in the same conversation instead of like I need to know the ACF APIs to work with getting the fields out, and I need to know this and then that. And there’s that side.

But there’s also the storage side. So we’re talking about the way that ACF stores their content. For repeatable fields that can be quite tricky. Flexible content, anything that has to do with data that’s not just a simple single value gets a little bit tricky depending on how you choose to store it in ACF.

So those sorts of things are more based off of the plugin developers preference. So ACF was developed in a specific kind of point of view, for how they should store the storage. Pods is the same way, we have a specific point of view where it should be stored a certain way. Every plugin will have their own points of view. But if we can settle on the structure of the content fields, the custom fields for each of these objects, and how they’re going to be specified to WordPress, that’s really half the battle.

Then we can start talking about, okay now that we have this common language let’s work on bringing everyone to the same storage, so anyone can switch between these different plugins and they won’t have to deal with any extra work. We could all agree on a shared set of storage, kind of specification standards really.

[00:30:35] Nathan Wrigley: The breadth of this project feels like it could be truly enormous because there are fields in all sorts of unexpected places in WordPress. I mean you may not be thinking about them all the time but you know we’ve got post types, and terms, and comments, and settings, and users, and navigation, and the media library and all sorts of different places.

How are you breaking it down? Is there an order in which you’re going to knock those dominoes over? Are you going for, I don’t know, probably the low hanging fruit of custom post types first, or is the intention to try and get everything done all at once? You did mention accessibility. Perhaps that’s come first because of Joe Dolson’s interactions with you.

[00:31:17] Scott Kingsley Clark: Yeah. So accessibility is going to be the main driving point for us right now. So we’re focused on the Settings API. If we can get this right and potentially the goal is to get it to the point where we can actually merge it just for the Settings API. Just for the Settings API.

We have an inside person now, inside of WordPress itself. So now we can start expanding it, and say okay now here’s the proposal to add this to the post types, and to the terms and everywhere else to be powered by the Fields API. And once you have those things powered by the Fields API, the full Admin UI revamp is becoming much more approachable for people who want to switch out the markup there.

They don’t have to modify core as much to make it happen. They don’t have to duplicate all the code and deal with merge conflicts. It’s just so much more easier when you’re working with data structures that are defined as data structures, and not purely as markup and save handlers like they are in many areas of WordPress.

[00:32:13] Nathan Wrigley: You’ve been doing this kind of work for years with Pods. So you know you’re incredibly familiar with this. Is there anything during your time working with Pods where you thought, I wish WordPress had this?

So I’m just wondering if you might try to smuggle into this some unique new feature, not something which we’re already familiar with. You know post types and comments and users. Really that question might go nowhere but I just wondered if there was something innovative that you’ve got. Really I’d love to try this.

[00:32:40] Scott Kingsley Clark: So I do have something but it’s going to be interesting to see if we can make it happen. So the way that this has been focused on has been replacing existing screens that are kind of hard coded and all that. But we haven’t really talked about, what about the block editor? What about React and all those things?

And the cool part about that is that if you look at the screen, if you go to the block editor right now, you’re looking at editing a post and you insert a block, like let’s talk about the paragraph block or even a group block. On the right hand side, if you have it open, the inspector control sidebar there. That allows you to control what the block settings are, on margins and adding extra classes if you want to add them to the block.

And many different blocks have many different settings. And then also you can click over and if you’re looking at the post type, or page post type you’ll see the word post or page up there and there’s a little kind of a tab, and you click that and then you are looking at the object controls.

So this controls what is going on with the page or post like attributes for the parent, or maybe the date, or the many different things like slug and all that. So both of these areas are areas I would love, not really to sneak in, but I want to get buy in from people. I want to find a way to build these screens, these sets of fields and have them extensible through PHP.

If we can do this in a way with the Fields API where you could register new sections and controls inside of React, it’s possible. We’re doing this right now. Pods is doing this, ACF, many other block builders are doing this with their blocks, their own blocks APIs. The way that we’re doing it right now is too much. It’s going down the same road of we’re locking ourselves in.

I want these sections and these controls to be extensible. I want someone to be able to override stuff. I want someone to be able to add new things to them. I want to add something ahead of it or after it. I don’t want to have to know any JavaScript to be able to do the bare minimum for basic controls.

You can still, with the Fields API even, you could still at that point do all the JavaScript or React stuff you want to build up your own custom controls, and the ways that you want them to display, and special handling for how to work with the blocks and all that. But really the bare minimum ought to be the way that we lower the bar towards developers, new people, new developers.

But especially at this point, PHP is not getting the love it needs as an API source for WordPress, especially with a block editor. We need to expand that. I think there’s so much potential.

[00:35:27] Nathan Wrigley: Given everything that you’ve just said, and we’ve now got a real nice full round picture of what it is that you’re trying to achieve, are there any significant roadblocks? I mean obviously hours and coding, the amount of time that it’s going to take you to do all these things, and the amount of people who jump on board the project, that’s a given. Are there any technical obstacles that are in the way that you foresee being problematic?

[00:35:52] Scott Kingsley Clark: So before, when we built all this stuff in the earlier versions, and I just read, we actually started working on the kind of Fields API idea in 2013. That’s even earlier than I remember. That was back in Freenode, Freenode IRC stuff.

I think one of the challenges was when we built all the different screens we had to modify WordPress Core files and override them. And as new versions of WordPress would be released we’d have to merge those changes into ours. It’s a headache to keep it up, and keep it updated for every release. And for even maintenance releases to make sure that you’re not breaking something that was changed or fixed inside of WordPress release, and having it so that my prototype should always work with latest WordPress.

Well that’s difficult because latest WordPress is always changing. I think that’s the challenge is trying to focus not on, like we did before, we had posts, we had terms, we had settings, we had users, we had comments, we had media, we had the customizer. All those different areas were covered.

We already had those things covered inside of the Fields API code we had before. You could use the Fields API actively to add things to those screens. But that was a lot. That was a lot to deal with. So if we focus on settings, that’s why I’m hoping this reduced focus on setting screens will reduce the amount of pain we have to deal with. Because when we’re merging things we only have to worry about just those settings screens that we’re overriding for WordPress Core. That’s it. And we don’t have to worry about all the different screens and all the different files that we’ve been overriding.

[00:37:16] Nathan Wrigley: Yeah thank you for that. I mean obviously you would be very warmly welcoming anybody who has listened to this and is intrigued by what you’ve said and thinks, okay I’ve got some technical expertise that I could apply to this project. If that’s the case, where are you hanging out most with this? I’m guessing the Slack channel is probably a good place to start. But maybe there’s some other places too.

[00:37:39] Scott Kingsley Clark: I really deeply would love to have more contributors. Anyone who can think about things in different points of view for how a Fields API should be built. Things like someone who’s involved with other plugins that do this type of thing. It’s a big plus if you’ve built a Fields API yourself for one of these plugins.

It’s also a big thing to think about you know just someone who’s not been building those things but maybe someone coming from outside of WordPress, or someone with heavier PHP structure experience. How do we structure the Fields API? And how is that going to look?

There’s also plenty of room for people who can help write tutorials, or help us write. I think one of my big deficiencies is having time to write up all the great text that we’re going to need for make.wordpress.org core posts about how do we describe what we’re building here, and get people involved and excited?

What is the proposal going to look like? And how do we lay this out nicely? And those types of things would be also very helpful to have. And you can find all of our efforts inside of Slack right now. So if you go into the WordPress Slack you’ll find us in the core dash fields channel.

We also have a GitHub that has been totally revamped from the old ones. We now have two different archive repos from the past versions that we had. And now we have this third repo that we’re using that is refreshed and ready to go. It already has some more research already in it and we’re going to start working from that repo now.

[00:39:03] Nathan Wrigley: That’s perfect. I will make sure to link to those in the show notes. Everything that you’ve mentioned I’ll make sure that it gets a link. But it sounds like not just technical people. There’s also room for people who have skills in, I don’t know, documentation or something that you’ve described. So the door is wide open. This feels like really important work. It would be lovely to get this over the wire. To get some more buy in, and more thoughts from different community members.

So yeah we’ll round it off there. Scott Kingsley Clark. Thank you so much for chatting to me today. I wish you all the best in getting this into Core in the, well, let’s say near future.

[00:39:35] Scott Kingsley Clark: I really appreciate you including me and this project in your efforts here to get the word out. I can’t say how much I’m excited. I’m just extremely excited to get this finally pushed up and hopefully emerged into Core. And I am working my behind off this entire month, just to make sure that we can try to get that traction and get it across that finish line.

[00:39:58] Nathan Wrigley: Well very much appreciated, because everything that you do and achieve will certainly make our WordPress lives a lot better. So thank you, Scott. I really appreciate it.

[00:40:07] Scott Kingsley Clark: No problem.