 and we are recording. Just a reminder to everyone. All right, so we are recording and welcome to everybody who is joining us today. As you are joining, if you would like to code along with me today, there is a plugin that you can download. I'm going to copy that link into the chat now. You will need a local WordPress environment and a code editor for that if you do want to code along with me. But otherwise, if you are downloading that or if you're not, or whatever the case may be, please feel free to go ahead and let us know where you're joining us from. You're welcome to chat or you're welcome to use your mic, whichever way you prefer. And then we'll start in a few minutes. Fantastic. I'm opening up that GitHub link right now here. Oh, we've got some other people coming in. Let's go right ahead. Wonderful. WP-learn-debugging 1.0.0.zip. I'll go ahead and download that right to my desktop. And then you said a local Dev environment, right, Jonathan? Yeah, if you want to code along, a local Dev environment of whatever type of environment you prefer. Oh, boy. Yeah, we've got Eagle from Santa Cruz. We've got Dave from Springfield. Oh, hey Dave. Wonderful. Yeah, let's chime in. Where are you guys from? Here, I'll go right ahead and put my calendar. Let's see if I can find my flag here. So, emoji hunting. Marko's from Stockholm. Hello, I'm from Canada. And we've got Kaiser from Dhaka, Bangladesh. And Kipa from Ukraine. Marko from Stockholm. So glad y'all are joining us. And Tracy Rhodes, Dylan Reno. There we are. Mark Wise and Sioux Falls, I think that's not so Sioux Falls, South Dakota, USA. What a lovely audience we have joining us today. Oh, Miguel from Salzburg. Where's Salzburg? Oh, and we've got Maria, Maria, partner Matt from Maryland, from Pittsburgh, Pennsylvania. And Archie Klein from Frankfurt, Germany. Okay, so I think everybody who has wanted to join is now joined. So I think we can start moving on ahead. So today, we're looking at debugging in WordPress. Before we get started, as always, a few announcements. First of all, welcome again, everybody. And thank you to Megan, who is coasting with me today. So everybody say hi, Megan. If you can't see this announcement slide right now on the screen, please do let me know. There should be a Google slide in front of the screen that I'm sharing with you. If you can't see it, I'll just disable the screen share and then re-enable it. So let us know in the chat or via mic, by audio, if you can't see any of these slides. As always, we are presenting in focus mode. So what that means is Megan and I can see all of your video, but you can't see each other. But please do feel free to enable your video if you would like us to see you. Currently, they're all disabled by default as they join. And this is just to prevent any kind of problems with Zoom bombing, which we have had a few issues of in the past. And then as always, you are always welcome to ask questions. You're welcome to post your questions in the chat or unmute to ask questions. The only thing that I ask is if the question is not specifically related to what I'm doing on screen at that time, please keep it for the breaks in between that I do allow for where I take a sip of coffee or water or something just to get my breath back. And then you can ask those questions there. You're welcome to, if you think of the question, you're welcome to post it in the chat. And then when we take those breaks, we'll cover those questions. But you are always welcome to ask questions. Then just a double check to make sure that everybody who wants to download the zip file and code along with me today, we're not actually going to be coding in the plugin. The plugin just contains an error, which is what we're going to be using to switch on debugging and see that error. And then also, if you're on a Mac, sometimes when you download a zip file on a Mac, it downloads the file and extracts the file and you end up with just a PHP file in your downloads folder or on your desktop. So there's a link that I found a while back to specific issue on a Mac. So if you find it's doing that's not downloading the zip to whatever you wanted to, you can either switch to different browser or change your Safari to automatically download the zip and not extract it. And then last but not least, as always, if I'm going too fast, do let me know. Do slow me down if I'm speaking too quickly and the closed captions are not keeping up. I do tend to get excited and I do tend to talk fast, so do give me a shot if that happens. And then last but not least, we will be posting the session to WordPress TV afterwards, probably during the course of the day tomorrow. And if you're looking for any other WordPress focused content, please do visit learn.wordpress.org. As I mentioned last week, all of my workshops are being turned into tutorials as well. So you can catch this now live or you can catch it recorded on WordPress TV or you can catch the shortened tutorial version of it on Learn WordPress in about a month to two months time. Okay. Any questions on all of that before we get going? Anybody still needing to get their local environment set up or anything like that need me to slow down before we kick off? Stuart has a question. So please go ahead with the question, Stuart. Oh, oh, could not hear me. Is anybody else having issues hearing me? Or can you hear me now, Stuart? Okay, all good. Excellent. Okay. Eagle says loud and clear, so I think we're all good to go. So let us move on to our learning outcomes for today. Today, we're going to be specifically looking at enabling the WordPress debug constants and what each one of them does and how they're useful. We're going to be looking at two debugging plugins. We'll be installing them and showing you kind of a breakdown of how they work. And then if we have a little bit of time towards the end, I also want to share some additional tools with you that I can recommend checking out. We won't specifically be looking into how to use those tools today, the additional tools. I'm planning hopefully a future session on how to use those and set them up because there is some installation required and some configuration required, but I will guide you through what they are and how they work. And then I'll also share a link to an article that talks about all of this process towards the end. So that's the goal for today, but primarily today we're going to be looking at the different constants in WordPress that enables different debugging options and then the two debugging plugins and why and how they're useful. I would also mention, and I'm going to do this now before we get started. I am still suffering a little bit with the symptoms of a cold that I had a few weeks ago. So my voice is very croaky. So I'm going to pop a threadloads engine now just to help my voice as we go through this. And so I apologize for any sounds of a sweetie rolling around my mouth. Okay. So if you haven't already had a look at the slides that I shared, I didn't flip. I just realized I didn't share them. Let me share them now. I'll share these slides with you now. I forgot to share them in PDF format in the group. So let me just enable this for anyone with the link. And I will copy the link into the chat. And if you want to follow along on the slides, you're more than welcome to. But the first article and the main article I want to share with you today is this one over here. So I'm going to pop this in the chat as well. You're welcome to open it up with me. I'm going to hide some controls. This is an article about specifically debugging in WordPress. Sorry, I've got all kinds of fan zoom things happening. Yeah, that's why my mask is moving around everywhere. But it is an article on the documentation, on the WordPress documentation specifically in the developer hub. And the title is debugging in WordPress. So everything we're going to be covering today is in this documentation. So if there's anything you're not sure of or if there's anything you want to read further about, so you can go and read up about it there. I'm going to be doing a very high level overview of the options on this page and showing you what they do and what happens when you switch things on and all that kind of thing. But that's the article that we're working off today. I have my local LearnPrice environment already set up and ready to go. And I don't have my plugin installed yet. So I'm going to install that first. I have it on my desktop. So I'm just going to click Add New. And I'm going to click Upload Plugin. And I'm going to choose File. And then there it is on my desktop, WB Learn Debugging 1.0.0. I'm going to open that and install it. And then I'm going to activate it. Now, the plugin itself doesn't do much. I'm going to switch over to my VS Code install now so I can show you what the plugin is doing. So this is VS Code with the LearnPrice site already opened. And there is the Learn Debugging plugin. It literally has one PHP file. The PHP file does two things. The first function here is it registers an activation hook. This is basically a function that will fire when the plugin is activated. And all this hook does is set up as Custom Table in the database. So the Custom Table will be called Form Submissions. It has an ID, a name, and an email field. That's not super important for our needs today. This is some code that I copied from a previous example plugin that I created before I think it was the REST API tutorial. But that's not super important today. The important part is just below that there is a function called WP Learn Register Roots, which is hooked into the init action hook of WordPress. So when that action hook runs, it'll fire this code. And what this code is doing is it's registering a custom REST API root. Now, if you don't know what any of that means, don't stress too much, because the actual REST API root part is irrelevant as well. Essentially, it's a custom root on the REST API WordPress that you can make requests to and you can receive data back. So don't worry too much about what it's doing. But the key thing to look at is the fact that it hooks into this init action. It registers this callback function into the init action, and then that will call this piece of code over here. Now, if you have installed this plugin on your site like I have, and you have activated it in your dashboard, you should theoretically see the dashboard screen that I'm seeing now, the plugin activated message displays, and the learn debugging plugin has this blue background, and everything is all well and good. However, I happen to know that there is a bug in this plugin's code. But looking at the WordPress dashboard right now, I don't see any kind of notification about the fact that there is an error. Now, the reason for that is that by default, if we open up the in the root of your WordPress install, there is a wp-config.php file. That file you may or may not recognize as the file where you will set up your database configuration settings if you're installing WordPress yourself manually. But towards the bottom of that file, there is an area where it says here add any custom values between this line and the stop editing line. And often if you're doing things like registering constants for a multi site network or things like that, that's the place where these constants are set. A lot of modern hosting platforms will do all of that for you in the sort of setup process. But some of the hosting companies that have been around for longer and sort of stick to what I like to call a more default WordPress install will guide you through sometimes making changes to your wp-fig file. Now, if we have a look here at this line 82, you'll see there it says define wdbug to false. So what that means is the wp-debug constant is set to false by default in a WordPress install. And what I would like to show you now is I would like to show you what that means when a WordPress request runs. So if I copy this wp-underscore debug constant out and PHP constants are always generally uppercase. I don't think it's a requirement, but it's sort of a standard that folks have adopted. And if I search, I can use the little search icon on the left hand side of my VS code window. And I search for wp-debug, which I've done by just pasting the clipboard value into the text field. You'll see the one, two, three, fourth result is in the wp-settings.php file. Now, some of you might remember a while ago we did a WordPress, what happens when a WordPress front-end request is run, and we look through the wp-settings file. And one of the things that runs is it checks if wp-debug mode is enabled and it runs this wp-debug mode function. So in VS code, because I have a certain plugin installed, I can highlight debug mode and I can click on it and it'll take me right to the file. But the file that I have opened, I'm going to guide you to there if you want to see it as well on your local WordPress install. Sorry, I just hid the wrong zoom thing, is inside the low.php file. And the low.php file, let's just see if the VS code, there it is. The low.php file sits inside of the wp-includes folder. So if you have your WordPress install open in your editor and you want to see where this file is, you go to the wp-includes folder, which is in the root of your WordPress install, and you scroll down to the files and there's a whole bunch of files above there, but you find the one called low.php and you open up that one and it's on line 444 function wp-debug mode. So let's have a look at what that code is doing so we can understand what happens. So it's here on line 479 and it says if wp-debug, in other words, if the value of wp-debug is set and it is true, then it does a whole bunch of things. It first calls the PHP error reporting function and sets the value to error reporting to the E underscore all constant, which is a predefined constant in PHP. And basically that means switch all error reporting on. So anything that was off previously, switch it all on. Then it checks if wp-debug display is set. So that's another constant that you can set in your wp-config file. And if that is true, then it'll set a PHP initialization value, which is what this I and I set function call does, and it says display error is one or true. If wp-debug display is not set or doesn't exist, in other words, the constant hasn't been defined, then it'll set the I and I set display errors to false. And I'll show you what that does in a second. Then the next thing it does is it checks if there is a wp-debug log constant and if its value is true. And if that's the case, then it sets the log path to the content directory, which I'll show you what that is in a second, and to a file called debug.log. If the string, sorry, if the D log value is not a true or false constant, it is a string value, then it'll set the log path to that debug log value. So what that means is you can actually set a specific path for where you want the things to be logged. Otherwise, it sets log path to false, which means it won't log anything. If log path is set, in other words, either to debug.log or a custom location, then it does some more PHP initialization settings. It sets log errors to one, and it tells PHP where to log errors. So it sets the error log in the PHP I and I to the log path. So those are all the things that happened if wp-debug is on. So just by enabling that constant, switching it from false to true, a whole bunch of things get enabled for you by default. Otherwise, it sets the error reporting to a specific subset of errors. And it's basically only core errors, core warnings, any compile errors, any major errors, warnings, pass errors, but it won't show you any deprecation errors, anything that won't break the site. So that's why at the moment, when I, if I go to, sorry, Zoom keeps taking over my window here, if I go to my wp-config file now and you'll see it's set to false, I'm not seeing the error that I know is there. If I switch this to true, that's all I'm going to do. I'm going to change wp-debug from false to true, and I go back to my dashboard and I hit refresh. Suddenly, I have right at the big of the top of my screen here, I have an error being returned. And I'm going to just zoom in so that everybody can see that. So there, right at the top, it says notice function register rest root was called incorrectly. Rest API roots must be registered on the rest API in it action. So I've effectively used the wrong action when I registered my rest API call. Now, the nice thing about this is the WordPress core development team are very, very good at making these errors human readable and also very framing so that you can understand what's going on. It says this message was added in WordPress version 5.1.0, which means before 5.1.0, either the message wasn't there or the functionality was different. And it tells you where the error is happening. It's happening in functions PHP line 5865. And the reason it's happening there is because that's the file in WordPress that handles the action in full talks. But what's great about it is this line over here tells us this is the error that we need to see or we need to fix, at least must be registered on the rest API in it action. So that's great. I can go into my code now. I can copy that rest API in it action line there. I can go into my plugin code. I can change the net action to rest API in it action. I can switch back to my dashboard. I can hit refresh. And yay, I fixed my buck. My buck is no longer an existing because I have not done things correctly. Okay, that was a lot of information done. So I'm going to take a break now. If anybody has any questions around how all that works and what we were doing. Otherwise, I'll take a break, grab a sip of coffee. And if there aren't any questions, we'll move on. But if there are questions, we can we can handle them quickly. And just having a look, it doesn't seem like we have any questions. So I'll go ahead and ask one. Jonathan, do you know what this Hello Dolly plugin is above? Because I mean, I've heard a song, but I don't really know what it's about. So the Hello Dolly plugin is one of the first plugins that Matt Mullardwig ever developed. It's a plugin that ships with WordPress core. And one of the reasons it ships with WordPress core is that it's a good example of a simple plugin. So for first time plugin developers, they can have a look at it, break it down, see how it works. And essentially what it does is if you enable it, which I'm going to do now quickly, it will automatically output random lyrics from the song Hello Dolly by Louis Armstrong at the top of your WordPress dashboard. It used to be enabled by default. And then a whole bunch of folks in the community didn't like the fact that it was enabled by default. So it has now switched to being disabled by default. And I do understand the argument. Essentially, you're getting an additional thing that you didn't ask for. Certain web hosts remove the plugin completely on a WordPress install, which is why some folks may have never seen it. But it's been part of my WordPress experience since I started WordPress. I'd actually use Hello Dolly to teach folks plugin development because it's a very simple plugin that uses a hook, it uses a callback function, it uses an array. So it's a great way to teach folks about plugin development. So if you ever want to check it out, I do recommend that. Can I ask one follow up question then back to the show? Do you think I could use that plugin and then put some of my own song lyrics in it instead of? I've actually done that. I haven't released it yet, but I have a version of Hello Dolly that is actually called, what is it called? It's called Metal Press. And it selects random lyrics from a motorhead song because I'm a bit of a metalhead and it puts those in my WordPress dashboard. So on some of my local environments, I have that plugin installed in place of Hello Dolly. So yes, you can absolutely do that. Oh, you got me jammed into that. All right, back to you. Okay, great. So we've now discussed the very first option in this article that I shared with you earlier, the WP Debug option. I kind of went through the process of what it does and all the things that it enables. The short answer is it switches those error messages on. That's the short answer. It does a whole bunch of other things, but we see that it switches it on. Now, the two additional ones that we chatted about when we were looking through was the WP Debug log. And then below that the WP Debug display. So as I mentioned earlier, WP Debug log logs the errors to a specific file. So what I'm going to do is I'm going to switch back to my plugin code. I'm going to reintroduce the bug so that we can see where the bug gets logged. And then inside of my config file, I'm going to just take this whole line of code here, copy paste it out so I can just add WP Debug log. And I'm going to set that to true as well. And as I mentioned earlier, by default, it will log it to the WP config directory, which is the one that sits just above WP includes just below admin. It's where all the plugins themes and uploads sit. And there is the debug log file there. I'm going to delete that one now. Because in a default WordPress install, if you enable the debug log, it will create the file if the file doesn't exist, because the WP content directly should be writable, because it's where you upload themes, where you upload plugins and where you upload media. So with WP Debug set to true, and WP Debug log set to true, and a bug in my plugin code, if I switch back to my dashboard, and I'm going to make this a little bit smaller again, and I hit refresh, it's now logging the error to the screen. But if I switch back to VS Code, and I have a look in the WP content directory, we will say there is the debug log file. And if I open that up, it also is logging the error to the debug log file. Now, the nice thing about logging the errors to the debug log file is I can then keep track of any errors that have happened. And I can sort of go back to them if I need to. It logs the date, it logs the time, and it logs the full error message. The downside of logging them to the debug log, as you can see, sometimes the error messages are quite long. So you have to kind of have wrapping enabled, or whatever the case may be, to be able to jump along them and read the whole error message. And also, because most of the error messages are expecting to be going to the screen, it has some HTML code embedded in there, which is not the end of the world. Now, what I prefer to do, and you'll see it's busy, it's busy logging errors because there's a WordPress admin Ajax function that fires every few minutes that is known as the heartbeat, pings, WordPress.org. And every time that's firing, the bug is logging in, it's logging it to the debug log. What I prefer to do is I prefer to include the WP debug display error, sorry, the WP debug display constant. And I prefer to leave that as false. And as you saw earlier, what that will mean is it will not write the errors to the screen, it'll then only write them to the log file. That's my preferred way of doing this. Now, there are some pros and cons to doing that. The pros, when you're in hardcore development mode and you're testing things out and you're coding and you're testing and you're coding and you're testing, you're not being held up by, oh, suddenly there's a bug that I need to fix. You're getting on with making your feature work or your plugin work or your theme work or whatever, and you're not seeing the bugs. The downside is you're not seeing the bugs. So you might miss them. So it's a good idea. What I tend to prefer to do, especially if I'm building out a new feature or I'm building something and I'm trying to figure out I will enable debugging, let it log to the log file, but disable it on screen, do my thing, get it working, and then I'll go back to my debug log and I'll see if anything was logged. And what's really, really nice is what you can also do with the WP config debug log is, as I said earlier, you can specify a specific path. So you can create a custom folder, you can create a path to a file that includes a date and a timestamp. So what I usually do is I set it for every day so that every new day that I'm developing creates a new log file, I can go back and look at old log files if I want to. But this is the way that I generally sit and have these three things enabled and I log to the file and off I go. Okay. You will notice, and I think it does say this in the documentation, that WP debug display and WP debug log require WP debug to be true. So if you haven't set WP debug to true and you try and enable the debug log or control debug display, that's not going to happen because as we saw earlier in the low.php, all of this additional functionality around debug display and debug log requires WP debug to be set to true. So unless we set that to true, nothing else is going to happen. Okay. I'm going to take a pause there and check if anybody has any questions. Otherwise if they don't, well, I have another one. I'm just filled questions today. So like that could be a little bit of a trick. So like you could get tricked up accidentally if you didn't know that, you know, that has to be on and off. Let's switch this then. Yes, absolutely. And that's, so that's why my default is always to do this configuration here. So it's like when I have, when a client contacts me and says they're getting a white screen of death or something is not working the way it should or some piece of functionality is not working the way it should. I've already got it hard coded into my head. WP debug true, WP debug display false, WP debug log true. I set those three as is, run the functionality that I'm trying to run, and then I check the debug log file. That's my default process for debug. Okay. Right. We don't seem to have any questions at this point in time. So I want to show you an additional thing that you can do that you can use when you've got this configuration enabled. And this, this is not based on having debug display set to false. This will work if debug display is set to true anyway. But this all this is nice when you have debug log set to true. We're developing, I'm going to fix this code quickly here. So let's actually just go back to the debug log and find the right action. Rest API in it. Excuse me. What you can do is you can use a PHP function called error underscore log. So what I'm going to do, if you have a look at this plugin code, there is this WP learn get for missions endpoint. Yeah, we should be able to trigger that. What I'm going to do is I want to let's say I'm debugging this. So let me show you how this endpoint does work. We'll just quickly run it in a browser. So I'm going to copy out the namespace for this endpoint or the root, at least should I say, I'm going to go to my local site, which is learnprice.test. It's the WP JSON URL. And then it's that one should work. Actually, hang on. Why doesn't that work? Have I copied this incorrectly? Let me just check my code here. Oh, I need form submissions as well. Copy that. API v one form submissions. WP learn form submissions. What have I done wrong? Oh, there is a forward slash missing. There we go. Hang on. Hang on. That shouldn't be doing that. WP learn form submission. Yeah. Okay. So if you've got this plugin installed on your local environment, whatever your URL is, your local URL, you can append this WP JSON, WP learn form submissions API v one form submissions URL to it. And it will then run the rest API request, which can be done in a browser. And you should get back an empty JSON array, which is the square brackets like this. I have a browser extension installed, which kind of cleans up the response. But if I switch to the raw version, that's what you should see. The same kind of thing. So let's say I'm doing that now, and I want to be as you see, maybe I'm expecting there to be results, and I'm not getting results. And I'm wondering, well, why aren't there results? And I want to be able to see what's inside of a variable that should have some results. If I switch back to the code, I know what aren't results. There are no records in the form submissions table, but let's say I want to inspect this results variable here, which is going to get the results from the table name. I can use something called, as I mentioned earlier, the error log function. And if I call error log and I pop in the results, something is going to happen. So let me show you what that looks like. We're going to leave debug true, debug display false, debug log true. And then I'm going to refresh this. And a critical error happens. Now, the reason the critical error happens is unknown to me right now. But I have debugging enabled. So let's go and have a look. And if we have a look at the debug log, we will now see that there was a fatal error that happened. So now I've actually created a PHP error. I'm using error log incorrectly. And the debug log is a great way to see these errors in action. Now, this is the other reason why I like to log to the debug log file, because let me show you what happens if I have debug display on as well. Is I get all of this on screen. And this is very difficult for me to read, because it's kind of just all jammed on screen. Whereas in the debug log, it's a little bit better formatted. I see right at the top, I see the time and date that the error happened. I see that it is a PHP fatal error, which is a very bad error. I see type of error, uncord type error, error log. It gives me some information. It says argument one, the message of the error log function must be of type string. And I'm giving it an array. So I'm giving it the wrong type. It's also telling me where it's happening. So it's inside of my plugin in the learn debugging plugins folder in that file. It even tells me what line the error is happening on. Excuse me. And then it gives me a full stack trace. So it goes all the way back from the first index of PHP file all the way up to where my error is happening. So that's another thing that I wanted to show you. I specifically introduced an error. And I wanted to show you what happens on the front end when you have debug layout off and then what happens when you have it on and then how it logs it to the debug log file. So now we can fix that error. Let me just hide these controls again. So to me, it's getting back an array of information. It needs a string. There's a very handy function in PHP called print underscore R, print underscore R. You pass it in the array and it'll convert to a string. And then if you're using it inside of an error function, you simply pass in true as the second parameter to the print R function. And what that does is that says instead of, so by default print R will export it to screen. If you specify the second parameter as true, it'll return it as a string. So this is a function that is very handy to keep. I'm actually going to copy this code into the into the chat. You can replace the results variable there with any other variable, be it an object, be it an array, be it a standard string, and it will return it as a string to the error log and you'll see what's going on. So what I'm going to do now is I'm going to empty out the debug log. I'm going to switch back to my submission, make the request. And now if I go into the debug log, I will see there. At that point, it is actually an empty array. So that means that there's nothing being returned from the query. So maybe there's no data in my database, and I can continue on from there. So error log is very handy to use with the print R statement. There are other options you can use. There's var dump in PHP, which gives you other things. There's a couple of options that you can use. Okay, going to pause there and check if there are any questions before we move on. Yes, indeed. If anyone has any questions. Now I'm sure everyone's asking and wondering what my third question is, but I actually don't have a third one right now. I'm just bumping and soaking the same. Now I remember, I think I saw a sticker on some laptop about var dump, and I'm not going to say it on this broadcast, but it does seem like that's an interesting function for sort of seeing what's in the clipboard, I guess. So let me actually show you what var dump does. You'll notice what I'm going to do, just very quickly, bear with me, I'm going to add a couple of records to my custom table that we plug in this query. So give me a few seconds here. I use PHP admin, PHP my admin in the browser just because I've been using it for so long. And I'm going to go into the learn press database and I'm going to find my form submissions table. Excuse me. And I'm just going to add some dummy, dummy data. Not even some Lauren Mipson. Look at that. I don't have the best brain for example data, but I always try and make it real as possible. I usually, I usually go with this, there's, there's John Doe, Jane Doe, Paul, Paul, Paul, what I call that's usually Paul George and George Paul. And then I jumped to Beatle names. That's fine. You can call me Megan Ringo today because I'll say Ringo, Bingo, Dingo, whatever if you want to try a really long name in your variables. I see Shohei has a question about a case study on separating debug and error logs. I actually don't have a case study on that Shohei. There are better ways of doing it than what I'm, I'm suggesting today. But you would, you would essentially, because my guess is that you have to see the difference between errors that are being reported because there's bugs in the code versus you logging to a specific location. The one way you could do that is enable the debug log and then have some parser that'll go through it. The other way that you do it is there's a, there's a tool that I'm going to chat about later called Ray. And Ray has a plugin that you can install on your WordPress site and I'll just go through how it works in a second. But then when you, when you use the Ray function, it specifically logs to the Ray application. So your, your functions that you want to export or your variables that you want to export would go there and your errors would go elsewhere. But I'm not aware of any case studies separating the two. I can definitely dive into it. I will see, I will see what I can find. I just realized I haven't, I'm just, would that be Ray.io? I was googling around here and I think it's Ray.io. I'm at 100% sure myself. No, no, it's not Ray.io. That's fine. We'll cover it quickly at the end. Okay. So I have, now I've got this thing rolling around my mouth. I've added the two fields to the table and you'll see that when I make the request, the fields return as a JSON object. So what I want to do now is show you what this does in the debug log. So let us just, so there you can see it there. That is when we, when we use print R. So it tells us that the initial variable is an array. The first value of the array is an object and the object has certain properties inside of the object. So that's when we use print R. When we switch to using var dump, let me show you what that does. So it's a var dump and then we can just pass in the results. I think that's all that's needed. Function value, array values, variable on export, why is it giving me an error? Expected type string. Oh, this also exists as string. So I think one, let me just, let me just check the PHP manual for this one. I don't generally use var dump. So give me one second. Okay. Parameters, the values, the value. Yeah. So that'll just export the value. So we'll need to use this with print R to get the human readable format. So let me do that. So we'll go print R, var dump, the results and then return true on that one. So that'll give us the string to the error log. And if we now make the same request, there it is there, I'll make the same request. You'll see. So what var dump does is it sends it all out to the screen, which is really not ideal. However, what's nice about var dump. So let's go back to the debug log. It's not logging to the debug log because var dump only goes to screen. What is nice about using var dump is you'll see that every single property within the object, it also includes what variable type that property is. So var dump gives you way more information. But as you can see here, var dump only exports to screen. You can't, well, you probably can capture it to a variable. You'd have to probably use something like output buffering or something like that. But it gives you more information. So that's the difference between the two. Okay. Let us keep going here. So I'm going to just do that. And I'm going to just clear this out over here. All right. That's our debug log. Let's close down settings and load. Let's go back to our, I'm going to just revert this change here. There we go. Okay. So that's how we can enable some basic debugging. Error log with the print r combination is a great way when you're doing debugging, you're trying to find issues. You're trying to see what's inside of variables and arrays and those kinds of things. It's a great combination to use. The next constant that this document has is the script debug constant. Now, what this essentially does is if you, if there are any built in JavaScript or CSS files, now, this would, this, this is coming from the days when we were using things like Gulp and grunt and various other things to minimize JavaScript files, to minimize CSS files. So they took up the least amount of space. Basically, what was doing is all the white space was being stripped out. In some cases, the JavaScript was being, being transpiled slightly. So long variable names were made shorter. And most of those debug, sorry, most of those default script files have a original source version, which is the sort of original way that the developer coded it. And then the transpiled version. If you define script debug to true, it'll load the original source version. And you can then inspect that version of code in, in the developer tools. It's something that is not super useful if you're trying to debug issues with the block editor, because a block editor uses a totally different way of transpiling that code. But if you're working with any of the, of the other libraries in the JavaScript world, you can use script debug, set it to true, and, and test any modifications on any of the built-in CSS or JavaScript files. It's not something I generally use. The only time that I've actually used script debug is when I was working on a plugin that had a JavaScript file and a CSS file with it. And I used to ship the original development version of the JavaScript or CSS file and the production version. And then enabling script debug enabled me to load the development version when I was developing, but then ship the production version, which was minified and all of that with the final, with the final plugin. And then lastly, there's the save queries constant, which I want to show you how that works and how it can be useful. And what save queries does is it saves any database queries to an array that can be displayed. So if you're having a WordPress site that's really, really, really slow, one of the things that you can check is what queries are being run and how long, how long they take. So let me show you with our little form submissions set up that we have, what happens if we enable save queries. So the first thing I'm going to do back in my WP config file is I'm going to define save queries as true. And I just want to mention something. It's a little bit of a side tangent. You'll see in the config file online, whatever it was originally, they say add any custom values between this line and the stop editing line. And then there's the that's it stop editing, happy publishing. You're supposed to, what I'm doing is kind of wrong, what you're supposed to do is define any custom values between those two lines. However, if you do it just after WP debug, that's also okay. It's not going to break anything. And I prefer personally to group all of my debugging constants together with the main WP debug. And then if I have any other custom concepts that I need for a plugin to fire or for some custom functionality, or maybe it's custom API keys or anything like that, those I will put between the custom lines and values. Not having them in there won't break anything, but definitely having them after this set of code will cause you some problems and possibly putting them before this code will cause you some problems. I generally have all my debugging ones here with the WP debug and then anything custom inside of there. So just a note on that. Okay. So with save queries true, the documentation tells us that the array of queries is stored in the global WP DB queries item. So I'm going to show you a very quick way that you can access that at the end of any of your WordPress requests. In a custom plugin, and we'll use the learn debugging plugin now, you can hook into what's known as the shutdown action in WordPress. So I'm going to do this right at the top of the plugin file here. I'm going to use the add action call to hook into a specific action. And I'm going to hook into the shutdown action. Now this action is run right at the end of any WordPress request, just before PHP sort of finishes running things. And I'm going to set up a shutdown function to be fired when that action is run. So we'll say WP learn shutdown. So that will add my callback function to the execution when the shutdown action happens. Then I define the function. So function shutdown. And then I, excuse me, create my function. And then all I'm going to do is I'm going to reuse this error log print R combination that we had here. I'm going to actually take it out of here for now because I don't want these things to log the results going to log the WP DB queries item. It's an array. So I'm going to replace that there. And then to be able to access the WP DB object, I just need to call global WP DB. And I always call it BD for some reason. Okay. So that's a very simple little function. I'm going to copy this out and pop it into the chat so that you all can see it. If you want to set it up in your plugin as well. And I want to show you now what happens when I do this. I just want to check I don't have any other logging happening. So that's great. I'm also going to just make sure my debug log is here. I like to keep it empty when I'm busy testing things out. And now if I run my custom rest API route again, that all still works fine, which is great. But if I now switch back to my debug log, now I have an entire array of every single database query that has been run on that request. So it got the option name and option value for something. It got another option value. It got all the options where autoload is yes first. Then it got the language. Then it got something about the user being an admin. Then it did some meta things. Then it got some more options because I'm a logged in user, so it's looking for log. So these are all things that are happening whenever a request runs. And then probably right at the end here somewhere we should see our form submissions being run. Maybe not because it's a custom query. Let me see if I can find form. There it is. There is this wp form submissions. So here at run about item 17 in the list. In fact, there it is. It's the last one because it's not done it again. But the next query that it ran was select all from form submissions, which is my query for my request. So there were 16 SQL queries that needed to be run before it could get to the point of firing my request and getting my form submissions. So that's a great way. And you can see it's also got you'll see this earlier. Here is the time that this request took. It also shows you say again. Sorry, it's so tiny. It's just 0.00. Because it's because it's local. So when it's local, it's very quick. It also shows you where these things are being run from. It shows you the query. So this is a great way to to check what queries are being run and then you can go and call those queries on your database, see how long they take, see what's happening. And so this is a good place to start if you're having a site that's very slow. Yes, Meg. Question, hand up. Does that mean theoretically if I have the same, if I like, I'm troubleshooting a site and I have a copy on my local and a copy on the live, I could run this both times and then look at the results and see sort of. Correct. Correct. Absolutely. All right. Cool. All right. Any questions on all of that? How save queries work before we move on? I am the loud and fascinated people today. Thank you. That's no problem. That's all good. I have noticed specifically with my workshops because they are very early for folks in the States, I have noticed that a lot of folks come along and they listen and then they go and watch the replay tomorrow at a time that suits them. That's fascinating. Well, then in that case, I'll make sure to tell everyone in the replay. If you have any other questions, I think you can get at us with what are we using for a hashtag to reach us today? I'm not sure. I actually don't use any hashtags. The only thing that I do and I generally forget to do this is I mentioned to folks the GitHub issue for the workshop, which we can actually do now. That's actually a good point. I used to include it in my slides and then at some point, I forgot and I'm not sure what. If you forgot, then let's just remember. So if anybody has any questions, if anybody does have any questions that they think of afterwards, if they're watching this, there is the GitHub issue. It's at github.com slash WordPress slash learn slash issues and it's number 1563. And you're welcome to leave any comments. You'll see me with busy planning today's session there and you're welcome to any comments or questions on that ticket. Okay, great. Perfect. So those are the things that I wanted to cover with you today specifically in the coding portion of the workshop. Now we're just going to be doing a little bit of show and tell. And you'll see right at the bottom of this page, there are some debugging plugins that are mentioned. The top two that I recommend are number one query monitor. And the other one is debug bar. Now what I'm going to do is I'm going to open both of them in the window and I'm going to share them with you in the chat. And then I'm going to install them and just quickly show you what they do. So debug bar is actually developed by a whole bunch of WordPress contributors, a whole bunch of folks have contributed to it. And it adds it basically you enable a whole bunch of options. You enable debug and you enable save queries. And then it sets up this debug bar console for you. Query monitor specifically focuses on your queries. So it takes all that information that we just saw in that queries array. And first of all, excuse me, it enables that constant for you. So you don't have to yourself. And then it actually adds it to your admin toolbar. So you can actually see what's going on. So let's start with query monitor. What I'm going to do, I'm going to go back into my config. I'm going to switch everything off for now. And then we'll turn things back on as we need to. So I'm just switching debug back to back to false. And I'm going to leave that like that. That's fine. That's no longer a bug. And that's fine as it is. Okay, so number of bugs in my plugin, I'm going to install query monitor. So in the plugin list, I can just search for query monitor. I can hit enter. Oh, sorry, that's searching the installed list of plugins. I apologize. First, I have to go plugins and I have to go add new. And then I can search query monitor. And I can hit enter. And I can just install it from the plugin list. And then once this is installed, I can activate it. And it's just, it's an honor situation. And you'll see in the top toolbar of my admin bar, there is suddenly this additional little section here. It shows zero and two seconds, 3.7 megabytes, 0.1 seconds, each queries. So that's showing you how much, how much memory is used to run all the queries. I think the first one is total query time. And I think this one is maybe average query time. And the last one is showing you how many queries are being run. So this is your admin dashboard side. Let's have a look at the front end of the site and show you what that looks like. So just loading the home page is 0.82 seconds, 4.1 megabytes of read data. I think the 0.1 might be average time or maybe that might be shortest query. I think that might be shortest query, but 33 queries were run. What's nice about this is now I can click on this database queries option. And it actually pops up a little query monitor at the bottom here. And I can now see all those queries. I can see what's happening. I can see how much time they took. I can see this overview. I can see the database queries. I can see the timings. I can view logs. And there's various logging variables that you can set up. I can have a look at request data. There really is some amazing information here. I'm not going to go dive into this deeply. If you're developing with WordPress, it's one of those plugins that I do recommend installing and using. The other thing I would like to mention is that the developer does have a GitHub sponsorships area that you can answer their work, because obviously they are doing this work for free. I think it's right at the bottom of the plugin page. There's a do you accept donations? And it says there I am accepting sponsorships. So if you do use a plugin and you would like to sponsor John, I do recommend it. Please go ahead. Eduardo, I'll get back to your question in a second. I just want to go through debug bar very quickly. So let's turn the monitor off for a second. And then let's install query. Sorry, let's install debug bar. All right. I've got to add new again. Sorry, folks. I'm off asleep today. Okay. So let's install that. And you'll notice in the debug bar page, it does say you need to enable debugging and you need to enable save queries. So let's do just that. Let me just move us out of the way here. So we need WP debug set to true and we need save query set to true. So that's the one difference between query monitor and debug bar. Debug bar requires you to set those things to true. But once we have that enabled and active, there we go. That's enabled. And so let's refresh the front page. And you'll notice that there's nothing visible that I can see right now. Nothing has really changed. So once those things have been enabled, then I just want to see, add a debug menu to the admin bar. That's right. But I'm not seeing that menu, which is interesting because there's normally a... Oh, there it is. Sorry. It's on the right-hand side. I do apologize. So there is the debug menu. It's on the far right, the hardy admin section. And from here, you can do a similar thing as you can. You can see the WP HTTP data. You can see all the queries. You can see the WP query object and you can see the object cache. Now you will notice that the diff between this screen and the other one, specifically admin area, is it's kind of on or off in the front end. Let's have a look at what it does in the front end. It's also kind of on or off. So it overwrites your view. You can't see the content and the monitor at the bottom. And so that's why one of my preferences is to use query monitor most of the time. And then I use debug bar if I need additional data that query monitor doesn't have. Eduardo has a question about what do you think about logging to query a monitor versus the regular debug logs? So it really is down to personal preference. Personally, I tend to like the debug logs because it doesn't require an additional plugin. Additional plugin you install is going to add a little bit of overhead onto your site. So I don't generally install these plugins on production environments. My default is to use the debug logs. And then if the debug logs fail on me, if I can't find the information that I need, then I switch to one of these two plugins. But that's just my personal preference. I do like query monitors where it handles the front end side of things. And you can have it enabled at the same time. There's nothing wrong with that. So what I like about query monitor is the fact that it's a toolbar, it's a panel at the bottom of my screen, but it doesn't overwrite the content. So I can refresh and see the content and then hook through and see things. More time has been spent on query monitor because it's maintained by one developer who keeps it going. He uses it quite extensively. So my personal preference is debug logs on first. If I can't find the information I need there, then I'll switch to query monitor. If I can't find the information in there, which is ready, then I'll switch to debug bar. I see Adrian has bailed, so that's fine. So that's the two plugins we are. Okay. We're coming up to the hour, and unfortunately, I have to rush off to another meetup now. I did want to go through Ray and XDBug with you folks, but I'm very quickly going to show you the sites for Ray. So Ray is actually a tool developed by a Laravel developer. Originally developed for Laravel applications, but they've added a WordPress plugin to it. What's nice about Ray is you have an application that runs on your desktop. And if you have the WordPress plugin installed, I'll show you what the application looks like quickly now. I've got it installed on my machine. And one of the other reasons I can't show you how it works is because I haven't configured it yet. But you have this little application that's running, and when you use the Ray function, I'm going to continue in trial mode here, it will actually output the details to this application. So you can see the screen just below it that I'm going to minimize now later. You'll see there, it actually here, the person is echoing or just using the Ray function and calling the string, and there it writes it to the application. Then they are using Ray on an array, and it's doing the print R true stuff for us and just outputting that array data. So it's a lot easier to use than using something like error log with print R and all of that kind of stuff. The downside is a paid product. So the free version, I think will log the first, I think it's 10 Ray calls. But if you have lots of them all over the place, if you get the latest 10, the paid for version gives you a lot more functionality. But it's perfect for if you're just trying to quickly debug a thing, and you're not quite sure what's on and you need to be able to run your code and see the debugging output at the same time. I have used Ray a few times very successfully. The other thing that I wanted to mention, this one is definitely a little bit more sort of diving into the advanced developer world, if you will, is XD bug. Now I've lost control of my, it's called XD bug. It basically enables you do what's known as step debugging on your WordPress code. So you can set breakpoints on your code. When you refresh the page, it'll actually open up your code editor to that point in time. And then you can physically step through the code line by line see the variables changing and see what's going on. I am planning a session on XD in the future to show you how it all works. But it's one of those things that requires a whole nother session. So I just wanted to mention it in today's session, so that folks are aware of it. And I highly recommend you go and look into it. There is a site that is in the resources. It's called learn x tag. I'm going to share it in the chat now quickly. And Acharya, I did see your question. So we'll get back to that, which is a bunch of articles on how to install and configure XD bug for different configurations. So there's one, excuse me, there's one for macOS, Laravel, Vallejo and PHP Storm. There's one for Laravel, Homestead and VS Code. There's videos about various things. There's live streams. There's articles on how to set it up. And then some, some BrightSpark developer named Jonathan Boslger also wrote one about how to set it up on PHP Storm and Ubuntu because that's what we use daily. So I contributed to that. And it was quite fun. So there's a whole bunch of different things that you can go and read about how to configure XD bug with your specific environment. So I do recommend checking out that if you are interested. Okay. And it says if we enable save queries, it will log all the queries run on every page of the site. Can we restrict it to a specific intended page or section, like a settings page or some major X function? Unfortunately, it's going to run on every single request. So the only way that you could really restrict it is if you switch it on, run the request and then switch it off. You could maybe do something like checking the request variable somehow, checking which request is being run and then somehow creating the log. But that's very, very difficult because it's a constant. So at the moment, it's kind of a site-wide thing. Typically what you should do, and this is generally the way that you do this, is when there's a problem, enable it, let it do some logging, investigate the problem, fix the problem, and then disable it. Don't leave it running all the time because it does add overhead. The logging is adding overhead as well. There is also a way on the server, on the MySQL server, to switch on a setting which logs slow queries. That's a little bit more server admin sysops kind of stuff. But you can do that as well. And that at least won't affect your WordPress install. That'll just be logging on the MySQL server. So that's another way to do it if you want to leave slow logs running, but not affect your WordPress site. Okay. Any other questions around everything we've covered today? I know we've gone through a lot of information there. Any other questions about all of that before we wrap up for today? Just having the last look here. I'm not seeing any other questions. We've got that last question for me. Oh, link to recording. Well, why can't you see into that one? These will be uploaded to our lovely dedicated archive, WordPress.tv. Y'all, if you're ever bored or would like to go to sleep with the sound of some educational content, may I personally recommend WordPress.tv? Absolutely. So Ramona, what I usually do is that tomorrow when I've downloaded and edited and uploaded the recording, I share the link to the recording in the Meetup chat area. So keep an eye on the Meetup page, and I will post that there tomorrow during the course of tomorrow. Great. I think that's everything. Thank you, everybody, for joining me today. Thank you, Megan, for hosting. I will share the slides again tomorrow. I usually share them before the session, but I forgot to apologize. I will share them again tomorrow. Thank you all for joining me. Enjoy the rest of your Thursday and enjoy the rest of your week. Bye-bye.