Cory and Phil are joined by Scott Kingsley Clark of Pagely and the Pods Framework. We talk about Pods vs ACF (in a friendly non-competitive way), the Core Fields API project, and the JavaScriptification of the WordPress admin.
Clips
Links
(05:35) Pods website: https://pods.io/
(21:45) Core Fields API on GitHub: https://github.com/sc0ttkclark/wordpress-fields-api/
(26:55) Calypso: https://github.com/Automattic/wp-calypso
(56:25) WordPress Slack: https://make.wordpress.org/chat/
(57:22) Elliot Condon is back: https://twitter.com/elliotcondon/status/1667470204425871360
(1:01:26) Scott’s website: https://skc.dev/
Transcript
Cory (00:00:15): Welcome back to In The Loop, a WordPress agency podcast by Blackbird Digital. I'm Cory Hughart, and in this episode, Phil Hoyt and I interview Scott Kingsley Clark of Pagely and the Pods framework. We talk about Pods versus ACF in a friendly, non-competitive way, the Core Fields API project, and the JavaScriptification of the WordPress admin. If you have any questions about WordPress website development, contributing, or anything else web related that you'd like to hear us discuss, send an email to [email protected]. You can also find us on Twitter, Instagram, and TikTok as intheloop_WP. Blackbird Digital is a web and app development agency that specializes in WordPress, creating onscreen experiences that connect, teach, communicate, and inspire. Visit Blackbird.digital for more information. Enjoy the show. Cory (00:01:17): Welcome back folks. Welcome back, Phil. Phil (00:01:20): Hey. Cory (00:01:21): Today we are joined by Scott Kingsley Clark, senior software engineer at Pagely Lead developer of the Pods framework, core contributor and lead developer of the primary thing that we're here to talk about today, which is the Core Fields API project. Welcome, Scott. Scott (00:01:42): Thanks. Really excited that you asked me on. I had been following you online and I was just very, very excited to be included in this. Cory (00:01:53): Well, we're really happy to have you. So to kind of start us off can you kind of briefly give us, I know that you have a long storied history with WordPress. Can you briefly give us, like you know, how did you start, how did you get into WordPress, and how did you end up working for Pagely and GoDaddy and all that sort of stuff? What, what's the, what's the history there? Scott (00:02:20): Well, I guess I'll give you the bookends. So when I started my career in high school I kind of made my own reselling host platform where I resold hosting for a bunch of people. It actually started when I was offering hosting for free <laugh>. And so I had a bunch of people that I was hosting for free on the back of one of my plans, and then I was like, Hey, I could charge for this. And then it grew to like a couple hundred people and I just didn't like it. And <laugh>, I was doing more development and I wanted to focus more on that, so I kind of pulled away from that and eventually ended up in the WordPress space a a number of years later after starting my own CMS or I working on my own CMS project. And then I just, I didn't think at the time WordPress was ready. And then it started being ready over a period of years. And so I probably started somewhere in 2007 or so with WordPress. I was working for a SEO company, marketing company, and they had forked WordPress and made some modifications to it and like changed to the files and stuff. I'm like, what are you doing this for? And I found ways to get those same things done with plugins. And where it wasn't possible, I contributed patches to WordPress to try to get filters and hooks, whatever added. And that led me to eventually becoming kind of enamored with a plugin that just dropped, that was from a person that came over from Drupal. They had built a plugin called Pods Framework, and that was Matt Gibbs. He started it out and I just joined, like, I wanna say days, maybe not even a week after he released it. I was like, Hey, this is what I want to do too. And I started throwing out enhancements and fixes and things to him, and eventually we collaborated a bunch, and then eventually he moved off to do other things and focused his time in other places. And he let me become the lead developer. And I've been leading development of Pods since then. And my career has really followed the trajectory of, at first it was all agency focused, and then it ended up going in a product focus, which was where I would really enjoying stuff with Pods. And so I ended up at agencies at like Web Dev Studios and 10Up, and then moved on to Modern Tribe and The Events Calendar, stuff like that. And now I'm actually kind of outside of the, the direct ecosystem in a way. Like I'm working at a host. So it's like my career is gonna come full circle. <Laugh>, I started <laugh> being a host, and now I'm working for a host, and so I'm working at GoDaddy. Technically I'm working for Pagely, which is a subsidiary that they acquired about a year or so ago. And my focus is like building all the WordPress-centric things that make our hosting platform from Pagely work really well for WordPress. That's, that's where I'm at. I've also been contributing a lot with WordPress core itself over time, but I just love helping people learn the things that I've learned and save time. I love helping people save time. Phil (00:05:28): I feel like that's a similar sentiment across the entire WordPress community. We often hear that people just want to keep sharing what they know. For those who don't know, could you maybe give a brief elevator pitch of what the Pods Framework is? Scott (00:05:41): Sure. Yeah. So Pods Framework is a plugin that allows you to create new content types for WordPress. WordPress itself has had custom post types since, you know, years and years now since around 3.1, 3.2, I can't remember which one, but everyone said that that was gonna kill Pods, but it actually, it made it stronger because now Pods had an API to utilize and it was normalized to use post types because at, at the time, Pods actually had been creating post types before WordPress had post types. And so it was just very janky and very edge-casey and all sorts of things we had to customize. So now that all stuff was built in stuff. So it allows you to build custom post types. It also allows you to create custom taxonomies as well, like different types of categories. And then it goes beyond just that. It allows you to create content types that are extended. So you can extend a user type or comments or media, create new settings, pages and things like that, and add custom fields to those things. So it's like as if you were to run Advanced Custom Fields alongside of a plugin, like Custom Post Type UI, but with more power and more PHP APIs to utilize.There's some really fantastic time saving things with data structures that Pods just is a first class citizen inside of Pods. Relationships and data are treated in a way that is abstracted to a point where every kind of pod can be utilized in the same ways. You can build the, build the same thing across different things, and it's all used in the same APIs. Cory (00:07:16): Hmm. So, speaking of ACF, cuz Okay. Obviously we've talked previously about how we are, we are ACF users, we happen to have a lifetime license. So <laugh>, you know, I haven't really felt the need to kind of shop around necessarily, but it's interesting how you explain Pods in a certain way coming from a certain direction of kind of custom post types first almost. And then, you know, ACF coming from a direction of custom fields first and foremost. And now, you know, interestingly enough, in the past, how long has it been in there, Phil? Like six months or so? Phil (00:08:00): Couple months. Cory (00:08:01): They added the ability to do custom post types and taxonomies in the ACF plugin, which, you know, before that we were also, you know, users of the CPTUI plugin. I mean, still have it installed on plenty of sites of course. But yeah. So it's interesting that's one difference I think I'm getting right, is kind of like, focus-wise. Is there any like other sort of key, I don't know, similarities or differences for people used to ACF that, you know, maybe, you know, they don't know about Pods and how it could be used similarly or differently? I don't know. Scott (00:08:42): Well, the good news is if they're using ACF right now, there's no reason to switch. If you have built a site and built a project and you're very comfortable, you're very happy, I'm not gonna try to sell you on Pods. Like I've told all of the people involved with Pods that are paid contributors and volunteer contributors to support and helping things for other people that, you know, we are just aiming to help you get further. And if that means, oh, hey, Pods actually isn't a really great solution for you, try this ACF plugin or try this add-on, or whatever. And I think that is really what sets us apart is, is we're not really trying to sell ourselves, we're just trying to sell you on the right educated solution if at all possible. So if you're thinking about the differences between Pods and ACF, I would say like earlier I mentioned Pods is really content type centric. We're a data structure plugin. So you create data structures with Pods, and ACF up until about two months ago has been entirely custom field centric. So you're adding a custom field and you say, okay, where do you want the field? And you can say, well, I want it on this post type and this post type and this post type. And when you're trying to look at the big structure overall, like it's extremely difficult to know, okay, what is actually my data structure for my site? Like what fields does this post type actually have show me all those fields? And that way at attacking the problem is not really the way that Pods handles that. Pods, you start with your content type, what content type do you want to work with? And then you go from there and you say, what fields do you want? And so that just really sets it apart because for me, as a developer, that is how I think about data. I think of data as: you've got tables and you've got columns and that same kind of structure works even with meta. It's, it works that way in my mind and for a lot of people. And ACF sometimes can be cumbersome for data when you're working with meta. Sure. And there are some add-ons that allow you add custom tables and things. But Pods does have a first class feature that it treats, like I said earlier, we have certain features that are just first class citizens inside of Pods that do not really differ between content types. And so you can actually have a post type that has a table or a taxonomy term table that is, it mirrors the, the table that you would have for terms and taxonomies, but it stores just the custom fields that you want. So you would have the ability to have indexes and things that you want to be able to look up on and relationships that are very thoroughly comprehensive there. A solution, like if you're looking at ACF relationships, Pods, relationships give you a similar structure. Like ACF is like, do you want a dropdown? Do you want a radio? Do you want these types of relationships? And then you have to say, well, do you want a post list or you have to choose those things individually and Pods thinks of it again, like data structure. So we say, what kind of field do you want? Do you want a relationship? Okay, well choose your relationship. What do you wanna relate to? And then we say, okay, here are the options you have. You can have checkboxes, you can have radio list or whatever else you might want auto complete. A unique thing we have is list field. So you have a list view that allows you to add data from modals right within it. So that could be another post or another object or another pod of any kind. So it's very interesting to, to see those variations between ACF and Pods. And there are other plugins out there, like I believe Types was a kind of a bigger plugin out there for a while and I think they just kind of have been pulling back a little bit because of the block editor kind of changing the paradigm for them, but- Cory (00:12:38): Oh, we'll get to the block editor. Scott (00:12:39): There's different ways to approach it. I think that's just what sets Pods apart is that approach: data first. Phil (00:12:46): Yeah. The structure and data comes first. Cory and I talk about this in our meetings on a regular basis where, you know, you'll go down a rabbit hole of like maybe just creating a field with a dropdown and then you realize later on it would be way better if that was like a relationship to something else or a taxonomy and, and you're kind of retconning it and going back and redoing some work. So but maybe just cuz our brains are a little too ACF-ified, we start with that. Cory (00:13:10): Well, I don't know if it's, you know, ACF-specific per se. I think what I'm understanding, please correct me if I'm wrong, of course. I think what I'm understanding is that Pods is trying to get you to think about data structure first and using that abstracted structure first and ACF, it's not so much that it's making you do something different, but it's just since it was, you know, always custom field first and that was kind of it, it had us thinking in core WordPress terms of posts, and posts over here, taxonomies over here, you know, relationships are, well <laugh> actually something, you know, we, in episode, what was it, 24 of, of this show we had Fränk Klein on and we talked about one particular issue that often comes up with post relationship kind of stuff, right? Where, you know, you want to have some post meta in some way if you're using ACF or whatever where you have associated another post with this post. And then, you know, you want to then show all those posts on the front end, or more specifically you wanna query for those related posts. And it's the sort of thing where, you know, as theme developers, first and foremost here at an agency level you know, we're just kind of taking in these requirements for, you know, a website and like, oh, we just wanna show these related posts and, and we're kind of, you know, taking the path of least resistance usually where it's like, okay, ACF field, relationship, it stores a post id, and now we can query for those. Right? But, you know, we know, we know that like querying for post meta, doing meta queries is, is not very performant. And, you know, even the, the PHP code sniffer stuff for WordPress like, yells at you like, Hey, we've detected a query, a meta query here that's, you shouldn't be doing that <laugh>. So I'm curious if Pods work like differently under the hood where that's maybe less of a concern? Or is it still this sort of thing where we need to, or we should anyways be coming up with a solution on top of, you know, the post meta stuff? So we, we talked about shadow taxonomy concept with Fränk. So like, sure, you have this post type, but now you need to write or find some code or something to like, also whenever a post is created or deleted or updated or whatever, update a taxonomy with, you know, that's under the hood that you don't necessarily see, but then you can query against the taxonomy instead. Scott (00:16:09): Yeah. That's, so that's interesting. I think I've, I tackled that a few different ways in in the past and the way that Pods handles it, we have, we do have the table storage option. So you can choose to have your custom fields stored in its own custom table. Cory (00:16:27): Okay, wow! Scott (00:16:27): But it's not, right now, it's not queryable through a meta query call instead of WP Query. You would have to either add your own join with a WP Query pre_get_posts kind of thing, or you would call our api, which is very powerful. Our API itself that allows you to find records will do all the SQL for you, it'll optimize the joins so that when you're saying select these fields, these columns, whatever else you wanna select and you say fetch it by this and limit it by this number of, of values to return. And then also why don't you at the same time filter it? So filter it by this one key is this value, and you can do those things and you can provide it in the same exact syntax as WP Query query, however it will, it'll automatically convert it to an SQL query for you. Cory (00:17:21): I vote, I vote for that approach. Scott (00:17:22): It'll then build all the joints in that you need immediately, as you call it. So like, if you have relationships, this is where it becomes fantastic because relationships in querying, like I know that like when you're doing queries, you all you have is IDs and that's that sometimes it's not everything you want, sometimes you wanna be able to query a little little bit further down the rabbit hole. And so one of the cool things about the relationships that, that we've built in our API is you can traverse deeply. So you can say and I'll give an example here. You can say, I'm gonna query books and I wanna fetch all books that have an author whose favorite color is green. I can do that with one line of code. It, I don't have to worry about SQL, I don't, I can just provide it in a race and text like a meta query and it'll do it. I just say the relationship field name of book underscore author, and I use a traversal and I say dot, so book underscore author dot favorite underscore color. And it will do it automatically. It will know whether or not if I provided, like if favorite color is another post, it'll automatically know I'm meaning to select the index field, which is post underscore title or things like that. Or if it is a, like a custom list of just text values, it'll know that it's gonna reference that column. Or if it's a meta based pod, like if you've got multiple variations of a table based or a meta based pod, it does all of that smart thinking for you and builds that query automatically for you. So it's just very flexible when it comes to dealing with those type of data situations. I think that's why overall it makes it so it's easier so you don't have to worry about, well this is a little slow cause I'm using WP Query meta query and stuff like that. It just does the lifting for you, especially if you've got table storage used. Cory (00:19:18): I know you're not trying to sell us and get us to switch but you're doing a great job so far. I wonder is there some influence from Laravel there in that kind of like dots syntax kind of stuff and easy querying like you just described. Scott (00:19:41): I don't know if Pods predates Laravel or not. But I don't think that's where we got it. Like, this is one of the main features I was a proponent of. Like, I told Matt Gibbs like, Hey, we should add this. This is really- if you could do this, this would be crazy awesome. And then he was like, oh yeah, that actually does sound awesome. And I'm like, well, here's the code. And so I built all of the crazy logic for it and then I've expanded over time and it's just, it's a really cool one and I've always loved it. Cory (00:20:12): That sounds incredible. I'm gonna check this out. <Laugh> Scott (00:20:17): And I probably should also note that like, all this stuff is free, and this has been one of the features in Pods for a number of years. I'm surprised like ACF or other plugins just haven't like copied logic or figured it out how to make it happen because it's not extremely difficult to make it happen. It's just Pods, like I said earlier, like Pods is data centric. It starts the type level. So we have APIs to query data, whereas like ACF doesn't really have to do that. It doesn't really need APIs to query data, so it doesn't need APIs to query relationships, right. And things like that. And I think there's room for someone to build something like that. And I think I actually have seen an add-on for ACF that can do something like that with code. So that, that's pretty cool to see it happen. I'm just surprised it didn't happen sooner. <Laugh> Cory (00:21:06): Yeah. Interesting. Well, all right. I think that's enough about Pods, cuz I'm getting a little too excited over here. <Laugh>, but you know, related to that experience related to actually your entire kind of you know, career progression up to this point just seems to be, you know, helping people to customize and, you know, kind of give back to the WordPress core in a way that makes it more customizable. So let's talk about the main thing I'm interested in, which is the core Fields API proposal project. And I'll put a link to the GitHub in the show notes. I'll put a link to that. Check it out. I, well, I guess the most obvious place to start is: can you give us sort of like a, just an overview of what problem this Core Fields API thing is trying to solve? Scott (00:22:07): I think probably it's more important to me because I, in Pods I have to integrate with all the different screens inside of WordPress. I've got the Settings API, I've got user profile comment add and edit screens. The post editor, the block editor, like the classic editor and the block editor. I have to do both. We've got the term add form, which is different from the term edit form slightly. There is the media, and that also uses similar things to the classic post editor, but it also has a media modal for the library. So when you're actually opening up the modal that you see a different thing, that's a different place to integrate to right? <Laugh>. And then you've got blocks themselves, you want to go develop a block and add fields to it, like in the controls settings area for the, what they call the Inspector Control panel. That right there, adding things to that is pretty difficult. Like, there's so many of these areas, like the Customizer, even for the old Theme Customizer, if you remember that. Phil (00:23:10): Oh, yeah. Scott (00:23:11): All these things have different ways of doing it. Not a single one of those APIs is universal. You can use the classic editor and the post editor and the comment editor things in similar ways, but there's lots of legwork to kind of make it all work the same, there's no shared unified markup that's accessible. That's your job. All of this stuff you have to do. If you remember widgets, you know, way back when- Phil (00:23:44): It doesn't feel like that long ago. <Laugh>. Scott (00:23:47): It feels like it's long, long ago for me now. Cause I don't really mess with widgets anymore, but yeah. Widgets, when you created a widget, you had to output your own form markup there too. The entire form markup and handle your saving and everything else. And it just became one of those things where I had to add custom fields at agencies for different projects. And one of the agencies I worked at, they said: 'no, you can't actually like, create a library and reuse it on different projects. You have to do this by hand each time'. And I was like, no <laugh>, Cory (00:24:21): Did you quit? Scott (00:24:22): The first thing I did was like, make it, I made it anyways. I made the library anyways and I got the team on board to use it and we just made it work for our team. Whether or not the whole company adopted it, it was working for our team and there was a lot of great benefits to it. Scott (00:24:40): But I've built Fields APIs for all these different interfaces multiple times. And eventually I was like, you know what, what if I just took the dang time to <laugh> try to find a way to get WordPress core up to snuff here. Like what if we had one API to say, I wanna add a field or a group of fields and I wanna add it to this screen. And this is a field type of text. This is a field type of number and this is a field type of a dropdown or whatever that needed to be. What if we could simplify all these terms and the structures and the form markup, but still have some ability for you to customize whatever you want. You can go back to doing whatever you want, you can output, however, whatever field you'd like. But, but the bare minimum you could get is something that's accessible and that is easy to use across all, all of these different types of, of content and these screens. Scott (00:25:32): And it is 2023. WordPress started in 20- or 2003 somewhere around there. Yeah. Because we have a 20 year mark. Phil (00:25:44): I've got the shirt on, yeah. Cory (00:25:45): 20th year. Scott (00:25:46): So 20 years. And we don't have a Fields API inside of WordPress. And someone could say that. Yeah. But we had a Setting API that was almost like a Fields API, or we had a Customizer API ,or we had all these different other APIs, but every time we built one, it was like another separate thing that didn't talk to the other. And they weren't first class. Like, this is a way to interact with fields and that's how you're gonna do it inside of WordPress. So this <laugh> project—wound you up this whole way—this project is the Fields API project for WordPress, and it aims to be that unifying API. We kicked it off back around 2015 or so, and we tried to get off the ground. Scott (00:26:30): I built, alongside a couple of people, we built multiple implementations for WordPress. Almost all those areas I mentioned we had a Fields API coverage for, so it would actually, if it was Settings API integration or whatever, it would talk through the backend and make sure the Settings API was doing what it needed to do. And it was working alongside of the Fields API. And we had all that stuff done. And, and this is around the time when REST API and even blocks themselves were kind of just starting to be birthed. We had I don't remember if you remember Calypso, if that's the word. Phil (00:27:08): Oh yeah. Yep. Scott (00:27:08): Yeah. It was like, Hey, we might rebuild the whole admin interface for WordPress. And then it never really happened for WordPress core. Phil (00:27:15): There was a desktop app for a moment there, <laugh>. Scott (00:27:18): Yeah, there was lots of really exciting things happening, but this didn't get anyone excited. It didn't bring anything to the end users. It wasn't something, oh look, this brand new thing, this new feature we just shipped. It was developer centric. And I think it just became- it enabled lots of things. Like it could have enabled so many more things with the REST API or so many more things with even WP-CLI and apps and Calypso at the time, and block editor and all sorts of things. If you wanted to add custom fields, those things would've been easy to implement because a Fields API is agnostic to the screens. And that eventually kind of wore me out. I just wasn't able to get it through the finish line and I said, Hey, someone step in and if you take it on, I will help you. But no one, no one stepped in. Phil (00:28:10): Can I ask, you know, as someone who's never contributed to Core or like directly I, maybe I can ask just like a sort of unfair question. Cause, I remember when like you know, just about ideas happening in the WordPress sphere in the community and in core, and then them kind of getting dropped. Cause I remember very much when Customizer came out and people were excited about it initially, and it felt like this way to replace custom settings, panels for themes. And it felt like it was just gonna keep getting better and better. And it kind of just felt like it stalled out really early on in its development. And it only had a handful of like, core fields that you could do. And then there was like a tutorial and basically, here's how you can implement select2.js inside of it. And it kind of just ended there. And it just felt like, I mean, whoever was working on it just seemed to like disappear. And, you know, it just is stagnant. But it seems like that has you know, the same thing with the Calypso and et cetera, et cetera. It just seems like that happened, has happened over and over for the last decade or so. And I'm just curious, like, how does like something like that happen? Like, as someone who has only seen it from, I've never seen behind the scenes. Scott (00:29:13): I think perhaps, and I can't speak for the people involved there, but I think perhaps it's one of those cases where there could be a number of reasons. One of which the things that they're working on is dictated by the company they're working at. So maybe the company has new shifting focus. Like Matt Gibbs, when he started Pods his company he was working at, they were, they needed a plugin like that. And eventually they didn't need it anymore. And so he didn't have the time to work on it, and that meant he'd have to work on it in his free time. And a lot of people treat their free time a different way than I do, and they actually make room for things and they're like, no, I don't wanna do 'work work' for my free time. No thanks. Cory (00:29:51): Oh, is that an option? Scott (00:29:52): <Laugh> But I think that's, I think that's possible that like some of these things became kind of superseded by other things. Like the REST API, the Customizer needed more things to be able to make it get to the next level. Yeah. And one of the things was having a better REST API to work with and then eventually, like we need to make some of these things more dynamic. Like, I wanna be able to edit content in the Customizer as well as editing settings. And well, what if we just took a pause here and rethought everything and we built something from the ground up and that became the block editor. Cory (00:30:27): Cue Gutenberg. Phil (00:30:28): It's just so interesting cuz I just feel like there was so much apprehension towards the REST API when it was originally being developed. Like, I mean, it didn't even almost get merged core for the longest time. And now it, like, now it powers everything that WordPress is currently doing and, you know, into forever. So it's just so interesting that, cause I remember the customer coming way before the REST API was like, you know, we had some small JavaScript stuff that you could like, talk to, but it wasn't anything close to what it's, you know, become. So, I don't know. That's just, I think yeah, just where your priorities lie in your free time. Definitely. Unfortunately, <laugh> yeah. Is the trajectory of WordPress in a lot of ways, at least in the past decade, it seems like maybe automatic and a handful of other companies have really organized to maybe try to rectify that situation. Scott (00:31:14): Yeah, I think they've been able to shift the focus a bit. And that's kind of where I was kind of reignited. So like, that was 2017 or so when we kind of were like, Hey, let's stop. And then just this past year a couple of people were saying, Hey, let's try to fix some accessibility things, but while we're in here, why don't we make it easier to add accessible fields in the setting screens? Cory (00:31:41): Hey, we kind of did that! <Laugh>, Scott (00:31:43): You're like, Hey, we could do that. And that's where we're at now. We're in the process of kind of rethinking everything. We're kind of focusing, instead of me building all these implementations for all the different screens all at once we're just focusing on the setting screen. But before we're doing any of that, we're doing research. Like where has things, where have things gone since 2017 with all the different plug-ins out there that have their own Fields API? Have they found any better ways to structure things? And found some good feedback from a few people, like from the people at Give and how they structure their, their markup and forms separate from their actual fields API configurations and that makes some solid sense and gives us some good ideas for moving forward. But we're working towards kind of getting that ready for this Community Summit this summer. And, and being ready at WordCamp US to kind of push it off the ground. Cory (00:32:36): I'm gonna be there, I think; WordCamp US. Scott (00:32:39): You are? That's cool. Cory (00:32:40): Finally decided to go to one. I've never been to one before. Scott (00:32:44): I just got my flight and hotel booked today! So I'll see you there. Cory (00:32:48): Speaking of the Customizer, I know there was some, there was some pushback too at a certain point because the, you know, the theme repository folks decided that, you know, it was required to use the Customizer for themes as opposed to all these, you know, custom settings pages. And there's a lot of pushback about that. This Core Fields API concept though seems, while you know, the code itself that I was looking at, kind of, it kind of hearkens back, I think to how the Customizer was meant to be used or whatever. But it doesn't look like: you must, you must do this. It looks like a 'here is for your convenience', but like, less about how you add fields and more about like, you know, here we've unified all of these ways to integrate with all these screens. Cory (00:33:56): Like that's the exciting part to me. And, you know, before I heard about the Core, you know, or when I first heard about the, the Core Fields API project, which was way later than it should have been, honestly, seemingly, like, I feel like I only really heard about it this year when you've kind of started up the effort again. You know, it definitely saddens me that there was no one that seemed to be excited about that; about really what's like a question of like developer experience, you know, not just for like theme and plug-in developers, but also core developers as well. Right? You know, so it kind of, it seems at least from the outside at least that maybe WordPress has a little bit of a problem with the whole dog food concept. Maybe I'm way off base here.<laugh>. Phil (00:34:53): No, I definitely do feel that way sometimes when I'm in the Git Issues for Gutenberg. So, yeah. Cory (00:34:57): But like, you know, if you're creating new things each place for use inside core and, and maybe not all of those APIs are necessarily accessible to, you know, outside of core or whatever, you know, instead of creating a unified system like that and building upon that, you know, it seems like it would certainly make everyone's lives easier. But, but I don't know what the logistics or the politics are that, you know, that kind of, you know, made that in, you know, initial effort kind of peter off like that. Unfortunately. I don't know. Do you have a take on this? Scott (00:35:38): So I'm very, very much excited about abstraction. That's why Fields API is such a big deal for me. And the cool part about the initial implementation I did back in 2017 or whatever was I didn't just implement the Fields API. I actually dogfooded it for the interfaces. So all the user profile fields, all the setting screens for every settings screen inside of WordPress that came with it, all of the post editor things that we could every much everything that we could get into the Fields API we did, right? Because those were the things that we knew would inform us on what field types we needed, for sure, the base ones for what WordPress needs. And then allowed us to say, here's the proof of concept here is the same screen that is inside of WordPress right now, but powered by the Fields API. You wouldn't know it cause it looks the same. And that's important, but it also is compatible. It's a hundred percent compatible with the way that you might've used hooks to add extra fields, but then you could use your Fields API to just give it an array of information and have it do it for you. <laugh>, feed the children, please. Cory (00:36:44): Yeah, I mean, one of the, the complaints of I had for a long time as primarily a theme developer is like, you know, setting the Customizer aside here, <laugh> for a second, cuz obviously that was one of the proposed solutions. But like, why is it so difficult to add things to the backend, the dashboard, the admin of WordPress, and have it look the same as the rest of WordPress? It's never been, it's never felt very easy to accomplish that unless you go, you know, crawling through the WordPress source code to find certain class names or whatever to stick on fields. But like- Phil (00:37:29): I feel like that was my old school way of creating my own settings pages, was just go through core, figure out how they did it, try to replicate it as closely as possible. But if you install, you know, five different plugins that have their own admin panels, they all look different. And even worse, sometimes they're like, you know, loading, you know, some kind of CSS framework on top of it, maybe even globally. And it's just causing style issues. Cory (00:37:49): It makes me wonder if like, you know, a certain point that you can look back to at, you know, just plugin settings, stuff in general that was mostly like, okay, we're trying to fit in with WordPress. However, whatever convoluted way they had to do that, it seemed like an approach until kind of semi-recently where everyone's just, I feel gone a little nuts with, you know, okay, we're just, we're branding everything, you know, all of our settings pages and everything. This is branded now, you know, it looks and feels nothing like the rest of WordPress, but deal with it because, you know, I have to wonder if that's because those APIs for just creating, you know, additional settings, pages and stuff that look and feel the same way and have the same fields, it just doesn't exist. Phil (00:38:41): I feel like it has to be the reason. Yeah. Like that is a hundred percent the reason why we get those options. And this is, I'm assuming a solution to all that. Hopefully Scott (00:38:49): I've seen a lot of plugins that will decide that they're- well WordPress interfaces aren't always the best looking. And some plug-in shops are like, Hey, I can make something look better than that. Let's make ours look good. And everyone makes theirs look good. The way that they want to make their own solutions look good. And then so you've got different interfaces. They've, I've seen most of these plugins have their own APIs because they're not writing all this markup manually. Right? Right. They've got their own Fields API. There's Fields API up the wazoo across the plug-in repository, like hundreds of plugins just have their own Fields APIs and then hundreds more, maybe thousands more have some sort of bare bones kind of API on it. And these types of things splinter the, the interfaces for WordPress experiences. And I find that one of the things that I try to do with Pods itself is like, how can I find ways to make it look as close to WordPress as possible? Scott (00:39:48): Not really deviating it too much, if at all. Using core classes. Like I said, I love abstracting. So like, I built whole abstractions to create these screens. So we have a, we have the ability to create custom content types that are their own tables. So this is outside of WordPress itself, but I bring them into WordPress with the same table structures. So you can have list tables and forms that look like the post editor and everything else, or maybe make it look at the setting screen and all that stuff is abstracted. So I just merely say this and this and it does all the stuff for me. I keep the markup updated so it's compatible for WordPress whatever interfaces that they're doing. And it's, it's done. But that process is very difficult cuz I'm very, very much privileged in the fact that I know the history of these interfaces. Scott (00:40:37): I know very easily where to get the classes and how the things will work and different screens in different contexts. And I now have all the code that lets me do all this stuff and developers getting out there, they're building a new plugin they need to build setting screen. They don't have that, they don't have a easy library to use. They could fork another plugin and say, Hey, I wanna copy their setting screen or whatever and do it that way. But it's very difficult. It's kind of a big lift when you wanna do something the right way. Phil (00:41:06): The WordPress way. Yeah, for sure. Cory (00:41:08): This reminds me of a conversation we had with JJJ [John James Jacoby] like two years ago about the the WP List class and how it's technically a private class that you technically shouldn't be using directly, but we all do it. Scott (00:41:23): The the WP List Table class. Yeah. <laugh>, I can confirm that. It definitely doesn't feel like it's like, oh yeah, this is easy. Phil (00:41:33): Yeah, sorry. I was just gonna say, you know, just being abstracted and, you know, maybe lots of people aren't saying this too much out loud, but there's definitely been glimpses of the future of the WordPress admin area you know, going towards a more JavaScript-centric experience. You know, we've already seen this in the site editor, but we've seen glimpses of what the settings panel could look like in the future. You know, this API having abstraction from the start, how do you see integrating with those maybe Inspector Control components that we already have, like being able to grab those and just being able to plop those into a page. Is, is that something that's already in the mix? You're already thinking about that? Like how how does something like that work with the future of WordPress? Yeah. Seeing how you seem, you definitely know the, the past, maybe you can see into the future. Scott (00:42:20): Well, if I'm looking at future, I definitely, and that's one of the things I'm kind of known for with some of my developer friends. Like, I'll be building something and they're like, Hey, how do I do this? And I say, oh, there's a hook for that. I added a hook like five years ago. Sure. Because I knew one day you're gonna ask me for this <laugh>. I knew it. But, but yeah. So this Fields API, if we get this this year, like if we can get it started and actually pick up steam this year, I think it's in a good spot because we do have a lot of things coming down the pike. We want to improve the user profile screens. We wanna improve the setting screen refactor. We, clean it up, UI and everything else. Do all these different things. Scott (00:43:00): And eventually the term screen needs love to and so does the common editor and the media library. Everything just needs more love of course to bring it up to snuff. The block editor's been getting all the love and sometimes all the hate <laugh> it is what it is. But I've been thinking about that. So the Fields API itself, if we had that in there immediately, when I switch over the interface for Core to say user profile should look like this. We're not using tables anymore. We're using, you know, whatever lists of fields and however you wanna display. Phil (00:43:36): Sure, yeah. Scott (00:43:37): We have the structure of the content, the data structure, the configurations, the Fields API is agnostic to the markup. So the markup itself implementing the table of of rows and fields with columns and and such for labels and field values and inputs and stuff. All that stuff is separate. So you're not locked. Immediately, all the plugins that have used Fields API, even core itself, will automatically transpose. There is no extra work. That's the cool part. Phil (00:44:07): That's exactly what I wanted to hear. Yeah. <laugh>, Scott (00:44:08): That's what we want. Phil (00:44:10): That's exactly what I wanted to hear. So that's, cuz that's like, it just feels so weird to still be able to have to set the homepage from the settings reading tab and it's just like one day, I know that's just gonna go away, but I don't want it rewritten ad hoc like it was the first time around. And it's just like, like if we could just have the design team figure out the vision and have that already be abstracted out, and then some other team on the front end can just go in and just tap right into that. It just seem, it seems like a, what a seamless way to like, make that happen without having to make it some kind of crazy engine work that you'd have to do on core to make that happen. Because we hear about, you know, I just going into the, you know, issues for WordPress and whatnot, you'll see like, oh well, you know, we just don't have this in the API yet, so we can't, like, you know, setting the favicon is still an issue right now. We still have to go touch the old PHP- Cory (00:44:57): Send you back to the Customizer. Phil (00:44:59): Yeah, yeah. It's just not, yeah, it's just not extended into the rest API yet. And it's, you know, that's just something that's been on the table for, you know, five years at this point. Cory (00:45:07): So, and speaking of the REST API, I suppose we could go there. I don't precisely know where the boundaries of the Core Fields API project lie. I kind of understand this idea of, you know, abstract data structures and I understand the, you know, going through the, you know, settings pages and like transforming them to use that instead of their essentially ad hoc approach to just, this is a different page than this page and this page. Is the REST API also part of this effort where it's just another interface that you have to create, you know, certain endpoints or whatever for, is there anything in there right now that, that kind of integrates with the REST API or is that like a separate effort? Scott (00:46:01): So the beautiful part about the Fields API itself is that if you're adding fields to like a setting screen, for instance, the way it is right now, we kind of have everything inside of the setting screen itself. But when you get it into the Fields API configurations, those are abstracted outside of the screen context itself. So you can say, I wanna know what the fields are for the setting screen for general and get me the configurations of those and tell me what kind of fields those are and what the field set is and all the sorts of things. You can get that stuff from any screen you want, you'd call it from PHP, right? And at that point, you call it, you can say, "I want to expose this configuration to the REST API" and now follow me on this magical train here, <laugh>. Scott (00:46:44): We take this train, this rest API train, we say, Hey, here's my configuration for my fields. Now I can build whatever interface I want for WordPress. Now I can say, oh, hey, I have a better idea for an interface. Here's how it looks and it would actually works. Or Hey, I wanna build an iOS app or a desktop app or iPad app Android app that actually does not just embed iframes things. It does not just embed web views and stuff. It embeds nothing other than the fact that it's already pulled the configuration and it knows the fields you're working with for the general screen for settings. It knows all these different things from from user profile and all those other areas that we might build into the Fields API. So that is the real power, is the fact that you can then take these fields configurations, not just revamp those screens, but be able to utilize that data in other contexts. Scott (00:47:34): Right now it's all hard coded. Like you have to know what those settings fields are and you know what the names of 'em are and you then have to figure, okay, well I know the title is always gonna be a text field Okay, and go on and go on. But other plug-ins, those plug-ins could expose so many other variations to that. I know there are plugins that are adding to the general and, and reading in other writing screens like Jetpack itself. Yeah. Jetpack could expose its own Fields API to those things. And then magically Jetpack without any other effort on its own is now exposed to these other apps who then say, oh, I know this other setting field is here. I'll show it. It knows it. Like that's the cool part. Cory (00:48:12): Yeah, that's amazing. So, then I guess getting back to the initial question, is this within the purview of the project? Or maybe that's the wrong way to put it. Do you feel like you can't just stop at the API itself in, you know, in PHP, right? But you have to then also do all the work to get it into these various interfaces, like you said already. The settings pages is one interface, the REST API is another interface. Do you think that you would have to then do all that work as well just to, for it to be accepted as like, oh, okay, now we get it and then bring it into Core? Or is there a chance that you can- Scott (00:48:56): I don't think it's required. I don't think it's gonna be one of those things where Fields API will get only merged if we have REST API or things like that. I think it's at the moment with WordPress core, it's like, if I can get just my foot in the door with Fields API, we can start building off of it right from there. Like, I'll be very happy to get the basic core configurations added for the setting screens and then exposing it to REST API. That'll be a whole nother task because everyone's gonna have their own opinions. Like, well, who should have access to configurations? Who should know what the configurations are? And then how do we confirm that they have access and how do we know which fields to show and which contexts and various other things that will have to be thought out and where, where is it gonna live? Scott (00:49:39): Is it living in the settings REST API or is it living in its own Fields API endpoint namespace, like where, where is- all that stuff has to be figured out and it's gonna be one of those very opinionated like battles to try to figure out, you know, where is this gonna end up? But if we just like focus on like, let's get the settings screen done, this could really give us that in, and then we can expand outward from there. Cause I don't really see there's any boundaries in this project. I don't really see that we'll stop at some point at just settings or profiles. I think there's so much more to do even after we're done here. It's like proponent inside of the iOS, WordPress app, Hey, let's start calling the field API configurations. Now if we detect them, call 'em, now show, show the screen. This is how we want them in a native app. Like, there's so many things we can do and not just stopping at the implementation of API itself. Cory (00:50:30): So I think my last kind of big question about about the core Fields's API project as a sort of boundless effort, <laugh> here you know, this is all sort of behind the scenes stuff and, and maybe not necessarily something that your average theme developer would need to, you know, or hopefully they wouldn't really need to interface with it directly because whatever, you know, custom field, custom post type system framework plugin that they're working with would just be handling this, you know, connection to this, a API for them. And it's just a unified thing. But like, the reason that we reach for these plugins in the first place is not just an easy way to show fields, but but specific kinds of fields, right? So like, you know, more often than not, we're not necessarily looking specifically for just a number or a string text, whatever field, like, or even a dropdown. Cory (00:51:34): Yeah. Like, you know, some of the things that we reach for most often, you know, just using ACF or whatever is like the idea of the relationship, right? Or like, I want a field that gets these posts or whatever. I need a field that is not just text, but is specifically a URL field. And we don't want to implement that validation for whether it's URL or not, whether it's an email or whatever. Like every single darn time, you know, we need to just add a field. Is that under the purview of a Core Fields api or is that under the purview of the plugins that are, you know, on top of the core fields api. Phil (00:52:20): Or even like the UI part of that abstraction? Scott (00:52:24): So there's two components. There's the ui and then there's validation. And wordpress query already itself has a number of validation functions, like is email and there's like, I think there's a URL one as well. There's, validation functions inside of WordPress core that we could utilize, that we can say, Hey, if you want to implement a URL field, if we're not already implementing one this is what you do. And there's some example like, here, just call this callback for validation. I think that the field API itself will be thoroughly hooked so that you can allow yourself to add custom validations. Like personally, if I am building fields into my api, I want to be able to say, you know, this one field has a very unique validation, so I wanna be able to say this is the field validation to use or override the core validation to say, I want it to do this instead, or whatever. Scott (00:53:15): There's lots of things we could do there. So that's the good news is the validations would be first class citizens in this approach. They would be part of the API itself. If there's not ones for a specific use case, those can be added by plugins because plugins can extend, because it is hooked, plugins can extend the field CPI with new content types and new structures for the types of data to store and to register in the markup itself. This hearkens back to a earlier thing you mentioned about the, the Inspector Controls panel in the block editor. When you've, when you're editing a block and you see that panel on the right side or left side, depending on how you have your screen set up those fields are in a section so they're already in groups of fields. Scott (00:54:05): And if you think of that paradigm as saying, I wanna register a section, I have a field, here's a label, here's a text, here's the type of input I want, blah, blah, blah, blah, blah. You, you can create these structures with the Fields API. You can say, for my block, I wanna register inspector controls for my block, and here is the sections of fields I want. And it'll do that for you. And those would then map over to the correct react components that will work in the block editor. But in the future, if we ever want to bring those into like the setting screen, whatever, they could also use those same React components to, to output those and, and Reactify the whole screens and everything. But those fields themselves would all get that power of having the ability to do custom validations, custom overrides. Scott (00:54:51): If you want your own output for those markup for, for the block editor inspector controls to do your own different component there or whatever. You have the flexibility to do that. So I think if we get this Fields API in place, we'll see plugins that are almost like, if you remember when block editor came out, there were a lot of kind of little, these 15, 20 different block plugins out there that you can get a bunch of different libraries of plugin or blocks out there. So you can say, oh, this one has a bunch of little gallery blocks. Okay, cool. Well you're gonna find that for Fields API at some point where someone's going to say, expand it with more field types or whatever. Or, almost immediately after we finish, we'll be like, Hey, we should implement these other field types. Try these out and we'll get people to test them and everything will be gravy and everything else. Yeah. That, that's the hope. Cory (00:55:39): So how can people get involved? Are you looking for people to, to get involved with this project? Scott (00:55:46): So you stumbled upon a secret, the secret code for the day is: Yes. Please get involved. We really do want help and it's, something I'm stepping up this summer now that my kids are outta school and there's less things going on, I am focused on getting this Fields API project to the next level so that we are ready. We have a prototype kind of started up. We have the scoping finished, all those things. We're hoping to wrap up by the time WordCamp US comes around so we can then talk about it thoroughly in the community summit and rub noses and shake hands hopefully we'll do some back backroom deals. Let's get this thing going. Team Core Fields all the way. But if you wanted to get in touch with that team; that's probably what the question you're about to ask. You go into the WordPress Slack, it is the core-fields Slack channel, and that is where we're all just kind of lurking and working on things as time allows. Cory (00:56:44): Okay. There you go. Get in the Slack people. Let's get this. Let's, let's do this. I'm pumped. <Laugh>, Scott (00:56:53): Please feed the children. Phil (00:56:55): This is a big initiative and it would definitely ease a lot of the growing pains that WordPress is going through right now, I think in the long term. I think, worth the effort. Cory (00:57:02): I think we just, we just need some dog food. We just need to eat our dog food. <Laugh>. Scott (00:57:08): It's time! Cory (00:57:10): So, yeah, I don't mean to end on this note necessarily, bringing it back around to, you know to ACF, but I just recently saw on Twitter that Elliot Condon is that how you pronounce his name? I've never said it out loud. <Laugh> Elliot of ACF you know, the original developer of ACF announced that he wants to get back into doing WordPress stuff, whatever that is. I'll drop a link to the tweet. So, you know I thought, and I actually responded to the tweet, like, Hey, check out this Core API Fields project. I don't know if you saw it; my first question is there a, is there a secret rivalry there between the, you know, ACF originator and Pods Framework, <laugh>, and second, if there, you know, isn't, or maybe it's a friendly one you know, what is, you know, do you think that he might have some insight or whatever that the Core Fields API project could use? Maybe you have enough, I mean, you probably have enough, honestly, <laugh> Insight. Scott (00:58:28): Well, well, Elliot in my relationship is the source of much WP drama <laugh> jk. No, no, no. We're actually really, really tight. I mean, he lives like across the world, so I don't really see him <laugh>, but we've interfaced quite a lot, a lot more than you think rivals would. We've emailed and DM'd and everything. I think we even one point met online for a call or something, and we've talked about Pods things, we've talked about ACF things, we've talked about other things, and sometimes I have bug fixes for him. Sometimes I'm saying, Hey, I found a security thing in this other plugin, I noticed it in yours, like, here, here's a heads up, or whatever. And we've always worked really well together in terms of that. I have known that in the past he wasn't, he didn't have a lot of time to do WordPress core contribution stuff. Scott (00:59:19): And I know in the past he's been with Fields API back in 2017, he, he said, yeah, sure if you do Fields API, I would be happy to try to figure out how to implement it with ACF. But he didn't want to contribute to it. And maybe that's changed. Maybe there's a way we can get him on board to be another big heavy hitter cuz we could use additional help. Even just people saying, yes, putting my weight behind it, let's do this. Let's you tell me what you need to do and I'll see if I can figure out how to help you do that. I would love to work with Elliot on this and and have a pretty cool collab on this. That would be the best case for me. Cory (00:59:58): All right. Well you heard it, Elliot, get involved <laugh> Scott (01:00:01): <Laugh>. Well, I'll message him right now. You tweeted him. I'm gonna DM him and be like, Hey Elliot, remember me <laugh>, I'm so glad you're back. Can you gimme all your time now? I heard you're looking for a small project Cory (01:00:16): Just a, just a tiny, just a just a morsel <laugh>. Well, speaking of time, I think that's just about all the time we have today. I'm very grateful that you were able to join us and talk about this really exciting thing that should excite more people about the WordPress core project certainly excites me. And I'm, I mean, my contributions are very- I'm not in WordPress core much at all. But just looking in from the outside as a theme and plugin developer, it feels so obvious. It feels so obvious. And it's just a shame that like, it's taken so long to get to this point. So I'm a hundred percent behind you and, you know, who knows, maybe I'll jump in the slack. I can't promise <laugh>, I can't promise anything, but Phil (01:01:03): I already booted up my Slack for the first time since 2018. So <laugh>. Cory (01:01:06): But I'm definitely gonna be following along at minimum and hyping it every chance I get. So thank you very much. Scott (01:01:13): Well, that'd be awesome. Thank you so much. Cory (01:01:16): See you at WordCamp US! Scott (01:01:18): All right, see you there buddy! Cory (01:01:24): That's all for this episode. Thanks Scott, for being on the show. I really wanna see the Core Fields API in Core, and if you feel the same, head over to the core-fields channel in the making WordPress Slack. Follow Scott on mastodon @[email protected] and on Twitter at @scottkclark. Check the episode description for links we mentioned in the show. In particular, pods.io and skc.dev. As always, don't forget to send your questions, thoughts, and fan mail to [email protected]. You can also find us on Twitter, Instagram, and TikTok as InTheLoop_WP. If you're interested in having a WordPress website custom built, or you want to join a team that does that, head over to our site blackbird.digital and drop us a line. Thanks for listening to In The Loop. See you next time.
