 Welcome. I'm Michael Wood. I work at Bluehost. I've been doing WordPress development for, I think, what, 15 years now? So, done a lot of PHP and various things. So, topic today is interactive debugging, and we'll kind of jump in here. So, I think everybody, when they first start out as a PHP developer, they have to figure out how to debug, right? So, usually there's kind of a progression that happens. The first step is what I call black box debugging. So, this is where maybe your new WordPress developer, and you're working with WordPress, and WordPress is just this black box that you don't really know anything about, and you don't always know what to give it or what you're going to get out. And so, you're just kind of guessing at what's broken, right? You have absolutely no visibility. And then, you learn about this thing called var dump. And then we have dump debugging, right? So, you start having slightly better guesses about what might be broken and dumping out clues onto the page as to what might be going on. Still very limited visibility into whatever the issue is. And so, kind of still a pretty simplistic debugging option. So, what we're here for today is obviously we want to go with interactive debugging so we can have full visibility of the code and understand everything that's going on behind the scenes. So, no questions. So, we'll get to the setup, but before we do that, just to kind of emphasize the importance of interactive debugging. As a new WordPress developer, I got very good at guessing what was wrong. And then, you know, var dump was helpful. But again, there was just so much about WordPress. It's very hard to wrap your head around all of the things that are going on. You know, everything from, you know, trying to customize roles in WordPress to, you know, routing and all kinds of stuff. So, when I first started working with somebody who was kind of my initial code mentor, he introduced me to interactive debugging. Now, granted, it was a lot harder to set up then. I spent two days, I think, trying to get it set up. But that was the key to me learning WordPress really, really well. So, that was the thing that allowed me to... And I probably did what most people probably wouldn't do, but I literally took a day and just started the debugger at line one of WordPress and went through, like, what's happening now? What's happening now? Everything that was happening on the front end of the site, from the URL routing to whatever else. So, I learned to hook in and create pages that don't actually exist, but they look like they exist in WordPress and do all kinds of interesting things. So, yeah, so if you've kind of seen WordPress, but not really, you know, delved it deep into any particular area, this is going to allow you to do that. And it's great if you run into a specific problem. So, you know, I've got this plug-in and this plug-in, and I can't figure out for the life of me why this WooCommerce product is just not showing up, but it's in the back end, you know, stuff like that. You know, you can just kind of jump in and start to figure stuff out. So, we're going to look at the debugging setup from kind of two angles here. So, we've got, well, I think most people probably use VS Code nowadays because it's really good with JavaScript. It's also good with PHP if you configure it that way. In my opinion, there's still some shortcomings when it comes to, like, heavy refactoring. So, I personally use PHP Storm, but I think that is also another very popular one. So, we're going to kind of cover that one as well. As far as our local environment, there are a lot of options for having the local dev environment. And depending on which one you choose, we'll determine how easy or difficult it may be to set up interactive debugging. So, the goal today is go with the easiest possible solution. And so, this is what we have. So, we're going to look at VS Code first. And so, first, and I do have some links and stuff at the end of the slides. I forgot to have an easy way to share that, but hopefully I'll do that, post it on Twitter or something after. So, VS Code, obviously, is a prerequisite if we're going to debug with VS Code. And then we're going to use local WP for our local development environment. So, personally, I use Lando most of the time. Lando has some easy options for setting up debugging. One thing to note about running, in this case, we'll be running something called XDbug. If you're running XDbug, it can slow things down. So, if you're not actively debugging, you can just turn it off. That way things will run a little faster. And then when you need it, you can turn it on and then, you know, run through your code step-by-step. So, once you've gone through the setup or installation of local WP, the first thing you'll need to do is go into the little add-ons sidebar, a little puzzle piece there, and then find the XDbug plus VS Code integration. And so this is basically just going to do the configuration for you. You don't necessarily have to do this. If you want to go deep into the settings JSON file of your VS Code and manually set it all up, you can, or you can just click that and it does it for you. This is way easier. So, next thing, if you don't already have a site set up in local, you'll want to go set up a site. So, you'll go create a site and you'll start it up. And then all you really do is go to the tools tab and click the run configuration to VS Code. That's where it actually does the setup for your settings JSON file and, you know, sets the paths for your project and does all that kind of good stuff in your hidden dot VS Code directory. So, you'll basically just click that after you've started your site. And then there is, in the overview tab there, there is a toggle for turning XDbug on and off. Like I said, way easier than the two-day installation process I went through when I first set this up. Way easier. So, literally just toggle it on. And then there's kind of two aspects, right? So, you've got your local environment set up, you've got a site running, you've turned on XDbug, you've got everything configured on the VS Code side, almost. And then, so there's two things that you're kind of missing, right? You need to make sure that the browser sets a cookie to let VS Code know that you want to debug something. And then on the VS Code side, you have to tell it, hey, we want to listen for a debug session. So, if you pick one up, let's work with it. So, the first thing we're going to do is install this XDbug helper for Chrome. That's assuming you're using Chrome. If you're not, I'm sure there's an equivalent for Firefox and all those. I didn't go looking all those up. But yeah, so you can install this XDbug helper. And then when you go to the options for this tool, you will actually select VS Code as the IDE key. So obviously, if we're using something like PHP Storm, we'd set it to PHP Storm. I think this is actually an outdated image. You don't have to go to other. I think it has its own VS Code thing now. But yeah, save that. And so then basically your cookie that gets set is going to be specifying VS Code as the IDE that it's trying to pick up. So in the top right corner, by your address bar, there's a little bug icon that will show up once you have that installed. And then you'll be able to click it and hit the debug option. So that just sets the cookie. There's really no, like, usually I'll just turn it on and leave it on, even if I'm turning XDbug off and then on and then off and then on. I just don't have to remember. And the cookie's always there. So I'll leave it on. So the one thing that we're still missing on VS Code side is the extension that actually allows you to do the debugging in PHP. So you'll want to go find the PHP debug. Extension, there are a few. This one is the most popular, and it is by XDbug. So that's the one that you want. And then once you do that, you will set a breakpoint. And setting a breakpoint is as simple as finding a line of code that you want to start debugging at. And you click just to the left of the number, and it'll put a little red dot there. And that red dot means that when your debugger runs, it's going to stop at that line of code. So then at the top, well, this little bar is actually kind of covering it up. I think the, yeah, so this is what the little bar up here looks like. You'll click on that. And assuming you've done a recent installation of local and you're running XDbug 3, which is kind of the default at this point, you'll just want to make sure that you click on that particular configuration so that it's correct. And then from there, the little, it's kind of weird because it's like two buttons in one button. The right part is a dropdown, and the left part is a button that you click to start listening for debugging. So you click the little green triangle, and then what will happen is it'll add a few things to the screen. So you can see up here at the top, there's like this little bar. It's got a pause button and a stop button and what looks like a rewind and some other things. So these are the buttons you'll use to kind of navigate in the code. And then down at the bottom, you'll have this little orange bar that shows up, and then that's how you know that VS Code is ready and listening for a debug session. So then the next thing you'll do is you'll go to the browser and load up your page or trigger an Ajax call or whatever it is that's going to trigger that code to run. And then you will be in an active debug session. And so as you can see, well, we kind of cropped it a little bit just to make it easier to see. But you'll see like all the variables and things that are defined at that point. Now, again, this is the index file in PHP, so it's one of the very first things it loads. So there's not a whole lot that's happened at this point. But any cookies that are set, so like you'll see your xdebug cookie in the cookies bar section there. And then any globals like server configuration settings that get set by Engine X or whatever it is that you're using. So all those things are there and visible. And then this little bar here at the top where you can manipulate the session, you can hit the resume button. So if you have another break point, it can jump to that. Or if you don't, it'll just finish loading the page. You can step into a line of code. You can force step into lines of code. So like if you have a conditional and you're like, oh, shoot, I need to get into here. But the condition is not right to do that. You could just force it to go into that condition. So a lot of cool stuff that you can do. Definitely something if you haven't done this before. Spend, even if it takes you a week, do it. Play with it. Force yourself to debug this way for a while. I remember when I first started, I would jump into a debug session. And I'll be like, this is complicated. And then I'll just do a var dump. But then after a while, it gets easier. You get more used to it. You figure out a little better how to explore and find specific things and to navigate from over here to over there and things like that. So definitely stick with it. It is worth it. And I've been using this for 15 years now. And it has, yeah, this is the difference between doing small websites and doing enterprise level work. So PHP Storm is not a whole lot different. Matter of fact, it's probably a little easier. You want to install PHP Storm. Just a little side note about PHP Storm. It is a paid product. However, it can be free, depending on what you do. If you happen to work at a school or have at some sort of educational, you know, location or virtual, they have some free licenses. If you are an open source contributor and you have a project that you manage, you can get a free license. So there's a lot of different things that could get you a free copy. But still, my code mentor used to say if this cost $1,000, you'd still pay for it. It's pretty good. So again, dependency, local WP. And then, you know, on the add-ons, this time we'll go with the XD bug in PHP Storm. And the setup there is basically the same, right? You create a site. Where did this slide go? Okay, it's had a little out of order, apparently. So you basically go into the tools. You click the configuration. That sets up the configuration in PHP Storm. And then you'll turn it on in here. And I'm assuming, yeah, we'll set up the Chrome extension. This time we'll go with the PHP Storm, which has its own option there. And save that off. Set up, you know, turn on the debugger. So each of these steps is, yeah. So I can tell you when I first started to, I forgot to click the listener button occasionally. And then I'd spend like three hours trying to figure out why I couldn't debug. So don't worry if that happens. It's just, this is what the slides are for. Just remind yourself of all the steps. You know, make sure it's on in the browser. Go into the PHP Storm. And there's this little telephone. If it's got the little red thing above the little bug there, it's off. And if it's, you know, no red, you're listening. So it's a little less obvious. That's the only thing that really tells you it's actually listening. So it's a little less obvious than VS Code. But then when you load up your browser, PHP Storm will automatically detect that there's an incoming session. And you can actually choose to ignore it, in which case your debugging will not work from that point on. So I recommend you click the accept button. And then, you know, then you have essentially an active debug session. The part where, the slide where you click the, here you'll actually click to the right of the number. But it does the same red dot. You've got some more options though, because you can actually right click when you set that break point. And you can say, you can set a conditional on the break point and say, well, if I, you know, maybe you're in like inside of a for each loop or something like that. And you can say, if this value is empty, then dump out this other value or something like that. Or well, then stop at that point. So if you've got like, I don't know, 1,000 entries that you're trying to go through and only like three of them are the ones you care about, you can have it just stop at that point. So same thing here. We've got all the cookies and all the other variables available. And again, I did cut some stuff off there. The goal is to actually go through a live debug session. So let's do that. So we're going to exit out of this. And let's see. Probably should open this up before, but we got time. All right. So here we are. We have this website called debug and X debug is turned on. The site is not running. We'll have to start it. Both will jump over the tools here for a second. You can see technically this one, we have configuration for both because I set up both. But we'll probably just stick with VS code for now. So again, if you are doing this for the first time, you just click that button. And then that grays that out. I think if you click and then go back, yeah, it's like, it grays out if you click it. And so it's kind of toggling between them, I think. So we'll click start. So that'll get the site up and running. And we will open up the site. So this is it. We'll go ahead and log in here. Actually, we don't need to log in. We'll just stay on the front end. All right. So now we're going to open up VS code. All right. So we've already got the particular project opened here. So this is the public folder. If you're not familiar with local WP, you can click go to site. So inside of my user folder, there's a local sites. There's an X debug folder. There is an app directory. And inside of that, a public directory. And that's where your actual code is. So that's what we have open here in VS code. So what we're going to do is we're just going to go to, let's see, index file. So again, just over here to the left, click. We're going to just ignore all these things. And then what we'll do is we'll come over here to the left. So when you install that VS code debug extension, let's see here. Does everything get bigger? Yeah. Okay. So yeah. So over here on the left, we have this run and debug. So when you click that, that's when you pop over here. You'll make sure that you've got the right selection. It's a little hard to read if you don't have it all expanded. But we'll go ahead and click the start debugging. So it's listening now. However, the easy thing to forget is, let's see, where did our extension go? Did I turn it off? I thought I had it on here. Oh, I was on another, okay. I was using a different browser profile. I don't actually think I, yeah, here it is. Yeah. Where'd it go? It's in this list somewhere. At the bottom? Yeah, there we go. So I'm going to pin it. So then we'll click that. Well, actually we'll close this down. So we'll click this here, hit the debug. So now our cookie should be set. And we will jump over. Well, actually we're not jump over. We'll just refresh this page. That'll immediately jump us into VS code. And so we're stopped at this line. And we can start to explore. So let's say, you know, we want to go to, I don't know, what plugins do we have running here? Not uploads. Let's see. We're running 2023. So let's say we want to learn something about 2023. Of course, this is a block theme. So that's probably not going to be very easy. It's mostly JavaScript. We'll see. So let's go into somewhere in WordPress core then. Let's find something in the includes folder. Anything you're interested in debugging? Post variables. Say that again? Post variables. Post variables? Yeah. Logging variables. You know, try to log into WordPress and within them. Right. Okay. So technically, we don't necessarily have to. Well, so if we jump back into the debug session here, we do have, and you can kind of expand and collapse these a little bit. But under super globals, for example, we do have, if you're doing a form submission, we have this post variable. We have our get variable and all these things. So let's actually just stop the debugger for a second. Go back over here. Let's just add some, you know, question mark. This equals cool and percent debug equals yes. And so now when we come, did it stop session so it stopped listening. So again, little things. So yeah, so you refresh. Here again, but we should have some more information, for example, in the get section. So we see this cool debug. Yes. So it's nice to be able to do that. So let's say we just wanted to jump in, right? So we have this step into, which is this. They're also mapped to buttons. So I hit F11. It'll do the same thing. And then we have a step over, which is F10. So in this case, I actually recommend using the, not the mouse, use your keyboard. It's a lot faster. So typically I'll have a button, a finger over F10. So like if I want to jump to the next line, I have to hold the F key down too. And then when I want to go into code, I'll hit F11. It's okay. This is a different computer than I usually debug in. But we'll just do it this way. Okay. So here we are. We're jumping in. So the very next thing we're loading up is this WP blog header. And so we can see what's going on there. So let's say we jump down to the next require here where we go into WP load. And so here we are inside of that. And we'll just kind of keep jumping in. So here it's defining abs path. So once we get past that line, we should be able to see where is it at? Can you show us what's in the locals? Yeah. So I believe there should be constants. Can you expand it? Yeah. Let me collapse this. They don't collapse as well here. So yeah, we have all our server variables. Say that again? The user defined ones. Expand it. Expand it. Expand it. Expand it. Right here? All the way to the bottom. All the way to the bottom. All the way to the bottom. Oh, yeah. There it is. Okay. Yeah. There we are. Yeah. So there's our abs path. And so yeah, you can see we've already set the, well, local WP sets the environment type to local, which makes sense. And then we have our abs path set so we can then jump in. So this is where it's going to do some setting up of error reporting. So if you have your WP debug and stuff like that, it's just kind of initial steps into that. So yeah, so you can see this is very helpful to be able to navigate. Now the hard part initially is figuring out where to start, right? Because you're like, well, I know there's a problem, but I don't know where it is. So a lot of times there, well, there is another cool tool that I do recommend. It's a step above dump debugging, but it's not interactive debugging. But it can also still be pretty helpful, especially if you're, for example, like trying to figure out, you know, what action hooks, you know, you're trying to dump stuff out on action hooks and figure out like what's going on. You could do that. It's called ray. The Laravel people tend to use it a lot. So it's a pretty handy tool, pretty simple. But again, you still have to put like function calls to ray in your code. And if you're running the plugin, there's a WordPress plugin. It won't output that stuff on a production site, but it'll log stuff as you're navigating. So, you know, it can be handy. And it'll actually tell you what line of code triggered it. So it can be interesting if you're trying to just like dump out some stuff and then you realize there's a problem and then ray tells you where it is and you can go start the debugger at that point. It's kind of an interesting mix of things. But yeah, figuring out where to start is usually the issue. Typically the easiest thing to do is to get an idea of what action hook is triggering the thing. So obviously if it's like data that's been manipulated and you're like why is this data the way it is, you're probably looking for a filter somewhere in WordPress or in plugin. And then if you know you're just getting some weird action like maybe, I don't know, a site is redirecting to a new location that you weren't expecting. That's probably an action hook. You start to learn after a while what action hooks are triggering what. But I think that's the hard part when you're talking about WordPress and trying to figure out where things are starting and what all is affecting it, right? Because you can end up in very different places depending on what plugins you're running and what theme you're running and all those things. So if, for example, we know that let's say we were trying to figure out why a site was taking us to a new place when it wasn't supposed to, for example. One of the things that I will typically do is I will go to, they haven't moved it over to the actual core pages. If you Google WordPress actions, it will pull up the codex here with the action reference. So if you're not that familiar with all the actions and things that are happening, let me see if I can make that a little bigger. Whoops. This button. Well, that didn't work. Oh, hit the wrong button. There we go. So yeah, so this will tell you actions run during a typical request. And they also have another section on the page where it's actions run during an admin request. So depending on whether you're working in the back end or the front end, it could be very different hooks that you're looking for. So these, just scanning these, they'll give you a general idea what that hook is for. And, you know, it could be that you have a particular problem and you run through this list and you're like, ah, there's probably like two or three that might apply. So what I would do is just do a search in the WordPress code, find that action, set your debugger there, just see what all comes through. If everything looks normal, then try the next one in the list. So there's a lot of things, for example, that happen on the init hook. So all your post types are registered and a lot of plugins are initializing some stuff. So that is not a bad place to start if you're not sure what all's going on. If you're just trying to toy around, it's a good place to see what happens there. And after setup theme is like one of the first hooks that is available to themes. So just so you know, if you're debugging something in a theme, you want to start with after setup theme. And most things in the theme configuration wise are probably getting set up in there. But, you know, there are a lot of things that happen on the page. So if you're talking about like WordPress taking a URL, processing it, parsing it, figuring out what page it needs to load, looking in the database, and then like putting all that together and rendering it out, then this parse request is kind of interesting. So parse request is where it says, okay, we have this URL or these parameters in the URL, and we want to convert that. You're able to take that and potentially handle that request entirely yourself. So this is where I had a little fun and started creating pages that didn't exist in WordPress and then having them render after we hook into this parse request because you can just do whatever you want. So that's kind of fun. But yeah, so we have things like template redirects. So if, for example, certain conditions are met, particular templates in WordPress will load. So this template redirect is used by WordPress to kind of dictate like this theme template is going to be used or that theme template is going to be used. But it can also be used for plugins to reroute to custom templates if they want. That's probably not the best way to do it unless you are in full control. So if you're working like enterprise stuff, it might make more sense. But then we have WP head. So this is where all our styles and scripts are printed out. Then we have the loop start. So if you ever wanted to hook into the beginning of a loop, you can actually use that and output something before all the list of posts. And then we have the post. So as it goes through each post, it's going to run through those. And then of course it will go through the content filters and stuff. This is just the action list. There's a separate page that actually lists all the filters. So if you're dealing with data that's getting manipulated, you might want to check that list. But just to get an idea of the overall flow of WordPress, what action hooks happen and what order. A lot of the issues when I first started was I would hook into something thinking it would work and it just never worked. And the reason was because I had hooked into a thing at a later hook after the other thing had already run. So it never ran my thing because it wasn't going to run again. So that kind of stuff, when you run into that, this is where the debugger will help you realize. Because you can jump into the bit of code that tells you what the current filter is. Or action or whatever. And then so when you're realizing that, well, I hooked into it, but it's not happening. You can actually jump into that and see all the hooks and all the actions that all the plugins have added in WordPress. And you can just peruse that list. And then that can be also a good starting place. Yeah, so we can jump there. Let's see. We'll have to find it. WP underscore loaded. And so the do action is where it would actually do the thing. So this is where it is. So, whoops. There. Why is it not sticking? Hold on. Well, I can stop it to see if it let me. That's weird. PHP storm must be set break points while I'm in a session. So, but I wanted to show it in VS code because I think most people probably use this. We may have already been there. What's that? We may have already been there. Oh, well, that's true too. Yeah, it probably, we may have jumped past it because we did go to this WP load. Although I don't think that would have run until toward the end, but either way. So we will, yeah, true. So we will restart that. Come back over here and reload that. So we're just going to hit the resume button because we know we have two break points. This one and the one we actually want to be at. So we're just going to resume to the next break point. So this is where we have WP loaded. So there are going to be a lot more things here. The other thing is that that is super helpful is the watch. So let's jump into the do action this way. So here again, we have WP filter, WP actions, WP current filter, all of these things. So when we're in here, we should have, yeah, locals, local variables. So these are all the local variables here. So right now WP current filter. I guess this is maybe what the first hook in WordPress or well, I guess we haven't pulled in the globals yet. So we have to step to the next line. And well, technically this line counts as three because there's three things there. So we have to go through it three times. But now we can see what actions are registered. So we have MU plugins loaded, registered taxonomy, registered taxonomy category. So all the plugins and all the WordPress core and all the themes are going to show all of that here. So if you've registered something and you're not seeing it, you should be able to check this list. And so here we have filters. So we got 345 here. And of course all of these are interesting. So if you're having query issues, you might want to start with some of the query pre-get posts type hooks. And then there's, yeah, everything from user email, all kinds of stuff. So we can, let's see, there should be, yeah. So the cool thing is you can set up a watch. So if you wanted to monitor a particular expression, so it doesn't have to be a variable, but it can be. So if we just wanted to monitor, well, WP actions, dollar sign hook name, that's kind of a dynamic thing, right? Like it's kind of hard to figure out maybe what, you know, because you have to inspect what hook name is and then go to WP actions and find the hook in the giant array. And it's a lot of hassle, especially when it's changing like every time you hit this function. So what you can do is WP underscore actions, dollar sign hook name. And then when we hit enter, right now it's null because we haven't gone past that line of code. But if we go into that, so, well, yeah, in this case it's saying if it's not set, so it's not set. So, yeah, so we'll kind of jump through. So let's do this. Let's, let's set, yeah, let's just do a break point there. So let's just keep running. All right. So here we are. So now WP actions, dollar sign hook name is two. So, you know, so, yeah, so, you know, there's a kind of thing where you're like, okay, well, how does WordPress handle all these things for more plugins and everything else. And so it gives you full visibility into every hook, every filter. And it may not be quite as obvious that something is a plugin hooking in versus WordPress itself hooking in. But after, you know, as you do this more, it'll become easier to kind of figure those types of things out. So, yeah, so we have this WP hook, which is I'll have callbacks. And then the callback here has a priority of 10. And then inside of that we have this escape URL. So that's the function that's hooking in there. And then so we have this escape URL function and an argument that's passed in. And so a lot of times like you can just go find this function escape URL and see how it works. So if you're doing this and this plugin has registered something, they'll probably have a more obvious function name like Yoast underscore, I don't know, get metadata or something. And then it becomes obvious that you're dealing with a particular plugin as opposed to maybe something that WordPress core is doing. Of course in this case, I don't think we're really running any plugins. So everything you're seeing here is just WordPress itself. But yeah, so that's kind of a general idea. Maybe you got technically about 10 minutes, which I think is supposed to be allotted for questions. So probably should take a few. But if nobody has any, we can poke around a little bit. Yeah. Yeah, I use 10 up Docker for local environment. I haven't. Yeah, I haven't specifically used 10 up Docker for local. So I'm not sure what. Yeah. I mean, Docker like I know for was it Lando, which is Docker setup, you set up a YAML file and, you know, it handles all the setup for you. You know, you could just set up like they have a little depending on which operating, you know, what do you call it server software and everything else you're running. It may have some different examples in the documentation. You just copy them in and it'll set up X debug. But yeah, I haven't specifically used that. Any experience with X debug? I haven't used map in a very long time. So I can't speak to it now in the past when I was using it, I don't think there was a way. A way to set it up. Hopefully that's changed. But yeah, I think that was actually what I was using when I was spent a long time setting it up. Yeah, I could. Yeah, it could be. Because I have the pro and I use that. Gotcha. Yeah. So if you pay for it, you get X debug. Oh, it did. Oh, okay. You can hear me again. What is this for? It died. Battery's out. Any other questions? You watched the variable WP action. Does that contextual only make sense when you're stepping within that function? Yeah, so if you set a watch and it's only like a variable that's in a particular function, it'll show when you're in that function. But outside of that, it'll just be like null or some empty value. I think in PHP storm, if it's not even in context, it says something like, what does it say? It's red and it tells you it's undefined or something. So yeah, different experiences in each environment, but mostly the same. All right. So yeah, so we, well, probably should just wrap it up. So I don't know who's speaking next. But yeah, I think this is really cool. I have, yeah, almost every week I run into a problem where this solves a problem. Would you mind giving us a quick summary of what the icons mean and the toolbar? Yes. So yeah, if you have an overwhelming, it'll actually tell you. So this one is the continue. So you hit f6, does the same thing. So that is if you have multiple breakpoints, it'll just jump to the next breakpoint. Or if there's no breakpoint after that, it just finishes whatever it's doing and WordPress is done with loading its code. The arrow moving over the dot is the step over. So for example, if you're running through the code and you hit a require statement and you don't want to go into a new file, you want to stay in the file you're in, you would jump over that. So it does not then load that file? Oh, it loads the file. It just doesn't take the debugger through it. Yeah. It just kind of skips over it. And you could do the same too with just particular. Just kind of run to the next breakpoint? Yeah. If you're on where we're at now, if you do step over, it just takes you to the next line. But if that next line would take you into something, it'll skip that. So then the step into is if you're on a line like we are now, it'll just take you to the next thing. So in this case, the conditional didn't qualify to go into that code. Skip that. Jumped us to the next applicable line. But again, if the next line was a require, it would take us into that file. So if, for example, you get in too deep, right? You're like, I got to back this out. There's also this up arrow, which is the step out of. So for example, right now we're in this WP includes plugin. So I just want to get out of this function, right? So I hit step out, and it's going to jump me out. In this case, we were going through the parse tax query. And so that spit us back out into the function where that was happening. So, and also helpful, as you're going through and looking at everything that's happening, you have this call stack. So you say, okay, where did I start? I started an index. And then somehow all these files loaded. And then, you know, these methods and whatnot from these locations. And now we're where we are now. So that's like your roadmap. So like a lot of times when you're debugging, you'll say, okay, I don't know what went wrong. But I know at this point is broken, right? So you can go to that point and you can say, okay, well, what happened to get here? You can look at the call stack and figure out what files loaded and all that kind of stuff. You can inspect your variables and be like, okay, well, what is or is not in the list of filters or actions that we're expecting. And of course, you have your watch. So you can set up that for multiple things. And, you know, if you're trying to hook in and create your own virtual page that doesn't exist in WordPress, you might want to watch a few things about the URL or a few things about the internal state of the post and things like that. And then, yeah, so it actually will show you to hear what the breakpoints are. So if you wanted to disable a particular breakpoint, you could do that. So it's easy to kind of manipulate and end up where you want to be. But yeah, so then the next button here is restart. So that's just going to, I think it just reloads the page. Let's see. Maybe just restart the session and we have to go reload the page again. But I don't use that one very often. And then the stop. So there's also a disconnect option, which is where it will completely shut down the session, which I think it does by default when it finishes. So, but yeah. So I think I'm out of time. But yeah, one more question. So when you're watching a variable like that, is there a way how you can at least keep the last value before you jump out? Or if you're watching variables, you always have to step into the function, step again and again until the loop is over. Or is there a way where I can just run it and maybe sort of have a log of what that variable was? That is the application for using ray because it will log it all and keep it in the log as opposed to this, which is just like whatever the current state is. That's what you get. So that's my use case for using both of those tools. You said ray? Ray. Yeah. There's spate ray. There's a plug-in. So it's put out by the, say that again. Is it RAY? Ray? Yeah, it's RAY. Ray. Yeah. And so yeah, there's a WordPress plug-in you install. And you could just put the word ray function call and just put whatever values you want in there. And then it will, ray is technically a paid tool though. So I think it's, well, just side note, Black Friday, they do a lifetime deal. So for like 300 bucks, you can get it for life. Otherwise, I think it's 60 a year or something like that. Not too bad. It's pretty helpful. And you know, they, between the interactive debugging and that, being able to log everything and kind of see everything that happened in a particular loop all at once, versus like maybe setting a conditional break point and honing in on just like one thing when it's at a specific value. Yeah. So yeah, so definitely something worth checking out. I should probably just pull it up here so you guys can see. So this is the official documentation page. So it's 49, 49. So that's like an application you install on your machine. And anytime you use the WordPress plug-in, which is also by the same name. It's a little hard to type with one hand. So let's see. Should be a WordPress. Yeah. Here we go. It's as easy as install this plug-in, pay for and download the application. Have the application open in your code. You said you have to dump the function in, right? Yeah. So, yeah, that's, it's kind of the toss-up. It's a better version of Vardump, basically. Vardump, it's just always a mess on the page, right? When you Vardump something, you're like, oh, well, that's hidden behind some like black background and I can't see it and it's hard to read. Whereas this is like, okay, well, we're taking it all out of that, putting its own tools so you can see everything. And you can assign labels and colors and all kinds of stuff to do that. So definitely worth checking that out as well. But, okay, I got to wrap it up. So I'm done. Thank you.