Query Monitor is the developer tools panel for WordPress. It enables debugging of database queries, PHP errors, hooks and actions, block editor blocks, enqueued scripts and stylesheets, HTTP API calls, and more.
It includes some advanced features such as debugging of Ajax calls, REST API calls, and user capability checks. It includes the ability to narrow down much of its output by plugin or theme, allowing you to quickly determine poorly performing plugins, themes, or functions.
Query Monitor focuses heavily on presenting its information in a useful manner, for example by showing aggregate database queries grouped by the plugins, themes, or functions that are responsible for them. It adds an admin toolbar menu showing an overview of the current page, with complete debugging information shown in panels once you select a menu item.
Here's an example of Query Monitor's output. This is the panel showing aggregate database queries grouped by component:
- Shows all database queries performed on the current request
- Shows affected rows and time for all queries
- Shows notifications for slow queries, duplicate queries, and queries with errors
- Filter queries by query type (
SELECT,UPDATE,DELETE, etc) - Filter queries by component (WordPress core, Plugin X, Plugin Y, theme)
- Filter queries by calling function
- View aggregate query information grouped by component, calling function, and type
- Super advanced: Supports multiple instances of wpdb (more info in the FAQ)
Filtering queries by component or calling function makes it easy to see which plugins, themes, or functions on your site are making the most (or the slowest) database queries.
- Shows all hooks fired on the current request, along with hooked actions, their priorities, and their components
- Filter hooks by part of their name
- Filter actions by component (WordPress core, Plugin X, Plugin Y, theme)
- Shows the template filename for the current request
- Shows the complete template hierarchy for the current request (WordPress 4.7+)
- Shows all template parts loaded or not loaded on the current request
- Shows the available body classes for the current request
- Shows the active theme name
- PHP errors (warnings, notices, stricts, and deprecated) are presented nicely along with their component and call stack
- Shows a visible warning in the admin toolbar
- Post content blocks and associated information (when using WordPress 5.0+ or the Gutenberg plugin)
- Shows query vars for the current request, and highlights custom query vars
- Shows all matched rewrite rules and associated query strings
- Shows all enqueued scripts and styles on the current request, along with their URL and version
- Shows their dependencies and dependents, and alerts you to any broken dependencies
- Shows you language settings and text domains
- Shows you the MO files for each text domain and which ones were loaded or not
- Shows all server-side HTTP requests performed on the current request (as long as they use the WordPress HTTP API)
- Shows the response code, call stack, component, timeout, and time taken
- Highlights erroneous responses, such as failed requests and anything without a
200response code
- Shows every user capability check that is performed on the page, along with the result and any parameters passed along with the capability check.
- Whenever a redirect occurs, Query Monitor adds an
X-QM-RedirectHTTP header containing the call stack, so you can use your favourite HTTP inspector or browser developer tools to trace where a redirect has come from.
The response from any jQuery Ajax request on the page will contain various debugging information in its headers. Any errors also get output to the developer console. No hooking required.
Currently this includes PHP errors and some overview information such as memory usage, but this will be built upon in future versions.
The response from an authenticated WordPress REST API (v2 or later) request will contain various debugging information in its headers, as long as the authenticated user has permission to view Query Monitor's output.
Currently this includes PHP errors and overview information.
To see more detailed information about a REST API request you need to perform an enveloped request which means appending ?_envelope to the requested URL. In this case, Query Monitor will include debugging data in a qm property in the response. Currently this includes database queries (including information about duplicates and errors), HTTP API requests, and transient updates. More information may be added in a future version.
By using the combination of the HTTP headers and the qm property in the response to an enveloped request you'll get good insight into the aspects of a request which have the greatest impact on performance.
- Shows the correct names for custom column filters and actions on all admin screens that have a listing table
- Shows the state of
get_current_screen()and a few variables
- Shows various PHP information such as memory limit and error reporting levels
- Highlights the fact when any of these are overridden at runtime
- Shows various MySQL information, including caching and performance related configuration
- Highlights the fact when any performance related configurations are not optimal
- Shows various details about WordPress and the web server
- Shows version numbers for all the things
Debugging messages can be sent to the Logs panel in Query Monitor using actions in your code:
do_action( 'qm/debug', 'This happened!' );The logger is PSR-3 compatible, so you can use any of the following actions which correspond to PSR-3 log levels:
qm/emergencyqm/alertqm/criticalqm/errorqm/warningqm/noticeqm/infoqm/debug
A log level of warning or higher will trigger a notification in Query Monitor's admin toolbar.
Contextual interpolation can be used via the curly brace syntax:
do_action( 'qm/warning', 'Unexpected value of {foo} encountered', [
'foo' => $foo,
] );A WP_Error, Exception, or Throwable object can be passed directly into the logger:
if ( is_wp_error( $response ) ) {
do_action( 'qm/error', $response );
}try {
// your code
} catch ( Exception $e ) {
do_action( 'qm/error', $e );
}A non-scalar value can be passed to the logger and its value will be formatted and output in the same panel. Can be used as a replacement for var_dump():
do_action( 'qm/debug', get_queried_object() );Finally, the static logging methods on the QM class can be used instead of calling do_action().
QM::error( 'Everything is broken' );Basic profiling can be performed and displayed in the Timings panel in Query Monitor using actions in your code:
// Start the 'foo' timer:
do_action( 'qm/start', 'foo' );
// Run some code
my_potentially_slow_function();
// Stop the 'foo' timer:
do_action( 'qm/stop', 'foo' );The time taken and approximate memory usage used between the qm/start and qm/stop actions for the given function name will be recorded and shown in the Timings panel. Timers can be nested, although be aware that this reduces the accuracy of the memory usage calculations.
Timers can also make use of laps with the qm/lap action:
// Start the 'bar' timer:
do_action( 'qm/start', 'bar' );
// Iterate over some data:
foreach ( range( 1, 10 ) as $i ) {
my_potentially_slow_function( $i );
do_action( 'qm/lap', 'bar' );
}
// Stop the 'bar' timer:
do_action( 'qm/stop', 'bar' );Note that the times and memory usage displayed in the Timings panel should be treated as approximations, because they are recorded at the PHP level and can be skewed by your environment and by other code. If you require highly accurate timings, you'll need to use a low level profiling tool such as XHProf. See the Related Tools section for more information.
- Shows any transients that were set, along with their timeout, component, and call stack
- Shows all WordPress conditionals on the current request, highlighted nicely
- Shows an overview at the top, including page generation time and memory limit as absolute values and as % of their respective limits
By default, Query Monitor's output is only shown to Administrators on single-site installations, and Super Admins on Multisite installations.
In addition to this, you can set an authentication cookie which allows you to view Query Monitor output when you're not logged in, or when you're logged in as a user who cannot usually see Query Monitor's output. See the Settings panel for details.
In order to do a few clever things, Query Monitor symlinks a custom db.php into your WP_CONTENT_DIR which means it loads very early. This file gets included before the database driver is loaded, meaning this portion of Query Monitor loads before WordPress even engages its brain.
In this file is Query Monitor's extension to the wpdb class which:
- Allows it to log details about all database queries (including ones that happen before plugins are loaded)
- Logs the full stack trace for each query, which allows it to determine the component that's responsible for the query
- Logs the query result, which allows it to display the affected rows or error message if applicable
- Logs various PHP configurations before anything has loaded, which allows it to display a message if these get altered at runtime by a plugin or theme
If your WP_CONTENT_DIR isn't writable and therefore the symlink for db.php can't be put in place, Query Monitor still functions, but this extended functionality won't be available. You can manually create the db.php symlink if you have permission.
Yes.
By default, Query Monitor's output is only shown to Administrators on single-site installations, and Super Admins on Multisite installations.
In addition to this, you can set an authentication cookie which allows you to view Query Monitor output when you're not logged in, or when you're logged in as a user who cannot usually see Query Monitor's output. See the Settings panel for details.
Short answer: Yes, but only a little.
Long answer: Query Monitor has a small impact on page generation time because it hooks into a few places in WordPress in the same way that other plugins do. The impact is negligible.
On pages that have an especially high number of database queries (in the hundreds), Query Monitor currently uses more memory than I would like it to. This is due to the amount of data that is captured in the stack trace for each query. I have been and will be working to continually reduce this.
Yes, if anything calls do_action( 'qm/cease' ) then Query Monitor will cease operating for the remainder of the page generation. It detaches itself from further data collection, discards any data it's collected so far, and skips the output of its information.
This is useful for long-running operations that perform a very high number of database queries, consume a lot of memory, or otherwise are of no concern to Query Monitor, for example:
- Backuping up or restoring your site
- Exporting a large amount of data
- Running security scans
A list of add-on plugins for Query Monitor can be found here.
In addition, Query Monitor transparently supports add-ons for the Debug Bar plugin. If you have any Debug Bar add-ons installed, deactivate Debug Bar and the add-ons will show up in Query Monitor's menu.
Please use the issue tracker on Query Monitor's GitHub repo as it's easier to keep track of issues there, rather than on the wordpress.org support forums.
Yes, the Altis Developer Tools are built on top of Query Monitor.
Yep! However, a user needs to be granted the view_query_monitor capability to see Query Monitor even if they're an administrator.
Please note that information about database queries and the environment is somewhat restricted on VIP. This is a platform restriction and not a Query Monitor issue.
I'm using multiple instances of wpdb. How do I get my additional instances to show up in Query Monitor?
You'll need to hook into the qm/collect/db_objects filter and add an item to the array containing your wpdb instance. For example:
add_filter( 'qm/collect/db_objects', function( $objects ) {
$objects['my_db'] = $GLOBALS['my_db'];
return $objects;
} );
Your wpdb instance will then show up as a separate panel, and the query time and query count will show up separately in the admin toolbar menu. Aggregate information (queries by caller and component) will not be separated.
Yes! You can enable this on the Settings panel.
I am accepting sponsorships via the GitHub Sponsors program and any support you can give will help me maintain this plugin and keep it free for everyone.
In addition, if you like the plugin then I'd love for you to leave a review. Tell all your friends about it too!
Query Monitor is private by default and always will be. It does not persistently store any of the data that it collects. It does not send data to any third party, nor does it include any third party resources.
Query Monitor's full privacy statement can be found here.
Debugging is rarely done with just one tool. Along with Query Monitor, you should be aware of other plugins and tools which aid in debugging and profiling your website. Here are some examples:
- Tideways or XHProf for low level profiling of PHP.
- Xdebug for a host of PHP debugging tools.
- P3 Profiler for performance trend analysis of the plugins in use on your site.
- Time Stack for WordPress-specific operation profiling.
- Laps for lightweight WordPress profiling.
- Clockwork for debugging and profiling PHP applications.
- Blackfire for PHP performance testing.
- New Relic for complete software performance analytics.
Query Monitor also has several add-on plugins which extend its functionality, and transparently supports add-ons for the Debug Bar plugin (see the FAQ for more info).
See also my list of WordPress Developer Plugins.
Code contributions, feedback, and feature suggestions are very welcome. See CONTRIBUTING.md for more details.
Query Monitor's icon was designed by Tubagus Didin Asrori.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.