EP443 – WordPress Fields API with Scott Kingsley Clark

[00:00:00] Jason Tucker: 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.

[00:00:30] Jason Cosper: 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

[00:00:41] Jason Tucker: It sure did.

[00:00:43] Jason Cosper: you. You texted me about this earlier and said it would just drop right

[00:00:48] Jason Tucker: it would just drop.

[00:00:50] Jason Cosper: Oh,

[00:00:51] Jason Tucker: 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.

[00:01:07] A p i speaking of which

[00:01:09] Jason Cosper: yeah.

[00:01:10] Jason Tucker: we have Scott on the show. Hey, Scott, how you doing?

[00:01:14] Scott Kingsley Clark: Hello. I’m doing pretty well. Yeah.

[00:01:16] Jason Tucker: 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.

[00:01:50] Scott Kingsley Clark: That’s

[00:01:50] what do you got going on with this? what’s actually happening here?

[00:01:54] The project for the Fields API just got rebooted. It was initially off in, probably 2000. Looking at my notes here, 2000, it’s been four, four years since we did Fields API stuff. So this has been a project that I’ve always been very passionate about. I’m,I’ve found my niche in WordPress, which is like, how do I improve things for people that are building things that I build?

[00:02:18] Scott Kingsley Clark: 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.

[00:02:34] and so the Fields API was birthed many years ago now, back in, the elder days. I don’t have a, I don’t have a. Day , but, but it was 2000 and. 13, 14, somewhere around there. And we all got together, us like developers working with WordPress and trying to figure out what we could do to improve things within WordPress because all of us were building this, these giant libraries, these sets of functions and classes and UI screens and everything else to build the same exact.

[00:03:09] Scott Kingsley Clark: 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.

[00:03:22] And we were like, Hey, what if we just generalized everything and got all the developers together? So we got a bunch of people together, we grouped out everything, all the ideas together, tried to figure out, okay, what makes sense? What library looks better and what structures should we use? And we went through three or four iterations of that.

[00:03:39] And then at the very end of it, it was just not really picked up. It didn’t pick up the steam that we had hoped. Was in part. Probably because two other things came out that point in time. The rest a p was one of the first things that kind of was like, they’re focused on the West, WP c i, things like that.

[00:03:57] And now we’re not really able to get Hey, we need to build P too. We couldn’t get that over the little hill there. And then right after that was of course Gutenberg block editor stuff. So that then was. I can’t get any attention now. This is it. Like everyone’s focused on this and our primary focus was like, oh, meta boxes.

[00:04:17] So we had to do a couple sidesteps and then ultimately we had, I, as a leader of the project, I just couldn’t continue. I needed someone else with passion to, to carry the torch and I would support them, but, I couldn’t find anyone to do that. And so four years later now, after that, stopped, Accessibility team came up with, needs to address the setting screen and use your profile screens.

[00:04:41] And someone mentioned, Hey, you should talk to Scott. And so they talked to me and it turned out I remembered the passion in my heart and the fire that was burning deep inside of this chasm. And I realized that if we approach this same type of need from the accessibility, Glass, you put your accessibility glasses on, pun intended.

[00:05:06] I think that you would in involve more people, more shareholders, more contributors instead of core contributor, core, development and make them see that, hey, yeah, the field is one thing, but also, hey, you know what, we can uniformly, improve all of those various screens, in an accessible way at the same time.

[00:05:28] Scott Kingsley Clark: 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.

[00:05:49] what this enormous structure of WordPress is. Describe it in the same exact language that can then be extended by plugins to say, oh, I want a field here. I want a field here. I want to take this field off. I want to, move this field to another screen. , all sorts of things become possible because you’ve got a configuration that is not just mark markup that’s been put into a PHP file that submits to a form that gets processed through a function.

[00:06:15] Scott Kingsley Clark: 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.

[00:06:27] Jason Tucker: 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.

[00:06:54] it’s all still the same stuff. You all have crud still going on here. you’re creating stuff, you’re reading stuff, you’re updating stuff, you’re deleting stuff, but. But you’re gonna do it a little bit different so that way we can all kind of work together. Does that also mean that by doing this, that you can essentially go from one plugin to the next and still be able to do the same type of functionality?

[00:07:18] Jason Tucker: Is that, is that one of the, one of the benefits here?

[00:07:22] Scott Kingsley Clark: 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.

[00:07:44] Maybe that’s unique for their projects, but the overall API that everyone is using as a foundation, a real foundation to all these plug-ins, potentially they can take away. This big part of their plugin that managed these configurations, if they even had one. some just have a filter, an array of values and a filter, and then you then output the things that are on the screen.

[00:08:06] So there’s, that takes that away and puts it into this WordPress course side, and now you have. One benefit being another plugin can say, Hey, I wanna integrate with this plugin. I wanna go ahead and add fields to the pod screen here. The settings screen for pods or the setting screens for a c f, or whatever.

[00:08:24] if we are all using the same configuration logic, we could potentially allow. More integrations with our own projects. So there’s one major benefit. The second benefit is the people that are using these plugins that say, I wanna switch from ACF to pods, or I wanna switch from pods to types, or I wanna switch from types to whatever.

[00:08:43] there’s numerous plugins out there. If you go to compare c K, or sorry, compare wp.com/ck, you’ll see a big spreadsheet of all the different options out there, which is. in itself, just an enormous undertaking that we were able to put this thing together. But there’s so many plug-in options out there.

[00:09:02] Scott Kingsley Clark: 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.

[00:09:25] And now when you switch from a c f to another plugin, you’ll have the same hopeful experience from. plugin into the next. And that doesn’t mean that I can just turn off one plugin and turn on the next, there’s gonna be a process because every plugin will still, like a lot of these plugins are maintaining configurations from the database.

[00:09:48] So someone goes through the screen in the admin area and they add a field and it has to save it to the database to know that the configuration is there. And then the plugin tells the fields api, oh, hey, I have a field that I registered here. This is where it goes. And so there’s still gonna be some sort of migration step from that aspect because I don’t think we can approach database stuff.

[00:10:08] I think that would be, really difficult to throw that into WordPress core at this point. if we can keep it focused,and maybe build from there. if something becomes unnecessary thing, but. I think that’s the real benefit is this foundation we can all agree on and say, yes, we all need this.

[00:10:25] Let’s at least use the same foundation so then everyone can be able to integrate with each other and I can integrate with CORE very easily, just as easily as someone else can integrate with my setting screens.

[00:10:37] Jason Cosper: 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.

[00:11:07] Underlying way that WordPress works, the, things that, we could potentially return, if there is a standardized fields, a p i in the rest, a p i in Gutenberg in all of these things. and really. . it,it reminds me a bit of, for these kind of,custom metal box,the pods, a, c, F, et cetera is, really.

[00:11:33] it’s almost like another Gutenberg where you had all these page builders doing their thing and it’s okay, now we have a standardized way inside core. And you look at a company like, brainstorm force, who built the ultimate add-ons for Beaver Builder and Elementor. And, they did, basically like the same thing and brought.

[00:11:57] their ultimate add-ons. I think they renamed it Spectra or something like that, for Gutenberg, but they were just like, Hey, this stuff that we’re doing in all these different page builders, let’s just consolidate that and bring it into like the way forward. . So it, I think it’s a really,radical thing that, needs to be done.

[00:12:18] Jason Cosper: 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

[00:12:28] Jason Tucker: Yep. Same.

[00:12:30] I think that this needed to be done initially, and I wish, and I understand why, but I wish you didn’t like, have to go through the whole, like losing your passion for it.

[00:12:41] Scott Kingsley Clark: 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.

[00:13:07] And that would allow you to do the things that you would need these plugins for to do more unified things like, you can register with a cf, with code php, Jason files and stuff like that. You can do those sorts of things and interact with not just setting screens, post types, taxonomies, users, everything just like pods.

[00:13:26] And so that’s unified experience and that is why a lot of developers prefer a c f is cuz I can do things in one place. I don’t have to do in a bunch of different ways. I don’t have to remember all these different APIs. , obviously there is UI in user experience benefits to using something like a c f or pods, to manage those things or to use it as the API that you drive your site with.

[00:13:46] But I think that the point that Corey made there about what if they tried to implement this fields into their plugin, what benefits does it give them beyond the open doors that they leave for people that are using their plugins to leave them? I think. . I personally feel obviously that, I’m selfish because as a developer of pods, I always recommend other solutions if there’s a better solution.

[00:14:12] obviously we’re a free plugin, so you can go get a c f. Sure. I really would love you to get a c f if that fits what you want or types or whatever else. But a lot of people come to pods. they’ll throw us a use case and say, we wanna do this and this. I’m like, you can do this right now, but you’re gonna have to develop a lot of code.

[00:14:27] if you wanna do this really cool thing on your site that’s, membership directory that has all these search and filter and faceting and stuff. Or you can use these off the shelf plugins and then customize it just a little bit. And so we can recommend people to the different needs there.

[00:14:41] Scott Kingsley Clark: 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.

[00:15:01] Why don’t you use the php? And so I personally feel it’s not missing an opportunity to monetize. or have a user, it’s an opportunity to become part of the solution, which is me helping build Fields API that can be used by pods, and for all these other plugins out there if they choose to implement it.

[00:15:22] and not be selfish in their money or their user base to do it for the greater good. Because if we all did this for the greater good of WordPress itself, it creates a more portable experience for users and developers who are using those solutions. So when you get locked into something, like types or whatever else, that, that has a specific configuration set and it’s hard to migrate away.

[00:15:46] I’m not saying that a about types cause I don’t know, but I’m just. If you’re using something that, that would choose to not use the field p I think that would be one of those things. You could say, I as a user have no idea what field KPI is, but I’ve heard that it’s this one plugin is not very portable because they’re doing everything custom.

[00:16:04] Scott Kingsley Clark: 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.

[00:16:21] Jason Tucker: 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.

[00:16:42] But

[00:16:42] Scott Kingsley Clark: full side editor,

[00:16:44] Jason Tucker: 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.

[00:17:11] So they’re not building like the management tool, like pods or one of these others. But rather they’re just knowing that it already exists and they can look and see what’s actually there and they’re just building the add-ons for it, as a plug.

[00:17:24] for those of, I was gonna say, for those of you, not watching, the video, Scott, while, Tucker was talking about this, was, eagerly rubbing hands together just.

[00:17:37] do you have one idea that you could share that would. Benefit this, have this,as you were sitting here, rubbing your hands together, is there something that, that could be shared that would,act as one of these types of add-on plugins that would tap into the field api?

[00:17:55] Scott Kingsley Clark: 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.

[00:18:21] Rest a p I would be able to consume the configurations that people have built. WordPress core has its own configurations, and people have added their fields to those different things and saying, I want a setting on this screen. I want a field and the user profile, whatever this configuration is now exposed.

[00:18:37] And you can say from the rest, p i side, Hey, why don’t you let people know what my configuration is, authenticated or whatever you put behind what you need to put it behind, for WordPress course sake. And now, WordPress’s API or app, on iOS or Android, your jet pack apps, all the different things that wanna do the stuff that’s built on top of WordPress and different experiences.

[00:19:00] someone who wants to build a completely new admin panel, someone who wants to do all sorts of different things and reskin everything and just completely redo whatever they want. , they have configurations. And now with the configurations they can say, not only do I have an app screen, like if I’m o on my phone, I’m opening up a wordpress.dot com app or whatever it might be, and I see that I’m editing a post.

[00:19:21] Scott Kingsley Clark: 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.

[00:19:38] It knows I have custom ones. It knows I have custom fields inside of some of these setting screens, like the general or permalink or whatever. It knows that I have more profile fields when I go to edit my user. It knows all these things beyond. Whatever implementation we dream up because the configurations are now consumable and with these configurations is what we unlock all of the extra potential.

[00:20:00] Jason Tucker: These are all the things that I was bitching and complaining about

[00:20:04] Scott Kingsley Clark: 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.

[00:20:27] All these things would be exposed and extendable and utilizable with P H P and rest, a p I and w, WBC I and whatever else you might want. Pull it through so that’s the extra icing on top of this cake. Not only we’re gonna try to standardize this process to develop with WordPress and to work within the,the apps and plugins and things that want to utilize these various parts of configurations.

[00:20:53] We have all, of, all the benefits I’ve already talked about. Just everything, just,

[00:20:58] Jason Tucker: Yeah.

[00:20:59] Scott Kingsley Clark: it’s awesome. I’m excited

[00:21:01] Jason Tucker: 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.

[00:21:19] Jason Cosper: 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.

[00:21:37] Mentally over, just the opportunities, provided there. I really. Whatever I can do to help out. it’s one of those things where I’m like, oh God, this is a big enough project where I’m just like, okay,how can I help ? Like how can we help? How, what, what is needed to help make this happen?

[00:21:57] Because,what’s that thing? the best time to have a Fields API was 10 years ago. The next best time to have a Fields API is now.

[00:22:06] Jason Tucker: right?

[00:22:07] Scott Kingsley Clark: make that a thing if it wasn’t one

[00:22:09] Jason Cosper: Right.

[00:22:10] so what we need right now is mainly The people to help make it possible. Help. we’re currently in the initial phases to say we’re not touching the code we had before. We have to rescope it all, make sure we’re using something that’s a modern approach, and figuring out exactly how.

[00:22:27] Scott Kingsley Clark: 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.

[00:23:01] I’m reading Corey’s here. He says on the surface it feels a bit anti f s E. we felt a push to do everything with blocks, which is great, but we still use a c F for certain things. Might this integrate with F S E in any way? I think.

[00:23:19] Scott Kingsley Clark: If you think about it, what are blocks?

[00:23:25] Jason Tucker: JavaScript

[00:23:26] Jason Cosper: Wow.

[00:23:27] Jason Tucker: To me it’s JavaScript

[00:23:29] Scott Kingsley Clark: Okay, it’s it. JavaScript, I see configurations.

[00:23:33] Jason Tucker: Okay.

[00:23:34] Scott Kingsley Clark: 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.

[00:23:44] Order attributes. What are the, when you look in, you’re editing the a block editor.

[00:23:50] You’re an a block editor, and you see the panel on the right or maybe the left, depending on your language or settings. on the right side, you see the options for each individual block. What are those? What if you start seeing these other parts, you start to see the bigger picture of, oh, what about, what if we, oh,

[00:24:07] Then you see that, this is not really anti fsc. it’s actually would improve a lot of things in the experience of building blocks and building things for, within WordPress, beyond just the settings and things like that. There are two entirely separate use cases, like when you’re editing, set editing, setting.

[00:24:27] Settings aren’t blocks. They could be powered by react components from the, from block editor. Sure. That improves inputs and stuff like that. and do some cool things like there, like that part. but they’re not Blocks use your profile, not blocks. maybe you might wanna be able to design your own.

[00:24:42] MySpace page kind of in a way. Like you have a editor and you can move things around, but that’s block editor inside of the profile. It doesn’t take care of the fields, like the post editor itself. Those have, fields not that are global to the PO post. there’s not just the blocks, but there’s the panels, the panel to manage page attributes and things like that.

[00:25:02] Scott Kingsley Clark: 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.

[00:25:23] it depends on what we’re talking about. . let’s consider my bar theory here as someone doing the limb. Okay. We’re not talking like lowering the bar to make it so they can jump over it. We’re trying to raise the bar so they can get under it, because right now we’ve lowered this bar in the limbo sense and people who have developed with P H P and have built projects agencies that are out there that have already left, the WordPress space, all of the things that they really don’t like is the fact that they have to do so many.

[00:25:53] Scott Kingsley Clark: 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.

[00:26:12] Now just use the Fields API to do your things and you can still have. JavaScript and React and all the things you want, you can still do those things. You can create a block instead, a WordPress right now with React and you define your, your configuration with J Jason. And, but you have to tell PHP this, you have to tell PHP this anyways, so why not create these configurations in a way that is across the board inside a word. everything is done the same way, at least at the very base level. And how implementations like the post editor, the, the user profile screen and the setting screen comments, whatever else, all these things could then use that same basis and they’re all off the same thing. And like I said earlier, add-ons, plug-ins, whatever you wanna use to integrate with these screens.

[00:27:04] They have the same experience at the base level. They’re just saying, Hey, for the setting screen, add this filled here. And then, oh, hey, from the, comment editor, add this thing here. It’s all the same. All the same. At the base level, same.

[00:27:16] Jason Tucker: 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.

[00:27:33] But, I’m super excited about this. I think this is gonna be one of those things that makes WordPress a whole heck of a lot better in so many different regards. And I think that, Just like what Cosper was saying, Scott, I really think that you found that spot that you can come back here and be like, okay, I’m, I am really going to tap into how I want fields to actually work with WordPress.

[00:27:56] And we’re super stoked for you.

[00:27:57] Jason Cosper: 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.

[00:28:13] Scott Kingsley Clark: 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.

[00:28:36] right now we’re in the core Fields channel. That’s a public channel. Anyone can join and be part of the conversation and chime in. We’ve had lots of people who have just come in with questions and ideas. Lots of dreamers like me who, want to see things improve in WordPress, and I would love to have more help.

[00:28:53] more people just saying yes or no or just giving feedback is helpful. that’s the biggest challenge right now for us, is making sure we have enough people, diverse voices that represents. Or press core contributors who have commit access. That’s a very important key cuz can’t get anything in without that.

[00:29:10] and then,people that are plug-in, developers who would potentially be able to use this, people that have built libraries, that could create some sort of fields API that would be useful for us to reference in our specification process. All that.

[00:29:23] Jason Tucker: Awesome. unfortunately we’re gonna have to have you come back and talk more about this.

[00:29:27] Scott Kingsley Clark: Oh no.

[00:29:28] it’s, yeah, it’s just, that’s what happens. 30

[00:29:30] Scott Kingsley Clark: Say it.

[00:29:31] Jason Tucker: 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.

[00:29:40] We’d love to get, Scott, more people helping him out and getting, getting this project going. So

[00:29:45] Jason Cosper: I, I just watched the, people in Core Fields jump from 332 to 335.

[00:29:52] Jason Tucker: Yes.

[00:29:54] Jason Cosper: the last minute, so

[00:29:56] Jason Tucker: here. This is great

[00:29:58] Jason Cosper: Okay. Jason outro.

[00:30:00] Jason Tucker: 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.

[00:30:21] Bye-bye.