 As for me, I'm Mike Hale. I've been in WordPress since around 2011 or so. I did a lot of corporate development before that, a lot of .NET, Stephanie, .NET developers in there? Never. Never. Never. All right. All right. I run a digital marketing agency called Stomp Gear. We do growth marketing for recurring revenue companies, but I'm also a freelance WordPress developer. I spend most of my time working on custom plugins for people, whether it's a direct client, or do a lot of work with other agencies. So this is going to be not necessarily plugin-based. This is a developer talk, but this is also good for people who are just implementing sites or troubleshooting sites. You don't have to actually write code, but you should be able to read it. So I said I'm a freelance developer, so this is how I spend most of my days. Just kicking back on, I think this might be women's feet, I'm not sure. My legs are not shaved, so I can't tell. Just kicking back on a beach, relaxing, having fun, doing nothing because freelancers, how many do we have? That's pretty much the life. I made a mistake this day and next to my beautiful little wooden tiki lamp thing that keeps the mosquitoes away, I brought my cell phone down to the water, and it's ringing and I said, okay, I'll get it, and it's my client. If you ever do support for a client and you just get that call and they say, hey, my site is slow. Can you fix it? You said, sure, that's what I do, I fix slow sites. You know, there are a million different reasons why that site could be slow, but you're going to have to figure it out. So WordPress, we're going to go look at it, see why it's slow. This is WordPress, by the way. Some gamers may know that's a gaming system, but no, this is WordPress. It's just a little black box with some plugs. You put something in, it spits something out. How it works, nobody knows. It's just you type in a URL and it does stuff, and it puts stuff on the screen magically, black box. For most users, that is a very good thing because that is what we want. We don't want them understanding, well, understanding how it works, but they don't have to know how it works under the hood. They know if I put in a URL, I click save, I add my content, I click save, it's going to show up on the website. Black box. Now, this is developer track, so I'm assuming people here have done some development. We know if we open up that box, this, my friends. This is WordPress. Badly coded old, this is, this obviously they have not updated these plugins. They're to the point of being rusty. Everything's just kind of tied together. The only thing, there's no duct tape in this picture. There's a lot of duct tape in WordPress. So how are you going to figure out how a site is performing? And this isn't just saying the site's slow, but that's the most common one. There could be some problem. Something might not be working. Something might not be appearing on the page where they expect it to. So how are you going to figure out in that? Well, yeah, I got a prop. What if I told you that there was a portal, a magical door, into WordPress, inside WordPress? No, it's a secret, shh, don't tell anybody out there. You didn't come to this talk, you didn't get to know it. I'm assuming this is the talk that has, wants nothing to do with WooCommerce, because if it is, you're missing a great talk next door by Lemma, so WooCommerce, come on. Who's going to buy stuff off the internet? The Debug Bar, the WP Debug Bar. So this is a WordPress plugin that's available. Just a quick show of hands. Has anybody used the Debug Bar on a site before? Okay, oh good, good. Usually, if I ask people that, it's like, the what? It is called the Debug Bar. It has nothing to do with stepping through code and debugging code, but what it does is it's going to give you some reports of what's happening inside WordPress on the page that you have it. Couple notes about this is one, this is not something that you're going to want on a production site unless you are actively troubleshooting it. If it's on the site and you're not an admin user, you're not going to see it on the front end. It will track both admin side and front end side, but there is going to be a little cost, your site was slow, it's going to make it just a little bit slower when this runs. So if you're not actively troubleshooting a site, this is not something you're going to want to leave on on a production site, because even though it's not showing it's still doing some stuff. And what this does, this gives you some infer, the basic one, it just gives you some information, very little. It'll tell you what page you're on, if there's a rewrite, some basic information like that. If there are any errors on your page, sometimes behind the scenes PHP will send notifications if there's deprecated code, or if you're using an array where string is, it doesn't cause a fatal error, but it's just not right. PHP will spit out those debug messages. If you do that, they will show up here, and you can look at those too. I do another talk about building developer friendly plugins, and one of those things is you should always run your code with debug true on when you're doing development, so that you see those things, so that when it gets to the end user, I shouldn't see any notices from your code unless it's something really strange is happening. The nice thing about the debug bar is, I said this doesn't really give you much, but show you notices, deprecation notices, fatal errors that were white screen, but there is a whole set of plugins that you can use for this as well. And I'm gonna run through a couple of these, and kind of where and when you might use them. First one is the debug bar actions and filters add-on. If you're gonna install one add-on, this is probably the one. And also just FYI, I will post the slides to the WCGR hashtag after, if you wanna see a few more of these. So WordPress, if you're coding to a lot of it, the actions and the filters are the big things. The actions are when the code does something, also run this code, that's all the hooks, that's the beauty of WordPress. And filters are saying basically the same thing, when I get this data, do something to it and then output it. So if I'm filtering a title, or if I'm doing something, when I purchase something and become or send an email, those are all the actions and hooks. I'm not sure the exact number of the average WordPress site, but it's something like 11 billion actions get called every page. Maybe not that high, but it seems like it sometimes. If you're developing plugins, it's a good idea to offer these actions and hooks, these hooks and filters to people that are using it so that they can customize your code or do things in reaction to your code. Having them in there is not a big deal. Saying do action isn't going to really cause issues, but when you have an action or filter, which are both hooks, I use those terms interchangeably, that starts causing an issue, that's where the problems come in. So the first thing this does is you'll see over here, now you have this action hooks and filter hooks part. This is not part of the regular debug. This will show you a list of all of the actions that are on that page. When that page runs, any actions that get fired are gonna be on this list. It's not the list of everything on your site, but whatever current page you're in. And again, that's on the admin side, if you're looking at it, or on the front end side. One nice thing about this is you could, if I do a lot of work with other people's plugins, and I have to modify them for a customer site or I have to add some functionality. They might do 80% of what I need, but I have to add some code to make it work for this one particular customer situation. One of the first things I'll do is once I install it, if I'm on, say it's a WooCommerce and I'm on a product page, I wanna see what all the different hooks are gonna be available to me on that page. It can just be a little easier sometimes than looking through all the documentation. It's definitely easier to looking at the code. There's one line of code that will put these on there, just do action. It works the same way for the filters. This will tell you what hook is there, the priority, which is nice. Sometimes you can see why is something firing before another. And then this is the callbacks that are actually called when that hook happens. So when something's being filtered, this is gonna show me what action is firing and then what code is happening to it. I had a site where it was a membership site and when you order a product, you get access to the restricted content on the pages and it sends an email and says thank you for ordering. And every time I was testing this, I was getting two emails every single time. And going through and I'm saying okay, I know it's happening on sale completed. I know that's where it's going. So you can put the debug bar on, find the sale completed, oops, find the sale completed and then look and say okay, what methods are being run on that hook? And then I found the second method and it was actually my fault. It was a copy of the plugin that had some test code in there but it took me a while to figure it out. But by being able to go through this, I could say okay, whenever this thing happens, what else is happening? And it was a way to get back and look at it. So that's the actions and filters plugin. Another fun one is the debug bar console add-on. This one's dangerous. This lets you edit and execute PHP code well on your site. It just gives you a little box and you type the PHP code in there. And it does format it the way that it does in the new editors now. It also lets you do the SQL server. It lets you run SQL commands in there and do database stuff. So PHP is just a simple PHP editor. You can run it, call it and then it just has an output. The only issue, it doesn't always work the way you'd expect it to. Especially when it comes to global variables. When I first put this on, I was troubleshooting another site and I had a custom post type and it had the global post. And I kept saying it here, global post and then trying to get it. That's not there. So I'm not 100% sure why. I may have been doing something wrong, I don't know. So it doesn't always work the way you might expect it to. But if you're on the admin and you wanna see what's the post meta for something without looking at a database, you can run something here. It's just a way to run code. I don't use this one much. Honestly, the SQL code editor, a lot of times I use a PHP storm as my IDE. So a lot of times if I'm looking something up, I'm looking it up in IDE. But this is a very powerful tool to do this. The other thing about this is you might have a test code page where you don't have some code written yet, but you need to add a meta field for a post type. You can do that here. You can put your update meta post field and put the value. And there's a lot of things you can do. You're probably not gonna be doing them a lot or too frequently, but it does let you. The other one with this very similarly is this gives you a SQL statement command. Again, I'll use workbench or the integrated SQL IDE in PHP storm and things like that if I'm actually looking through the database because this is very, not very friendly to look at. Oops, wrong button. It's not very friendly to look at. You can't really copy out of it, but you can't edit anything. So this will just run your SQL statement and show you the results. And you can do updates, selects, anything you need to do. The debug bar constants add-on. So in PHP and any language really, you can define constants. So constants is I could say define my plugin version equals 1.0.1. Anywhere I want to get, check that version instead of checking if it's this value, I can just check against that constant. I can't assign that constant a value after the define. It's immutable. It just won't let me, okay? So that's one where, and I know where if somewhere in my code I need to check, say I have a status code of, cancel, status code of active. I don't want to check cancel and active all the way because maybe I've changed those some days. Maybe some point in time it changes. You define the constant and then I just say check for my constant. Constants are usually all uppercase with underscores in between the names. So again, they're immutable. What this plugin will do is it will show you all the constants that are defined. This one isn't, I don't believe this one's page specific because it's basically all of them. It breaks them down into three pieces. The first one is built in WordPress constants that are defined. Apps path, cookie path, these are all built in WordPress constants that you might need to check. You don't, you know, there's not a lot of these that you're checking. Apps path, if you see a plugin that's usually the first check. If this not defined, it's probably not a WordPress site. And then you only see, you know, exit so that you can't access pages directly. It will also show you any WP class constants. So classes are just in an object-oriented way of programming, which is an option in PHP. You don't have to do it that way, but it does give you some benefits. I'm a very, you know, object-oriented development when I do it. It's just, it's a style thing. There's some things you can do with namespaces that give you some of the benefits, but it's just a kind of a clean and encapsulated approach to doing things. And this will go through all the different constants for all the different classes. And the class that debug bar constants, see, the debug bar is giving some of our own stuff. Accusement, that's, Accusement is a class. So these are all the constants that are defined within that class. It will also give you all the current version of your PHP constants. These are ugly. These are things like, you know, calendars, what certain, certain values means, you know, min lengths for certain values. The only time I've ever come across where I really have to go back and look at constants is to see if something is defined, and if it's not defined and I'm expecting it, I have to figure out why that constant is not in the list. The other thing with it too is sometimes different versions of things will define things differently. I can look back and say, okay, why is this, you know, I'm expecting this value from this constant, but it's not working. Let me see all of them. So probably not one that you would use, you know, a lot, but it is there when you need it. One of the other plugins is the debug bar cron add-on. And cron is an interesting thing in WordPress. It's basically a task runner that's at scheduled intervals or at a scheduled time. The WP cron, you can add that in your code, you say basically saying every hour do this thing or at this time do this thing. It's not always, it's not always sure fire. If you're on a low traffic site, the way this fires is if somebody comes to your site and it loads, it basically is checking to say, hey, do I need to run this cron job? If not, it doesn't run. If you have a very low traffic site and maybe you go a day without a hit, those crons aren't going to run. What does that matter? Well, what if you had a scheduled post that you had scheduled to publish that next day? If nobody's hit that site, your scheduled post is not going to publish and it's just going to sit there unpublished. And there's a plugin that you can get that will go back and do missed ones. This is good for a lot of things. It can be a little hit and miss. Some hosting companies have an external cron that you can run that will run a script for you within that. That turns it off. What it'll show you is the total number of events that are scheduled, whether it's doing the cron at that moment or not, when the next one's going to go, and then what time it is. So this is next, it's going to run this again in 17 minutes. And this, the lines that I hear what it gives you is what, or when this one's going to run. So it's hourly, daily, daily. What's going to run when we do it? Because you say add cron, you give it a time and then you give it the function that you want to run. This is the actual function that's going to run. And then internal val, I don't know what those mean. And then it argues if you're passing any arguments to it. The only time I've ever done this to see if something did run, or if it didn't run or when something is set next to run. This one is a very, very useful one. This is the list script style independence. I should take a step back and just say, when you, these are all available in the WordPress plugin repo. I'm showing about eight of them. There's a lot more, some are very specific. Some might be specific to WooCommerce or to a specific plugin they have, sometimes even the different plugins. So what you do is you'll install the debug bar and then you'll just install the plugins that you want. You don't need to run cron if you don't care about the cron. You're going to run the constants if you're not ever looking at it. I have a way I'm going to show you later where I have them all kind of installed at once. But this one is one that you're probably going to use. This will show you all of your include styles and scripts and their dependencies. So the scripts dependencies, the first three, obviously, you know, jQuery Core, jQuery Migrate. And then if your jQuery is loaded on this page and then it depends on these two. I don't know how many times, I'm going to plug in, register a script and maybe my enqueue script is just a little, you know, I have a typo in it or I have something wrong or the script isn't there or whatever. And yeah, you'll see those usually in the console, the console log in the browser. But what this is, is you say, hey, I'm expecting the script. Why isn't the script here? Or why is the script failing? Is one of the dependencies not loaded where it's supposed to be? This one is a good one to go through and say, you know, how many are there? One of the things when sites get slow, one of the big things on sites is when you have a lot of external requests. If you go to Google PageSpeed Insights for any WordPress site, and it's gonna say, you're loading all these different JavaScript files because a lot of plugins will put their style and their script and then another plugin will have their style and their script. And then you start getting 18, 20, 30 different external scripts that can be run. One of the best ways to go around that is there are plugins like W, what is it? Autopmize, auto-p-tomize, it's a weird one. But there's ways that you can put those scripts instead of the separate files, it will put them all together or concatenate all those scripts. That usually works, almost always works, but you run into issues if those scripts sometimes have things named the same or similarly, or there's a certain order or whatever it may be, there's a few times where those that concatenate a script will not work. Some of the caching plugins will do that as well. So you have to kind of try it on your local site, make sure everything works before you do any of those types of optimizations. But this will show you, so on this page, I have 22 total scripts and then 14 in cubed style. So I have 22 and 14 different CSS files on there, so that's a lot. And the other thing is the dependencies. If I know a script is depending on something and that script has not been loaded, then that script isn't going to work. The debug bar, reboot requests add-on, I like this one because I do a lot of code with third-party APIs. I write a lot of plugins that are calling some other service and if you're using what you should be like WP remote get, WP remote post, there's built-in functions in WordPress that let you call an API easily. They wrap up a lot of the plumbing around making an API call and then just give you back the results. This gives you a lot of information. If a site is slow, if a site is slow and I know I'm calling different third-party APIs, maybe their API is taking 20 seconds to return my result back. This one, it will show you that because it's gonna show you all the HTTP API, and these are, again, third-party requests on a different site on that page that are being run. Some details around it, what the address is, what the parameter was, how long it took, the total number of requests. There's also an option, it will show you all the parameters that you sent back and all the response headers that come back. So maybe if a call is failing, you can look at it and those response headers, maybe it's unauthorized. Maybe your API key went bad and you need to refresh. There's a lot of different ways you can do that. So if you are having code, writing code, or if you're just troubleshooting a plugin that makes third-party API calls, that debug remote request add-on is a good one. And again, I didn't have a good example, but this will just show there's one site I'm calling a thing on ConvertKit. It's actually coming back as a 404 and then there's all my information on it. The debug bar short codes add-on, I'm sure everybody here is familiar with short codes, it's just a little snippet in brackets that you put that gets executed when that page is run. This will show you all the registered short codes, what method gets run when they go in use as if they're in use on your current page. This is one where it'll show you a lot of them and then usage, so if you have a short code with parameters on there, it will show you how that one appears on your page. This is another good one. Sometimes you might, I mentioned before when I'm working with a new third-party plugin on a site and I'm not familiar with it, I wanna know, okay, how's that content magically appearing? Is it coming in in a short code? Yes, did they put a short code on this page? Is this the right one? Do they have the right parameters? This kind of saves me from having to go back in and look at the actual content of the page, even looking at the source code. This will give you some details on the short codes. The debug bar transients add-on, this is one that you're not gonna use a lot, but a transient is a way to save data for at most a certain amount of time. You can add it, it's volatile data. One of the most likely reasons you're gonna use this, I told you I do a lot of work with third-party API, so if I'm calling a third-party API and say that data is gonna be good for an hour, I don't wanna fill my database with stuff, but that data doesn't change. It's not like real-time stock quotes or whether, it's something that I'm just gonna save, maybe the next person's looking at it, maybe this person comes back to this page and wants the same result. I just gonna save it for up to an hour. The next time I make that call, I'm gonna say, hey, check the transients. Does this transient exist? Yes, use it. If not, okay, then make the expensive API call and come back. The tricky thing about this is you can set a time for that to expire, but it's not guaranteed to be there until that time. I ran into an issue where I thought I could save something for two minutes or five minutes or whatever it was and that it would be there, and at times when the WordPress crown runs, it can get rid of transients before the expiration. The expiration is a maximum. There's no guarantee it's gonna go up to that. Lesson learned, the hard way. Along with the debug bar, this is actually a separate plugin. And Kyle, if you guys were in Kyle's talk just previously, he talked about the query monitor. This is a super, super useful plugin. Even if you don't do all the other debug bar stuff, this is a really good one. It works like the debug bar and a lot of the debug bar plugins or the add-ons can be used within this. It kind of has its own UI. If you're using this and the debug bar, it gets a little goofy because you have the debug bar section and then you have the query monitor. But what this does, which is really nice, let's just show you how long it took total for the queries on the page. It'll show you the actual queries, what called them, so you can see things getting called, the get option is gonna be called a lot. And then the time, this was on my dev environment, but it will show you even number of rows. That's another key thing. I had a site, it was a membership site, and the homepage was really slow. It had a query that would return every member. And they had about 40,000 members on their site. So you don't need 40,000 members on one page if you're just checking for one user. So that was obvious. There was a goof in the code, but this was a good way to say, hey, why is that so slow? Okay, well, I'm returning 40,000 records and obviously I don't need them. One way to get this, all kind of all in one is I developed a plugin called the debug bar suite. It is not in the repo, it is on GitHub. It uses Composer to pull down all those different, all those add-ins I just showed you. And then in the admin, there's a debug bar suite. So you could pick and choose which ones you want on. And you can also add your own add-ons through additional hooks and filters that will put them in there. The reason I did that is in development, I would download the plugin, the debug bar. And then I would have to install this add-on, and that add-on, and that add-on. And I use about eight of them in development. I just have them there whether I'm gonna use them or not. So this is just a nice little tool that you can use. Pull it off of GitHub, put it in your development site. Probably not one you're gonna want to debug something on production ever because it does use Composer so you have to pull things down like that. But if you're interested in, this is a nifty little tool that I built. And there's a link down there. Start it, love it, I don't know. Make it better. It's open source. So now we've done all this. We've solved all of our clients' problems. That's their website. It's really, I mean, look at how fast this little dog is blurry. I mean, it's so fast. I'm surprised his tongue isn't flapping in the wind there. And then what do we do? We go back to relaxing, sitting on the beach. All right, I think I have time for a couple. One or two questions? If anybody has any? I know that was a lot. I know we covered a lot. I didn't want to go into way too much detail around hood. I just want to give you kind of an intro as to what they can do. I would suggest install the debug bar on a local development site. Because we're all developing locally, right? We all have a local development environment. We're not developing on production. Just in, if you are, don't tell me. But play around with it. Add some and start getting used to it. You'll start seeing some of the cool things. This was all over the last year or two. I've really been trying to level up my development side. I've been doing more unit testing. I've been doing more code standards. Any tool that I can put in my arsenal, in my toolbox to make myself a better developer I've been doing. This one is very handy. And the more and more I get used to using it, the more time it saves me. So please check it out and try it. I covered it all. Yeah. Is there a reason you don't have your suite available on the as a workbook plugin? I didn't put it in the repo right now just because when you set it up, you have to run a composer command and what that'll do is I have it set to use the actual plugin repos once. I don't have it set up now to where like, if one of those add-ons is updated, I know because I have one that has them all. It's just not quite polished yet. It wouldn't be against any of the terms, probably next version or so. At some point, I would like to put it in there and just make sure it's cleaned up a little bit. But yeah, so I just hit, I have it on GitHub because you know, most developers can pull it down. It's really, the average user is not gonna put it on there. So, but yeah, but I might do that at some point. Hey, contribute, get it ready to go. Yes. Yeah, the debug bar should work on anything. And it helps you because sometimes if you're doing an older versions of WordPress that'll show you the PHP constants. One, that might help because it might be an older site that has an older server. It's not older than PHP. I'm sorry, this one helps too. Sometimes you don't always know on a server what version of PHP is there. You might not have access to the control panel. You just have admin access. If you put this on and you look at those PHP constants, you'll be able to tell the version and you'll be able to kind of get some information of maybe things that you're expecting to be there that aren't. But yeah, it should work across versions of WordPress. If you have an ancient version, maybe not, but yeah, it'll work on that. There's no issue there. Some of the other add-ons you might have an issue with because if they're newer and they're using something in their code, but those are kind of specific to different plugins or different things that you might see. All right, thank you very much.