Search
Close this search box.
Search
Close this search box.

Debugging WordPress

New Relic

New Relic APM is a powerful tool that drills down into the inner workings of a WordPress website to pinpoint plugins, theme template files, database queries, external calls, or coding errors causing performance issues on your websites.

In order to install it, you must have SSH server access (with the sudo command available).

First of all create your dashboard.

  1. Go to Dashboards.
  2. Click Browser pre-built dashboards.
  3. Search for wordpress and select WordPress Full Stack.
  4. Select your account.
  5. Click View dashboard.

If you see no data then:

  1. Go to Add data.
  2. See if you have any gaps detected.
  3. Click See gaps.
  4. Click the desired gap and click Install new relic.
  5. Select On a host -cli.
  6. Run the command on the server.

 

Plugin activated fatal error

Install and activate Error Log Monitor and see the error logs.

UsageDD

Install and activate UsageDD plugin.

UsageDD allows administrators to monitor the resource usage of their WordPress installation. It will add a small box at the bottom center of each page, only visible to administrators, that displays the number of MySQL queries, the amount of memory used by the page’s code, and if you are using a compatible webserver (most are compatible), the “time to first byte” (TTFB) and the time required to generate the full page.

The number of queries (for example, “27Q”) will give you an idea of whether you are having MySQL problems. The number of queries should ideally be under 50.

The memory usage (for example, “18.3M”) will give you an idea of how large your site’s code is. This number should be under 50 megabytes (MB), and ideally should be under 32 MB.

Slow SQL queries

Slow SQL queries can crush your WordPress site’s performance. Sometimes, slow queries are a result of poorly-formed SQL that never should have been done that way. And sometimes, slow queries were actually fast queries at one point—but as the site grew older, the query got slower and slower, unable to keep up with the expanding database.

Query Monitor

Query Monitor is a plugin that provides a ton of information about the current page. In addition to a whole bunch of information about the internal workings of WordPress, it gives a detailed breakdown of:

  • How many queries happened on this request
  • Which queries on the page took the longest
  • Which functions spent the most time on SQL queries
  • Whether those queries came from plugins, themes or the WordPress core

Too many queries

If a page of your site takes forever to load, than you should first check how many queries are happening for the page request. To do so:

  1. Let the page load, while you have Query Monitor activated.
  2. Roll over to the plugins button on the top bar and click Queries by component.
  3. Check to see if a plugin makes too many queries. In an actual scenario, at one of my websites, the WPML plugin was making 1200 queries! Seems that I had a really old version of the plugin that had query issues. By updating the plugin, the queries went to 30 and improved my site’s performance drastically.

Debug bar

Debug Bar places a new option on your admin bar labeled “Debug” which gives you troubleshooting information on any page on your site. You’ll be able to track PHP errors, SQL queries made on your page, calls to WP Query, info about your HTTP Request and Rewrite Info, and chunks of your Object Cache.

This plugin is for developers, and not meant for a production site. It’s perfect for testing your site locally or on a staging server, but if you weren’t following the list above, this plugin probably isn’t for you.

Before you even install and activate the plugin, you’ll want to make sure you set up your WordPress configuration correctly in order to enable all of Debug Bar’s functionality. In your wp-config.php file, find where it says

define('WP_DEBUG', false);

and replace it with

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

Once you have added these lines to your wp-config.php, save it, then install and activate Debug Bar. You’ll immediately see a new button added to the top right of your admin bar, labeled “Debug.”

Next, install the Debug Bar Slow Actions plugin. It will let you easily find out which actions and filters are the slowest during a page load.

Visit any page on your site and click this button and a modal box will appear with a list of information on the page that you are on.

At the top global information for your site and server. Your server type, PHP and MySQL version, and the amount of Memory your WordPress install is using.

Notices / Warnings will display any PHP errors or notifications on the page. If there are any, then the Debug button will be orange. Otherwise, you will not see this tab. This will only work if WP_DEBUG is set to true.

Make sure you have no notices or warnings in your page.

Deprecated.

Make sure you have deprecated functions in your page.

Debug Bar Slow Actions

If a typical WordPress page load takes more than one second, chances are there’s something terribly wrong with your site, a theme or a plugin is probably doing something it shouldn’t. Obviously you don’t have time to review every single line in your codebase, so Debug Bar Slow Actions might help you out.

It adds a new panel with a list of the top 100 slowest actions (and filters) during the current page request.

Writing your own messages to the WordPress error log

If for some reason you want to spit custom messages, in various points of your code, than you can use this method.

A practical example, is for example, when you have an online payment process and something goes wrong and you want to debug what’s going wrong at various points of your  code.

Step 1: Create the write_log function

Just open your functions.php and inside add this function:

if (!function_exists('write_log')) {
    function write_log ( $log ) {
        if ( true === WP_DEBUG ) {
            if ( is_array( $log ) || is_object( $log ) ) {
                error_log( print_r( $log, true ) );
            } else {
                error_log( $log );
            }
        }
    }
}

Step 2: Create a debug file

In your `wp-content` folder create a new folder called `mu-plugins` and in that folder create a php file with the error level you want, for example:

<?php
error_reporting(E_ALL & ~( E_NOTICE | E_USER_NOTICE | E_STRICT | E_DEPRECATED | E_USER_DEPRECATED | E_WARNING | E_CORE_WARNING | E_USER_WARNING | E_COMPILE_WARNING | E_PARSE ));

Step 3: Change wp-config

Open wp-config.php and make the following changes:

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);

Step 4: Add your debug points to your code

Now, you can go to the points of the code that you want, and by using the write_log function, you can output your own messages

Step 5: View your debug log

The actual debug log is saved in a file called debug.log in your site’s content directory. One way to view and clear your log is to access that file directly. That’s not a particularly good way of working, especially if your site is on a remote server. There are plugins that make it easier to work with your debug log. That said, it’s important to be familiar with this method as if you can’t access the WordPress back-end due to a fatal error, your debug log might hold the clues to understand why.

My preferred method is using the Log Viewer plugin.  This free plugin gives you two ways to view your debug log, as well as the ability to clear it. When this plugin is active, you can view your log from its admin page, which is accessible from inside of the Tools menu.

Learning Resources

WordPress Speed Optimization Guide