 Hey there, and welcome to Learn WordPress. In this tutorial, you're going to learn about debugging options in WordPress. You'll learn how to enable the built-in WordPress debugging options and how to use them, as well as some plugins that can help you debug your page requests. Debugging is the process of finding and fixing errors in your code. As the two primary programming languages of WordPress are PHP and JavaScript, you need to be able to debug both. With JavaScript code, which is executed in the browser, it's fairly straightforward to use console log to write messages to the browser console for the purposes of testing and debugging. PHP, on the other hand, is executed on the server, and so you need to find ways to find out what's happening when things go wrong. There are a few third-party tools that you can use for advanced debugging, like XDbug or Ray. But for the purposes of this tutorial, you'll learn about options that are specific to WordPress and require no additional software. In WordPress, during any WordPress request lifecycle, the WPDbug mode function is run to set up the debugging environment. This function is located in the wp-includes-load.php file. If you look at this code, you can see that if the wp-debug constant is true, then it sets the PHP error reporting level to eAll, which means turn on all error reporting. Additionally, if wp-debug-display is set to true, then it sets the display-errors-php setting to 1, which means to turn on displaying these errors on screen. Finally, if wp-debug-log is set to true, then it sets the error-log-php setting to the wp-content-debug.log file. It is also possible to configure a custom debug log file location other than this default. If this log file is enabled, it will set the PHP log error setting to 1, and set the error log setting to the path of the log file, meaning that all errors will be logged to this file. Using this knowledge, you can configure your wp-config file to enable debugging in WordPress. For enable debugging, open the wp-config file and scroll down to where the wp-debug constant is set. You can then update that section to look like this. This configuration will enable debugging, disable displaying errors on screen, but enable logging errors to the wp-content-debug.log file. Depending on your personal preference, you can enable displaying the errors on screen, but this can lead to the errors either being missed or overlaying other important information on screen, which is not ideal. Additionally, if you're ever debugging an issue on a production site, you don't want to display the errors on screen, as this can lead to sensitive information being displayed to the user. To see this in action, let's look at an example. Let's say you developed a plugin with the following code. The plugin creates a form submissions table in the database where it is activated. It then registers a REST API get route to fetch the form submissions from the database. For the purposes of testing, you've manually inserted a few records into the form submissions table. However, if you visit the REST API get route, you don't see any form submissions, so you need to start looking for bugs in your code. Simply enabling debugging, any errors in your code are automatically logged to the wp-content-debug.log file. So, if you take a look, you'll see that any errors have been logged. In this case, two errors are being reported. First, is a PHP notice triggered by WordPress, which is caused by hooking the wp-learn-register-routes function on the wrong action. It is an error related to the database query being run to fetch the form submissions. It looks like it's querying the table form submission, not form submissions. We can fix this by fixing the action hook that the route is to be hooked into, and we can fix the table name being queried in the form submissions bug function. Fix these errors and visit the REST API get route, you see the form submissions are being returned successfully. In addition to logging errors to the debug.log file, you can also log messages or variables to the debug.log file using the PHP error log function. This function accepts a single string parameter. For example, if you wanted to log the SQL query being run in the wp-learn-get-form-submissions callback, you could use the following code. So we could say error log wp-db-last-query. If you refresh the request and view the debug.log file, you'll see the query being logged to the file. In addition to logging the last query, you can also log all queries that are run during a WordPress request lifecycle. To do this, you enable the save queries constant in your wp-config file. Once you've enabled this constant, you can log all queries by using the following code. So if we switch back here, we can do something like this. Print R and get wp-db-queries and set the second parameter to true. This uses the error log function combined with PHP's printR function to log the wp-db-queries array to the debug.log file. This array contains all the queries that have been run during the WordPress request lifecycle and is only available if the save queries constant is enabled. So if we test that on our form submissions endpoint and then switch back to the debug log file, you'll see all the other queries that have been run in the WordPress request up until the point that our form submission query is run. In addition to using the built-in debugging options, there are also a few plugins that can help with debugging. The first plugin is Query Monitor, which is a debugging plugin that adds a debug menu to the admin bar and displays information about the current page request. It includes information about the database queries that have been run, the current HTTP request, the hooks and actions that have been run, loaded scripts and styles, and much more. The second plugin is Debug Bar, which also adds a debug menu to the admin bar and displays debugging information about the current page request. It focuses mostly on the database queries that have been run, includes data on the wp-query object as well as the HTTP request, and includes info on the object cache. Picking on any of these items opens up each plugin's specific toolbar, and you can view all the information about the different queries and sections that it logs on. And that wraps up this tutorial on debugging in WordPress. For more information and debugging options, check out the Debugging in WordPress page on the WordPress Developer Documentation. Happy debugging!