 As developers we spend anordinate amount of our time debugging stuff, so the premise of this talk is that we should have enough time to do that we should have the best tools for the job. I found in the past certainly when I was learning PHP that I found property buggers like XDBug quite difficult to set up so hopefully this is going to help you with that. So what are we going to go through? Well we're going to look at how XDBug is configured at a server level and that's what the USB pen is getting handed out for now so there's a virtual box on that which rather than trying to get everyone, a lot of people using Macs so I guess that's really standardised but I suppose people might be using Windows so rather than trying to get you to set that up for your specific operating system. There's a virtual box, a limited space virtual box if you cannot start one. So then we'll look at making PHP Storm and NetBeans talk to XDBug. How many people are using PHP Storm? Is there a lot of you? Anyone using NetBeans already? No. We'll go through a very simple example of just examining the contents of some of your variables as your code is running using XDBug. And then there'll be a bit of time for you to try and set up yourself. My colleague Michael is here with me as well so if people have questions then we'll move around and try and help you. And then depending on what time allows we'll do one or two more examples of using XDBug. So why XDBug? Well, probably a lot of you will recognise these functions down the side here. Probably a lot of you have used them to output contents of variables as your code is running. I think it's a Drupal 8 kind of equivalent for dumping contents of variables and objects. So I kind of think these variables are a little bit like trying to climb Everest wearing a tweed jacket. This guy is called George Mallory and him and Andrew Irving tried to climb Everest in I think about 1924 and they might have made it to the top. Nobody really knows but they certainly didn't make it back down again. So they're very heroic but they weren't successful. So we don't want to try and be heroic and use these kind of really primitive functions to debug our code. We want the best tools to do it. So yeah, just to reiterate what I said about debugging, you're going to spend a lot of time. I'm sure you already spend a lot of time debugging and the rest of it writing books. So XDbug is kind of the puff of jackets to your tweed jacket. So if you're going to be spending so much time debugging, you should be talked up properly and have all the kit. So XDbug lets you inspect your objects and your variables at runtime. It shows you what your call stack looks like so you can see a trace of what function is called what. And it integrates with your IDE with PHP Store and it's open source. So how do we set up? Well, here's some prerequisites so you need an IDE. I didn't want to concentrate entirely on PHP Store because although it's a great IDE, it's paid and it's not open source. So I also use another example as well. We're going to be using, feel free to try and set this up if you want to play along on your own operating system and get vacant virtual box. So you get this set up locally on your machine. Otherwise if you use vacant virtual box we should be able to help you out a bit better to get stuck. There's a readme file on the USB stick so if you get that virtual machine there's a tar file which you can untart. And then there's a readme which has just got some fairly simple command line instructions as to what to do. Cool, okay so it's live demo time. So this is the contents of the tar file that is on that USB stick. So we've got some resources here and the resources. We've got a JSON file and we've got this virtual box. So I don't really want to, I thought quite long about how to get this most usable for people who wanted to set it up. I don't want vacant virtual box to be a distraction from what we're actually talking about which is actually bug bits. The most appropriate thing to use. Probably people who have used Docker and other things might think why am I not using that. But I just want to use something that has been around a while and was proven and wasn't going to be hopefully a distraction. So the first thing we're going to do is add that virtual box to vacant so that we can use it. So that's vacant box add. And we just add the JSON file which contains a load of configuration. I think I'll have to force it because I've probably already got it set up. And then just go into the folder that's got my vacant file in it. And it should then be able to do vacant up. As I say, I'll stop in a minute and if you want to do this, it will stop. So it should then be able to SSH into it and in here should have an already set up convoluted path. But we've got Drupal 8 installation in there which we'll use for this demo. So the other thing I'm also going to do just by way of configuration is to set in my host file a host's name for this virtual box that we've set up so we can access it in the terminal. So what we should have very slowly. So I just need to add basically my host file. I need to add the IP address of my virtual machine and this Drupal VM.dev host name. And then so whilst it's being slow, we'll look at how X debug is set up. So the first thing you're going to need to do, and I think it's on this virtual machine that's already installed, but on any other system you'd have to install X debug itself. So that's, we use app to get for that because we're on Linux here, a Debian based machine, and it's PHP. I should say it's already installed for me yet. So if I've just got too many virtual machines running or something and it's eating up memory, just let me check that. Maybe I should just restart it. Okay, okay. Let's do it quick. Okay, so this is what you should be seeing here. Can you see that? Command font big enough for everyone to see. Can you see that? Okay. Okay, and here's the page we should have whilst that's doing that. I'll just look at, I'll just show you the configuration for X debug and I'll just talk you through that. So on this virtual box that is, we're using PHP 7 and we're using FPM which is the manager for fast CGI PHP, but I need to worry too much about that. But that just dictates the path where any file is basically. So that's a new file. To find a path to that new file, if you're not sure about it, you can go into the report section in Drupal and there's a link to the PHP configuration. It just gives you an output of PHP info and that'll tell you exactly where your X debug configuration is. So you've got a few settings which are always the things that trip me up when I've tried to set this up. So the Zen extension is just the path to the extension basically. If there's no path like that, then PHP knows by default where it thinks, well, it thinks it's in the default position and it just looks there and finds the X debug extension. And then we've got the remote enable. So this turns on X debug basically and it allows X debug to connect back to whatever processes made the HTTP request to your site. And do remote connect back rather than you can, if you have possibly other connections that are being made to your site, you could specify that you only want X debug to run for something that's coming from a specific host. Or you could specify a host name and a port number here to say that you only want to run X debug for your local machine, for example. But in this case, we're just going to let X debug connect back to anything that's made the HTTP request to your page. The remote port is just the port that X debug uses that you're also going to configure in your IDE so that they can talk to each other. And then we've got an IDP which we'll look at in a bit. I don't know if you actually need this for PHP Storm. I think you do for NetBeans and might need it for other IDs. But the remote auto starts below that kind of overrides it because that just basically says run X debug under all circumstances. And then we've got a path to a log file there as well so we can, if anything goes wrong, hopefully we'll get a bit more visibility through the log file. Okay, so then you probably need to, if you've made changes to that, you're probably going to need to restart PHP service. So I'm just going to do, and then I'll restart patch heat as well for good measure. So it looks like might have already got this setup. So I'm going to just look at the PHP Storm setup for this. So I'll start by, I'll create a new project so that I can show you how it's done. So we're going to create a new project from existing files. The default option there is fine so I'm going to just click next. And then I need to find the project route to that Drupal installation. Now the thing with Vabrant and VirtualBox is that you can share folders from your local machine to the box itself. So Drupal is actually installed locally at administrator. So there's my Drupal route there and I'm just going to mark it here as the project route. I'll add a new local service so I can show you how that's done. So let me just call it DCL. This is the address of the site that we put in the host file earlier. So I completely forgot what that was. I just lost that window. We're going to use that server and then we don't need to put anything in here. Yeah, that's a good idea. Thank you. We don't need to put anything in there because we're just using the, we're not in the subfold or anything at that URL. That should create a project. So that's the project setup, but we need to tell PHPStorm where to find our PHP interpreter and how to connect to XDBug. So that is done through PHPStorm preferences, languages and frameworks, PHP, and then I think in here there is a debug section. But at this language level here, we just need to set the interpreter and we choose a remote interpreter. And we choose the vagrant option here and we need the vagrant instance folder. So that is the path to the place where vagrant is installed. So that's thinking about it. So maybe I can just open that other project that we had already set up. I'm going to cancel this for now. So this is what Michael's done earlier. And so you'll see in PHPStorm is very small like on that top there, which is your listener. And that's off at the moment, but you want to turn that on. And we're then going to, we're also going to check this. So in the London menu, we're just while we're making sure that it's set up properly, we're going to check this break up first line in PHP script. So this just means that the PHP's going to stop running and then a debugging session will start on the first line of PHP that runs when you execute Drupal. So to bootstrap Drupal, you should just be able to refresh the page. It doesn't seem to like it because I didn't check it. So I explained some of these controls. So what should happen when the page loads is you'll get a break point at the first line of PHP code that runs. And I don't know if anyone who's been trying to set this up now has got that far. But once that's working, you know that your ID is speaking properly to XDbug and you can enter that off for now. And then going to open index file, you should be able to, if you click in the margin next to that line of code, you'll get this little rent circle, which is a break point. And then if you then refresh your page, I don't know if this is going to do it for me, but we should get a break point appearing. Is it already open? Ah, so it's just hidden. Thank you very much. Okay, brilliant. Okay, so that's next step, isn't it? So what's happened here is the, thank you for that. So my code stopped running. That's why if I look at browser, it's still, you can see that the page is still loading, but it's actually stopped at this break point. And I can see in the debugger that it stopped an index of PHP and I can see that these are the variables that the XDbug can see at the moment. So you can look at the globals, for example. And we can, if the cookie is set or if we're getting post variables, we could look at those. We can see there's a bunch of server variables that you can see here. These are kind of PHP fundamentals. And then we can see this auto loader that we've created on the line above. You can see that that's visible in your debugger here. And you can see that that is some sort of object and it's got, as populated with arrays and other items in there. So you're able to browse through everything or variables in memory. So I was going to show, I don't know, five minutes left, haven't we? Is it finished in quarter two? No, you've got ten minutes left. Ten minutes left, okay. Okay, so I'm going to show you an example which might or might not work. So I'm just going to go into the Drupal root in my virtual machine. And I'm just going to enable the examples module. Again, this warning, I think the permissions aren't set up properly on the folder where XDbug is trying to log stuff to. But we'll leave that for now. So I'm enabling the examples for the developers module, which is just a Drupal content module. And in there, I think we've got a sub-module example, a hooks example I think. So that's enabled and I'm going to go into PHP storm and I'm going to find one of those examples. So here I've got a implementation of the node view hook. And I might use this, for example, to complete a hypothetical example, to change some of the properties of a node in Drupal before it actually gets displayed. So let's create a quick. I'm going to stop my debugger. I also have to stop it here. Let's see if I can reload the page. I'm just going to create an example node, logins, admin, and password for the site. So I'm just going to create an article node, save that, and publish it. And I also, I know that this hook, I think only runs after cache has been cleared. So I'm just going to clear the cache with Drupal. And then I'm going to set a breakpoint inside implementation of hook node view. And hopefully we'll be able to see all the variables that we have in that hook that we can change before the node is viewed. So I'll start my debugger. Open my debug window from down here. Let's refresh that node view page. So it stops. I've still got that first breakpoint, so it stopped there. So I'm just going to remove that breakpoint and click this regime program button here, which should keep running the application. And yeah, so you can see I've now stopped on the first line of code inside that hook. And I can see variables that are getting passed in, or parameters that are getting passed into this hook implementation are build, entity, display, and view mode. And I can see exactly what's in each of those by browsing them in my debugger here. So one example might be that possibly one of the properties on your node, well, you might use pre-processing for this, but so if you were using that hook, you'd probably be very tempted to use things, the functions that we looked at before, print underscore rdpm, a kint, but this is much more efficient. So you can see exactly what variables you've got when you're implementing that hook, and then you know how to work with them. So I'm going to stop there, I think, quick while I'm still kind of ahead. If anyone wants to hang around and try and get it set up, do so. I hope that was useful, and I hope you're going to be able to implement Hextybug and start using it. It's definitely worth getting through all the teathing trouble and the headache of configuring it, because once you've got it set up, you'll never want to be without it. Thank you, everyone.