 So, the door is closed, welcome everybody. We will present for you, wait, there is more advanced debugging tactics. We will talk about debugging PHP code and JavaScript code, and I'd like to know before we start who has been to the session about PHP debugging yesterday. That's a nice amount. Okay, I will promise that we will only have a maximum of 25% overlap, but it will be more funny. Okay, another note, we assume that you know what a breakpoint is. If you don't, well, I think you can follow as well. So let me first introduce ourselves. Next to me is Mark van Gent in green, and I am Daniel Smith. We are both based in the Netherlands, we are Dutch, and we work for Dutch agencies. I'm also a core maintainer of in-life form errors, and Mark, do you want to add something about yourself? No, you can look me up. He's a great, great mentor. He was my mentor, and you'll be here as well tomorrow. So why should we use a debugger? Well, first of all, it's really, really nice to not have to write debug code anymore, because if you don't write any debug code, you also don't have to clean it up, and you also don't risk of having debug code in your production program. The second best reason I think is the ability it gives you to learn. It allows you to easily follow, for example, the flow of the code, and it gives you a lot of contextual data, like all the variables you have during a certain point in the runtime of your program. And also, it really simplifies development. Oh, yeah. Also it helps you find bugs. So in this presentation, we will work with the following tool set, PHP storm, X debug, the Chrome development tools, and the Chrome extension. So please, Mark, tell us more. Thank you. I'm happy to. So, yeah, that's our PHP debugging. I think it's really important to know your tools. So who's using PHP storm over here? Yeah, that's what I thought. Okay, so PHP storm has a couple of great things, and some you might already know. So we're going to do this pretty fast. In fact, we have to do the whole presentation pretty fast. It used to be a one-hour presentation. We took out 25% and doing it in half an hour today. So here we go. You got a lot of deeply nested attributes in arrays, in arrays, in arrays, in triple core, and in triple modules. So if you want to take that out and need to access the variable, there is a really great thing called copy path. When you have a break point somewhere, you can copy the path and you get this whole form attributes class identifier. So you can use it at once in your code. It's great. And then the call stack. You know when you put a break point somewhere, okay, you're right there, but there's a call stack. It means that you can go up the tree and see who called this code and where's the code that's called that code. So you can go all the way back up to index PHP where it all started. So that's a good way to figure out what happened and why it happened. And then conditional break point. This is actually something that I learned when I was on a code sprint at a triple con. I saw a core maintainer using conditional break points everywhere. So there are some points in your code where you pass multiple times. So for instance, in config management, that's called many times, but you're only interested in one specific occasion where it goes wrong. So that's where conditional break points come in. You say, okay, this is not always a break point. This is only a break point when this key has a certain value. It's great to pinpoint where exactly things go wrong. One caveat, always used to double equal sign. So use a comparison operator. If you use only one, it's an assignment operator and you're actually changing life variables in your running PHP script and it messes with your mind pretty badly. Okay. One more tip. In PHP storm, you can record shortcuts and macros. On my machine, I got a command shift dot or control shift dot if you're using Linux, which types foo equals bar and sets a break point at the same time, which is really nice, although this introduces debugging code which Danielle just told, I shouldn't do, but, okay. Still works. Like that. But wait, there's more. So you see this hooligan and do you recognize this code? If you've ever written something like this, console log, console debug, you shouldn't do it anymore. Why shouldn't we do it anymore? Well, because it's 2017 and Barney says so. Stop it. Also, don't use the alert function. Basically for JavaScript, if it runs in the browser, you can also debug it in the browser. So we want to start to debug in the browser. We will first have to open the development toolkit and then open one of our source files. So the easiest way I always do it is the command P. You can do it from every tab. If your developer toolkit has the focus, you can just start typing anything you like. It has a very smart fuzzy search, so you can just type a part of the word and, for example, end in GS, it will quickly find your file. So it will show up in the sources tab, control P or control O sometimes or command. Using break points, it's quite similar to how we are used to it in PHP storm. You can also put it on a point in your code on a line number. And you can also use it to, well, step-by-step walk through your JavaScript code, as you can see here. But what I like more is that it can also detect changes. Sometimes things happen. You install the library. You use all kinds of fancy stuff that's shipped with Drupal core. And something changes. You don't know exactly where that happened, why it happens. And what you can do is you can place break points that watch for changes. For example, here, I say, hey, buddy, tell me if something changes in your attributes, for example, if a class is added. Well, I click in the menu of Drupal, Drupal 8. Something happens. I hit jQuery. But then I use the call stack on the right side and see, ah, there's some JavaScript I do recognize and maybe understand, maybe can change. And I see in my code, oh, yeah, there was a toggle class. Well, that's a really nice way to find where something happened. And you can also do it, for example, if you really, really don't know what is changing. For example, you don't know that it's a class or on which element it is. You can also say, hey, watch for the subtree. Is there something maybe down the road that is changing? It will be a bit more difficult to exactly find where what happened because the call stack will probably be a bit longer. But using the call stack on the right side, you can easily find, hey, there's probably a non-minified piece of code which you can look into. What we just saw is that was jQuery was opening, often it's for us a black box. We just assume it works if something is broken. Well, maybe I did something wrong. So what you can do is say, hey, jQuery, I don't want you to open if I'm breaking on some code. You can right-click and say, hey, add it to our black box. You cannot do that per file, but you can also go through the settings and use a smart regular expression to say all these kind of files I don't want to show up in my developer toolkit. Otherwise, one nice point that Mark also mentioned for PHP, we can also do conditional break points in JavaScript. On your line number, if there's a break point, you can right-click it, let's wait, right-click and we're going to edit it and add a little bit of code that says, hey, when processing the entities on this display, I only want to see when a node is processed and then when I do something, it says, hey, the yellow break point slides up, hey, this is happening. Really nice. We talked about the context. It allows you to really easily understand your code and what's available on a certain point in time. Here's on the right side, beneath your call stack, you can see all the variables that are available. What you can also do is open up the console. PHP storm also has a console. We didn't see it, I think, this time. No, but what's really nice, for example, for Drupal, we work with behaviors and sometimes you just want to repeat one of the behaviors and see if it works, do I need to add the ones or did I put my context right? You can, for example, just trigger your code in the console and watch what happens and then step by step go through your code and see, hey, it's my behavior working, right? So for people that do want to know what happens in jQuery and you have your minified version, there's also a nice option to prettify your code. So it's the other way around, you can click it, really nice. Now we can understand something. The variable names wouldn't make that much sense, but it helps a bit to read through the code. If that's not bad as enough, just like in SCSS, there's support for source maps. So you can use your minified JavaScript and debug via source maps. So here's an example site. There is a minified script and I cannot really debug that. Google already says, hey, I detected a source map. Okay, then I go and find the non-minified version. Where is it? It still says minimal. Google knows more than I do. He says, this is the non-minified version and we can open it and you can put a break point in there and it will show you everything with really nice variable names, function names, and so forth. I didn't know that. Okay, I did. But tell me more anyway, Mark. Thanks. How are we doing for time? Cool. So mobile debugging is a different topic that's going to give you some break once in a while. So we've seen the Chrome Inspector, but did you actually know that the Chrome Inspector is also running on your Android phone? So I'm not talking about device emulation. It's not like make believe, do as if we were a mobile device. No, it's really on your mobile device. So what do you need? If you've got Chrome on a laptop and Chrome on a tablet or phone or maybe a WebView app, which is actually an app that's basically running a small website wrapper, you enable USB debugging on that phone. That's basically all you need to get is working. I'm not going to explain it in much detail because it would take like half an hour by itself, but there's good documentation on the developer.google.com website. So when you've got that, you can go in your browser to Chrome, colon, slash, slash, inspect and you will see your connected device and you can make a connection to it. You choose the device and the app that's running on it, which is probably Chrome or Chrome and on device, it will ask you to accept the connection and then you have a connection. Oh, by the way, this assumes that your phone is connected with the USB cable to your laptop. And that's basically all you need. And then you really have what you see over here on the left. You see the inspector just like, you know, and it's on your laptop. So you just see the inspector and you can point and click elements in your site. And you will see them simultaneously on your phone screen. You will see them highlighted as if that is your actual browser and because it is your actual browser. So that's a great way sometimes if you really can't figure out where sometimes some things are working on the desktop, but not on your mobile device, use this. It can even handle port forwarding. So you can visit sites from your mobile device that are actually running on local host. And just like I quickly showed you here with how to do it with Chrome and Android devices, it's also possible with Apple devices. And well, Apple is Apple's worst best if you've got an Apple laptop and Safari and the whole Apple suite. But point being, you can do this and it's not as difficult to set up as you might think, at least for me it was a revelation doing this for the first time. I was, OK, well, I can do this and it works. Cool. Interesting. I like this one. Got some more? So if you're doing Drupal, you want to contribute, which everybody wants. For everything you want to introduce, introduce, or you want to fix something, you have to write tests. Oh, we have multiple types of tests. And we can debug them all via PHP as well, PHP storm as well. The main difference is that, for example, if you want to debug your normal website, which is not a test, instead of, for example, setting your cookie via your extension you probably use, mostly you have to set this extension in another way. Because instead of running it through the browser, you will be running PHP via the command line. There are a couple of ways to do that. PHP storm can set some of them for you. And in some cases, you will need to export some variables to your environment of your console. These are some examples for Bash and Fish. Another important one, it was all so mentioned yesterday. I think it is to set up PHP storm in a way that allows multiple connections, say three or more. So we have a small demo for you. We have a load test. And you can right click this test. And when you put a breakpoint and say, hey, debug this code, and it will be really, really quick and show you what's happening. So I think we have a new record, Mark. I think we do. So, yeah, time to say thank yous. And we want to say thank you to our employers, and say special thanks to Triquanta who allowed us also to prepare this presentation. And we would love to hear your questions. If there's anything that's not completely clear, anything that you demo or anything, well, I don't think that live demo is right here. But anything that's not clear or you want us to expand more on. So please make yourself heard. Hey, thanks for the presentation. There's something I often fail at making work, which is the use of workspaces to map a local file system to the sources you see in the inspector. Is there some explanation about that? You know, when you go to the sources screen, Chrome tells you that you can map the local files to a workspace, but they can never make this work. Yeah, you mean in PHP when the PHP storm, right? Oh, in Chrome, sorry. I haven't used that a lot. Sorry. But tomorrow we can investigate together. So please come to the front if you have a different question we can answer. Only questions are allowed that we can answer, otherwise we look stupid. Well, I just want to say both of us will be here tomorrow. And we've done this as well at, well, the triple development days. If you have problems setting up your XD bug, for example, or want to know how you get everything running, please visit us. We'll be here, I think, all day. You can find us here. Oh, wait. There's more. Do we got time? Yes. Oh, we got time. Did you know that actually SAS, the CSS preprocessor, has a debug function? It does. Yeah. You can enter at debug and then include a variable or some calculation or something that you do. And it will just turn up in your command line when you're running the SAS watch command or your gop watch or something like that. Seriously, it's cool. So. But don't forget to remove your code, Mark. Sorry, Daniel. So what do you think? Leave us a message. And have a great DrupalCon. Thank you all.