 You starting going? All right, I don't know if you had some kind of intro you wanted to do. All right, well, in that case, hi, everyone. I am Pat Eason, as you all can see by your schedules. We're going to talk about using WordPress as a content framework, mostly without plugins. So as anyone's really dev much into WordPress, you've seen lots of plugins that can do all sorts of things, like adding fields and making post types, things like that. We're going to talk about doing that without having to use plugins to keep your themes a little smaller, a little more compact, and also really how to think in terms of how WordPress wants to organize your content. Because this is a very specific way it wants to handle that. And it's a little unique compared to some of the CMSs. So we'll start with just looking at vanilla WordPress and what content types it comes with. It comes with two post types, pages, for mostly non-volatile, permanent content, things that aren't going to change a whole lot, and then posts, which are going to be volatile and time-sensitive. So things that are changed on a regular basis, added to, removed, updated, things like that. And we can organize these right out of the box with categories and tags, categories being hierarchical, so jazz, things under jazz, and tags which will be largely singular. So music, for example, could be a tag. But if it was a category, music, jazz, rock, hillbilly, whatever, rockabilly, actually. So with that in mind, WordPress is kind of a simple solution for organizing content. It comes with two ways it wants to handle things and it really wants to do it that way. It doesn't like to really deviate away from that. So I found this quote, and this is actually, and I'm gonna be referring to and comparing to Drupal a lot. So if anyone here really hates Drupal, sorry, you have to kind of deal with that. But it's a really good use case for certain things that WordPress doesn't do, but we would love for it to do. So we're gonna try to take it a little more towards that, but without killing what makes WordPress so great, which is simple, fun to use, and easy. So this is directly out of Drupal's introduction. If you actually download it and really go through all their documentation, and that is solutions for content management struggle to balance flexibility and simplicity. Solution is too simple, can only be used for a single purpose, but if it's too flexible, maybe too difficult for newcomers to learn, or it's really intimidating. So we're fighting against complexity and simplicity. So over here I have Drupal 7's default, Bartik admin theme, and then the WordPress dashboard, which we all know and love. So this is a lot of stuff to see, if it wasn't as blurry, it'd be a little easier. But these are all, think of this here in WordPress, your dashboard sidebar, as every option here. So everything here has a whole bunch of extra options, a whole bunch of extra sub-options, just a lot to manage. So coming to that, it's like, that's a lot. I've heard Drupal can do a ton of things, but man, that's intimidating. I don't want to deal with that. Whereas WordPress is simple, it's kind of like a homies help homies situation. It's like, you want to make posts? No problem, those are right there. You want to make pages? No problem, those are right there. You want to see what's going on? No problem, it's right here. Why would we make it complicated? But that does lead WordPress in particular out of the box to be kind of single-minded. And that is, I want pages, I want posts, I want categories, I want tags. Don't do anything like that. That's not like that. So we're really trying to take the greatness of WordPress simplicity, almost trying to make it a little more like Drupal in terms of flexibility. And that is making it into a content framework. And what's great is WordPress can do both. It can be complex and simple, but you gotta know how to do it. Because you can make some real damage, end up like Drupal, which is a little more complicated. Or we can make it what we want, which is an amalgamation of the two. So I'm gonna start with kind of three questions we're gonna ask along the way. And that is, how do we structure content WordPress style? As I said, WordPress has a specific way, and once they handle content, both posts, taxonomy, things like that, we're gonna look at what data points we have and how we should properly organize them into that content structure. And also, how do we really implement that data in a usable way, both for administrators and for ourselves as developers and designers? Like what good is it to us if it's no good for the administrators? What good is it for the administrators if it's no good for us? We really gotta balance those. So let's go back a little bit. At our, but no WordPress content types structure. And we just wanna kinda go a little further than this. So we've got posts and pages, posts and pages. So we got those two buckets of stuff, but we may need another bucket of stuff. So let's say, for the sake of argument, and I'm gonna show you it anyway, we're gonna make a dog kennel kinda site. So we need a bucket for dogs, we need a bucket for cats, we need a bucket for whatever's. Well, we also need to be able to filter those too. So if I have my pages bucket, I can filter that by tags or categories. If I got my post bucket, I can filter that by tags or categories. This is bucket filter. But if I got dogs, what am I gonna filter that by? Tags and categories doesn't really make much sense. And since those are related to those two, I'm kind of cross-pollinating things that are unique to those particular post types into that. So that's no good. We're gonna want another taxonomy for that. So that's where WordPress custom things come in. Now WordPress likes to use the term custom for anything that's not default. In particular, we're gonna get custom post types, custom taxonomies, and custom fields, or post meta. Now, if it helps, if you're like a real hardcore developer in MVCs, think of these as models and the attributes and associations they have. So post type may be your model. If we had a dog model and the association may be breeds, that's how our dogs are gonna relate to each other. And our attributes may be fields like weight, height, eye color, things like that. So if you're really into models, that's how to really think of those as kind of relating to each other. So this is about what we're gonna put together. It's already put together, but we're gonna just uncomment things so you can see how it works within kind of the WordPress environment. You can create the word camp kennel. We have a taxonomy here that we're gonna deal with categorizing things by. We got our post type, which are gonna be our dogs. We'll get them, lots of dogs. And then we'll add some fields so that we can specifically add additional information that wouldn't be traditional title and content. So first, let's go ahead and head over to the little dashboard we got. Got our word camp kennel, excellent. Yes, I know. And we'll check out our sidebar. So this is, as you can see, we already have the welcome screen. So this is pretty much stock WordPress, exception of that theme that we put up on top of it. We got posts, media pages, comments, everything you're used to. So if I were to come in here as say charged with, you gotta put dogs into this kennel website, but I don't know what's going on. I've never used WordPress before and I don't really know where to put those at. How would I do that? For the sake of just understanding from a content architecture, I don't know. They could tankly be pages. They could tankly be posts too, but it's gotta be an easy way to do that. So the way we're gonna handle that, if I can head back to my slide to show, is through some custom post types. So the custom post types we're gonna introduce based on that mockup are dogs. We're gonna have a specific place just to put in data for dogs. It's that simple. Custom post types represent a specialized group of data. So that would be, like I said, just dogs. That's all we're gonna put in there. It'll have unique roles and capabilities if you choose to implement those. So if only certain people can deal with that, only certain people can see it, edit it, view it, delete it, things like that. But also whenever custom post types are introduced into WordPress or registered, they also include unique archive and single templates. So since we're introducing dogs, we could have archive-dog, php in our theme, and WordPress will go, I get that. You're looking at dogs, you're looking at the archive for dogs. I'm gonna get that template instead. Otherwise it'll fall back to the default. And also singles, no point in having a dog single page look like a page single page or a post single page. WordPress is smart enough, it gets that, and we can add in single-dogs or single-dog, whatever we call it, and it'll go, got it, we're gonna grab that, we're gonna use that instead. And to do that, it's as simple as this line right here. We can expand that out and we will in a second, for really all we're doing is saying register this post type, we're gonna call it dogs, and WordPress will figure it out. So in total, this is what we're actually gonna drop in, and we'll check that out in Adam. See how all that works. So here I have my content framework file, which is just being included into the functions.php file in our theme. If you're unfamiliar with how WordPress handles functions in the root directory of your theme, so I was gonna be functions.php, anything extra you put in, that's where it'll go. So this is just being included into that just for the sake of privacy, so we don't muddy it up. And I'm gonna do two things. First, I'm gonna create an array of labels, and these are gonna be used on the administrative dashboard. So things like the name will be dogs, but the singular name will be dog, because why would I say view dogs if I'm looking at one? Things like that. As we go down here, these are the actual arguments we're gonna pass into register post type to make it do a little more than just existing, because we wanna make this unique. So our first thing we're gonna do is we're gonna say, is it public or not? What's great about WordPress is it'll allow you to make post types that are not public, so that may sound completely useless to some people, but what that means is it allows you, if you choose to have a false public post type or invisible post type, is you can use it for administrative functions. So it matters to you and your plugin or your theme, but it doesn't really matter to the end user, so they don't need to worry about that, but you can use it to store your own information. Yes. That would be more user administration, not really for a post type. You could, technically, but it's kind of working around what WordPress already has to do. Does that answer your question? Yeah, it is, for sure. This is the WordPress way of who wants to do it, but I agree with you. Next up, is it publicly queryable? It's very similar to whether it's public or not. Basically, can I access that from the front end? So if you want something to be modifiable on the dashboard, but not modifiable on the front end or visible on the front end, no problem, you can do that too. Show UI and show in menu will be very similar. So should I see this in the dashboard? Show UI. Should I see this in the admin bar? So if I go to, so plus here, choose to make something, could say whether or not we want that to show there. Now this gets very granular after a while, but there's a lot of use cases for certain situations depending on what you're trying to implement. For this situation though, we're just gonna say yes to everything just to get it out there. Query bars, including query bar for URL querying. So if you don't change your URL, permalink structure, you could say website dog equals one, you can get your dog, that equals one. Our URL slug, this is gonna be relatively important. Rewrite, ray, the slug we want, and we want to be called. So if we are making this post-item, we want to call it dog. We want it to show up as dogs, no problem. Change to your Rewrite slug, and that is welcome up on your permalink structure. And then for the most part, it's all pre-self-explanatory capability types, WordPress, since it's built around the idea of pages and posts. I'll say, how are we gonna model this? Are this gonna be kind of like a page? Kind of like a post. For our instance, we're just gonna say it's kind of like a post. But really what this does is it just influences what dashboard meta information is available. Things like templates, ordering, timed releases, things like that. Has archive, hierarchical, and menu position. These all influence if it has archive, if it's hierarchical, like a page, or on what menu position it has in accordance to the rest of the dashboard. And then lastly, under supports, we can say what exactly WordPress style does this support in that admin? So for this post type we're making, dog, we're gonna say it has a title, we can edit it with a content editor, so the WYSIWYG, it's gonna have a thumbnail, and it's gonna have an excerpt. Now anything WordPress related we can add and remove from. So if I said this post only allows titles, I could remove all of this and just have title. That's all it'll allow you to input. So you can control fields that way to a certain degree based on what WordPress has built in. But later on we're gonna build off of this a little more and make it more robust, field-wise. So what we're gonna do right now is I'm just gonna uncomment this field I have at the top to enable our post type. All right now we have posts, pages, doesn't mean anything to me, I'm just trying to make dogs right now. Give this a refresh. Oh, awesome, now we got dogs and cats. I understand this, so let's check it out. Check out, we'll see all our dogs. Excellent, so I've already put in some. Let's go ahead and edit one, edit Amber. See we have our title which we defined that we wanted. So I can change the name of this dog which we're giving it the title of. We have our WYSIWYG, so if I wanted to edit some content, see, Amber's pretty cool. Put in whatever we want. And then that is, no, not it, featured images. We also add featured images as well as excerpts. So if we wanted to remove one of those, we'd remove from that array I just showed. If we don't, leave it in there, and we got that. But in terms of dogginess, there's not much to this. I mean this is basically just a post called dogs. I mean dogs have breeds, dogs have heights and weights and things like that. Should probably accommodate that a little bit. So let's head back to our slide show and keep moving. Now let's talk about breeds. Or in this case we have some taxonomies. So taxonomies, as we saw, we had two kinds that come built into WordPress. We have categories and we have tags. Categories are hierarchical, tags are not. Kind of singular. They can be applied to multiple post types. So default WordPress, vanilla WordPress, tags can be applied to multiple different posts. Categories can be tagged to multiple different posts. But they can also be cross-pollinated. So category can apply to a page. It can also apply to a post. So it's not unique to that situation. Same thing we can do with custom taxonomies. Since we have, we just made dogs as our post type for our model for data, we also want to be able to classify breeds. Well we can apply breeds to posts and dogs, but then that's confusing to an end user. It doesn't really make much sense from a data architecture standpoint. So for this particular situation, we'll create a custom taxonomy that relates only to our newly created custom post type. And in addition, just like custom post types, unique archive templates are automatically detected once you create a taxonomy. So we're gonna make breeds. If we had taxonomy-breeds.php in our theme, we tried to view the archive of that taxonomy where the press will be smart. So I know what you're looking for, we're gonna use that one instead. And again, registering a taxonomy is easy. We're gonna use a vanilla. Register taxonomy, I wanna register it and call it breed, and I want it to be unique to our post type dogs. So if, with that in mind, in a dashboard, if I were to do just that, the dog's post type would have a new taxonomy called breeds under it. And actually we're gonna go a little deeper. So let's head over to Adam. We'll check out our breeds taxonomy. So we're doing the two same things we did with post types. Create an array of labels, create an array of arguments. I'm actually gonna register it. And it's very similar to post types, almost one-to-one. Our labels look the same, either for administrative functions, breeds, breeds, search breeds, popular breeds. Basically what we want the admin to render out when you go to certain pages and functions. And then our arguments are gonna be very similar as well. Hierarchical, whether it's showing the UI, showing admin column. So if you have the viewing like posting the admin, have it show in there as sortable or not, you can apply update post callbacks, which is a discussion for much longer that we don't have time to go into. Where you only be able to query it based on the variable that you give it on the slug breeds. And also rewrites based on that breed or based on that taxonomy. In this case, we're calling it breeds. So let's go ahead and uncomment that as well. Get that primed into WordPress. And right now, if we look at our dogs, we have all dogs and add new. But I wanna be able to add breeds. So since we just uncommented that, it should be loaded into WordPress. We'll give it a refresh. And there we go. We now have our breeds available to us and it's under our dogs. We check out things like cats. I have breeds on cats. We look at pages, don't have breeds on pages and likewise on posts, no breeds on posts. So this is gonna be unique only to our dogs or our dog post type rather. So if we check it out, it acts and looks very familiar. It looks and feels just like if we were to input tags or categories. The only difference is it's called something else. And that is because it is exactly the same. Where Priscilla considered this exactly like a post or category or a tag or category. But it's just gonna make it unique to whatever you want it to. So in this instance, we have a couple of Boston Terriers, German Shepherds, things like that. And we've already applied these to a couple. So let's head over to the actual front end. So this is our empty page where things like breeds and dogs would show up if we had registered them. So we're actually on the dogs archive page. And now that we've registered some taxonomies, some post types, we should start getting some data in here. And we do. Excellent. So we got dogs over here being rendered out. Remember Amber, we edited her, we said she was cool. And then we got our breeds on the other side which are being auto created based on what breeds we have as well as the counts they had. So we got Boston Terriers, German Shepherds, all sorts of things. And in particular, we have two Boston Terriers. I'm not gonna look through all these guys, I don't care about Boston Terriers. So I'm gonna filter by my Boston Terriers. And there we go, perfect. These two guys are assigned the breed taxonomy for Boston Terrier. And since we are now on breeds slash Boston Terrier, that specific archive template, which is based on this taxonomy that we gave it, see we're looking at breeds, Boston Terriers. And then we have just this too. So let's go and check one of these guys out. That's cute. But I'm missing a whole lot of stuff here. So this dog's name is Zoe. I know that based on that URL. Here's a little information about Zoe, but I don't know anything else. I don't know what the idea is, I don't know what age, size, color. I'm looking to adopt this dog, I don't know anything about it. And I mean, I could argue that maybe you could put all that here in the content WYSIWYG, but that's a lot of room for error. I mean, everyone who comes and edits these dogs could change it in any different way. Some could say age comes first, some could say size comes second. People could change this however they want it. What we want is very specific animal ID, age, size, color, spade neuter, now it's trained location and adoption price. So if I were working out of candle volatiring, filling out these forms manually by hand, kind of want it to be just like that. Like why would I deviate from that? So in order to make that happen, we are going to add some custom fields. And this is the mostly part of without plugins. So a custom field or post meta if you're used to that terminology too, just adds additional data to a post. So if we're totally unique to it, it's not gonna cross-pollinate, it's not like a tag or anything, it's just information in the database. Again, completely unique. And plugins will make this easier by a lot. So we're actually gonna use a plugin to make this happen. In particular, there's two that I like to use. First is advanced custom fields. Now this comes in two flavors, free and not so free. Honestly, the free version is so amazing that I have not really had a use to buy the paid one, but there are a lot of commercial extensions for this that are phenomenal. I'm gonna be showing off ACF in particular with this WordCamp Kennel so you can see how all that works and what all possibilities it gives you. And then we'll talk about some upsides and some downsides on that one in particular. Another popular one that I've used is pods. Now pods is a little more than just making fields. Pods, let's the best way I say this, invalidates this whole talk because it does everything. But it's really heavy. Pods is originally made by a guy who came from Drupal and was like, I wanna see more Drupal in WordPress. And he did, like really well. But it's kind of heavy. It does a lot of things that you may not use so it's still there and primed. Honestly, if you don't have to use every feature in pods, then it's probably best to go with something else. But let's not say pods is not excellent at what it does and it does everything very well. So post types, taxonomies, organization, fields, does it all. Well, back. Not necessarily slow, just with the way that PHP is in general, if it has a lot of features that you're not using, those features are still available and being loaded in some way, even if not being used. So maybe not slow, but just a lot of stuff there. It could potentially end up slow. I'm sorry? Yeah, exactly. So we're actually gonna play around with ACF here real quick. Head back to our backend. Let's go to our plugins and already have this installed. So we don't gotta worry about internet slowing us down. And here we go. Fast custom fields by the great Elliot Condon. Condon, however you say his name. And, look at action, activate, do it. Great. So now we have ACF activated. Check out our sidebar and go all the way to the bottom. We've got custom fields and I just wanna look at them all. And you're not gonna let me. All right, there we go. The mobile, I'm not used to the mobile layout on this. So this is gonna look, and this is actually a perfect example of a hidden from front end view post type. What ACF does, is this looks similar to how you view all your posts. Cause dog details is a post type. So dog details has all the extra fields I'm gonna add to dogs and saving as a post type. Not visible on the front end. You can't query it, can't access it, can't archive it. So only here being used as a repository for information or just a bucket for fields. So let's check out our dog details. I already made this and we'll see what we got. And awesome. That is actually one to one we wanted. That's pretty sweet. But let's change something up a bit just to have a little fun. So we've got things like animal ID, age, size, color, space neutered, so on and so forth. But I feel like maybe location shouldn't be available unless I click something. So maybe if the animal is in foster care, I shouldn't even bother asking about the location because it's in foster care. I don't wanna expose that. So let's add a field and give it a whole bunch of fields to add this. So the label is what'll show up on the actual page itself when you're editing or creating your content. So in this case, the dog page. So we'll say is foster care. And that'll auto create a field name that's what's gonna be saved in the database. So if you look up and try to do get post meta, you'll get it by is on a score foster care. Now I'll modify the field type. Not by default, ACF comes with a lot here. But that is infinitely extensible. But for the sake of time and right now and we don't wanna bloat things up too much, we'll just use what we got here. Now I just wanna see if it's true or false. Are they there or are they not? We can add some field instructions if we wanted to. These will be shown alongside our fields. So this accepts standard markup. We'll just say is this dog, dog in foster care. Man, I can't spell. Moving on, we have the option to say is it required or not? We're gonna say no. Because honestly what that would do is force you to make a true or false true. And that's not what we want. We can add additional messages if we felt like it. These are actually very similar to the instructions. So we'll leave message alone. We can set our default value to checked or not checked. We're gonna say not checked. And for this particular situation that'll be it. We have our new field. Close that out. Called is foster care. Show up under adoption price at the very end. But we're gonna add some conditional field statements here. So that is foster care is directly related to location and back and forth. So with that in mind, let's go ahead and drag this up. Sol drag and drop on this particular sorting. So let's say, uh-oh. Okay, it doesn't like to do it in a mobile. Come on. All right. So sorting in mobile does not play very nice as we just found out. That's okay. We'll make this work. So right now we want location in particular to only show up when we say a dog is not in foster care. So we'll edit location. We have all this information we have about location. We got field label, field name. Field type is that is a select type. We got some information here. Kennel or foster care, but that doesn't really matter now. So we're going to get rid of that. So our only option is we'll say Kennel and facility. It's not required. So if it's there, we can have it. If it's not, not a big deal. And lastly, we're going to add some conditional logic. Now this is kind of like the secret sauce to ACF I feel. And then you can make some really robust content curation fields based on what values currently exist and what values don't. So conditional logic is yes. And we're going to say this is related to is foster care. Now, is this equal to checked? Is this not equal to? We're going to say not. So if foster care is not checked, I can choose a location. If it is, it should not show up. So we're going to say show this field when all these rules are met. Excellent. Now we'll go ahead and give this a save. So let's see if that worked. Now, we think it will. We'll go to all dogs. We'll just edit Amber again. Awesome, we have our breeds, which we added. We can add breeds if we wanted to. And just like we're press fashion at a lot of fill. Got Boston Terriers, put those in again. Hmm? Oh, no, no, I purposely removed it. And then now we have our dog details. It's exactly what we put in ACF. Looks just like it belongs in WordPress. Doesn't look like it came from somewhere else. So it maintains the same brand standard that people are used to working with, but we're just adding on. So now let's see if location is available. All right, it is. Well, it's because we said it's not in foster care. What if it isn't foster care? No location's gone. It's in foster care, we don't need to worry about that. So that is, in my opinion, like the most powerful thing about using advanced custom fields is that not only can you create these fields and then return them very easily, but every single one of them can be conditional and related to one another on compounding statements. So it's not just, is this true or false? It can be, is this, is priced between $20 and $50? If yes, you have to sign a waiver. If the waiver is checked, yes, sign a waiver, then upload a waiver. You can very much compound those and make really robust field forms with that. So let's go back to our single. We got this dog who we're supposed to have information on, but we didn't because we forgot to install advanced custom fields. And I'm glad someone told us to do that. We'll see if we have any information now. Excellent, we do. We can change this all manually if we wanted to. So let's check out things like age one year. That dog looks a lot older. Go ahead and change the age just for the fun of it. So it's two year, two month. According to our backend, this dog is now two years, two months old. What does our front end say? Two years and two months, excellent. So that's a brief breakdown of advanced custom fields. I can use that to make some more extensible post types. And honestly, that's it. And that's all it takes to really make WordPress into a more powerful content framework. So you can go make some cool stuff with this, make better administrative content curation experiences for your users and better experiences for your developers and designers to make awesome things, really, features, mockups, whatever. Possibilities are endless. Well, that's it, guys. Yes. So to make this show up, you have to have a little snippet of code, right? Yes. Yeah, let's go and check that out. Where do I got that? Generate what in particular? No, no, it doesn't automatically do it. The way that I'm pulling these in is just using WordPress's built-in get post field or get post meta hook. So once I get this open, we'll check it out. There we go. So here is where I'm calling in size, for example. So we're just saying, does ACF exist? If so, get post meta. This is a default WordPress hook, and I want size. So if that would, it did exist, it would render it. And if it didn't, so for example, if ACF wasn't there or I didn't actually make a size field, then it would just ignore it. So this isn't something that comes built into the plugin. It's WordPress specific. Now ACF does have its own way of getting things, which I feel is kind of unnecessary in a lot of situations. But you could just say get field. Size, and it would do the same thing for advanced custom field situation. So below would be how ACF would wanna do it, and above would be a more agnostic method. Any other questions? Yes, there's none of you right now. I'll put those out. I'll tweet it, white open tech will tweet it. They'll be available, definitely. Yes. With the WP API, not in particular, I've used it for things like Twitter grabbers, scrapers, but never like, I really can't think of another one. I mean that's a perfect use case for it. I mean really, the best way to think about this is it's just a way to section off and organize content so that's easier for you to get hold of. So it's less taxing for searching through, like I want all posts, but I only want these ones, but only in this situation, and it's a lot for the database to handle, it's a lot for you to have to think about. But if I'm like, I just want Boston Terriers. That's easy at this point, because we put all these in. So yeah, perfect use case, man. Yes, real easy. All right, so let me bring up the dash icons. Let me get a name for these. Oh no, we will solve this. So here we're defining our custom post type. Really, all you have to do to change the icon, you can use WordPress's built-in dash icons, which is probably a good idea in most cases. And that would be as simple as just adding an extra argument here, icon name of dash icon. And then that would then load that glyph from their dash icon library. If you wanna do something else, you could, I believe, and if I had internet access to load some images and do that I'd show you, you could include a URL in here as well and it would instead load that URL into that. Or you could always modify the administrative CSS and that'll do it too. And maybe menu dash icon. I haven't done that many times. Most people are totally cool with it being the same. Or actually probably underscore. So that's still up for debate, but it still works the same way. Maybe icon, maybe menu icon. Yeah, no, so let's go ahead and do that real quick. Let me get rid of this in case it breaks things. So let's head down to our breed and we're saying just dog right now. I turn this into an array that I call it cat or cats. I call it cat, great. To our dashboard, give it a refresh. If we check out cats, we now got breeds. However, if we go into breeds, it'll still cross-pollinate. So you can't assign taxonomies to multiple things. How far are you to be a cat? Yeah, or it'll start tabby to be a dog. So if you use the same taxonomy on two things, they will cross-pollinate. WordPress just treats that as its own bucket that multiple things can suck out of. Yes. The performance benefit, honestly, if I were to have done it all with just registering things like WordPress style hooks that are already existent or extant, then it would be more performant. Maybe not like glaringly more performant, but it would be simply because I'm not requiring additional functions or features to make things happen. The only reason that I used ACF in particular for this example is super easy. And also registering and saving custom fields to the database on WordPress isn't quite there yet. In the same way that post types and taxonomies are. So it's kind of a lot of back and forth to make it work. It's a little chunky. But ACF in particular is pretty lightweight and doesn't really muck too much up. Unless this is, okay, I just thought of this. If you make a massive form with a lot of conditionals, that will slow down a lot. The actual managing, not the loading. So that's the only downside. If you do have a massive form with a whole lot of JavaScript going on, logically the browser's gonna joke at it. But yes, you're right. ACF would be performance benefits if I went one way all the way or another way all the way. Any other questions? The negative of disabling ACF would be if I input all this, I just wouldn't be able to grab this data. So the data would still exist in the database because where ACF saves all the data itself, so like age, size and all that, as well as the field types that I made. So we saw that ACF has dog fields. That would still exist. So if I installed ACF again, they'd be available. I just wouldn't be able to access it. Right? Yeah. Mm-hmm. Yeah, so. And would it register all the data? Yeah, so the way that works, and I don't know if you'd have time, but I guess we totally do. Yeah, so I don't have time to put it together, but basically what Clifton's talking about is ACF, if it's installed as a plugin, we can edit it just like a plugin. That's cool, but it has to exist there. However, you can export advanced custom fields as a light version, with just a big ol' array of all the fields you created, and include that directly into your theme. So right now, if I'm, I don't know, pretend I don't know what I'm doing, I was just told to add dogs. And I come through here and I'm like, ah, dogs don't do everything I want. I wanna add hair length. Well, I see custom fields here. I'm gonna check that out. Oh, great, I can edit dog details, blah, blah, blah, I could break things. So to avoid that, right here, directly under custom fields, we have an export option. So if we choose to export this, you can say what field groups we want. Yes, we want our dog details. It's our only field. And it gives you detailed instructions on how to export and use these. So in particular, we're gonna export to PHP, and it's just gonna spit us out a big ol' PHP array that will then, as it says, paste into your functions file. So let's export to PHP. Yep, that's a big array. So let's take it, go into our functions file. We'll just slap it in there. Don't think about it too much. And there we go. See we got things like color. Let's see, it's type text, all that. Give it a save. And because I'm feeling a little crazy, what I'm gonna do is I'm just gonna delete all the fields we just made. Done, gone, no more fields. But we export it. So if we do go back to our dogs, we'll edit Amber, see it's still there. So you can have the actual whizzy wig editor for your fields, or if you just want those to be permanent and non-editable, you can export those directly to your functions file, and those will load up there in the same way. So function the same. So if I put in some details here, give it a save, we're saving it. Sounds great, let's actually view it. There we go, it is saving what we told it to. Any other questions, or everyone's brains full? All right, well thank you guys for coming. Oh yes, one more. Sure can, you wanna see one? Let's do that, that's exactly why I didn't bother showing you guys that. So let's go ahead and let's head back to ACF and we'll just make a whole new set, call it default, create a new field, and we'll say this should default, and should also auto-crit. So we're just making a text field, basic text field, everyone's seen, and for default value, we'll say cool beans. So every time I load a page that requires this and doesn't have it, it should default to cool beans. Let's check out amber again, edit. See we still have our dog details that we manually forced in, and then down below that, oh hold on, I just missed a step. I didn't force this to go to dogs. So you have to force the location, I totally forgot about that. So now our default value fields will go to post type, is equal to dogs. Well I'll save you, there we go. So we have our new field, we just call this should default, has already defaulted to cool beans. If I wanna edit that, I can edit to my heart's content. Mm-hmm, absolutely. So like if we're looking at our default group we have here, we're saying put this on dogs, but we could also say put it on cats, and the post status is equal to, that was a default draft. So it'll only show up the first time we try to make a cat after you save it. Well thank you all for coming, it's been fun. I'm glad that people seem to have got a lot of this. I'd used to use pods a lot, but then like I did, it was for like a hospital.