EP443 – WordPress Fields API with Scott Kingsley Clark

Episode Transcription

Speakers:
Jason Tucker: 32.55%
Jason Cosper: 13.31%
Scott Kingsley Clark: 54.14%
Jason Tucker:[00:00:00]
This is episode number 443 of WPwatercooler WordPress Fields api. I’m Jason Tucker. You can find me at Jason Tucker on a bunch of things. You could also find my website too. That’s, Se Reed. You can find, Se Reed, over on Master On as well.
Jason Cosper:[00:00:30]
And y’all know who it is. This is your boy, Jason Cosper, AKA Fat Mullenwig it again on the world’s most influential WordPress podcast. Wow. It just really cut off
It sure did.
you. You texted me about this earlier and said it would just drop right
it would just drop.
Oh,
But I do wanna take this opportunity to let everyone know that, if you are watching this, or if you’re listening to us later, we would love for you to share it. Hit the share button someplace. Share this out so folks can, learn about what Scott’s Scott has going on with the, field’s.
yeah.
we have Scott on the show. Hey, Scott, how you doing?
Scott Kingsley Clark:[00:01:14]
Hello. I’m doing pretty well. Yeah.
man. it’s good to have you. We,we always, you’re like our, fields core respondent, if you will, you’re the person who always comes in talking about how to actually do more cool things in WordPress. as it relates to Fields, extra metadata, all sorts of fun stuff like that. And we thought we’d have you come on and talk a little bit about the Fields api, what you got going on with it, and what can folks do in order to get involved as well.
That’s
And as. The lead developer of the Pods Project, I, it’s second nature to me to know all these things about WordPress and the limitations of what it can do in the side of WordPress and how to extend it, and how to extend it in a way that makes it look clo as close as possible to word the WordPress experience.
at the time, that was meta boxes, so we were building meta boxes and fields. For the meta boxes. We were doing all sorts of things with user profiles and setting screens and all the different. And they’re all unique. Each plugin had their own way of doing it. Each plugin had their own way of storing things.
And so that is the hope is we’re. Do a narrow focus on right now, just a setting screen and user profile screen right after that,to revamp them for accessibility and implement this fields api, which hopefully would allow us to unify these types of screens to register configurations of.
There’s an actual structure to it. it’s an educated configuration that you can use all over WordPress and eventually, hopefully extend it to other areas inside a word.
Oh man. I don’t know how you even approach getting a whole bunch of different developers that have spent lots and lots of hours building essentially their own thing and getting them to be like, Hey, I need you. You’re not really abandoning this, but I want you to change focus, and I want you to look at it from the standpoint of using this API instead of the things that you’ve built yourself.
Is that, is that one of the, one of the benefits here?
so there’s numerous benefits, but one benefit being that. From in, in this theoretical world where we have a Field’s API instead of WordPress and that plugins have implemented that themselves, they have the ability to. Use the field p to register the configurations and then override things to do even more glorious things in inside WordPress and do things that they want do.
If we help these plug-ins unify under this library, it would allow these plug-ins to offer either at least a similar, at the bare minimum, a similar experience to what they can get when someone adds a field to a screen, but potentially having the ability to. Make it easier for migrating, because hopefully the data that they’re saving and sending out and rendering is going to be using that library.
See I one, one of the things that kind of strikes me about this and has excited me about this since. you initially were, had started work on this, y you and everybody else, who was working on the field API is, this is one of those things that, much like kind of the projects that you said, upend of the apple cart initially for you with the breast p and with Gutenberg is like, this is one of those like radical things that can like basically change.
And I’m happy that you, Scott, have found a way to reignite your passion for this, like I am. a thousand percent behind you
Yep. Same.
But, hell, I’ll take it now, the, so Corey has a good point. So Corey mentioned that you can see the benefit to the developers. obviously this is a developer’s focused API that allows developers to not need a need to require a plugin to do the basic. Integration with any setting screen or user profile or whatever, those areas of WordPress that you can currently interact with just basic filters or function calls would be unified in this fields api.
So we’re almost like a gateway in a way from our support. At the same time, like I said, I’m selfish. I, as a developer, I don’t wanna have to require them to use pods to do anything as part of this same conversation, if they can use Fields API to do the same exact thing, and they’re a PHP developer and they just need to be able to add a field somewhere, there’s no reason to install pods.
And when I use the plugin, I see everything different from what WordPress looks like. And so I feel like it’s not part of WordPress. And so those experiences, also help. . So I don’t know it, it’s a give and take. I think it’s hard to answer that one particularly easily.
Yeah, Corey’s coming in hot with the,the questions here, the, this one in particular, where, they’re saying the, core fields a p i, since, customizer came out and it wasn’t quite what they were hoping for. Yeah, . And the thing is that we could just all of a sudden just turn away and go we’re not using customizer anymore and we’re now using something totally different.
full side editor,
Full side editor, . the other thing I was thinking about regarding what you were just saying is that having those,you, you could, I could essentially see companies coming out with add-ons that are not, essentially, not like managing fields. but rather they’re just, knowing the fields exist and then building blocks or something that will allow for those to be displayed a different way or something like that.
There are endless examples and the coolest part of this whole thing. . We build this Field’s API and we get people on board, but it’s not just people using it to add fields in different places. All of the extra benefits of this project are seen by add-ons, like you said, that want to make use of the configurations that they know of, but the like we talked about REST, api, W B C I, things like.
Okay, cool. I can go edit my post and do my block stuff. I go to my setting screen. Okay. Send my settings. I’m not in the WebView at this point. I’m actually in the app in a native, SC native, solution that will allow me to consume through the REST API for my WordPress site, my configuration, so it knows what my setting screens are.
These are all the things that I was bitching and complaining about
this would do for rest API and for the W C I and all the other areas that would be able to expose this thing, this information that is currently. Held tightly instead of a secure vault within WordPress, either hard coded with filters in various places, all the different things that you might see in classes with their own individual classes like post-class and term class, all this.
Yeah.
it’s awesome. I’m excited
I’m excited too. You just talking about that, having the mobile app be able to actually know that these fields exist and make it so that you can edit them and use thing, input stuff into them. man,that I’ve been dreaming about this for years and complaining about it too.
Yeah. It’s really funny because,I was, before you went off on that I was about to highlight this question from Courtney. Would this help data between apps sync better? And I think you basically, hit that on the head right there with,and of course made, made Corey, Dr.
right?
make that a thing if it wasn’t one
Right.
What things we want it to do in the structure. We’re basically, before we write code, we’re telling, we’re creating a specification for that code to say, this is what it’s gonna do. This is the functions, these are the methods, and things like that. Deciding on that. Once we get that part done, we then start building the code with tests and everything alongside of where press core things and hopefully get it a proposal out for it and let people use it and try it and see if they like it and throw us. Ideas and, frustrations maybe, of things we can improve on there.
If you think about it, what are blocks?
JavaScript
Wow.
To me it’s JavaScript
Okay, it’s it. JavaScript, I see configurations.
Okay.
I see blocks that need to be told, where they need to be shown. While that stuff that’s all inside, when you register a block, you see the ability to have attribute.
All of these things have. Considered as configurations and if you have a unifying api, that lifts all these things up in a way. Very easy for someone to add new ones, or a plugin to add new ones and not require any single drop of JA JavaScript in that process. That allows us to lift that bar up, cuz we’ve lowered the bar.
Things with JavaScript builds that are bugging and incredibly difficult to deal with when there’s updates and managing dependencies like crazy. And, okay, which WordPress version do we to try to create compatibility with? All those things are now, if you work within WordPress version X Point Up, then you have the Fields api.
Yeah. it sounds like we have, quite a few people in, in our live chat here that are super stoked about this. if you’re listening to this and not watching it, this is one of those episodes where it’s like we would spend too much time just reading all of the things that people were commenting about.
So Scott,I know that we’re right at the end here, but,I would really, before we end,if there is a time, end place, room in Slack or whatever the,the field a p i folks or are meeting regularly, please, let’s shout that out. Let’s, get that in front of people.
Yeah. So if you want to be part of this conversation, we have a Fields API kickoff chat that we had, in the early January that we posted on make wordpress.org. Slash core, you can probably find that while looking at the Fields API tag there, but if you want to be part of the conversation inside of Slack or whatever, we end up using because currently there’s talk about maybe switching away from Slack.
Awesome. unfortunately we’re gonna have to have you come back and talk more about this.
Oh no.
Say it.
that’s what happens. But, I wanna say thank you very much for hanging out with us, folks in the chat, if you don’t mind, I’d love for you to find a place to where you can hit share, share this stuff out.
I, I just watched the, people in Core Fields jump from 332 to 335.
Yes.
the last minute, so
here. This is great
Okay. Jason outro.
Here’s our route. Over to wp water.com/subscribe and subscribe to this content here. We’d really appreciate it. We’re gonna have Scott back. We want you to make sure you’d be able to find him and be able to come and hang out with us. So go do that and you can find us where all awesome podcasts can be found. Talk to you later.

Show More

WPwatercooler

EP443 – WordPress Fields API with Scott Kingsley Clark

Panel

Episode Transcription

Speakers:

Likes, Bookmarks, and Reposts

One response to “EP443 – WordPress Fields API with Scott Kingsley Clark”

Leave a Reply Cancel reply