 Thank you for the awesome introduction, since there are some non-dutch speaking folks in the room I'll be doing the talk in English and I'll be talking about debugging workers today. Who am I? I'm the guy on the screen here, I've been working at Combell, it's a Belgian hosting company for approximately 10 years now, I work as a support engineer, so on day-to-day basis I deal with customers calling or mailing and saying, hey my site is broken, it's down, this isn't working, technically every kind of issue, both with WordPress and other CMSs, with custom applications, websites and things like that. I've been a WordPress user since version 1.5 back all the way in 2005, I have a passion for security and performance and I'm on Twitter at Altebrechtreikarts.com, now who knows this whenever launching a new website, or even auditing plugins or things, or even when migrating your website, just by show of hands, who has seen this before, pretty much everybody, and things like this I assume as well, doesn't it make you go like banging the keyboards against your desk and things like that. Now before we can dive into debugging we need to understand what kind of errors there are and basically let's say 95% of all cases you'll be seeing two kinds of error codes, you've got the 400 error codes and the 500 error codes, now any of you know the difference between a 400 and a 500, anyone, yeah, Sherwin? Yeah I do, but the mission related was 500 more code errors. It's actually far more simple to explain it, 400 you stuffed up, 500 your server stuffed up, basically. Just to give you an example, 400, I'll just go back, here you go, since it needs to be politically correct, I said stuffed up but you all know which word I mean, now in the 400 series there's like the things you will see most are like 404, 403, things like that, 405 sometimes, 401 is also one that sometimes happens and well yeah, the explanations I think they speak for themselves, so there are pages with the RFCs with the entire status codes which are pretty fun, one of them is called I'm a Teapot, just think it up, it's really funny, and then the 500 series of codes are exactly what they are, server related, so in terms of server error, server's unavailable, the one you'll probably see most is the 503, 503 or 504, both are pretty common, so anybody has an idea of how to debug this, anything, just shout. Check the logs, yeah, check the logs, yeah, exactly, there's actually three things I use, server logs, very important, WP debug, which often gets forgotten, sadly enough, and WP-CLI which is actually just a command line interface to manage WordPress, but it can be really, really helpful in case of errors, so first up, server logs, okay, so there are a couple of types of errors you can see in logs, you've got the fatal error, you've got warnings and notices, and you've got several limit related errors, just to give you an example on how a server log might look, this is an example of some excerpts of an error log of one of my own sites, which I just changed to some website.com, just to keep it a bit anonymous, because throughout the talk you'll be seeing actual examples of tickets I've worked on for the last month and a half, and errors that were triggered on sites, and to keep some anonymity for our customers, I just changed them all to some website.com. So, this one here, I'll just go over some of them in detail and highlighting, so client denied by server configuration is one that we often get, usually in the case that something is pretty darn wrong with your HTX file, so if you get a client denied by server configuration, it's probably a good idea to start by looking at your HTX, and there's things like this, a timeout, which can point in the direction of several things, but usually it's, for example, an external element that needs to be checked or a server that needs to respond, and it doesn't happen, or just keeps on waiting, and eventually the server will kill the process and will get this kind of error thrown, and then there's of course things like this one, everybody hates this one, because, well, it's obvious, it's obvious fatal error means PHP will stop processing the code and just kill it all, and throw no output or limited output or whatever, it just won't render, it won't get the requested result, like for, in this example, you'll see the fatal error, so this will give you an indication of this is a breaking point for my loading process, for my process I'm trying to do, whether it's loading aside or doing some action in the back end or whatever, and then it helps to just follow the line and just actually just read what kind of component is triggering this, so in this case if we look into this log excerpt, we'll see here that it's concerned to the, or it's related to the WP, to the WooCommerce multilingual plugin, specifically this one, now if for example you just updated your WooCommerce multilingual plugin, you knew because of this that this broke, so the easiest way would be to revert the update and just get in touch with the developers or look further into what's actually blocking this, and you'll also always get further information on what the exact issue is here, so this is why the logs are really, really important and certainly, well, based on the amount of calls or mails I get, I'd be happy to say if 25% of our customers look at the logs, I'm afraid that's not the case, so they just call it, it's broken, then there's an amazing tool within WordPress called WPDbook, it's always there in our WPD config file and so often forgotten, even with my colleagues at the support team, so they just go into the server logs and if they don't find it there, oh I can't find it, Brecht, will you look at it? And I always say have you tried WPDbook? So in WPD config we have one simple line, which is WPDbook false, and just to enable the debug function, you can just switch it to true and it will output extra information on the errors, but of course that's not very, how should I put it, it's public, the errors are public for anyone to see, just if you do that, it's blatantly public. And there's extra statements you can give, define, so this is actually a line you just can add beneath or above the WPDbook true line, and this will actually create a log file in the WPD content folder, so all the extra information that you're probably missing in the server error logs will be added there. And then this is a very good one, especially when you need to do this on a production environment of a customer, is just setting WPDbook display on false, so you have the ideal setup here, which enables WPDbook, it'll enable writing the output to a log file, which is not public technically, or at least it's not showing on the rendered version of your website, and this disables the rendering of the errors on your website, so for the customer, or client, or whatever, or your room project stairs, for the visitor, there's nothing to see, but you're logging every single instance of a failure within WordPress, so this is a very, very good setup if you want to go run a debug. And what file did you chase this? This is actually all entries in the WP config file, so by default you have this first little line, and those two are ones I add just to keep the output hidden and logged into a file, which makes it easier to just in VI or whatever your preferred editor is on the command line just to analyze logs and search for specific entries. Then we have WPCLi, which has recently become an official WordPress project, which is a very good thing. These are some of the commands I use. Now, for example, a customer calls us and just WP this plugin and on my website isn't loading anymore. Okay, no problem. First thing we can try is just see if WP plugin list gives us an output. This provides just a simple list of all plugins and status if they're active or not and if there's an upgrade available. But the fun thing is if that works, you can easily say, okay, WP plugin deactivate, and for example, Yoast-SEO, and it will deactivate that plugin even if you don't have WP Admin access anymore. So this can be a live seeker. The same thing with teams. You have WP team list, activate and deactivate. And then, especially in certain issues, when the log files don't tell you everything, WP debug doesn't show any specific indication, the server logs don't give you any good instance, it might be a good thing to test the WordPress website and the plugins by using WP checksum core or WP checksum plugins. Now, what this does is it will run a test and verify the files of your installation against the one in the repository. And in, I'd say, 5 to 10% of all cases, this results in finding or hacking related files, which become an issue in the rendering process or who intertwine with the running, which causes a conflict between plugins or things like that. So this can be a true live seeker, and it's actually rather fast, so please use it. Another cool thing is, and I'm pretty sure it's not an intended use of WP CLI, but sometimes whenever I run a command, for example in this case, this is a recent one from a couple of days ago, I just ran the command WP team list to see what teams were running, and I got this output. So this isn't the normal output for WP CLI, but the fun thing is, this was code, this was an error which wasn't in the error logs prior to running this specific command, nor was it in the WP debug. So, I don't know if anyone can tell me what this would indicate. So it's a resupply expert, an expert experiment to do one to be erased, and then it says Fevicon underscore 316779.ico evaltcode evaltcode evaltcode. Basically, this site was hacked, and the entire error, which was a blank page, in a certain screen in the back end, was triggered by an infection of the XMET plugin. And this was found through using WP CLI, just listing the team, because else I wouldn't have found it, or except after a long search probably, but using WP CLI in this case made it much easier for me to just trace it back to where it came from. Now, there are also several, I call them typical errors, and easy fixes or quick fixes or things like that. How many of you have seen the library, the media library in this state? Presumably after a migration, I would say. Some people, I suppose, okay? So usually this is the culprit. So in the WP options table, there's a specific field called upload path, and now when you're moving a site from one server to another, that path can be different between the two servers. Now the problem is if the path is different, and you don't change it, either your website will load endlessly, try to load endlessly, or your media library will not show. So if this is the case, just empty the field, clean it, and usually it'll work. Anyone has seen this before? Just a CSS less render. It's also one thing I often see when clients are migrating from one server to another, especially when it's from the non-combal server to a combal server. Directly structures are different, but this is not something which has to do with that. In this case, I just broke it deliberately just to show you, but in this case, usually the site URL has something to see. I often see this when customers change their domain name, and they make it a type of graphical error. You can look pretty long and hard for it, but usually just checking out the site URL and the home URL are a pretty good place to start. It won't fix everything, but to my experience, in 90% of cases, this was the cause. Then this is also one, which you'll find often in the server box. Specifically, you cannot modify header information when the header is already sent. I don't know just by show of hands but most of you are active PHP developers. All of you, okay? I'm doing the better part, even, which is great. So most of you, in this case, will know that a PHP script is bound to just give header output once. Now, in WordPress, I don't want to point fingers, but some teams or some plugins don't always uphold the best coding standards, which can cause the situation where header output was already sent and there's more header output being sent and sometimes triple or more. Well, PHP can't handle that very well. So there's an easy fix for this, which is in our PHP settings. This just enable output buffering. It's just a simple change in the PHP.NE or in your control panel for whatever reason. And that'll fix it for you. So this is actually one of the errors I get most often these days. Mostly when customers are using one kind of page builder, which I won't name, which sounds with composer. I'm not a fan, sorry. So this is one, yeah, sure. Why isn't that set by default there? Well, that would depend actually, it would be logical to set it by default. I can't actually figure out a use case at this point why you wouldn't want to set it. Any questions concerning? Because it's, yeah, this is pretty much it. Whoa, that's it. Could Thais go next time? I could ask, sure. Okay, thanks. Okay. What kind of question was that? For a question like that, you have to make it a serious question as well. Could you elaborate on the housebook, for a little more? Thank you. Yeah, sure. It depends on what you are looking for. Are you looking for a more technical response on how the function works? Or are you more into the causes? The causes. Okay. The basic explication is that if there are several sources of output, whether it be the team, several plugins, they all are sending some amount of header information. When the request is being processed, it expects only one set of headers. When there's multiple, it goes wrong if you don't have output buffering active. And what output buffering would do is just, it'll hold open the processing of the script or the requests until all header output was received. It'll be keeping it in some kind of buffer, which is obvious, if you see the name, output buffering. It'll then all solidify them in one major header and then go over to the rendering process and then return the results. Yeah, right. Yeah. Hope that covers it a bit. It sounds like misbehaving plugins. In most cases it is. That's why I actually said it's, it's why not every single plugin or team developer upholds the best coding practices, because that's usually the case. It's often a space before or at the end of the, pre-opening tag or at the end of the, before closing tag. Yeah, true. Simple typing error. Yeah. That's what I mean. Any more questions? Maybe city, but are there any plugins that could prevent bugs? What would you recommend? I do, I use a draft and we're fans, but is there any more which I get used to? There are plugins, but not necessarily for WordPress. In that case I would, this is actually more a bit of the responsibility of the developer, of the plugin or team or even core developers. There's a plugin called PHP Code Sniffer, for example, which you can use in either via command line or for example it can integrate perfectly in PHP Store, which will just scan your code and see if it upholds to the best coding practices. They also have specific, a specific set of libraries to check WordPress related tags and hooks and things like that. But you can also verify your code against PSR1 or 2, things like that. And those will help tremendously to avoid blatant errors, for example, a space before or after the tag. That might help, but it's not something we can usually prevent on the WordPress site. However, there is some logic built into WordPress. Let's say you're trying to activate a plugin which you wrote yourself, it has a code, it'll just deactivate the activation process and just tell you, okay, there's a fatal error here, we couldn't activate. You'll at least have an indication, but when it goes wrong on an update, it's not always covered by WordPress. And since WordPress at that point will break, there's no plugin in WordPress that will help you out, because it's going to get executed anymore as well. Anymore? Well, to summarize, I think very good attention, I hope. 400 errors is the one that I messed up, 500 errors is the one you messed up as a server. If something breaks, plugs, the LAPCLI, and then if nothing else works, blame the hosting company. I would say at least call the hosting company and get them to help you. Thank you very much.