 Good morning, everyone. Thanks for showing up here this early hour. It wasn't expecting a such a great turnout, so I'm already very pleased. So, thanks Colton for the introduction. Most things have already been said. I work at Combal, which is a Belgian hosting company, where I'm the local WordPress expert kind of thing. I'm mostly passionate about WordPress security and WordPress performance, so loading time, keeping out hyper strings like that. But since I work at Technical Support Team, obviously I deal with debugging WordPress on a daily basis, helping customers resolve issues. So I have a couple of questions for you. Ever launched a new website and experienced something like this? Perhaps one updating your aims? Or even when migrating your website? Who has seen this one before? Just show of hands? Okay, yeah. Probably everybody. Or this one. Oh, it was nice. I hate that one. So yeah, we've basically all seen these kind of things before, and we usually feel like just smashing the keyboard around and going on a rage. But that's not the answer. The answer lies in error codes and other kind of things. So, basically, before we can dive into debugging, we need to understand that there are two kinds of error codes. You might run, obviously there are more kinds of error codes, but these are the two you'll run into most often. So there's 400-based error codes and 500-based error codes. Simplified, it will mean 400 U stuffed up. It's a client error. 500 is the server just doing something it shouldn't be doing or not processing something correctly. That's a really simplified version. So you have, like, the 400s are bad requests. So you're sending the bad requests to the site or whatever. Forbidden, 4-4-9-10 is the most common one. So basically, this is not the page you're looking for. And then 500 ones are things like internal server error, not implemented, service-unavailable, gateway timeouts, things like that. Basically, that's your server saying, I will have it. Now, the most important part is how to debug. There are actually several tools we can use and I'll go over them throughout the talk. So we have the server logs, obviously. We have WP debug, WP CLI, script debug, save queries, and a couple of plugins we could also use. The first one would be the server logs. When having an issue with any kind of site, who of you automatically resorts first to the server logs? Just a couple of clients. A couple of people, more than I expected, which is a good thing. It should basically be your first step or one of the first steps you can use because the server log will contain quite a lot of information on what's going wrong with the website. Now, there's several types of errors in the logs. Obviously, you don't want to make an error because that's the execution that stops and it's over and out. You have some warnings and notices, and you have some limit-related errors. Now, with limit-related, I think you all know memory limit errors or other resource limits. So let's show a few examples here. This one, for example, I'm denied by server configuration. This one, which is fairly common when, for example, something is being blocked via the HDXs. So if you see this, you can barely... you need to resort to your HDXs or some other hidden problem. This is one of the limit-related ones. This is a call being made to an external service and to external service. It just doesn't respond in time. It failed. This one is the killer. So if we have this, this UV is some kind of bug or some coding error or whatever. But it's severe enough to actually just crash the entire processing of the PHP and thus resulting mostly in white page of death or something like that. Internal server error, if it's the error is severe enough to entirely crash PHP, it could also result in a server error. And that's why we use WP debug. Has anyone used it before? A few people? Cool, cool. So inside WP config, we have a simple line, which is ultimately by default sent to WP debug. It's false. We can turn it on by saying put it on true and then it will show you a whole lot more error-related information, which will help you trace the origin of the problem. Now there are a few extra statements you could add to that because we all know showing errors in the production environment is probably not the best practice. So that's why we could, first and foremost, add like WP debug log sent to true, which will create a ebug.log file in the WP content folder, which is handy. But furthermore, we can also add this one, WP debug displayed false. So this would result in this combination which is in my opinion the ideal setup. So we enable WP debug, which will start logging for all errors. We'll enable debug log. So the information gets written to the debug.log in WP content and we won't display it publicly. So we enable WP debug as false, debug display as false. Now WP CLI, it's a great tool. It's been taken into the core projects of WordPress a year and a half ago or something like that. There are some great tools we can use so if your hosting company doesn't have WP CLI on their servers, please do yourself a favor, do everyone a favor, go and do them about it. It should be standard on any server where you have SSHXs and where you're hosting WordPress. It'll give you a few commands. So like WP plug-in list, it's fairly obvious what it does. It will render your list with all the plugins if they're active or not in the WP version, if there are any updates or things like that. So the most interesting part is actually WP plug-in deactivate and activate because well we all had that case where we just installed a new plugin and suddenly we had widescreen and dev. In most cases we were able to connect SSHX just to WP plug-in deactivate, let's say for example the US SEO or any other plug-in access map or whatever. And you'll be able to disable it from the command line restoring access and functionality, which is a very handy thing. Same thing with the WP team command, it also allowed you to activate the activate teams to gather this thing. There are also a few new statements. WP checks and core was in quite some while and WP checks and plug-in is since version 1.5 included in WP CLR. These are great tools because if your site is for example hacked or it is doing something which you're not quite understanding and there's even the slightest impression that there might be something going on there, you can always run these commands. These commands will test and verify all of the core files, all of the slugger files against the version in repository and show you a list of files should not be there or have been altered, which can help greatly while resolving issues. So this one is actually bold, especially since we have the addition of the plug-in version and it's like if I'm not mistaken, they're currently cropping a team command as well that might be a problem. Another cool thing was sometimes WP CLR produces unexpected results so the command crashes. So in this case I ran a WP team list. It didn't give me the output I was expecting, but however it did give me this unexpected and some variable in some websites postmitted.php. Now the fun thing was since there's no WP checks on the team I never noticed this, but this was the cause of an error and it didn't show up anywhere else until I ran that command and that's how I was able to find but this was actually a bit of a hack. It's an unexpected extra result of WP CLR but it can turn out to be very handy. Don't start shouting or screaming when WP CLR does not produce this because the output itself of here can be handy as well. So that's a great side effect. Let's call it that. So as you can see this is obvious. Then there's script debug. So this is a cool thing because by default everything is being minified. JavaScript files, some CSS files and if you have any issues it can help you just add this little tag to your WP contact which forces WordPress to use the non-minified versions of those libraries, those files which can easily help you while debugging any team or plugin or whatever related issues. This can be a very handy tool. Next, which is another great one. This is actually a great one to just do some checks and do some analysis on some slow loading sites where you have the impression that it might be query related. So by adding this one to WP company you force WordPress to store all the information on the queries into a WP deviated rate so you could visualize it simply by for example adding this piece of code to your free result at PHP which would then write all of the output just below the size. Can be handy in some cases. There are some plugins as well which we can use. First one is core control. As anyone who heard of it or used it before you can use it to just do some extra things which can be handy in the debugging process so you can verify how fonts are working you can basically take manual control of it to force upgrades and things like that you can do some extra logging tests of the transport methods things like that. This is basically some more advanced stuff which you probably won't be needing right off the bat but it's there if you need it and it's great and it works. And I had to use it like in the 10 years I'm working at the support desk right now I had to use it two or three times to get something resolved. This gives you an indication that it's not a thing you'll be needing by default. Not at all. WP debug bar is another great solution so if you're not eager to start adding the save queries to your FWD.php for example you could certainly use this plugin which does the same thing. It'll just ask you to add the statement to the WP company but then it'll add a bar on top of your WordPress admin area which you can just look up the results and see what's going on there. Now there's always a number of declares we all come to face one day or another. Like who's had this one before? Please email me while still your files are there. Usually it has something to do with this. This is the open path cell in your WP options table. We often see this after the migration so you've moved a host from one company to another and suddenly this stops working. Check your upload path because probably your previous host had a different path being set there than your current host and just emptying it or changing it to do the correct path for your current host depending on their requirements for their environment will resolve it and just magically we see real clear. Here like kind of sabotage my own site just to make my point. So we have a CSS-less layout-less version of the website. Same thing here. Usually it has something to do with your site URL or home URL just not being set completely correct. As you obviously see I've just sabotaged myself. This is how the library just did this intentionally. Then there's this one which is more or less on the rise in my personal experience. I see this. They used to see it like once or twice a week and now I see it 10 times a week. I don't know why but it's increasingly really increasingly. So the issue here is cannot modify every information others already sent. So it's a fairly common error. Possibly cause what states is before or after the opening and closing the expert DHE while the function is creating some output. It has already sent. Basically it's while it's intended so if it's not related to this or this every function is going to create some kind of output which will result in headers being sent. But the problem is that headers are normally headers are only expected to be sent once. Now if you have several plugins running functions that are producing output headers will be sent multiple times and while server and browser will go what is this? So what does this matter? So there's a quick there. There's another great fix to do this or to resolve this. It's actually just by enabling output buffering in your PHP setup. It's not the best way. The best way would be avoiding things like this things like this but output buffering will get you along with you. Then back to the nearby future who has heard about TIE. This is a great future for WordPress. It's a new project where actually the team involved is actually doing some code checks making sure that WordPress code and eventually also pulling in a team code will conform to the necessary standards within the PHP language. So in the end resulting in better code. They're doing this by running automated tests against a whole bunch of core plugins and just the idea would be that whenever a plugin is put into the repository it will test automatically and the developer will get some feedback on okay, this needs to be changed or this isn't optimal. It's just making a cleaner code in the end for all of us. They're using escaping, sorry I'll try to get back to that but it's an automated tool and they just recently used it to just check and alter about 100,000 lines of code in the WordPress core and nothing more. It's a really good tool. Now, the important is what can you do as a user? Well, basically report bugs and issues to the developers and don't do it in a manner of hey, I need the specs right now this is an error. Please don't do that. Most developers in the WordPress community aren't even doing this cool time as their main job. We're all in this just because we love WordPress and we want to make it better. But be constructive and provide as much information as you can. This will help the developer to go a long way and then to meeting your needs and getting things fixed. So, at least try to provide some information on how to go to use the error. That would be great. That's about what I have. Right now I've been rushing with it since we started a bit late. Hardly many questions.