 Today's talk, of course, is about creating custom WordPress themes. So in other words, if you've ever wondered how could I maybe avoid paying for a new theme every time I want to build a site, or maybe I just want to do something that's a lot more custom or what have you, we're going to get into some of that information here. So real quick boring information about me, I'm from here. I do mostly front-end and WordPress work. I'm the founder of Titan Host, which is a managed WordPress hosting company. You can find some of my stuff here, and these slide links will be available later as well for those who want to read them later. So this talk is primarily geared towards designers and developers who want to create their own themes. And again, if you're looking to maybe create a theme for the WordPress repository, the theme directory, or something like that, there's additional considerations that aren't really covered in the talk. There's certain requirements that those themes have, which you don't really have in a custom theme, so we're not going to cover that kind of material. So some prerequisite knowledge in order to really get the most out of this information need to have a basic knowledge of HTML, CSS, and JavaScript. In other words, if you are unable to currently just build a static web page with those technologies, you'd be better off learning that information first before proceeding too far, and then a basic knowledge of PHP. Now for those of you who know PHP, this is all very rudimentary stuff, right? And if you don't know PHP, don't be too scared. It's pretty easy to pick up. There's a lot of really great documentation, so it's not that scary, but in order to really take advantage of the power of custom themes, got to have some PHP or some familiarity. Now there's some other links that I've included here for further reading, so if you're looking at these slides later, you might find these helpful. One of them is WP Hierarchy, which we'll talk a little bit more about later. Codex, of course, which is your Bible for all things WordPress, how to do this, how to do that. And then Custom Post Types, which we're going to talk a little bit about. That's also a topic that's included in the Codex. And then ACF, or Advanced Custom Fields, one of the most popular WordPress plugins, which we'll also be talking about in the context of our discussion here today. So what I want to start off with are some of the basic core concepts of a solid custom theme. And this is by no means an exhaustive list, but it's just some important tidbits. So first is set up assets for easy re-use, so that means if you're working with files, whether they be PHP files, JavaScript files, SVG files, whatever they are, you should try to set yourself up for success, so it's easy to implement those things anywhere in your theme that you want to. You'd ideally want to minimize hard coding, but I mean by hard coding is me going into a file and typing in something like a value, like the link slash project or whatever, instead of perhaps giving a user the ability to dynamically enter that information in the dashboard. And then this, and I think this is the most important thing I want to stress the entire time, make the user experience a priority, in this case the user being the person managing the site. We would hope that you make the user of the website your priority in terms of designing the site, but that's not what I mean here. I mean, if you're building the site for someone, so you're building a custom theme that somebody else is going to use, you need to make sure that the experience that that person has is sufficient for their needs and expectations. Can they change the things that they want to? Are the instructions clear? Can they get in there and not be frustrated? Those are the things that are important. So a couple other little cool kind of things to keep in mind, I think, is that all of these templates that power these themes, they're all driven by one thing, which is data. So in other words, you're taking data from places and then outputting it in some meaningful way inside your template. So the way that you organize and structure that data is important. And when you use modular styles that are easily reused, it greatly speeds up development time. So what I mean by that is if you're making a series of components in your custom theme, if you style them in such a way that they don't have to be nested on a specific page or page template, they can just be dropped in and used where they are, that allows you a lot more options. And it speeds things up massively. So you have to write less styles. So some characteristics of common custom themes, although again, this is by no means an exhaustive list. One of those things is using SAS or the SCSS syntax. Do you have to use that? No. And we'll explain in a second. But it does provide you, again, a lot of convenience as far as speed and ease of setup that doesn't have any kind of negative impact on the final product whatsoever. So also, we're talking about a theme that would use ACF Advanced Custom Fields to allow you to add custom data to various entities within WordPress. And again, we're going to talk a little bit more about that in a second. Now, for my money, as far as task runners go, and if you don't know what that is, I'll explain in a minute. Gulp or CodeKit would be some of the best choices. I mean, you can use Grunt if you want. These are just my personal opinions, I guess you could say, right? But if you're going to choose between one of those two, CodeKit is best when you're working alone, and if you have a Mac, obviously. And then, Gulp is best if you're working on a team. Why? Because it can run on anybody. Anybody can use Gulp, whether you're a Windows, Mac, user, what have you. And then finally, and this kind of goes back to what I was saying about user experience and those things, making your theme as dynamic as possible so that somebody doesn't have to be a programmer in order to make changes to every little thing. It allows you to build more value into the theme. So real quick, we were talking about task runners a second ago, like Gulp and CodeKit. These are basically things that are used to automate various tasks during development and or deployment. Like a very good example would be minifying files. Say if you want to make changes to your styles, have those files be minified and then upload those to your web server, you could use something like Gulp, CodeKit, what have you, to do that automatically for you. So it just does it on save. Also, using a task runner allows you to use things like SAS, less, Babel, and all those kind of things. So SAS and less would be a pre-processor, and then Babel is something called a transpiler, which lets you use really modern syntax for JavaScript that is compiled to work in older browsers. So really quick, just to kind of break down the differences between these two things, is Gulp is a CLI, like a terminal command line application, whereas CodeKit is an actual desktop application. So the pros for Gulp is that you can run it on anything. You can do just about whatever you want with it. And it's ideal for teams that are multi-platform. So if you have a shop that's Mac Windows, say, then something like this would make much more sense. Although, it can be slightly difficult to set up. And it might be more intimidating if you're one of those folks that gets a little scared whenever you see the black box in the blink of a person. Whereas CodeKit is very easy to use to set up. It's very fast. The developer is regularly updating it, and he has the most hilarious change log notes of all time. However, the con is that it's Mac Windows. So that may or may not always be an option. But if you're like a one person shop, and you're just making these things for your own clients or whatever, then you would just want to decide which one makes the most sense for your use case. So we're talking about SAS earlier. This is one of those things that's simultaneously both very popular and slightly polarizing inside the industry. People are like, what, my CSS isn't good enough? No, your CSS is just fine. SAS compiles to CSS, though. So in general, yeah. If you know how to use it, you should use it. It allows you to use things like variables, lets you write code a little bit faster, and creates selectors that all kind of merge together, and allows you to have dry, like don't repeat yourself, kind of styles. Also a fun fact, well, since we're in Jacksonville, of course, the creator of SAS, Hampton Catlin, he's actually from here. He was born on the West Side. He was pretty sweet. So you can learn more about SAS in general at this link here if you want to know more about that. So the basic thought process, when you go into writing a theme, it's pretty straightforward. And again, it's not like a super silver bullet thing, but it's just a rough approximation. You start by planning what you want to do. Determine an outline of what that is. Like you might say, what are the deliverables? So what do I think I need to do to accomplish that? How would it make sense to structure this? Or what should I tackle first? And then you focus on that data. And I'm going to get into more about what I mean by that in a second. The next step is once you set up a place for all this data to live, then you actually plug it in. Like go into the WordPress dashboard, go to your page, plug in some information, and then write code to make that data actually go somewhere. Now some people might say, well, why don't you just write the code first and then I'll put the data afterwards. I feel like that's kind of backwards. The trick is you want to make sure that you have a data-first approach. So you're setting up everything in a way that allows that data to make its way where it needs to go, be manipulated accordingly. And in this case, data could mean a lot of things. It could literally just be paragraphs in a blog post, like page content. It could be, like if you're talking about a book, it could be the author or the publish date or the ISBN number, any sort of information that ultimately needs to get displayed on that page. And then after you write the code of course, you test it to make sure that it works. So an example structure of a custom theme, like thinking about this from like some folders. The organizational style I tend to gravitate towards is something like this, where you have an assets folder that then has a place for your CSS, your images, JavaScript, SAS files, or maybe fonts or something else. You know whatever you need. It includes directory. Sorry, I skipped a little ahead of myself there. So yeah, things like images, font files, and so on, in assets. So the ink or includes directory, this is where I store PHP files that aren't like they're not really necessarily templates. They're something that you would include inside your functions.php. Like a good example is there's lots of gists and GitHub repos for disabling emojis in WordPress, because it causes additional header requests and people don't want them. So they say, I want to just turn that off. So you might throw that inside a file, disable-emoji.php, and then have that in your includes directory, and then include it in your functions file. So that code is just in its own file over here. Also, you might put things like short code definitions or functionality snippets, like I was saying, with the emoji disabling. So this parts folder, and this is one of those things where everybody has their own feeling about how you should actually name this. But I usually go for parts because it's shorter. It contains all template partials, parts for short. And these partials will be included in various places. So we'll look at some examples of what a partial looks like in a bit. So then inside the root of your theme, you have things like your WordPress templates, like page and post templates, the sidebar template, search form, all those kind of things. The functions.php file, which has to be there. And then, of course, style.css, which is one file that has to be in every single theme. It's got to have some comments at the top that tells what the theme's name is, who the author is, et cetera. So you'll want to make sure that's included as well. So real quick here, we were talking about WP hierarchy very briefly earlier. What it basically is, is it's an enormous flow chart that goes through all of the different paths for how WordPress templates work. So pull up here really quick so y'all can see if you're not familiar. So it's a little blurry, but it's basically an enormous flow chart that goes from left to right. So if I'm on a single page without an annoying cough up, get out of my mind, single page right, and it's a static page, then it's going to look for a page template, and then it's going to fall back and look for these, and so on, and so on. And then finally, it's a little cut off right now, on the right you have index.php. So index.php is basically the fallback for all other templates. So if you forgot pretty much every template except that one, it would still be able to work. So just a quick breakdown of some of the more common ones, and there's a lot more than just this. But these are some of the ones you might work with often. It's page.php, which is the default page template just for all static pages. Single.php, which is the default for all things that are posts. So that could be a regular blog post or a custom post type. And again, we'll talk more about those in a little bit. There's also home.php, which is where your blog home page template, that's your blog home page. So when you go into your settings and you say, this is my front page and this is my blog home page, that's the template the blog home page wants to use by default. Index.php, like I said, it's the basic fallback template for all other types. Then you have front-page.php. And we'll talk a little bit more about that in a second as well. But that's the template that's used for the front page, like the your static home page, if you will. Then lastly, you've got archive.php, which is an archive page template. So that could be things like a, it could actually be a category, which is kind of confusing because there is category.php as well, right? But an archive is basically any sort of category page for posts. So it could be a tags, a date archive, an author archive, what have you. It's like the ultimate fallback for all of those. And then category.php. And again, a category is actually a type of archive. But if you have category.php in your theme and archive.php, the category pages are going to use category.php. So sometimes that can be relevant to use as an override. So like we were talking about before, one of the first things you've got to do, of course, is you have to plan. You have to get a complete or mostly complete picture of what it is you're trying to do. As we all know, sometimes clients have a little bit of a shifting deliverables. They may not have everything up front, but you may be able to get out of them the essential information that boils down to what are we trying to do here. We may not know exactly what thing or widget to use or whatever, but we know what the end result is. And then you can consider ways that you can create that necessary functionality based on that insight that you get while making the management interface approachable. So again, what this means is if you're creating a place for somebody to go and type things in to make changes to their site, it has to be something that can understand. They can't look at it and go, I don't know what to do with this, because then you haven't given them anything of value. You've just given them a black box that will scare them and not be useful. So another thing that I find to be helpful is in the very beginning, I always try to think, what type of custom post types do I need to create? So a great example of this would be, like say, a site about an author. I write books, so I have a website. Maybe I want to have a page that lists all of the books, all of my works, in a grid, and I want to be able to have somebody click on that and then see information about the specific book in question. That book would be a custom post type. And again, we'll show an example of that in a little bit here. So you also want to try to think about how many unique templates that you need to create. So one thing that when we're talking about templates is all those ones that we saw before, those are all defaults. You can, however, just create your own arbitrary template files and then assign those to various pages, poster, or other kinds of things in various ways. So you may say to yourself, well, I have all these generic ones, but I need a special template that's full width instead of having a sidebar or vice versa or some kind of thing like that. And then you also want to try to think about what kind of external libraries or plugins you'll need to create these components or templates, something like, say, modernizer, slick.js for a slider, animate.css. Try to think about those things in advance, if you can. And then I would also recommend trying to think about what kind of global options you might need. For example, if somebody has company information, like an address, a phone number, a fax number, or whatever, that appears in multiple places throughout their site, it's usually advantageous to provide a spot for them to enter that information and then maybe use a short code or something so that they can update it in one place and it goes everywhere, things like that. Another great example of this is social media links. You want to give somebody the ability to pop in their Facebook URL or whatever without having to use a special plugin just to do that. That type of thing would make sense. So once you wrap up your plan, you should ideally have the necessary information that you need to begin building. So what that means is, if you don't feel sure about what you're going to build or you don't feel confident, you might want to try to plan a bit more. But if you can't, then that's okay because sometimes things get tweaked as you go through it. Sometimes you have the best plan in the world and then you get 30 minutes in or 10 hours in and all of a sudden you realize, you know what? You need to change my approach. And that's totally fine. So now, let's talk a little bit about ACF or Advanced Custom Fields. This is one of the most popular plugins in WordPress. As you may, for those who aren't familiar, the counter for active installations kind of stops at one million. So there's definitely more than just one million that have this particular plugin. It's, at its core, it's basically just a plugin that allows you to easily associate data with posts in WordPress. Now, that also could mean pages, right? Because technically pages are a post type or whatever. But you can basically attach data to things very easily, very quickly, and in a variety of different helpful and useful formats. Like having a date picker, for example. Or the ability to create variable amounts of things like slides. And we'll go into an example of what something like that looks like here in a little bit as well. And one thing also that I just want to shout out for is Socheep. Socheep. Like, I'm talking $99 for unlimited sites, one time fee cheap. Updates for life cheap. So in the sense that when you buy it, it pays for itself after about one project. But there is a free version as well. So you don't necessarily have to buy a license for it. But if you want to, it's very affordable. So some core bits about ACF is it has a concept of fields, right, just like the name implies. So you create fields which are places where you enter data. So that could be just a text box. It could be a text area. It could be a gallery of images. It could be a Google map address. All kinds of different things. And those fields are ultimately placed into field groups, which are collections of fields, that you can display at various locations. So for example, if I was creating a book, custom post type, and I wanted to enter some data about that book, like the author, the published date or whatever, I would set up a field group for those fields and then tell it to appear when somebody's editing a book post type in the interface. And again, I'll show you guys an example of that here in just a second. So for all the database nerds out there, this data is all stored in post meta, so it's pretty easy to access. And I guess the main value proposition is like I was saying in the last slide. It's all about just associating data, which sounds like a really boring thing until you actually try to create a bunch of custom fields beyond just an input box inside WordPress. It's actually really laborious to do. And even if you know how to do it, it just takes a lot of time. So a quick breakdown of the pro versus the free version for ACF. All the core functionality in ACF is available for free really. There's just a couple things that you get with pro that are particularly useful, things like a repeater field. So if I wanna have a variable number of things, like slides for instance, and a slider, a flexible content field, which is kind of similar, allows you to basically create output that you can put in different orders. That's the worst explanation of all time, but I would consider reading more about it later. And the group field and some more. We're not gonna get too much into all this stuff just because we only have so much time, but I'd encourage you all to take a look. There's a lot of really cool things. And like I was saying before, it's really cheap and it's definitely a time saver. So you can do things like make Google Maps with markers, sliders, carousels, accordions, and so on. So like we've said, I'm gonna say this again, working with data is very important and proper data handling is key. So my suggestion is to try to structure your templates and logic around variable-ized data. So the worst is hard code all the things, right? Like the idea is if you need to make an edit, say to the name of something or the output of something that occurs in multiple places, you should only really be editing that in one spot. If you have to edit the same thing in six different places in one file, you might wanna try to rework that and say, how could I reuse this more efficiently? Another thing to think about too is if you're using a function of some kind to output information and you're recalling the same function multiple times, that also is, you know, it can start to get a little bit less than performant too. So let's go into a little bit about ACF and custom post types. So we talked a little bit about this here. This is an example that I created of a field group. And so we can see here, and it's a little fuzzy, so I'll read it in case anyone can't see. It says book details, that's the name. And then we have two fields here, author and publish date. One of those is a text field and one of those is a data. In fact, I should be able to show you all this directly. There we are, that's a little better. So you have the author, the publish date, and then you have a text field and a date picker, right? So what this actually looks like, if we go to all books here, you can see the book that I created earlier. So now we're looking at the gunslinger, right? And so we can see this little excerpt about the gunslinger. And then down here we have a spot called book details where I can just type in Stephen King and then I can choose that date right with the handy little picker. The process that the time it takes to create something like this is roughly about two minutes, assuming that you're relatively fast with the mouse, so your mileage may vary. But it's ultimately very simple and you can get really powerful in general. So there's another example of that, a bit of a wider view, but it's a little blurry. Sorry, projector. So now that we're kind of ready to get started in building things, we've done some planning, we've done some thinking about what we wanna do. No, we wanna use ACF. Yeah, that's great, and all these different things. So what now? My first recommended step is to install all your required third-party plugins. So if you use something like Yoast or ACF or whatever those things, just install all of that stuff right away. So that way you don't run the risk of trying to do something and then it fails. Oh yeah, I need that plugin installed in order for this function to work or those stuff. It's just, I find it best to set those things up in advance. From there, you wanna create your custom post types. Again, I always recommend doing this early just because it gets you thinking about them. It allows all of that data, or you have a place for your list field groups for the data to live. It's usually best to start with something like that. And then also set up a field group for modular, for a modular template if your build includes one. So what does that mean? Well, with the flexible content field, you can basically create a series of different choices that somebody can pick and then insert into a different order on the page. So say I created a slider component, an accordion component, a page content component, and a full-width image component. And I wanted to make those with ACF, but I also wanted to give my client the ability to reorder them on the page or maybe take one away or not. You can use ACF in a single template to create a flexible layout that lets somebody do those things really easily. So you define what the choices of those sections could be, and then somebody can choose the order in which they appear. So in general, I think it's a good thing to have if you have ACF Pro, and that's something that brings value to your client. However, if you're having to build pages that are in a very specific layout very specifically, like this is a very intricate design and this stuff has to be just so, then having a template like that maybe doesn't provide as much value. Next step too is if you have a sitemap that you know for all the different static pages you wanna create, I usually go ahead and just create all the top-level ones. If nothing else, so you can fill in things like menus or just click around and see different formats for things, it can be pretty helpful. So next, I'd recommend setting up your global options using either the Customizer or ACF Options pages. So this is one of those pieces of advice that's contrary to uploading a theme to the WordPress repository. If you're uploading a theme to WordPress like one of those free themes you can just download, those have to use the Customizer for option pages. If not now, then soon, right? But when you're doing it yourself, you could just use an ACF Options page and ACF gives the ability to create those on the fly very easily so you can just use your field groups in there like anything else. Just nice, because with the Customizer you have to actually write PHP or JavaScript in order to create those fields. So again, if you're not super PHP heavy, you may find that actually a little easier. So this is an example of a template. In this case, this is the front page template of this theme I was working with, right? So it starts off with a call to get header here at the top, which pretty much does exactly what you think it gets header.php and sticks it right there at the top, which is like the start of your HTML document. And then the footer with get footer right down here. And then in this case, we have some foundation markup for the XY grid that they have. And then there's a WordPress loop here and what's this, get template part page, parts front page. This right here, this get template part call is referencing a partial called front-page.php, which I know is kind of hilariously bad to name like that, but that's how it was when I started working with it. It's a partial though, so it's basically spitting out the main inner content of the page. We can see that we have like the main element here, which contains all the main content for the page, right? And then this is inside of it. So this is basically the internal guts of that page. But because all of that stuff is in its own file, it's much easier to read and digest this. I can scan through and say, okay, so the stuff that's right here, it's all in this file. Makes things nice and easy from an organizational perspective. So this is an example of a component that I constructed for a previous demo that is an image slider that's powered by ACF. So what we have here is a repeater field that allows you to choose a series of different slides. So let me go ahead and pull this up so you all can see it on here. And again, it's a little squished, but the concept I hope, oops, that is not what I wanted. There we go. Okay, so see here we have a slider demo, right? And so I can go ahead and put an image and a link, an image and a link and so on. And I can add these slides. And then if I want to add another slide, I can just click the add slide button. And now I have additional fields and I can create an additional slide here, right? So this is the code that actually makes that happen. You may remember before, I was talking about variableizing data, right? That's what this little block is for. So I store this information inside these variables. So what this means is if these field names ever changed and this is a really basic example, so it's maybe not as best to illustrate the point, but I can only show so much on one projection, right? But this now is a lot easier to work with, especially if you have a more complex template. So if image appears, say the image was being called in a few different places or in a few different contexts, or maybe there was some text below the image that was also linked, but it had its own anchor. So I'm calling that link multiple times or whatever. Then being able to define that data in one place and then reuse everywhere else that does represent a lot of value. So a couple of tips for success here. So when you're testing in, oops, went too far. So we're talking about frontpage.php a couple of times, right? So there's some cases where you should use this and some cases where you maybe shouldn't, right? So if you need to build a unique template, right? Just for the homepage. So the homepage, whatever that homepage is, always needs to have a certain look to it over certain options available or whatever. Then using front-page.php would actually have value. The reason why is because if you sign a template or a page to front, like, excuse me, if you sign a page or set a page to your homepage and you have front-page.php and then you try to override the template with the template selector, it's not going to work. Front-page.php takes ultimate precedence there, which is nice though, because that means it will approve the setup. It means that it's less likely that somebody's going to choose the wrong template or use the wrong page slug or some other type of thing. It's a lot more bulletproof. Now, if you're just using a generic page template that has a bunch of flexible sections for all of your pages and the homepage just has a specific arrangement of those things, it would probably make more sense just to use the regular flexible page instead of having a special template just for the homepage. So really quick, as far as assigning templates to pages and posts, if you've never seen it before, that's done just right here on the WordPress edit screen for a page or what have you. So another thing that is a common mistake that you see in a lot of older custom things, but it still comes around from time to time, is people in queuing scripts and styles just by literally making a script tag. I could go into my header and script and source and all that stuff. While that is fine, when you use the actual WordPress methods, WPNQ style, WPNQ script, it allows you to register those scripts and then possibly do things with them later. So for instance, if I had a script that I wanted to load on every page except one page, using this in queue method, it makes it very easy to do that or if it was a multiple conditional thing, like if this thing's here, do this, but otherwise do these things. You can do stuff like that because you can work with these scripts in a programmatic way and possibly alter them before they've been output anywhere. And if you're not familiar, the action that you need to attach a callback function to to use these is WPNQ scripts. Now, if you don't understand the word of what I just said, if you're not, because the codex is very detailed, it has lots of really great examples. And if you look at a few of the code snippets there, maybe try it out yourself, you'll see it's pretty approachable. So this is a big one that I have a lot of personal feelings about, which I'll try to keep to a minimum, but when you're working with images, especially with like with ACF or the customizer, there's a new media control that you could use that outputs an attachment ID. I always go for the attachment ID. And the reason why is because once I have that idea, I can literally do anything else that I want. The ID call is very simple, getting an ID for something is very easy, but I don't need an entire object's worth of data just to get one little thing. Like if I just want the URL, I can use WP, get attachment image source, or if I want just an image tag with my source sets and all the attributes already done for me, I can just use WP, get attachment image. The best part about using both of those things, by the way, is you can pass an image size to that, just like you came with the post thumbnail. So you don't have to worry about figuring out what's the URL for insert size of image I created here. You can just pass the name of that image size and WordPress does all the work. And there's a link in the codex here for WP, get attachment image, which I would recommend looking at it if you're not familiar, it is very helpful. So for testing and debugging, your friend is WP debug. So if you've ever looked at WP-config.php, which is where all your like database credentials and stuff are stored for WordPress, you may have seen this constant WP debug defined somewhere. So if it's set to true, it just means that PHP errors are going to output on the actual page. So if you're in development, and you've ever gotten that dreaded widescreen of death thing, with this turned on, you wouldn't really get a widescreen anymore. You would actually get a PHP error, say error online X or you missed a semicolon or whatever it is. In general, when you're developing a theme, I always recommend turning this on. If you're in a situation where you're getting a ton of notices or other things that are from an extra plugin or something and you can't fix them yourself, you just gotta ask, is it not a big deal? Is this something I can live with? Or maybe should I use another solution? That doesn't throw as many errors, right? And so the default value of this, like if you didn't have WP debug, the constant inside WP-config, it would default to false, right? But if it is there, you can specify it as either true or false. Also, for those not familiar with PHP, Vardump is a fantastic resource for figuring out how your data is being, or what format your data is in or what the data is. So it not only outputs the data stored in a variable, but it'll also tell you the type and usually the count or length of that thing. So if you're having an array and you Vardump an array, it'll say array, and then it'll give you a number of how many items are in that array. Or if it's a string, it'll tell you how many characters the string has, which is nice because if you need to make sure that this variable is actually a string and you're, wait, I don't think this is working right, then test it. Is it outputting as a string? Maybe not. Maybe it is. So if you wrap a Vardump statement in a pre-tag, like in this code sample down here, this will kind of pretty print the output, so it's a lot easier to read. Like if you just do a Vardump regularly, it's just gonna put a bunch of text in line. It's really gross and annoying. But with pre-tags, basically these styles are largely just default, but it'll go ahead and make it all pretty and a lot more human legible. So in conclusion, I've said multiple times that there are a few different ways you can do things, right? There isn't just one, this is the only way you can do it. This is the only way that makes sense. But it's also important to note that it's not just about what you like, either it's about the situation that you're in. So if it makes more sense to go one way for this situation, you create a better result for your client by doing this thing, then maybe that's the way you should go. Also, make sure you plan before you code. Even if it's just as simple as John and down in a brief outline or notes or whatever works for you, try to think about what you're gonna write before you actually write it. And, excuse me. As I said before, and I just wanna repeat it a million times, always try to keep your code as dry as possible. So you're not repeating yourself. You're keeping things simple, easy to edit. So if you get a call, hey, you just spent a couple hours and revamped this site you made for me the other month, it's not a pain for you to do that either. So it's not just even for the client's benefit. Structure your data for optimal sanity. So, like I was saying before, try to make sure that if you're working with data that you're handling it in a way that's clear and easy to understand. What that could mean is even just naming your variables in a way that makes sense, right? If I'm storing the data about a book in a variable, what should I call it? Book, not like cheese whiz or something. So I'm gonna look at that and go, what does that have to do with books? This makes no sense, right? So, one of the other things too, I always try to think in terms of pieces, right? A dynamic website is all made up of pieces. It's not just one big file that you write all your stuff in. It's not one index.html file. It is a conglomerate of stuff that all feeds in and plugs in. You just gotta think in terms of pieces. And what I mean by that is if you're writing, if you have one function and your function is on PHP file, that's like 200 lines, maybe it should go on its own file. Maybe it should be more organized that way. Or if you have a couple of different sections that are all going into one page template, maybe those should all be their own partials. Those kind of things.