 And to kick off today, firstly I'd just like to say a huge thank you to the organizers and sponsors of this event. WordCamps are fantastic events. This is my fourth, I believe. And they're always amazing. I'm just always so surprised at the bar they set for quality in everything. And especially considering the price, it's just absolutely astounding. So massive thank you to the organizers that made this happen and the sponsors for putting in as well so that we can have a great conference. I'd also like to thank Tim Butler for his talk this morning. And he was going into some general troubleshooting with WordPress and it ties in really nicely to this, which is a bit more of a deep dive on extra bug as a tool. As another follow on from this talk, Topher is going to be talking at the same time tomorrow afternoon. And his talk is going to be on local development environments in WordPress. Your development environment is quite important when it comes to using extra bug. And I'm going to go into some of that. But for a deep dive on using, I believe, local by flywheel and server press, check out his session, which is at the same time tomorrow. So in this talk, we're going to be going over using extra bug to profile our code and pinpoint bottlenecks a tiny bit like just a little bit. We're going to be going into using extra bug to debug our WordPress applications a fair bit more. And also gloss over how using extra bug can help us actually develop new features. So it's not just about debugging all the time, like extra bug can help you as an ongoing development tool. Really, it's all about delivering higher quality data to you as a developer so that you have a better understanding of the flow of your application and about your local scope and the context that everything's happening in. So in order to understand why extra bug is great and why it can offer a lot to you as a developer, it's probably also more like, we need to understand where we're coming from. And so I'd like to go back to the land before extra bug. And these technical sessions can be a little bit dry. So I'm going to try and mix it up a little bit here. And I want you all to come on a journey with me and just picture and visualize some things in your mind because we need to go all the way back to late May of the year 2000. So humanity has come together as one to celebrate surviving the Y2K bug. You know, the world didn't blow up and we're all super stoked about that. Sydney is an absolute frenzy right now because the opening ceremony of the Olympic Games is just four months away. Pop culture is doing some pretty interesting things at the moment, I guess as well. And I'm bonnosed to any of us at the time. We're just two months away from having the mother of all bangers dropped upon us and life would never be the same elsewhere in the world. Some guys like Rasmus Liadov, Andy Gutmann and Ziv Seraski are about to drop something on us called PHP specifically version four featuring Zend engine one. And it says up here now with added programming language because this pretty much was the first PHP release that was a programming language. It started as a very simple templating language intended primarily to interact with C programs and people started using it to build more and more complex stuff. And they eventually went, well, okay, maybe you want some tools and like functions and objects and things for was the first release. It was really like, hey, PHP is here as a programming language. And we got this beauty. All right, we got VAR dump and life has never been the same. It's been a little while since the year 2000. I mean, for starters, I was 10 then. Some things are still relevant. VAR dump is still relevant as well. Thankfully, some things are not still as relevant. These two statements are very much still in use. I don't want to pretend like they're going anywhere or they're going away. I'm not here to sort of shame you if you're still using these in your code all the time or saying you're not a developer, anything like that. They're still very relevant. But I want to get into some of the troubles that we can face when we're using functions like these, which I'm going to group together under the term of print based debugging. Okay, so echo a print based debugging, whether you're putting it out on the screen or throwing it in a log that you're going to look at later somewhere. It's really, really useful. It's super accessible. It's very quick for us to get up and running in it and just inspect something quickly. However, it does have some issues, right? It only gives us values for the chosen variables. We need to be very explicit with it about what we want to see. So we say, okay, I need this variable and then it dumps that particular one out for us. It doesn't show us the rest of the current scope. And in development in programming, scope is hugely important. And it also only captures variables at single points in time. So it offers us no real way to monitor their changes over time apart from simply adding more print statements or more echoes or something like that. To use an analogy, print based debugging is a bit like this. This is a single snapshot from an MRI. There's some really useful data in this. And sometimes this is all you need. You know, sometimes this alone can be enough to diagnose the problem. But it's also lacking a lot of other things too. If I ask you to describe this person's face to me, you're going to have a really hard time doing it based on this single snapshot alone. So the alternative or what I'm kind of moving towards here and proposing is introducing you to step through debugging. So in step through debugging, we stop execution of the program at a particular point in time. And we call this a break point. From there, we have the ability to inspect all variables in the current scope. We can even modify the current scope and allow the program to resume execution. And we can see the current call stack that has led up to this break point in some advanced implementations of debugging tools. You can actually go back into previous context and see what their scope is as well, which can be really useful. From that point, we are able to manually advance through the execution to see changes over time. And this ability to sort of see how everything is changing in our application over time can be invaluable. A lot of the times when you're starting to use step through debugging, you'll see things changing that maybe you weren't monitoring. So you've got a carbon paying attention to this variable the whole time. But as I'm stepping through, I can actually see that these two things over here is changing as well. Maybe that's contributing to my problem or maybe that's something I can utilize. So to go back to the MRI analogy, it's like this. The cool thing about this for me and about using stuff like extra buggy is that we haven't lost anything. There's almost no trade off there. And in programming, that's quite rare. We still have access to all of the information that we had before. It's not like we're trading one set of information for another. We're just augmenting it with a lot more context and the ability to sort of travel through time and watch out changes. Really, really cool stuff. As you can tell, I'm a pretty passionate advocate for extra bug and step based debugging in general. It really changed my view of a lot of the applications that I was working with when I started using it was like opening up the door. And all of a sudden I could understand a lot more about what was going on rather than just trying to focus on one particular thing at the time. The other thing that I don't like about echo based or print based debugging is that it requires modifying our code. So I'm sure we've all seen code bases that look like this. You know, they've got the commented out like bar dumps in there or print out for error log or whatever. And sometimes, you know, they're not even commented out. I've definitely seen that before people leave them in there. You know, not really knowing that they're spamming the error log with stuff or whatever. I mean, I've done it. I'm going to admit to that. And you know, sometimes we can just find out actually forget to remove them after we've fixed the bug as well. And you end up with a bit of this type situation. No one's really happy in this sort of situation. So now that you can understand what step based debugging is potentially going to bring to your workflow, hopefully a bit, let's actually get into extra bug. Yes, that is the official logo. That is 100% the official logo. I think it's straight out of 2002 or something when it was released. But the team maintaining it are doing an excellent job at keeping up with all of the developments in PHP. So the logo is old, but the extension itself is still very, very, very relevant and quite cutting edge lives at extra bug.org. You can download it if you need to compile it into PHP into your PHP sort of set up. I'm praying you never have to do that. Because a lot of other modern development environments now going to give them to give extra bug to you, but the docs are on there and the docs are key to sort of understanding all the different facets of it. So extra bug can do a lot of different things. It's not like all it gives us is this step debugger or something like that. It makes bar dump better. Right. So it changes its functionality. It introduces sort of some tables and like syntax highlighting and the call stack and everything to it. So even if you're still just using print based debugging, you're going to have some benefit from having extra bug on your development environment. It can do code profiling to measure performance. And I'm going to touch on that briefly. And then again, step three debugging enabled using this DBGP protocol, which is really like my favorite part of it. So we are just going to touch on profiling a little bit. Tim mentioned that in his talk as well this morning, that you can send off a variable effectively to extra bug, telling it to turn on and to do a profile. It's going to put out a case ground file for you. Really, really cool and can be really great at profiling performance issues. I'm not going to get too much into it because Otto has done a fantastic talk that he delivered at WCEU quite recently. And if you want to go into profiling, this is definitely the one to look at. A couple of things that I would sort of say as part of, you know, if you're going to look at profiling with extra bug is that take the measurements as being a little bit relative. It's really useful for you to sort of look at how much this function takes to execute in your context versus this one. But I wouldn't take absolute numbers from two different scenarios and necessarily compare them because of the way it's implemented underneath, like extra bug does need to make some kind of changes to how your code executes, like at a much lower level than the PHP language that you're writing in. However, you know, doing that can sometimes one, it takes longer to execute like any request that's running extra bugs, probably going to take about four times longer to execute than a normal one. And so the the profiling can sort of be a little bit off, particularly when you're dealing with big like sort of big request, big loops, big arrays, that kind of stuff. Xh prof is probably a better tool there. And the other thing that I'll say is that if you're running extra bug in a VM, which a lot of people are now, if you're running it inside like a Docker container, which is what say local by flywheel is doing, you're running it in a vagrant box, a lot of the time it's just going to output to slash TMP like the temp directory. In most VMs that I know of, that's not something that's kind of mounted and shared with your file system. So it can be a little bit hard to retrieve that log sometimes. There is a setting that you can change. And my advice is just to change it to say, whatever like directory is getting mounted onto your VM. So that way you have easy access to it. Remember your IDE is living on your computer, VM something separate, make sure that you get it to output the cache run file into the bridge, or you're going to have to go in there and like pluck it out, which just adds extra stuff to, you know, sort of your thing. So remote debugging, it's a little bit fuzzy, but yeah, this is just an example of me, you know, noodling around in PHP storm going through some of the things. And we're going to cover what we need to do to sort of get into this. So to get started with remote debugging, we need to have the extension installed in our PHP environment. We need to have a valid sort of ex-debug client or something that can receive the communication from it in the DBGP protocol and gives us a GUI to interact with it. And we need the correct configuration of both of them for them to sort of really meet in the middle. You're talking about like a client and a server trying to talk to each other. It's crucial that they're trying to, you know, speak to each other in the correct way using the same ports, all of that kind of gear. Otherwise it's going to have a real ships in the night misconnections that are vibed to it. So first up PHP, choose your local development environment. There's stacks of really great ones to choose from at the moment. So I'm just going to really quickly go through all of these, but basically all of these environments that I've just gone through have either an ex-debug in them by default or have a really easy extension that you can use to enable it. I'd highly recommend local if you're not super comfortable working with, you know, like vagrant boxes and everything like that. I mean, even if you are, it's still a great, great platform. The guys are here too, so go have a chat with them about it. If you are using local, don't use the flywheel profile. It doesn't have ex-debug in it. Use a custom profile, but apart from that, they're all going to have ex-debug. Chassis as well, got to give a shout out to that. Great, great project, highly configurable vagrant box. They have an ex-debug extension that you can install and it's going to use puppet to provision everything for you. Makes it really easy. They also have a GUI in beta, I believe at the moment. So that could be a cool way of getting involved with it. Homestate is what I started on, just for some context, but it's all kind of the same after a certain point. You need to choose your IDE. So who here knows what an IDE is? Show of hands? Yeah, kind of. Integrated development environment. At the end of the day, yep, cool, it's your text editor. But the idea is that an IDE should be more than a text editor. You want some kind of like code completion in there. Yeah, if you can like be running a language server in the background, that kind of stuff. But the main games in town at the moment are PHP Storm. Who here uses PHP Storm? Yes, freaking love this program. Big advocate for it. And recently there's been a newcomer in town, which is VS Code from our friends at Microsoft. Really, really cool IDE. And this has sort of a debug interface built into it. And someone made a PHP debugger extension that allows like the, you know, extabug DBGP profile to talk to it and utilize that. So yeah, really nice. VS Code is free and the extensions for it are free. PHP Storm is licensed. It costs money. I think it's some of the best money you'll ever spent, but it does cost money and it's not open source. If you're more about that, VS Code can be a great alternative. And is like, yeah, has just as many features in there for using extabug, all of that kind of stuff. And yeah, again, free. Between this and local by flywheel, you can get all of this stuff that was previously super hard to install yourself and configure, just talking to each other like almost out the box. It's, you know, it's 2018 as they say. Bonus tip, browser extensions. There's a Chrome and any other equivalent browser version of an extabug helper. And it just helps you set the query parameters or the cookie values that's going to kick off an extabug session for you. Not 100% necessary. You can put them in there yourself. You can configure your IDE to include them for you. But for me, I love it. It's just that ease of use kind of thing. You can be on a web page. Just tell your IDE to listen and then go from there, particularly if you're setting up extabug on a project you've never used it on before. This can be the quickest way to get started because you can just go, we'll go through that flow, but you can just kind of go listen, start, and then the IDE can almost generally work out the path mapping for you. So we're going to talk about configuration. We're not going to get into the real nitty gritty of this is how you set up VS code with local by flywheel or something like that because there's too many different combinations. I've published, sorry, published. I've written about four articles at the moment aiming for a total of eight on different combinations of configurations just to help you guys get up and started with them. And I'll be publishing them along with the slides. So quickly on IDE configuration, if you're configuring PHP Storm, your extabug settings are going to live in here which is sort of language frameworks, PHP debug. The key thing in here is what port it's listening to. That is like crucial because you need to make sure that extabug is sending out on the same port that your IDE is listening for. And that may differ from project to project. VS code, it's going to be in your launch.json. So you're going to come up and launch configurations in there. Again, it's crucial where you set your path mappings and then your port. This stuff can exist on both a global and a per project level in both of these IDEs. So for example, if you typically use one environment all the time, you can set that up as your global and then you get a special snowflake of a project that's running something else or you're using a different VM or whatever, you can configure different settings for that. And now we're just going to get into the remote debugging request flow. The reason for this is, again, configuration is often a bit of the stumbling block for this. If you haven't got extabug up and running before, a lot of the time it's the configuration stage that people fall over in. So I do apologize that we haven't got into a terrible lot of like using it, but getting it running is the most crucial thing. So the requests come in like a HTTP or in some cases a CLI request is going to come into PHP. Depending on these settings here, it's going to choose to potentially respond back and with a DBGP request. So default enable is where it's on all the time. Remote enable is whether or not we can switch it on from a remote and remote auto start is turn on every time we get a request. If you are trying to switch it on selectively, you're either going to be using a query bar or a cookie value of those two down the bottom there. This is all in the docs, but yeah, these are really key. A lot of people are just copying and pasting configurations from articles on the internet. That can put you in a fair bit of trouble because if you don't know what you're configuring, you can't troubleshoot it. You may have a slightly different set up to them and you can get in some trouble. Then extabug is going to reach out. So based on these settings here, remote port is what it's going to try and talk back to. Remote host is what it's going to try and connect to which should be your IDE. And remote connect back is just connect back to whatever's connecting to me, which is what we want to use most of the time in a local set of environments. So this goes out looking for port 9000, you know, a little bit of a what's out there kind of thing. And hopefully if we're all set up there listening for connections, we get this kind of exchange happening where we go, yep, I'm a valid extabug client. Here's some break points. Let's do this thing. So, you know, then we should end up with something like this where we actually end up in an extabug client. This is PHP storm. And here's a handy little gift of this whole process that I probably won't make you watch due to time constraints. If you're getting it set up for the first time, you may be presented with a screen like this. And this is just asking you to identify the path mapping. This is particularly important if you're using like Docker containers, vagrant that kind of stuff because the path mappings on that machine are going to be different to the path mappings on your local machine. And extabug and your IDE just need to make sense of that. So, let's quickly walk through the components of the extabug client. We've got the call stack, which is the files that we've been through to get to this point. We've got the variable inspector, which is all the stuff that's in the current scope, including globals, including constants, all of that kind of stuff. We've got watches, which are continuously evaluated expressions. So if, for example, you need a calculated value based on a variable or something like that, then a watch may be what you need for that. And then lastly, we have the debug console. So this is not like a bash sort of anything like that. It's actually in context, in the current scope. You can just execute sort of code and see how it evaluates out against your current environment. In this example, I know when I recorded it, I'm stopped inside an object constructor. If I typed in this here, I would get the version of that object back. And yeah, again, that's pretty useful for a lot of things. So getting onto the actual WordPress side of things now. One of the things that I find it the most useful for is debugging actions. Timing is hugely important in WordPress. It's quite procedural, very, I guess, without hooks and filter system. It's almost a bit event-based at times. And so working out the timing of things, or has this fired yet? Or is this going to fire? What is changing this value? I can't work it out. What filters have attached themselves? That kind of thing is crucial. So for that, you can use the variables inspector. I don't know if you guys are aware of this, but yeah, all of the, I think the GIF just went past it. All of the filters, like so all of the actions and filters that are gonna take place or have taken place are all registered on a global called WP filters, I believe. So you can go into that array and inspect and see the different priorities that things are gonna run with. It's gonna give you back like the name of the callable and everything like that. So if you just wanna know, okay, there are five different things that are running on this same action and mine's not running at the right time or something like that, or what else is affecting this. You can just go in there and check it out. You can also use the console. So you can run things like did action or you can run things like has action, which are probably part of the, like the lesson known side of the actions API. Most people are just using add and do, but yeah, you can use those to see if things are attached and at the end of the day, that's just interacting with that global array. The importance of timing and state in debugging cannot be overstated. A lot of the time we're facing problems that only exist in very specific scenarios. I mean, for me, I work a lot with WooCommerce, for example, and you know, you might find that you have problems with particular products or it's like, I've got, when I have these things in my cart or something like that, the issue becomes apparent. So being able to sort of load up that case and then inspect everything as it's happening is super useful compared to just trying to print out a few things or read through the code yourself and sort of hope for the best. You can actually step through the code with some valid variables there and see what's happening, see what calculations are taking place, see where it's going wrong. You know, maybe like a function call is returning null or false or something like that when it shouldn't be and then you can work out from there. I've discovered lots and lots of problems in, you know, the code that I've written, code that others have written. So, you know, WooCommerce extensions and things like that too. So the importance of state and timing in debugging, like I said, cannot be overstated. Extabug probably gives you a little bit more control over that. As I mentioned, you can also modify the current context. So if I was to go into the console or something like that and pick a variable that's in the current scope, then I could actually set a new value for that. I could change the global array. I could actually even change like the superglobals and stuff like that. If I want to just put a bunch of things in a get request that never actually happened on the front end or, you know, maybe I filled out a form name field wrong in my HTML template and I don't want to go back and change it just to debug this thing. So I'm just going to edit it on the fly. Really sneaky, but, you know, sometimes you got to get the job done. So, yeah, there's a lot of things that you can do there. Being able to actually alter it, you know, you can return early out of functions and all that kind of stuff with different values. You have more flexibility. You have more flexibility to sort of test. None of this is going to, yeah, none of this is going to actively solve your problems for you. It's still up to you to use your, you know, abilities as a developer and your intuition and your understanding of the code to solve the problem. But for me, it's just about having good quality information in a timely manner and about being able to sort of increase like your productivity by not having to run seven different, you know, page refreshers because you've are dumped out the wrong thing or you can't work out, you know, what you're meant to be targeting just about increasing your productivity there. As I mentioned as well, when I'm developing for some plugins, so WooCommerce, Gravity Forms in particular, I use X debugger heap then I kind of scaffold out my extension, go to where it is that I want to execute, set a break point there and just kind of see what rocks up. I just see what information I'm given by the action that I'm hooking into or by the point in the execution that I'm at. And then I can go, okay, I've got all of these things to work with. A lot of the time it can stop me from writing code that I don't need to, to like go fetch values that are actually already in scope. Or sometimes it can identify a problem for me that like, cool, I don't have access to this. So maybe I need to write some code to then go and get it. Should I use X debug? That's like the golden sort of question. Like should you guys use X debug? The rule for anything in sort of development is kind of this, like if the utility that you get from it is greater than the cost of implementation, whether that's in time or money, then you should probably use the thing. For me, you know, I work a lot on the PHP side of things. I work on a lot of different projects. I'm context switching all the times and it's really hard for me to be intimately familiar with the code bases of everything that I'm working with. I get a huge amount of value out of X debug. If you're maybe developing heavier on the front-end side, you may not get as much value out of it, but you'd probably get lots of value out of Chrome's built-in step debugger, which is, you know, in the browser there for you to use. So whether or not it's worth it for you guys to go through the process of getting it set up is really up to your judgment. And your particular situation. But I just wanted to present it to you as an option so that you kind of know, I always wish I could know more information about this. Like for me, I was always like, I want to see what my program does as it executes. And then I found X debug and realized that that's a real possibility. And that was, you know, a big step forward for me. As I said, detailed setup guides are on the way. And it would be remiss of me not to mention my employer, which is Frame Creative. They've sponsored me to come here and speak to you all today. We're an agency based out of Adelaide. We're kind of creative first. We do a lot of digital stuff as well. And we're currently hiring and accepting remote people. So if you're interested in working with a modern WordPress stack, we build off of like Timber, Twig and use Webpack and all that kind of stuff. That's your jam. Please come and have a chat to me at like the drinks tonight or something like that. I'd love to grab your details. I think that's pretty much me done. I would love to throw in a live demo, but how are we going for time? Cool. If we have a lot of questions, then we may run out of time. Otherwise, I can just kind of fire up a session and we can walk through a little bit of code if you like. Yeah. Hands up if you've got a question. Is everyone feeling like they want to see a live demo a little bit more than ask questions? Yeah. Cool. I understand that talking about it is quite different to seeing it in action. So, you know, let's get out of the slideshow. Everything's changed. All right. So, here is like a website that I just built really, really quickly to take most of the screenshots and gifts that you guys saw in that presentation. So, I used local by Flywheel to get this site up and running. And I also installed an extension that someone had made for local by Flywheel called extra bug control. And that gives me a little bit of control over some of those things without having to go in and manually edit the config file. The key here is that I am using port 9005 because I have about four different VMs all running extra bug on this machine at this point in time because I've been testing different configs. Back in PHP storm here, which is shrunk considerably. In the setup for this project, we can also see that I'm listening on port 9005. So, it's crucial that those two things line up. I've already connected to this for the first time. So, when I hit a breakpoint, I'm not going to see the screen that asked me to perform a path mapping. All right, but we are going to hit some breakpoints. So, the first thing that we need to do is we're already listening for connections, which is fantastic. Back in here, I am going to use the extra bug Chrome helper to debug this page. So, we're going to turn that on if we refresh the page and the demo God smile upon me. Yep, we're here. This is like one in a million that never happens when you're demoing things live. All right, so this is where I've set my first breakpoint. This is in the init, I believe, function of like WooCommerce's main class. It's just firing up a bunch of things. As I was mentioning before, you can sort of step through and move along manually. So, we have these controls down here and they're really the key to all of that. So, you can step over, which just means really advance another line where I am right now. If a function is about to execute, all I want to see is the result of that, just keep me moving. So, in this case, we can go, all right, cool. Session class equals apply filters, WooCommerce session handler, WC session handler. Someone can hook in there and potentially add their own session class if they want, replace it. I don't think that's going to happen. As we can see, this is now executed. We got back, you know, the result of that and it's been saved as a variable in the current scope that we can see there. If I wanted to, I could actually change that now as well. I kind of won't, because it will probably screw the whole thing up, but we can keep advancing. Now we see that it's calling that and going into the init of that particular session class. If I would like to see what's actually happening when this is taking place, I have another option called step into and that takes me down the next level of execution. Now we're in that init function of the WC session class. So we can then continue to advance along manually. That can get pretty tiring though. So we also have the option to step out of, right? So we can step out of where we currently are, which is this little guy here, step out. Finally, I'm not sure if every implementation has this, but PHP Storm definitely does. It has this really nice option here called advance to cursor. So if you go, oh wait, I've stopped in the wrong spot. Actually, I want to be like 20 miles up the road, something like that. You can either choose to set a new breakpoint and kind of play to that, but that gets messy. You just add unneeded breakpoints that you don't really want in there. Or you can just throw your cursor there and go advance to cursor. I use that one a lot. It's a really, really good sort of time saving tool. As I mentioned, we can see our current scope. So that's this variables tray down here and we can inspect anything. And then we have the console that we can also evaluate in the current scope. So, for example, like I said, we've got this. In this case, this is the main WooCommerce class. I don't really know what's been set up yet because we're pretty, but I mean, I think this session should be set up. So, yeah, we can see we got back like the session object in that case. Like I said, this can cause side effects. You know, if I called like a method in this that was actually going to do something, like it would do something and then continue on with the request. It's not just frozen in time. This can make changes. It's important to note though that if you change any of your PHP code, those changes aren't going to be reflected until this whole debugging sort of request is finished and you start a new one. Because at this point already, the PHPs like, you know, been compiled to opcode and all that kind of stuff. And that's what's running. So if you make changes and save in your IDE, it's not going to follow that actual code until this debugging session is finished and then you've done like a refresh of the page or something like that. So they're the sort of like really the main components being able to step through, step into functions and then step out of them again are the key components of utilizing this. And like I said, the utility of it really depends on what you're trying to do. In this case, for example, we're in a class constructor. That's a pretty closed off method. Like maybe something's been passed into the constructor, but not really like it doesn't have a whole lot of state going. But I want to see if we go to the shop page, we should hit another break point, right? So this isn't a template. At this point in time, we have a lot of stuff in the current scope, right? Like WordPress in general, sort of because it uses includes and everything, it just all passes along if you're not using a templating framework or anything like that. So we've got a lot of stuff in the current context and that's when you can run into bugs that say involve like collisions in variable names and those kinds of things even if they're not explicit like globals that could just be that you end up with two things in your template that are named the same like another plug-ins adding it in or something like that. So depending on where you're operating like the current scope could be very important or it could be like pretty simple to reason about and maybe you don't need the inspector to work out what's going on. For me, yeah, I really like it when we're using it with Timber and Twig because I can just sort of break right before we render our view and all of the data that's getting passed into the view is then able for like is there available for me to inspect that's a really clean like nice way to work. I can see everything before it goes into the view iterate over all the posts all that kind of stuff if I have to. The last little tidbit that I would love to show you today if I still have a minute up my sleeve is that break points can be conditional. Okay. So when we're setting a break point which typically you do just using the gutter in your IDE like a lot of the times next to the line number you click there there are actually explicit PHP functions that you can call to trigger a break point but then you have the same concerns as print base debugging just less side effects because effects debug doesn't exist and yeah. But I much prefer to do it this way because I don't like making unnecessary changes to the code base. When you throw one in you have the ability to do this kind of stuff like an add a condition there. So I've just right clicked on it give me the ability to add a condition. You can also do those kind of things via the break point inspector that PHP storm has for you. So at the moment this is a list of all my break points and whether or not they're currently enabled. So you can have many defining your code and only some turned on any particular point in time. But I love conditional break points because what are we doing in WordPress a lot of the time we're getting a lot of posts and then we're looping over them. I don't want to step through every iteration of that loop right so I can go I'm having an issue with this particular post for some reason it's not doing the same thing as the other one and I can go okay this is only going to be a break point when like post ID is equal to six or something like that. And so it's going to loop through that as many times as it wants but then eventually hit that and go oh okay yeah in this case the post ID is six. So let's stop here and then I can debug that. I think I'm out of time guys so I hope that you found the demonstration a little bit useful. That's right yeah we've come to the end I'll let you go a bit further there because I really wanted to see how those conditional break points work. So everyone can join me in thanking Alex with a round of applause. Thanks guys.