How to debug WordPress the right way

Symptoms of WordPress PHP code error.

If you have problems on your WordPress site, looking through your log files is the first step to troubleshooting your problems. This is what we call debugging.

WordPress includes several debugging tools in WordPress to find errors and be more productive in your coding as well as increasing the overall quality of your code.  You can debug the main WordPress installation, themes, plugins or your own custom code, and more.

Generally, these tools are settings intended for use by developers and should not be used on “live” sites unless you don't have a staging environment ready for testing. However, you can also use them in certain scenarios to help troubleshoot issues you may be experiencing with third-party code, such as plugins or themes.

To enable debugging mode in WordPress, follow these steps:

• Connect to your SFTP and locate the wp-config.php file in your WordPress root directory
  

  NOTE

  Remember to replace  PODUSER with the system user that owns your website, WEBSITENAME with the name of your website.

/srv/users/PODUSER/apps/WEBSITENAME/public

• Open the wp-config.php file in your preferred text editor.
• To enable debugging mode, add the following line to the wp-config.php file:
• Then insert the following code BEFORE /* That's all, stop editing! Happy blogging. */ in the wp-config.php file.

// You need to increase your PHP memory limit in WordPress and refresh your site to test whether or not this is causing your 500 internal server error.
define('WP_MEMORY_LIMIT', '1024M');
// Enable WP_DEBUG mode 
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

• Refresh your site and give it at least 5 minutes, WordPress will save all error information to the debug.log file in the wp-content directory.

Debugging Options Explained

There are several additional settings you can use to control the debugging information that WordPress provides:

• WP_DEBUG_LOG: When WP_DEBUG_LOG and WP_DEBUG are enabled, WordPress saves all error information to the debug.log file in the wp-content directory. By default, this setting is disabled.
  To enable this setting, add the following line to the  wp-config.php file:

  define('WP_DEBUG_LOG', true);
  		

• WP_DEBUG_DISPLAY: When WP_DEBUG_DISPLAY and WP_DEBUG are enabled, WordPress displays error and warning messages on web pages. By default, this setting is enabled. When this setting is disabled, debugging messages are hidden from view.
  To disable this setting, add the following line to the  wp-config.php file:

  define('WP_DEBUG_DISPLAY', false);
  		

• SCRIPT_DEBUG: When SCRIPT_DEBUG is enabled, WordPress uses development versions of core CSS and JavaScript files instead of the compressed versions that it normally uses. By default, this setting is disabled. You can use this setting to test modifications to built-in .js or .css files.
  To enable this setting, add the following line to the  wp-config.php file:

  define('SCRIPT_DEBUG', true);
  		

Logging Database Queries

If you are experiencing database issues with WordPress, you can enable query logging. When query logging is enabled, the following items are saved in the global $wpdb->queries array:


• The actual database query.
• How long the query takes to run.
• The function that called the query.
To enable database query logging, add the following line to the  wp-config.php file:


define('SAVEQUERIES', true);
	

Where to Find Your Server Log Files

The most common logs to examine are your app's Nginx, Apache, and PHP logs, which will likely show details about any errors:

Nginx Access Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_nginx.access.log

Nginx Error Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_nginx.error.log

Apache Access Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_apache.access.log

Apache Error Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_apache.error.log

PHP Access Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_phpX.Y.access.log

PHP Error Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_phpX.Y.error.log

PHP Slow Request Log

/srv/users/PODUSER/log/WEBSITENAME/WEBSITENAME_phpX.Y.slow.log

How to Read the PHP Slow Request Log for WordPress

The PHP slow request log is where PHP records information about any request that takes more than five seconds to execute.

Having slow PHP code not only creates a bad experience for your site's visitors, but it is also expensive for you. An app with fast PHP code only needs a single PHP process to handle many requests each second. However, since each PHP process can only execute one request at a time, when a PHP script is slow, the app needs additional PHP processes to handle the requests. Each additional process uses more memory, so having slow code means your server needs a lot more memory.

If your Pod has high memory usage or requests that are timing out, you may have slow requests that you can debug by reading the PHP slow request log.

Understanding the PHP Slow Request Log for WordPress

The PHP slow request log records stack traces (also known as tracebacks) of each slowly executing script at the moment the request passed five seconds in execution.

The top of the stack trace is generally the cause of your script's slowness. The rest of the lines below that tell you each function call that led up to that point.

Note that you will sometimes see  +++ dump failed at the bottom of a stack trace. That indicates the end of the stack trace and does not indicate a problem.

If you see a WordPress plugin name in the slow request log, you may be able to resolve your app's slow request problems by disabling the plugin.

Common Causes of Slow Requests on WordPress

There are a few common causes of slow requests.

Slow Requests Due to curl_exec()

If you see the  curl_exec() function in your PHP slow request log, the problem is not a bug in cURL but rather that the request is taking a long time to complete.

When your scripts rely on making requests to external services and other websites, your own site can become slow and unreliable due to problems with the other website. For example, if their website is slow or is rate-limiting your requests, your own app will become very slow. These issues can be resolved by disabling plugins that make external requests and not writing your own PHP code to perform HTTP requests to external websites or services.

Slow Requests Due to mysqli_query()

If you see the  mysqli_query() function in your PHP slow request log, the problem is not a bug in MySQL or any MySQL settings but rather that your PHP code is executing slow SQL queries.

You can have slow SQL queries due to, for example, lack of proper indexes in your database tables or PHP code that is inefficiently using the databases. The solution in this case is to track down the particular queries that are slow and fix them.

Acceptable Cases of Slow Requests on WordPress

There is one acceptable case of slow requests where you can safely ignore entries in the PHP slow request log: slow requests that are not being performed when answering a website visitor's request but rather are scheduled requests being performed in the background. Common example of such requests are requests for  wp-cron.php or any requests you may have scheduled using cron.