 Can you hear me? OK, cool. Got to get this on my level. OK. Hi, so I'm introducing Corrie Crowley. Corrie is a partner and lead developer at Fly Plugins, a WordPress plug-in company that develops WP courseware, S3 Media Maestro, and churnly. When not developing plug-ins, Corrie can be found playing guitar around a golf and spending time with his family. Thank you. OK, let me just get situated here. OK, so as she said, my name is Corrie Crowley, and I'm a local here. To Phoenix, I actually live in Queen Creek, and I usually stay in Queen Creek. This is probably the furthest I've been in probably like six months, because I work remotely. I work from home, and in fact, all of us at Fly Plugins work remotely. And we like doing it, and we have great success doing it. So today, I'm excited to be here. I'm excited that this WordCamp is happening. I always get excited when the local WordCamp happens. I like to go to other WordCamps. Last year, I went to WordCamp US in Nashville, and that was a blast. But I like it when it's here, because I like to be in your family. And I'm a father of three great kids, and my wife is very supportive of doing stuff like this, talking at conferences. So I'm happy to be here. So today, I am excited to talk to you guys about better debugging for better troubleshooting. And today, I'm going to be showing you, hopefully, hopefully showing you some new things. Who here develops pretty much 24-7 and uses debugging constantly? OK, so fair amount. Hopefully, for those that are just beginning development or dabble on the weekends, hopefully you guys can learn something new today and use one of these tools and attach it to your tool belt for later use. So like she said, I'm a partner and lead developer at Fly Plugins, and we develop three pretty awesome plug-ins. We think they're awesome. The first in the workhorse of our three plug-ins is WPCourseWare, and it's an LMS that is simple and powerful and runs thousands of businesses across the United States and internationally, so we're pretty proud of it. We also develop S3 Media Maestro, which is an Amazon S3 plug-in that allows you to insert downloadable media straight from Amazon S3 or CloudFront and insert it directly into your poster page. And we also offer content protection for things like videos, audio files, and even downloads. So pretty cool plug-in, you should check it out. The third one, and this is our newest one, is called Churnly, and it's a subscription churn solution that integrates directly with WooCommerce and easy digital downloads. So if you need a churn solution specifically for WordPress, specifically for WooCommerce or Edd, then Churnly is the plug-in you need. So today, I want to talk a little bit about the six stages of debugging. And hopefully you guys have run into one of these at some point in your career. And the first step is, when you're debugging, is that can't happen. How many times have you responded to a client or to a support request, and they say, hey, this isn't working. I don't know why your plug-in doesn't work on my site. And basically, your first instinct is to say, I don't think that can happen. Second stage is, OK, maybe it is happening. It is happening on your site, but it doesn't happen on my machine. I've tested it. It works locally. So it must not be broken. Something else must be going on that is interfering with our plug-in or maybe the host, one of those things. So the third stage is, that shouldn't happen. I don't know why it's happening, but that shouldn't happen. Definitely not. The fourth stage is, wait, why does that happen? That's kind of mind-boggling. Fifth stage is, oh, I see, I see, I see what's going on. And then the sixth stage is, how did that ever work? I mean, I've been developing for probably close to 15 years, and I have written a lot of crappy code. And I'm sure we all have. And that question, how did that ever work, has come across my mind a lot, probably. Specifically from support requests or clients that are complaining that something doesn't work. And so I go through these stages, like, that can't happen. There's no way that doesn't happen on my machine. That shouldn't happen, number three. But wait, why does that happen? And then you have an aha moment. Oh, I see what's going on. And then you ask yourself, who developed this? I'm sure it was someone else. And then you get in there and you look at it, that was me three, four years ago. So hopefully, let's just refactor this and move on. So today, I really wanna give you the tools to be able to diagnose further, number four and number five. So why does that happen? And what is the solution when you realize that it is happening and you're not really sure how to solve it. So I'm gonna give you some tools, some tricks, some techniques to be able to troubleshoot the problem that you're facing and then come up with a solution using debugging and hopefully provide a solution to your client or your customer. So this is our agenda for today. We're gonna talk about debugging with print statements, something that I love to do, I'll be honest. We're gonna talk about debugging with XDbug. Who here has heard of XDbug? Awesome. It will help your life and your code in so many ways. Then we're gonna talk about debugging with the browser. Who here has debugged directly in the browser before? Nice, all right. Well, maybe I won't be teaching anything new here. And then we're gonna talk about some other debugging tools that I've used along the way that helped me solve problems. So, but first let's talk about a couple debugging prerequisites. So debugging PHP code is part of any project, but WordPress comes with specific debug systems designed to simplify the process as well as standardized code across core plugins and themes. So I'm sure everybody has seen the white screen of death. A client calls you up and says, hey, we're grateful that you guys built this awesome website for us, but nothing's displaying, it's white. Like, I don't see anything or they might see something like this, this page isn't working. Oh, that's a nice error message, right? You built them this $10,000, $15,000 website and the homepage doesn't even work. Or you might be getting a bug report. And the first prerequisite that we're gonna talk about is that when something like this happens, when a bug report comes in or a client calls up that's mad because their website isn't working, the first prerequisite is that we need to stay calm. I'm a big fan of the office, I love the office. And this is exactly how I feel when something comes across my desk, that's a hard problem. Like, I just wanna run around and be like, hey, guys, it's okay, it's gonna be all right, just stay calm, we're gonna figure this out, this is not that big a deal, it's okay. So the first step or prerequisite is to stay calm. The second one is to insert this little statement into your WP config file. Now, the WP debug constant is an internal constant in WordPress that can trigger debug mode throughout WordPress. Now, what does that mean? So debug mode basically means that all error messages or notices or PHP notices will display once WP debug is set to true. So this page now becomes something like this. So you usually get some type of statement that says PHP fatal error, right? And that's the reason why you're getting a white screen of death. So in addition to, although this is good that we're seeing this, sometimes it's not so good because you don't really want the client to see this. So you enable WP debug, but I also like to enable a couple other constants. The second one is WP debug log set to true and this will log any PHP notice, error, deprecated notice, anything that PHP will throw as an exception to the WP content debug.log file. Now, recently in WordPress, they also came out with a way to specify the path of where you want that debug log to be and instead of passing it true, you could pass a path instead of true and that will output the log notices to wherever you want. That's a recent thing though. Another constant that I always enable is WP debug display set that to false and any set display errors. I usually just include this one because sometimes some hosts won't obey the WP debug display. So I have to use the any set. It doesn't happen very often anymore but I usually almost always include it and this will hide that ugly error that you see on screen. So now the client's not gonna see the specific statement PHP fatal error online 99 so you don't look like a fool. Another one that I commonly enable which is script debug but this is every once in a while. Script debug when set to true will use the dev versions of the CSS and JS files included inside WordPress but there are some libraries that don't obey this such as jQuery. So I don't use it that often. One that I do use quite often especially in plugin development is the save queries constant and I usually set that to true and this will save database queries to an array that you can inspect and you can see what function called it, what's being called and how long it takes. Okay so now getting this bad error on the screen now becomes goes back to hey this page isn't working or the white screen of death but it allows you to output information to the debug.log file so that you can work in the background while something else is going on. So that's kind of the prerequisite that I always uses that you need to enable those constants anytime you come across an error or you start debugging something on a remote server and I use this a lot on remote servers don't look at me like that. What's that? Sure which one, this one? Oh sure so I use these a lot on what I'm debugging on a remote site and usually this is when like a client or a customer submits a bug report or a ticket request to me and says hey this is not working at all and usually instead of just walking them through it I usually just ask for some FTP access and I immediately go in and start enabling these statements so that I can see information in that debug.log file even though the homepage may not be broken I may be able to see either a PHP notice or a fatal error that's being thrown in a Ajax call for example the debug log file is very useful for that kind of debugging. It can be useful locally as well and you always want to enable it when you're developing locally but it's especially useful when you're trying to debug on a remote server or in some type of environment that you don't have full control over. Okay so let's talk about moving on from prerequisites and moving on from the constants that we need to set let's talk about debugging with print statements. So print statements are very useful for lots of different use cases. I know that we all want to jump to using an X debug but print statements do have their place in debugging. Now usually people that use print statements when debugging use something like these two statements. So die, var dump, some variable or die, var dump, some array and it outputs to the browser like this. So you're trying to debug something on the homepage you want to see if it outputs you want to see if the array outputs correctly then die, var dump is sometimes what you need to use and that's perfectly fine. So this is an example of how it can be used inside a function. So we're calling an action of WP head and we're trying to see what the current user array or object looks like and so we use die, var dump, print our current user true which will output exactly like this. Okay, now the die, var dump can be used but I usually like to stuff it inside of a function called DD die, dump is what it's called. If anybody's ever used a framework like Laravel or anything like that, DD is pretty common and it uses some type of dumper method but in this case I've modified it to just use our die, var dump statements so that whenever I'm debugging I have this function available instead of writing out the whole line of die, var dump I just write out DD which is a lot shorter and it gives me the same result. So whenever I'm debugging I try and make life as easy as possible and usually I have these functions stuffed into a plugin that I install automatically and I can give you guys an example of that a little later on. So let's go back to this constant though past the die, var dump stuff that displays in the browser. We want to enable WP debug display as false so that we don't see that gobbly-gook on the front end of the website. We want it to be output to the debug.log file. So in that case we use a PHP function called errorlog. So errorlog is very similar to die, var dump except for it always goes to the debug.log file. So errorlog, some variable or some ray using printr can be useful for outputting stuff to the debug.log especially in like Ajax functions where there's no front end display of an Ajax function you need to output that to some type of debug.log for further processing maybe later on. So I do the same thing with errorlog. I usually have some type of simple function like log or you can prefix it or put it in a namespace that allows you to, it's just an easier function to remember when you're debugging and you can pass a simple variable into this function or you can pass an array and it will output information. For example, like the current user, it will output the object of the user in a semi-readable form that you can go through and you can find the piece of information that you're looking for and be able to further debug from that. Okay, so that is debugging with print statements and it's a very simple technique, very useful technique and can be used in many different situations but my favorite way of debugging is debugging with xdebug. So in order to debug with xdebug though you have to have the environment locally or in a semi-close environment, maybe a virtual machine. I have used xdebug on virtual servers that are not on my machine before but it's a very rare case most of the time and it's usually only on a staging or a development site, never in production. xdebug is never turned on in production on any server because xdebug actually will slow down your site when you're using it. So xdebug, and this is from their website, xdebug is an extension to PHP to assist with debugging and development. It contains a single step debugger to use with an IDE, with IDEs. It upgrades PHP's var dump, so remember our divar dump statements. It adds, I put star traces, it's actually stack traces for notices, warnings, errors, and exceptions and it features functionality for recording every function call and variable assignment to disk. It contains a profiler and it provides code coverage functionality for use with PHP unit. Who here uses PHP unit and writes unit tests? Less of us, I guess. Unit tests I've found are, unless you really like them, they're hard to write, especially for a project that you may only be on for three weeks. It's hard to justify writing PHP unit tests and I found over the years that writing unit tests actually prevents you from having to debug them further. So I think of unit tests as preemptive debugging or preemptive strikes to running into issues. So take that with a grain of salt, it may not be within your budget or within your timeline, so just do the best you can. So like I said, xdebug can help in many ways. It can make our print debugging that we just talked about way better. So remember these dive our dump statements. Well, it can turn dive our dump statements from this, which is kind of hard to read, to look like this. So as soon as xdebug is turned on and you use a dive our dump statement, more than likely it will output something similar to this. Colors may change, maybe the indentation may change just a little bit, but it should look something very similar to this. This is easier to read in my opinion than this. So xdebug, even with our print steam, even with print statements can help immensely. So it can also turn errors like this that are very vague and one liner, even though it seems clear, maybe you need to know a little bit more of where it came from and xdebug can turn that statement into something like this, which will give some type of stack trace or maybe a couple more lines that will help you understand where this error is coming from or what caused it. So that's one way that xdebug can help. Another way it can help is it can do code profiling to measure performance. Now, I'm not gonna go over code profiling today, mainly because it's actually the least used feature for me, mainly because it's hard to measure correctly because there's so many different variables and the way xdebug works, it's hard to measure profiling, or at least for performance, with xdebug I've found. I use other tools for that kind of stuff, so take this one with a grain of salt. It can be used for that, but I tend to use other tools for performance. So the main benefit for me is the step through debugging feature of xdebug. And mainly I use this when I'm doing remote debugging into a virtual machine, something like, I mean it can be used on any different environment, such as MAMP, I tend to use Laravel Homestead or Valet. It can also be used with local by flywheel. That's a very easy tool to work with when it comes to xdebug and it's actually the tool that I'm gonna be using today to show off xdebugging. So it can work with many different environments. Now, it also needs to be able to work with some type of editor in your environment, such as an IDE. My personal choice is PHPStorm. Who here uses PHPStorm? Nice. I am a big advocate of PHPStorm. Even though it technically costs money, it is well worth it in the amount of time that it may save you on a project or finding out an issue just because of the amount of tools that it gives you to debug an issue or it also gives you many different tools to help you write code that will be more performant and easier to work with in the future. But you could also use something like Visual Studio Code. It's also very good. I also use Sublime Text a lot. I'm an original Sublime Text user. I like Sublime Text for many different things and I've even used it for xdebug. So, notepad++? It does not fit on my slide, but I have used notepad++ before in the very early days of my development and it's not a bad tool. I just feel like there's better tools out there. So, PHPStorm, Visual Studio Code, Sublime Text are kind of the standard these days. So, if you haven't checked those out, I recommend you go check them out, see if you like them. So, when we're doing remote debugging, we have to enable xdebug and this is different for each environment that you use, whether you're using MAMP, something like Laravel Valley or Homestead or maybe VVV, but I'm gonna show a simple way using local by flywheel. And there is this add-on for local by flywheel called xdebug controls and I've given the link at the bottom and you guys can go check this out, but it basically allows you to activate xdebug when you need it and it allows you to select things like the port. Let's see. What's that? Yes, I am. There will be available, Carol's gonna post them after this and I'll also tweet them out to a link that you guys can download them. So yeah, xdebug controls is very useful at least for using xdebug. Okay, so I use PHPStorm, which is the IDE of choice and that's what all the examples will be in and so let's get into the process of remote debugging. So at this point, we now have an IDE that we're gonna work with. We also have xdebug set up for local by flywheel and it literally comes pre-packaged. The add-on will just help you enable xdebug and put it on the right port. Now, the biggest hurdle for people to get xdebug working is getting the configuration set up properly so that xdebug can work. I feel like the majority of times I've tried to use xdebug and I failed is because I didn't have a piece of configuration for xdebug set properly. Maybe I had a different port. The standard port for xdebug is 9,001, I think, or is it 9,000? But I usually set it to 9,002 just because I know that something else could be interfering with it and I know that 9,002 isn't used for anything so that's what I usually set it on. And then I usually always set, let me go back to this side, I usually always set a remote enable to true sorry I made this really small and I can't see it. So show local vars, remote connect back needs to be on, remote auto start needs to be on. Those kind of debug variable or xdebug variables need to be set properly for it to work and make sure that you have it turned on because you can turn xdebug off and still have it installed but make sure it's turned on. So now that we're using PHPStorm, let's go through a little bit of how it works. So when using xdebug, we're hoping to gain a little bit of insight into what the code is doing, what is happening with the scope of the code, what variables are being set and what variables aren't being set. So the first thing that we need to do is we need to start listening for any xdebug incoming connection because when you refresh your browser, a connection will start if you have xdebug on and you're listening. And so PHPStorm will pick up that signal and say okay, I need to look for any break point. And you can set a break point by putting that little dot in the gutter of the ID and it's just a little click. And basically what I'm saying here is when an xdebug connection comes in, I want to stop at that point and evaluate what's happening. And at that point, I basically start to get information coming through and where it's coming from. So in this case, in this specific scenario, I'm trying to inspect what's happening with current user. Now I put the break point directly on current user but when it breaks at that point, current user technically is not set. So what I need to do, sorry, I don't have this on the slide but what I need to do is step over and there's different controls to be able to do this but I basically need to step over current user and that will give me the value of what current user is set to and notice there on the right in the red highlight, it says current user and it has data that is set and it also has data that is set down in the variables pane down below. And so you can expand this information and just like with our print statements, we can now see what's happening with current user. Are we getting the right ID? Is a capability set for this user? There's tons of information that you can see along with any of the global server variables or the get request variables or anything that you're trying to look for is usually in this variables pane. Now another cool thing about Xdebug is that when you're hitting break points, you can use an interactive console to evaluate expressions. So you can pretty much type any PHP you want inside that console and it will give you back, let's say the value of the current user. So, and sorry, my slides are kind of out of order. So after using the console and stepping over or stepping into a function, that's what's happening here. Basically at WP and Qscripts, I'm stepping into the hook functionality that comes into a different file. You can also use the step over function that will step over the current function that you're trying to evaluate, et cetera. So I just have a couple more screens. Gosh, I wish I could see this. Sorry, these are out of order. So step into, I already showed step over. I wanted to show this part though. So with any break point when you're using Xdebug, you can actually set conditional break points so that it will only run if a certain condition is met. And a very simple example of that is I set the break point to current user, but I only want that break point to stop when the current user equals one. So very useful for that. I am running way low on time here, hold on. So conditional break points, great stuff. Xdebug basically is just awesome. So if you haven't used Xdebug, I encourage you to research it and add it to your tool belt to be able to debug your code and your plugins better. So let's talk about debugging with the browser and we're gonna kind of go through this a little fast. So the typical debug with the browser is you use console.log. And you're usually debugging some type of JavaScript if you're using the browser to debug. So when you use console.log, it will usually output in the console whatever you put in there. Such as hello, hello, Corey. But another place where I would recommend that you look, next time you're trying to debug some JavaScript is in the sources panel. And this sources panel can be very useful for debugging certain JavaScript files. And it basically acts as a simple Xdebug, but for your JavaScript inside the browser. And this is showing Chrome, but I know that you can do this with other browsers such as Safari or Firefox, just not as well. I typically use Chrome all the time. So we have on the left, the file navigator, in the middle, the code editor pane, and then on the right side, the JavaScript debugging pane which is very similar to the Xdebug that's in our PHP Storm IDE. So you can set break points just like you do in Xdebug and you can evaluate them on the right. So you can even store local variables or watch certain variables, which is really nice. And you can even do conditional break points which is really nice. So let's say that you only want it to break if a certain value equals a certain string or a certain integer, you can make that happen. And the way you do that is you right click on the break point and click edit break point and it'll give you this little dialogue that will be kind of interactive and you can set it to certain variables. Okay, you can also use the debugger statement in your JavaScript. So the debugger statement will automatically stop your JavaScript at that point. It's kind of like a break or a dive or dump but within the console. So yeah, this is just more slides that I wanted to go over about resuming, stepping over, stepping into, stepping out. Very useful. Another thing that you can use when debugging with the browser is the view if you're working with view which hopefully you are or React, you can use the view JS panel which is a Chrome extension and there's also one for React developer tools. So if you're working with Gutenberg and need to debug some React stuff, React developer tools is a great way to be able to do that. So other debugging tools that you can use, these are just some of the ones that I like to use and they're plugins. So WPPHB console, I haven't used this that often but every once in a while I do like to use it. Basically it's a plugin you can install with a Chrome extension that can allow you to set kind of PC certain debug statements and they will appear inside your console on your browser with stack traces and everything. So that's a really nice plugin to use sometimes. The next one is debug bar. I'm sure many of you have used this. I've used many different extensions for debug bar. You can view WP query information, you can view hooks. One really nice one is a rewrite rules inspector that's pretty fun to use and to test your rewrite rules. And the last one that I like to use more than any other tool is query monitor. Who here uses query monitor? Good on you. It is an excellent tool that can output many different pieces of information. Just going through these fast because I've only got one minute. The last tool that I will mention is a tool called git bisect. Who here has ever used git bisect before? So not very many. Okay, good. Git bisect is basically a way that you can identify a commit that introduced a bug. I would explain more about it, but we're kind of out of time. So thank you. Hopefully you learned a little bit more about debugging. And I don't believe we have any time for questions. Sorry guys. If you have questions come up to me after I'd be happy to explain anything that I presented today or if you're having a specific issue with something regarding debugging or troubleshooting. Thank you.