Query Monitor is the developer tools panel for WordPress.
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, user capability checks, and full support for block themes and full site editing. 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.
For complete information, please see the Query Monitor website.
Here’s an overview of what’s shown for each page load:
SELECT
, UPDATE
, DELETE
, etc), responsible component (plugin, theme, WordPress core), and calling function, and provides separate aggregate views for each.is_single()
, is_home()
, etc.In addition:
qm
property of the response.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 if you’re logged in as a non-Administrator). See the Settings panel for details.
I maintain several other plugins for developers. Check them out:
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.
Query Monitor aims to be fully accessible to all of its users. It implements best practices for web accessibility, outputs semantic and structured markup, uses the accessibility APIs provided by WordPress and web browsers where appropriate, and is fully accessible via keyboard.
That said, Query Monitor does not conform to the Web Content Accessibility Guidelines (WCAG) 2.0 at level AA like WordPress itself does. The main issue is that the user interface uses small font sizes to maintain a high information density for sighted users. Users with poor vision or poor motor skills may struggle to view or interact with some areas of Query Monitor because of this. This is something which I’m acutely aware of and which I work to gradually improve, but the underlying issue of small font sizes remains.
If you’ve experienced or identified another accessibility issue in Query Monitor, please open a thread in the Query Monitor plugin support forum and I’ll try my best to address it swiftly.
Yes, it’s actively tested and working up to PHP 8.2.
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 WordPress in the same way that other plugins do. The impact is low; typically between 10ms and 100ms depending on the complexity of your site.
Query Monitor’s memory usage typically accounts for around 10% of the total memory used to generate the page.
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:
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.
Yes, but a user needs to be granted the view_query_monitor
capability to see Query Monitor even if they’re an administrator. See the WordPress.com VIP documentation for more details.
This feature was removed in version 3.12 as it was rarely used and considerably increased the maintenance burden of Query Monitor itself. Feel free to continue using version 3.11 if you need to make use of this feature.
Yes. You can enable this on the Settings panel.
I am accepting sponsorships via the GitHub Sponsors program. If you work at an agency that develops with WordPress, ask your company to provide sponsorship in order to invest in its supply chain. The tools that I maintain probably save your company time and money, and GitHub sponsorship can now be done at the organisation level.
In addition, if you like the plugin then I’d love for you to leave a review. Tell all your friends about it too!
$EZSQL_ERROR
for database query errors as it’s not possible to determine if the error should be ignoredsessionStorage
for the selected table column filters so they don’t persist across tabs or sessionswpdb
(see the FAQ for more information)wp-content/db.php
from another plugin doesn’t get removed when deactivating QMposix_getpwuid()
or posix_getgrgid()
doesn’t return an expected value.switch_to_blog()
and restore_current_blog()
on Multisite installationsQM_Data
and QM_Component
classes to make the data collection more structured and reliable9
for maximum compatibility with other plugins that use a shutdown handlerdashicons
dependencyshutdown
dispatcher from 0
to PHP_INT_MAX
to ensure as much data as possible is collectedQM_DARK_MODE
constantdb.php
qm/component_type/{$type}
filterQM_VERSION
constantdo_action( 'qm/cease' )
, for example to prevent memory exhaustion during long-running operationsqm/component_context/{$type}
filter to complement qm/component_name/{$type}
and qm/component_dirs
shutdown
hook.qm
property in enveloped REST API responsesQM_HIDE_SELF
constant before it’s definedQM_DB_SYMLINK
constant to prevent the db.php
symlink being put into place.SAVEQUERIES
in the query collector.scope
attributes on table cells.innodb_buffer_pool_size
variable to the mysql environment list.QM_Backtrace
.wp_die()
output.QM_HIDE_SELF
configuration constant.is_favicon()
conditional added in WP 5.4.QM_Util::get_file_dirs()
and get_file_component()
to allow support for non-standard plugin and theme locations.found_formatted
property because this can fire before WPML has initialised its locale proxy. Fixes #485.WP_DEBUG_LOG
, which now accepts a path too.QM_DARK_MODE
.SAVEQUERIES
is defined as false.wpdb
instances.