Back

WordPress plugins we love – Query Monitor

14 August 2019

Tim Nash

Trying to hunt down that irritating bug, and the basic logs are just not cutting it? Looking to squeeze a few extra ms performance? If this sounds like you then this is a plugin worth looking into.

Query Monitor is a plugin designed to allow for complex debugging. It goes beyond providing quick access to wp_debug levels of debugging and introduces a bunch more tools. 

Query monitor is so powerful that internally at 34SP.com, using it effectively is a core part of our WordPress specialists’ training. Don’t let the fact it’s a little intimidating put you off though as it’s quick to get to grips with.

Once installed and activated, the first obvious presence of Query Monitor is the dropdown menu in the admin toolbar, which shows some basic statistics about the page load. The plugin will show this information to every administrator role user and any super admins on a multisite setup.

From the dropdown you will be able to see any notices and warnings being generated, however it goes beyond that, for example the “query” option will let you see the MySQL queries being called when generating the page while the HTTP API request tracks AJAX requests being made.

Hooks and actions will show you all the actions and filters being called to generate the page, and more importantly what’s calling that action, is it a WordPress core component such as Gutenberg, or a plugin?

One of the really nice features for a developer is that you can configure any function call shown in a stack trace to be opened in the editor of your choice. It’s a little touch but makes it a breeze to use. You can use this feature even on a remote setup.

For developers and folks working directly with code, Query Monitor has a couple of actions that are really useful (and as actions, won’t generate a fatal error when Query Monitor is not there). The first is logging.

The logger is PSR3 compatible. To use it within your code:

do_action( 'qm/debug', 'I logged a thing' );

It supports all PSR3 log levels. These will show under logs within Query Monitor:

  • qm/debug
  • qm/info
  • qm/notice

Whilst

  • qm/warning
  • qm/critical
  • qm/alert
  • qm/emergency

will show in logs but also generate a visual warning in Query Monitor notifications.

You could also call the logging directly rather than via a WordPress action, but if you don’t use the hook then you will need to write your own checks to make sure Query Monitor is available, which might become awkward if Query Monitor is to be turned off in production.

The second handy feature is basic profiling by wrapping

do_action( 'qm/start', 'myname' );
my_horrid_code();
do_action( 'qm/stop', 'myname' );

around any code block you want to profile. You can then find details under the timings section. 

How do we use it?

In addition to using it during development on our own products and sites like this blog, we also use Query Monitor to help us debug issues clients are having.

We tend to use Query Monitor to look at things like HTTP requests, as it provides us with a quick way to inspect what triggered the HTTP request. This is particularly useful for queries such as, “My WordPress admin area is running really slow and taking x number of seconds to load.” Inevitably this will be either a rogue MySQL query or an HTTP request such as a callback to validate a third-party plugin license. In both cases we can use Query Monitor to see what’s causing the slowdown.

Our second use case where we would reach to Query Monitor over other tooling is where we believe there is an issue with a plugin or theme, and need to know what hooks are being fired to allow us to then investigate the code. Normally this is around enqueueing styles and scripts that get tripped up with the site and home url being in different locations.

Using it with debug bar extensions

WordPress has a semi-official “debug bar” tool, and one of its biggest features is that there are various debug bar extensions. If you install and enable a debug bar extension (which install as regular plugins) then Query Monitor will take over displaying their output. In effect, this means that Query Monitor can use any debug bar extension.

There are also extensions for Query Monitor itself provided by third parties other than the original developer but to date we haven’t used any of them here.

Using it in production

While Query Monitor is a tool for improving performance, it’s not a tool we recommend running constantly in production. It’s the perfect tool to install while hunting down an issue or running performance tests as it does slow down your site, albeit far less than some competitor plugins and performance profilers.

I can’t imagine running a development site without Query Monitor or similar installed.

Alternatives

Whilst we love Query Monitor, it’s not the only tool out there. The original WordPress debug bar is available and also LAPS Profiler is well worth a look, with powerful features but perhaps not being as user-friendly as Query Monitor.

Like WP-CLI, Query Monitor is one of those aspects of WordPress that once you start using, you will never want to go back to not having its capabilities. Query Monitor is definitely a WordPress plugin that we love.