 Thank you for the kind introduction. So, Amiva, I didn't understand the first thing in Greek, but thanks for the kind words. I spent a lot of time debugging in our ongoing clients support team, and I want to share with you some of my thoughts and some of my experience, how to do that faster and how to do it easier. But first, how the story goes. I was actually here last year. It was an amazing quad camp. I really enjoyed it. I love Greece. I've been in art in several times, and I love it. As she said, I also love photography. I love photography and sensors. I have like maybe 300 pictures of this one, I guess. I was actually here the whole day yesterday, and thanks to my great friend Fotis, I spent the day going for a day trip around Greece. I'm very thankful for that. I had amazing time with all these people, if that loads. Yeah? Okay. So, I enjoyed Greece again. And I'm traveling a lot. I'm going to a lot of work camps. I love spending time with the workplace community. And I work for Cloud Favorite. That's a WordPress agency in the US. We are doing client projects for big enterprise companies. We are a distributed team. We work from different places around the world. I usually work remotely. I travel a lot, and I'm something like digital nomad. Also, we do a lot of things with WordPress, mainly with WordPress. We integrate external APIs. Also, we do some Warwell-based stuff and so on. We extend the functionality, adding our own APIs and so on. So, usually I would imagine that my working days are something like that, enjoying sunshine, working outside, beach, cocktails, so on. That's actually my photos. Some days it works like that. Most of the days it doesn't. Most of the days it's just working from home, debugging. Instead, I don't have a cat, I have a dog, and that's why I stay home mostly, lately. So, let's talk about debugging. When I was a child, my grandfather was dealing with fixing cars. And back then, the cars were pretty simple, right? Everything was more obvious. You can see the engine. You can see where the parts of the car are. You can fix it. So, my grandfather was really good with that. He was able to fix different things. And with time, that actually changed. Because back then, the cars looked like that. They don't look like that anymore, luckily. Therefore, with electronics, both computers and so on, and debugging of the problems is way harder because the engines actually look something like this. So, we don't know what's underneath it. You don't know how to fix something that's not that obvious. Even if you know how the car works, they still kind of work the same way. My grandfather doesn't know how to fix that anymore. So, what they do now, they debug the cars with software. And some of the problems are really hard to be found because they're actually happening in some specific situations. And for that, the both computer is behaving differently. The debugging software needs to be different and so on. It's kind of the same with the software projects. Even if you know how WordPress works, how the plugins are connecting, where the hooks are and so on, with different projects, you will find out that there are so many things that can be done differently. Even if you know the structure, you still don't know what exactly the problem could be. So, when you see an old project, let's say, or even a project that you worked on for a while and you don't even remember anymore how something was done, how you would know where the problem is, where you can start, what you need to do to find the issue or to add a new feature or to extend something that's older and so on. Well, you can start with that. So first of it, don't ever, ever, ever debug in production. There are little kittens over the world that will be very upset if you do that. And yeah, you'll have to spend some time to recreate the production environment. You will have to spend time to set up a local setup or to install everything that's needed for a project. I have a huge project that needs several things like Laravel, Tumblr, Redix, and so on installed on my machine and running at the same time. And this takes time. But trust me, I've worked a long time with old projects. It will save you a lot of sleepless nights if you just have a set of different in production. We usually have local dev server staging and then production. Then you can set debugging constants in your WP config. I actually recommend if you just insert another one, local config, so you can do that outside of version control. You can just ignore it and don't have the chance for this to go on production by chance when you're deploying something. Actually, WP debug will show you errors. You can debug work in your environment. You can also do that in your local server setup, of course, for PHP errors, but that somehow sometimes is very helpful. You can also display the errors on the front end with the WordPress constants. Then you need to get familiar with the project. You'll be very surprised how different things can be done so many millions way that you can even imagine. Even the straightforward things. I've seen so many different implementations of one simple thing that I can even count them. You'd need to check if the plugins and WordPress are actually updated. You'll be very surprised how many problems will magically disappear if you just update everything or how many new problems can appear, but that's a different topic. So after you already know the structure of the project, you can start debugging if the problem is not already disappeared. Of course, the first thing that you need to take is the error work. Error works for PHP, JavaScript, consoles, network to see where the external API scores come from and what IJX scores are loaded, what scripts are loaded, is there some error in the JavaScript, console, what exactly you are searching for and so on. If you're lucky, you'll get something like this, fatal error, whatever line or whatever file, you'll know what the problem is in this. Plug in, go there, fix it, simple enough, everything's fine and you can move on. Unfortunately, it doesn't usually happen like this. You'll get something in double P in quotes, plug in PHP, whatever that you have, absolutely no idea where it comes from. That specific case, by the way, this project loaded 64 gigabytes error work for three minutes. It literally killed my machine when I started it. It killed the server actually. And the whole problem was in a plugin which was implementing the same hook that's implementing in the core. No one obviously thought that these bot links can be used at the same time. They're conflicting in some file in double P in quotes that is not showing me anything. So I don't actually know what there is and there is no obvious way to fix it. So as mainstream it sounds, the next thing that you can do is just try to find where the problem comes from. Is it plug in, is it team, is it plug in conflict with something, is something new that you installed. So disabling plugins or removing them one by one will at least show you in which folder you can search for the problem. Then usually you get to that because you need to trace the problem. There is no obvious reason where the problem comes from. So what you can do is just to find the closest thing that you know. It could be HTML tag, CSS class, function that you know is operating on this. Or whatever you can remember closest to the problem. So just use grep which is bash command for search. It will find you the file where this is being called. So that will help you to trace the problem to the next file, to the next function, class, plugin or so on. So you can find where the initial where is. That's sometimes very fast, sometimes not that fast. So after that's what you can do. You can use some of the pre-built PHP functions to actually show you what exactly is being called. Vardomp is printing the results in the browser. And thank you. Actually, sometimes that is not working because you don't know where exactly this is being called and where in the browser to check for that. So then you can use error work. Error work will show you in the PHP work where whatever you want to see, whatever variable or function result you need. So the thing that you need to have in mind is that actually it's accepting string. So if you need to error work object or array or whatever else, it's better to just use it with print so you can actually see the result. What else you can do? You can use some of the query monitor plugins to see what actually is being called. Because the problem may be coming from something wrong in the database that's being called. Maybe something is curated the wrong way. Maybe there are queries that you don't need on that page. Cury monitor plugin is very useful for that. I'm not sure how much that can be seen from there. But the point is that it's showing you the slow queries. It's showing you if there are some notices, warnings, and so on on the page. It's also showing you what after what is being curated from the database. So you can make for your clear picture what exactly is happening, what's loaded on the page, and so on. Also it will show you all the hooks code on that page and it will do clear profiling for you. That may help for some situations. And if all that fails, or if you just prefer this as a faster tool, of course what you can use sex debug. It's a debugger tool for PHP. It can be used on most of the setups. So you just need to install it with whatever package manager you use on your system. And then just set up it. There are different setups depending on editors and so on. I personally use item. And after I set up it in the PHP setup file, I just import it in my editor. There is add-on for that. Most of the famous and most used editors have extensions for that. So you can set up your own on whatever you prefer to use. There are also several very useful extensions for ex-debugged for the browsers. This one is something that I use because I usually use Chrome. And it can be stored in the browser so you can track ex-debugged there. There is also another one. It says that it's the easiest thing for Firefox. I've never used it, so I'll test it. It's probably the one. So if you prefer Firefox, of course, you can try this one. And here is what I need to do in my personal setup. I just set up a debug point and then the route I can see where and what's being called after what. There's plugins and functions and so on. In my personal case, I don't like it that much because the extension for item is, it always starts from the first route, which makes it very slow for me. It maybe can be improved with time, but for now, it's not my favorite thing. If I use it, I use it just in the terminal. You can also use it from ex-wpcli. So what you need to do is to set up a specific setup for your bash profile and instead of wp, when you're using wpcli, you can just call wpd and you can debug your wpcli commands with ex-debug. That can be also very helpful when you're writing commands for wpcli migrations or whatever scripts you need to extend it with. Yeah, okay. Yeah, what usually helps if nothing is working, you need to check the permissions because there are situations when you have 500 server error in something and it's not loading, there is no obvious reason, there are no errors, there are no JavaScript errors, there is nothing obvious that is not working and you find out that the permissions on some file or folder or plugin are not the correct ones and it need to be changed so the site can reload again. Okay, if something can help more on that, that's the version control. If you're lucky and you're working on an old project, of course the old project will have a version control but that's not the main case. So that's a good moment where you can change that and start using it. If you're lucky and everyone wrote good commit messages if everything was tortured fine and you had different branches with different issues and features, you'll be able to track back in the code where the problem is coming from. For example, you can use git lock. That's supposed to be moving, I'm not sure if you can see it. So basically if you try git lock, it will load you all the commits, it will show you when the commit was made, what the commit messages and so on. So you can use that the commit hash to use git diff and see what changes were made for this commit. And if you know, for example, when the problem started, you can check in time what exactly commit was made on this date or who did it and check what the differences in the code are. Actually, there is also very useful in station for item called git time machine which is doing something like this. It is showing a whole diagram with the commits and you can go do diff between files and commits in time. Okay, next, obviously, yeah. Okay, other thing that you can try is git blame. As it says, he's actually checking for wine per wine, what exactly happened in a file. So you can see when someone did change on that line, when's the last change, you can see the commit hash and you can check what exactly happened in that particular commit. And if you're looking, you have a good commit message, you can understand the reasons why the file was changed. So what, you know, if you need to do something else, if you need to insert a new feature in another project, do you have enough hooks? Do you have where to embed it in the old code? Do you know how to extend the functionality without breaking things? Because you can change one thing, you can add a new feature and break something else. So what's the best thing to do in the beginning is to filter and check what filters and actions you have in the old project. So we can extend it without actually changing the existing functionality. You can check that by just gripping for why filters and so on. You can check if the functionality that you want to extend is actually hooked somewhere where you can change that. And if you have really good structured code and so on, you'll be able to do that pretty easy. For example, if you can't find a hook where you want to add your feature to, you can also remove some functions by removing filters and adding your own. Of course, you should be very careful about order that you are doing that because you can't actually remove something that's not there yet. So you need to add the specific order for calling the functions. And then for example, if you want to change a filter, you can just remove it, add it with your own, add the hook that you need, and then hook the new feature that is needed. And in the end, of course, you need to add tests because for example, imagine that you had tests in the beginning. You'll be able to do that very fast without actually doing anything of these steps by now. So never mind if you're using PHP unit in functional tests or you are using, for example, codeception or something like this. If you know how to write tests and if you know how to run the test, you'll be able to find the problem way faster. My personal favorite is codeceptions. We are actually doing more acceptance tests than functional tests. I personally like it because you are able to install it with Selenium server, for example. It goes through the browser. It actually performs one by one every step that the user will perform and shows you even JavaScript and forms. It's feeling them and then it's showing you the results and if something goes wrong, you can check that pretty fast. For example, you can change something but you don't know on how many places in the project that's actually used so you don't know if you are not breaking something the same time when you're fixing other things. So the tests are crazy useful thing. And also what you can do is to make a standard for your procedures. For example, you can use PHP code sniffers for checking cares. This will show you very fast in the files where the problems might be. You also, there are so many PHP, MD for example, JavaScript, CSS linters which can show you errors in the files. Also, you can use something like Jenkins that is running tests and going to everything and check it if the code is fine. This will help you next time and the persons that will work on your code after you to be able to find problems faster or even not to create them. You can also set up some automation. I'm really a big fan of automations for local installs something maybe like Docker to create faster local installs so I don't need all these steps when you're starting a new project. Or for example, when someone is coming to work on your project and you need to onboard him or her very fast. And when you finish your work it's pretty important to add documentations. There are very useful extensions which can be adding documentations in the code itself or just adding documentations in wikis or whatever you use for version controlling it. Also, you need very descriptive commit messages that are showing the other people what you did, why you did it, why for example you changed something that doesn't seem that logical on first sight and show everyone what your idea was because trust me in two months you won't remember why you did that. That's it. If you have any questions, I'll be around. I hope it was helpful.