 All right. Shall we start? Thanks, everyone, for coming to this session. It's exciting to be able to present a session in Drupal Con. It's an event that means a lot to us as a community. We're going to be talking about debugging your PHP applications. Hopefully, this is going to be a little bit more practical than usual. So we're not going to go just over PHP debugging. We're going to go over S-trace and how to look into what your PHP application is actually doing. So let me present myself first. I'm Felipe Fidelix. I'm UK business development manager for Platform Assage, a continuous delivery hosting company. We are doing some pretty interesting stuff in the hosting space if you have complicated needs for your applications and you're not running just Drupal because Platform Assage can run pretty much anything that's PHP-based, Node.js, Python, Ruby, Go, and very soon Java. So we're going to start by debugging by using the simple, the quick dirty way that a lot of you are probably already familiar with. And then we're going to go over step-by-step debugging which allows you to have a lot more control over what you're looking and requires a lot less iteration to find the stuff that you're looking for, the bugs or whatever you're looking for. We're going to also do some profiling. Profiling is when you're doing, you basically generate a trace of an application request and then you are able to analyze that trace to see how your application is doing and what's taking most time, which bottlenecks your application may have. So it can help you debug performance problems. We're also going to go over S trace, like I said, to debug your application in real time. It's fantastic for debugging stuff in production. It's an invaluable tool to use in production. We're going to just glance over HTTP traffic monitoring. We're not going to go too deep here. But it might be useful when you have JavaScript interactions in your application and when you have sub requests in your PHP application. And of course, in the world we live in today where we're all running applications in the cloud, it's very important to be able to debug your stuff in the cloud as well, not just in your local environment. So we're going to go over that as the last part of the session. If at any time you have any questions, you please come over to the microphone. I'm not going to wait until the end. I think it's going to be better for this type of session if you just come over to the microphone and ask at any point. So feel free to do that. All right. The first thing that you might want to do as you're developing in Drupal 8 and you want to see what's inside a variable or you want to see what's going on in the page is actually to use a kint and the dump methods. They are really useful if you don't have xdbug installed or you just want to do some quick dirty debugging. You basically write kint and then inside the function you put the variable you want to look at, you can also do something like get available variables as a PHP function to actually look at all defined variables. The syntax for that is something like this. If I can spell properly, get defined vars. This will print. It's a little hard to see, isn't it? Hopefully it's a little better. So this function here will basically get all the variables that are defined at this moment in the runtime of your process and it will pass those variables to the kint function which will print a pretty save this. It will print these variables in an array for you. Here apparently there are no variables here. Hold on. Kint is not able to access this. Let's try with server. So here are. Here's everything that's inside the server variable and kint prints it in a pretty way for me. Kint is a library that actually handles all of this. Kint comes with the devil module which you should have if you're debugging anyway. You can click this button here to open it in a new window because sometimes because of the layout of the page you're not able to easily see the variables here and look at them especially if you have CSS that's changing the color of the font. So you might want to click in this button. You will open everything in the new page and it will allow you to actually search and filter everything for you. You can also, using, you can drill down here. It's going to tell you the size of each directory. So that's pretty neat. And if you're using twig, you want to debug your twig variables. The function for that is dump. It will help you actually see your twig variables. And you also might want to use this module. It's really, really useful for seeing what's running and what's actually happening in your runtime. So let's give it a try if it doesn't break. Well, Web Profiler apparently doesn't like me. So here's the Web Profiler bar. It will give you some pretty useful information as well especially if you don't have XDbug available. Most of these are available in XDbug but a lot of them aren't. Especially, so the query time, this is extremely useful. If you want to check if you have some specific pages with bottlenecks, you can see the number of database queries. And if you click on it, you can actually see the database queries that happen in your page. So if you are familiar with how this used to work in the devil module in Drupal 7, this is a lot better. It's a lot cleaner. It's a lot faster. So it should be very useful. And you can see the patterns of the queries, the queries that took the longest to execute. So it's really good to debug performance problems if you have pages that are taking too much to generate the first byte. And it's also going to show you here in performance timing the time to first byte, which is something you really want to check for your applications, even if your application has a CDN behind it and you're caching it well with varnish or whatever. The time to first byte is important because some users, the users that don't actually touch the cache, whether because they're authenticated or because the cache has expired, they're going to hit this time to first byte. So it's important that you keep this low. And of course, it will give you lots of information about your runtime, the extensions that are running, the blocks that rendered in this page which is also super useful. The extensions are being enabled on this site. And the cache calls, which is also really good to check if your site is being effective when it comes to caching. If you have a high hit ratio, it means things are getting cached properly. Cache is not being validated too often, so that's good. And the assets and the regions in which they're being loaded from. Let's go back. So that was Web Profiler. It opens this small bar on every page for you. The really interesting part, which is how to use XDbug. I included a link here to the documentation on how to install PHP Storm. XDbug with PHP Storm. I'm not going to go over the installation here, but it shouldn't be too difficult. There are a bunch of tutorials online on how to do it. But one thing that is probably good for you to understand is that step by step debugging with XDbug, it just trumps every other way of debugging. And if you have it configured in a way that doesn't generate a lot of hassle for you to actually get it running, and you start using it as part of your daily tasks. And when it becomes natural to you, you will never want to go back to using kint or dump or var dump, for God's sake. You always want to use XDbug, even when you're on the cloud, even when you're working remotely, because XDbug can actually debug sites remotely and do step by step debugging, which I'll show you how. So this is basically the most important configuration you need to do for XDbug and Drupal, especially if you're running a composer-based Drupal project, because the Drupal directory is outside of the, sorry, the dependencies are outside of the web root. And the Drupal root is not in the root of your repository, of your project. So it's really important for you to use settings like this. And these max simultaneous connections are also excellent if you're running Drush and you want to debug Drush commands and cron and whatever, because by default, XDbug will only do one connection and Drush executes everything in a sub-request which counts as a secondary connection. So if you don't do this, and you run your site using Drush, you won't actually be able to debug your application if you don't increase the number of simultaneous connections. So you might want to set your settings something like this. Right, so debugging with XDbug is a very simple process and really gets very natural once you start doing it a few times. Basically, you set a breakpoint using your IDE. Most decent IDs, they have an easy shortcut or even just a mouse click in the side of the line where you can set a breakpoint. A breakpoint is the point of the request where the IDE will pause completely. And the PHP server will just stop executing so that you can look, do what you have to do, and then you can let it continue running if you want to. Or you can just break the request and stop it. That's fine as well. After you set the breakpoint, which is just one keystroke or just a mouse button away, most IDs, you just set your ID to start listening to connections. And then you just run your page as usual. Let's just give it a try here. So this is this exact page, right? And I want to know what, just give me a sec, I'm actually going to use a more complicated page. I want to know which arguments are being loaded in this page, page example. So this is the page, uses arguments here on the page. And I want to actually see in the code which arguments are being passed to this function. So I can just set a breakpoint here or here. And I will set my ID to start listening to connections. You can also put a shortcut here if you want, or just leave it enabled as well. You can do that. So it starts listening as soon as you open the ID. And it's not just PHPStorm that can do this. There are a bunch of IDs out there that can do this as well. So after I set the breakpoint, essentially what I have to do is just load the page. Now, the page stopped executing. It didn't load. I pressed Control-R, but it actually stopped loading. And I can just come here and I can see that these are all the variables that are available at runtime at this point. There's the first variable which is defined here, second, and everything else that's defined. I can take a look. I can explore. I can also copy the values as JSON. Even if it's a big array, there are a bunch of options here to copy. And you can also, which is a very neat part of PHPStorm, is that you can set watches. What a watch lets you do is you will basically always show the value of a certain variable at the top of this list. It might not seem useful here, because you can already see the value of seconds here. But if you have a variable that's deep inside an array, so let's say server. And I have to scroll a lot. So let's say it's here at watches. And then it will always show me the value of server request time here at the top of this list. So even if you keep moving and go to other functions, to other methods, it will always keep showing this value for you. It's really useful when you're doing recursive functions, when you're doing deep nested functions. And I'm sure that if you start using xdebug, you will start using it as well sooner or later. Right, so again, I am here. And this is the highlighted line that PHPStorm is showing for me. It means that execution is stopped here. If I press F8 or I click the step over button, it will go to the next line, the next statement. And if I press F8 again, it goes to the next statement. And you can keep following your code and reading everything that happens and actually seeing the variables defined here so I can go to the next function, which is this one. And you already show me. It's still showing the server request time here because I set a watch. And it's still showing me all the variables that are defined. And this is not even the same function. So it will keep showing you all the variables and everything really that you need to see. And you can just keep following the execution, pressing F8 or the step over button. But there's more. You can also, so if I press, if I'm here in this line and I press F8, it will actually go to this line. But what if I want to know what's happening inside this function? Then you can press F7 or step into. And it will go inside this function, right? And you can see what it's doing. Even the initialization of the class, you're not going to miss anything. So I can also look at the dispatch function here. See, dispatch function. And I can keep following the flow of the application. So it's extremely useful when there's a bug that you don't really know where it is. And you want to start from the beginning of the execution to actually find the problem. You can press F9. So it will continue to execute the application until it breaks again in another break point. That is the same thing as this button here, F9. Since there are any more break points for the IDE to break, you just finish executing it. And my page will render just fine. Now, up until this point, you can already see that it's really useful and it's going to be better than kint or dump functions to look at stuff. But that's not the best part of XDbug. I'm going to try to show you the best part here now. So here I am. It has broken again here. It's in this line. But the good thing is that you can also see which function called this function. And you can see the entire stack. And from the beginning, how your application flows and which functions were called. And you can actually go back in time to look at the variables. So I'm here in this function arguments. But I want to know where it was called from. How did I get here? How did the application get here? You can just follow the frames here, which is just another word for the stack. And you can actually go back in time here. And you can even look at the variables at this point as well. So at any moment in my application, I can see the variables even if I didn't set a break point there. So you can basically go back in time and look at everything that your application did at this point. See, all the variables are here. Even from the beginning, when Drupal bootstrapped, it's all here. So that is a really useful part of XDbug. But to use this, you need a good IDE. There aren't many IDs that support this. PHPstorm is one of these IDs. But again, that's not all. You can still do things like, and this is my favorite part, is that you can actually execute code in real time. There's a console. And in this console, you can actually run PHP. So you can, let's say, you can var dump first, var dump the variable. It's not going to return anything. You can also do anything that you can think of in PHP. You can actually run it here. You can define variables, and you can actually modify your runtime. And whatever you're doing here, it's not just something that's happening on the side. It's actually happening in your requests in real time. So you're actually modifying your request here. If I type, let's continue. So you can see that the var dump that I typed, it actually happened in the page. Because whatever you do in the console is actually happening on that point in the request. So you can imagine this is really useful for debugging. Let's say you're debugging a user page. And at that moment that the user is being loaded, you also want to modify the user variable. Hey, you know what? I want to test this guy as if you had a different role. Or I want to test this woman, see if she could have a different picture. See how a different picture in different resolution looks like. So you can modify it during the runtime. And it just works. It's really a cool part of XDbug. All right, so let's get back to this. Any questions so far? Just again, feel free to reach the microphone. No? All right. So OK, seems you have one question. You just showed us the console. Great thing, by the way. I was wondering when that was coming up. But I've actually never tried. If you go back in the stack and then use the console, does it also work for that? No. Why not? I'm afraid not. The way that it looks at the stack is basically just, PHP doesn't have a garbage collection mechanism like other languages. A lot of other languages do. So it actually just, XDbug just stores those variables in memory so that you can look at them. So even though I said that it's kind of like going back in time, it's not really just PHP, XDbug. It just stores all those variables for you to take a look at later. But it would indeed be awesome if you could go back in time and execute a console commander. Right, so one tricky part of debugging and you're going to deal with this sooner or later is that sometimes when you are running an application, even if it's on your local server, your IDE doesn't know where the files actually are. So if you have an application in your slash var slash www folder, but your actual development code is not there, it's actually running in a different folder, in your home folder. There's no way XDbug can know that. It only knows what the PHP server knows. So it will tell you the path of the file, let's say index.php, which is where you set up a breakpoint. It doesn't know where, PHPStorm doesn't know where in your disk that file index.php that the server executed this. It doesn't have any way to know that. That's what path mappings are for. So with the PHPStorm path mappings, you can say, hey, you know what? This folder in my computer is the same folder as this other folder in the server. So you're basically telling, you know what? If this folder here in the server slash var slash www gets called, it's the same thing as my folder in my computer here in my home folder. So you're able to set breakpoints that way and even do remote debugging. And the way that XDbug and PHPStorm do that is via path mappings. Again, not all IDEs have this functionality. So only pretty much the most sophisticated IDEs have this. And if you don't have this functionality, you actually need to put your local development files in the same absolute path as the server. And sometimes that's not even possible. And yeah, what happens is that PHPStorm, it will look at all your files. Let's say I set up a breakpoint in index.php, right? It will ask you, it will look at all the files in your projects that are named index.php. And it's going to ask you, hey, where is this file in your projects? You know what this file in the server was called? Tell me where it is in your server. And for Drupal, I selected slash web slash index.php. And then it's able to find all the other files in my project. You don't need to really do it again. You don't really need to do it once. And that is a pretty cool feature of PHPStorm and XDbug. Right, so the thing about XDbug is that the first time you configure it, it's going to be pretty aggressive. It's going to try to debug every single request. It makes everything slow, because XDbug is slow. It's a debugging tool. It will make your request slower. So you might not want to enable it every time. And one thing you can do is activate this functionality here, where you're only going to trigger breakpoints when you put this little query string in your URL, in your address bar of your browser. There's also an option for a cookie. And as you can see here, I'm using this add-on, this extension for Chrome. It basically sets the cookie for me, so I don't have to go to the inspector and set the cookie myself. But basically what it does is XDbug stays dormant. And when I select this option here in this extension, it's actually going to trigger any breakpoints that I have set. So it's also a neat part, and it helps you keep things faster. The same thing you can do for profiling. I'm going to have to skip these parts, unfortunately. Profiling, I'm going to have to just glance over it, but basically it generates a trace of your application in a few files. And it stores the exact amount of time, each function, and each method, and each class, the amount of time each one of these took to execute. So you can find any bottlenecks in your application. And then after you generate these files, you need to look at these files using a tool. One of the tools that are really good for this, not often used, is Kcache Grind. It's mostly used for not PHP programs, both for Java or C++ or other types of software, not usually PHP. But you can use it for XDbug traces as well. And you will tell you exactly how much time each part of your application took to execute. So it's really, really easy to find bottlenecks this way. You can no way. You know what? My application is spending too much time rendering this view or spending too much time talking to this other service and et cetera. So yeah, I listed a few. I'm going to share these slides later, but I listed a few programs here that you can use to analyze these traces. PHPStorm also has a trace analyzer. It's not as good as the other ones, but it's sufficient for a lot of cases. Now, this one is really cool. Again, I don't have a lot of time. So let me just do this again so you can actually take a look at it, because it's really fast. It's supposed to be really fast. Yeah, basically, we'll dump all of the system calls that your application is executing. In this case, I am Stracing. This is a tool that's available for Linux and macOS, but there are similar tools for Windows as well. It will basically dump every system call that your PHP process is doing. And this is an invaluable tool to debug in production, because there are no really performance disadvantages of running it, so you can run it anywhere you want. And you can actually see what your PHP process is doing in real time, and you don't need to attach a debugger or anything like that. It just starts printing every system call that runs. So you can see which files are being loaded. You can see if it's talking to another server, if it's talking too much to MySQL. You can see that it's wasting too much time on disk, if it's loading too many images. And there are a lot of cool tricks that you can do with Strace to actually filter this output here. A few of these tricks are listed in the slides. I'm not going to be able to go over them, unfortunately. But a few of those is follow forks. It's important when you're running PHP FPM and you want to see all the child processes. There is also dash O if you want to save the output to a file. AC generates a summary of how long it took to execute and things like that every call. And the best thing is that, depending on the service, on the server, and on the service provider she's using, the hosting company, it will actually have Strace available for you. Platformer Sage is one of those. It has Strace and a bunch of other tools that you can use to debug. I am going to have to skip this Wireshark part. But Wireshark is a tool that lets you actually look at the TCP and UDP traffic of your network card. It's quite useful if you have to take a look at JavaScript interactions and you're not able to trace everything for some reason. So you can also look at the things that Chrome don't actually let you see using the inspector. And Wireshark will let you do that. And I actually intercept the traffic and manipulate it as well. Charles is an HTTP proxy that allows you. The reason I use Charles is to debug when I am using a mobile phone. So if you're using a mobile phone, you can set the proxy in your operating systems settings. And it will talk to Charles. And all traffic will go through Charles. And then you're able to actually debug things from there and manipulate traffic and see everything that your mobile phone is doing for that page. And it's a lot better, I'm telling you, than using the remote debugging of the Chrome inspector. It lets you do a lot of things that Chrome inspector doesn't actually do. That's pretty much it. I'm kind of out of time. I was going to talk a little bit more about platform message. How much time do we have? Two minutes? OK, two minutes then. So platform message is a hosting company that the coolest part is that everything is Git driven. You do everything via Git. You control which services are available for you. And you can say, hey, you know what? I want MySQL for this application. I want Solar for this application. I want RabbitMQ. And you define all of that in a few YAML files. You should retain a lot of control over the build process. You can run Node.js. So you can compile fast during the build process, which is not very common in other hosting companies, at least. But you can run Node.js and Gulp and et cetera, all these tools and image optimization during the build process. And you can have as many environments as you want for every Git branch that you create. You'll get a full environment with a copy of your production data. And that's pretty cool for teams working together. And you can run strace there and PHP debugger and xdebug. They're all really quick. xdebug is just three lines that you add to the YAML file. You can also run there Blackfire. We have integration with Blackfire. You can run new relic. We also have integration. They're all just a couple of commands away. So that is pretty neat. All right, questions? Sorry, can you repeat that? Excuse me, can you tell us more about remote debugging with? Remote debugging, yes, absolutely. So remote debugging, for instance, in platformers, to do remote debugging with xdebug, you need the xdebug extension installed on the server that's executing PHP. It's not very common for you to find that in hosting companies. Platformer Sage, for instance, you can enable the xdebug extension. And after you do that, you just run this command here, your terminal, your local terminal. And you can debug your application as if it were local. So it doesn't make any difference for PHP. So we would think your application is running locally, but it's actually running on Platformer Sage on the cloud. So you can do everything that I just showed you. And the latency is actually pretty good. It's not slow at all. It's as good as you can expect. So that is the way to debug with remotely. By using an SSH tunnel here, this is basically the command. And then you can do that quite easily in Platformer Sage. But again, the hosting company needs to have support for xdebug. Any more questions? No? OK. Thank you very much, everyone, for coming. If you're in a line and you want to go inside the function, and then you can step out of the function back to the same line, yes. It's a weird process. Basically, you have to configure Twig to save. You know that Twig gets compiled to PHP, right? So by default, Drupal doesn't save those files. So if you configure Drupal to actually save those files, then you can debug on those files. And there is a, yeah, the compiled files. There is a helper, xdebug breakpoints, I think the name of the function, that when your file gets compiled, it will break automatically xdebug. When it gets to that, it's part of your Twig files. OK. So it's xdebug. Yeah, something like that. And if I put this one in the Twig file, does it work? Yes. That is correct. It's in the services.yaml file, yes. And also, sorry, apologies, I have a bad code. So even if you don't set this function, you can actually go there and look at the files and find your Twig file that was compiled and look at all the compiled codes. It's not that hard. It's a little hard to read. But if you put it in PHP Storm, it will format it properly for you. So it looks OK. And then you can debug it from there. Sure. All right. Only Drupal 8. I'm OK. Oh. Oh, no. Sorry. That is not correct. The Web Profile module is not in project slash Web Profile. It comes with the devil module. That, it took me a few years using S-Trace until I found this. Yeah, I'm going to share the slides. I'm going to put them on the DrupalCon Vienna site and then we'll be able to see it. But it's, yeah, this is the way to do it if you're using a host that has PHP-FPM. Everyone needs to use PHP-FPM now. If you're using Apache and ModRite, you're wrong. So PHP-FPM, and you know that the problem if you use PHP-FPM is that for every request, it opens a new process. So you'll never be able to find the right process ID. It's impossible. So the way to do it is by debugging the parent process and using the dash F, which follows the focus.