Corrects the description of how autoloaded options behave in memory. No change to what is measured or scored; one WP-CLI metric was renamed.<\/p>","1.0.2":"
The plugin was renamed to Turbopress Database Diagnostics; the WP-CLI command and the public filters changed with it.<\/p>","1.0.1":"
Corrects two wrong statements about transient cleanup and adds a category for transient rows an object cache has made unreachable.<\/p>","1.0.0":"
First release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3660666,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3660666,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3660666,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3660666,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.3","1.0.4"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3660666,"resolution":"1","location":"assets","locale":"","width":1280,"height":850},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3660666,"resolution":"2","location":"assets","locale":"","width":1280,"height":893},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3660666,"resolution":"3","location":"assets","locale":"","width":1280,"height":660},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3660666,"resolution":"4","location":"assets","locale":"","width":1280,"height":1045},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3660666,"resolution":"5","location":"assets","locale":"","width":1280,"height":1075}},"screenshots":{"1":"The diagnostics tab: the score, the plain sentences behind it, and every deduction listed with the finding that caused it.","2":"Autoloaded options attributed to the plugin that created them, with the unattributed remainder grouped by prefix.","3":"Autoload, object cache, OPcache and page cache side by side, each with the figures it was judged on.","4":"The table overview: sizes, free space and collation differences, with the mixes that break joins marked as critical.","5":"Cleanup after a dry run: the rows were counted, nothing was changed, and only now does the button to delete for real appear."}},"plugin_section":[262246],"plugin_tags":[1328,153,7913,47179,247],"plugin_category":[54,59],"plugin_contributors":[260860,260859],"plugin_business_model":[],"class_list":["post-353329","plugin","type-plugin","status-publish","hentry","plugin_section-dashboard-widgets","plugin_tags-autoload","plugin_tags-database","plugin_tags-object-cache","plugin_tags-opcache","plugin_tags-performance","plugin_category-security-and-spam-protection","plugin_category-utilities-and-tools","plugin_contributors-robbsie","plugin_contributors-turbopress","plugin_committers-robbsie"],"banners":{"banner":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/banner-772x250.png?rev=3660666","banner_2x":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/banner-1544x500.png?rev=3660666","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/icon-128x128.png?rev=3660666","icon_2x":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/icon-256x256.png?rev=3660666","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/screenshot-1.png?rev=3660666","caption":"The diagnostics tab: the score, the plain sentences behind it, and every deduction listed with the finding that caused it."},{"src":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/screenshot-2.png?rev=3660666","caption":"Autoloaded options attributed to the plugin that created them, with the unattributed remainder grouped by prefix."},{"src":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/screenshot-3.png?rev=3660666","caption":"Autoload, object cache, OPcache and page cache side by side, each with the figures it was judged on."},{"src":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/screenshot-4.png?rev=3660666","caption":"The table overview: sizes, free space and collation differences, with the mixes that break joins marked as critical."},{"src":"https:\/\/ps.w.org\/turbopress-database-diagnostics\/assets\/screenshot-5.png?rev=3660666","caption":"Cleanup after a dry run: the rows were counted, nothing was changed, and only now does the button to delete for real appear."}],"raw_content":"\n
Turbopress Database Diagnostics is a diagnostic tool, not a cleaner. It answers a question the usual optimisation plugins do not: why<\/strong> is this installation slow, and which plugin<\/strong> is causing it.<\/p>\n\n Most sites do not need another delete button. They need to know that 600 KB of options are read into memory on every single request, and which plugin put them there.<\/p>\n\n Every WordPress request reads all autoloaded options before a single line of the page is rendered. This plugin measures that payload exactly, lists the 25 largest entries, and attributes each one to the plugin that created it.<\/p>\n\n Attribution works by matching option name prefixes against the plugins installed on the site. It matches strictly: a prefix only counts when the option name continues with a separator, so The unattributed remainder is grouped by its shared prefix, so instead of one anonymous lump you see, for example, that six options starting with Options whose plugin is no longer installed are reported as their own category. So are theme modifications of themes that have been deleted. These are the leftovers no uninstall routine removed.<\/p>\n\n Three findings are also placed in Tools \u2192 Site Health, where people already look: the autoload payload, what removed plugins left behind, and orphaned metadata. Only those three, and only because WordPress does not check them itself; its own object cache and cron tests are not repeated. Site Health never triggers a scan, it reads the last one.<\/p>\n\n Each measurement is recorded, thirty of them, in an option that is not autoloaded. The report then says what moved: \"+180 KB since the measurement three days ago\". That answers the question a single snapshot cannot, which is since when<\/em>, and knowing what you installed that week usually names the cause.<\/p>\n\n It also checks whether the options table has the index on the autoload column that WordPress 6.6 introduced. An installation that grew out of an older version sometimes lacks it, and without it the first query of every request scans the whole table.<\/p>\n\n From these measurements the plugin names the one factor that costs the most time before the first byte, in plain language and with the numbers it is based on.<\/p>\n\n It also states the interaction administrators most often get wrong: a persistent object cache removes the database query for your options, but not the payload. The options still travel to PHP and still sit there as an array for the whole request, cache or no cache.<\/p>\n\n The plugin measures that cost on your server rather than asserting it. Decoding is not where it sits: WordPress keeps the raw strings in that array and turns a single option back into a structure only when something reads it, so most of a large payload is never decoded at all. What every request pays is the array itself, and it costs more than the bytes suggest, because PHP adds a fixed amount per string and per entry. Measured on two installations it came to 1.09 and 1.60 times the size on disk, the higher figure on the site built from many small options. That is the number that matters on a host with a tight memory limit.<\/p>\n\n WordPress has no scheduler of its own; it keeps the list of due work in a single autoloaded option and looks at it when someone visits. The plugin reads that list and reports three things that go wrong with it: an event scheduled hundreds of times over because a plugin rescheduled without unscheduling first, events overdue by days because nothing is triggering cron at all, and events belonging to plugins that are long gone. Every hook is attributed to its plugin the same way options are.<\/p>\n\n Orphaned post, term, comment and user meta, post revisions, expired transients, auto-drafts and trashed posts. A table overview from Free space is reported per engine rather than as one number, because Collations are compared against the WordPress tables, not against the majority: on a site with many plugin tables the plugins outnumber core, and a plain majority would report WordPress itself as the anomaly. Tables still on the three byte On large tables the exact count is attempted under a deadline enforced by the database server. Only when that deadline passes does the plugin fall back to a bounded sample, and the result then says so. Because orphans are created by events and therefore sit in contiguous blocks rather than spread evenly, a sample can be genuinely inconclusive; in that case the plugin reports a confirmed lower bound and states that the total could not be determined, instead of printing a number that looks measured.<\/p>\n\n WooCommerce data is treated with care. Orders, their metadata and active sessions are never counted as orphaned, trashed orders are never offered for deletion, and while WooCommerce keeps its orders in its own tables (HPOS), post meta is reported but not offered for cleanup at all: whether a row still belongs to an order cannot be answered reliably then, and that is not a basis for an irreversible delete.<\/p>\n\n Cleanup exists, but it is a side function, not the selling point. Every category runs on its own, never all at once. Dry run is the default: you see how many rows are affected and confirm before anything is deleted. Work is batched over the REST API with a progress display. There is no cron job and no automatic cleanup.<\/p>\n\n Everything the screen does is available through WP-CLI, because the scanners\nwere written to know nothing about the admin screen.<\/p>\n\n That turns a report across many installations into a shell loop, which is the\ndifference between a tool for one site and a tool for a hosting account.<\/p>\n\n Scans never run during regular page loads. A result is kept for 12 hours and refreshed only when you press the rescan button.<\/p>\n\n Version 1.0 reports on a single site. On a multisite network, activate it per site; network activation is refused with an explanation rather than producing numbers that look network wide but are not.<\/p>\n\n\n Reading is safe. The scan runs two queries against the options table and a handful of aggregate queries against Cleanup deletes rows, and deleting rows is never risk free. Every operation shows you the affected row count first and requires confirmation. Make a backup before you delete anything.<\/p><\/dd>\n Because it does not know. Option names carry no author. Attribution is derived from prefixes, and when a prefix matches nothing on the installation, the honest answer is that the origin is unknown. A guess would send you looking in the wrong place.<\/p><\/dd>\n Yes. The prefix table is filterable:<\/p>\n\n The array is keyed by prefix without a trailing separator. If you are a plugin author whose options are showing up as unattributed on other people's sites, adding this filter to your own plugin fixes it for every user at once.<\/p><\/dd>\n Yes, and that is the point of it for anyone looking after more than one site. turbopress_diagnostics_loopback_sslverify decides whether the loopback request verifies the TLS certificate. Return false on a staging environment behind a self signed certificate, where the check would fail for a reason unrelated to caching.<\/p>\n\n Probably not. Managed hosting commonly puts No. It is a single GET request to your own home URL, made by your own server, to look at the response headers. Nothing is sent to any third party. You can switch it off in the settings, in which case page cache detection is skipped.<\/p><\/dd>\n It does not. Redis and Valkey statistics are read through the connection the object cache drop-in has already established. If the drop-in does not expose its client, the plugin reports that no statistics are available rather than trying to connect on its own.<\/p><\/dd>\n Yes, as JSON. This is meant for support tickets: it contains the measurements and option names, no option values.<\/p><\/dd>\n\n<\/dl>\n\n\nAutoload with the plugin responsible<\/h4>\n\n
acf_field_group<\/code> is attributed to Advanced Custom Fields while acfxtra_setting<\/code> is not. Anything that cannot be attributed is reported as not attributed<\/strong> rather than assigned to the nearest plausible plugin. Guessing would be worse than saying nothing.<\/p>\n\nionos<\/code> account for 186 KB. Grouping is not attribution and is labelled as such, but it turns a dead end into something you can search for.<\/p>\n\nObject cache, OPcache and page cache in one picture<\/h4>\n\n
\n
maxmemory-policy<\/code>.<\/li>\nobject-cache.php<\/code> and advanced-cache.php<\/code> drop-ins from their file header.<\/li>\nopcache_get_status<\/code> in disable_functions<\/code>, running but with opcache.restrict_api<\/code> locking this path out, and measured from the command line where OPcache is off anyway. Only the first two are faults of the site; the rest are hosting arrangements and are left out of the score rather than counted against you. Where the counters are unreadable the plugin still asks opcache_is_script_cached<\/code> whether a WordPress core file is in the cache, so it can say whether OPcache is actually working instead of guessing from a configuration flag.<\/li>\nIn the Site Health screen<\/h4>\n\n
What changed since last time<\/h4>\n\n
The verdict<\/h4>\n\n
Scheduled events<\/h4>\n\n
Database bloat<\/h4>\n\n
INFORMATION_SCHEMA<\/code> with size, engine, row count, collation and free space. Tables whose prefix belongs to a plugin that is not installed.<\/p>\n\nDATA_FREE<\/code> does not mean the same thing everywhere. In MyISAM it is waste that OPTIMIZE TABLE<\/code> returns to the file system. In InnoDB it is space the engine reuses for new rows, so it is reported separately and never called reclaimable. And with innodb_file_per_table<\/code> switched off it describes the shared tablespace, so the same figure appears on every table; there the plugin leaves it out and says why, rather than adding one number up thirty times.<\/p>\n\nutf8<\/code> or utf8mb3<\/code> are called out separately, because those cannot store emoji and make joins against utf8mb4<\/code> tables fail outright.<\/p>\n\nCleanup<\/h4>\n\n
On the command line<\/h4>\n\n
wp turbopress-diagnostics scan # score and the figures behind it\nwp turbopress-diagnostics scan --refresh # measure again first\nwp turbopress-diagnostics report > report.json # the full document\nwp turbopress-diagnostics categories # what can be cleaned, and how much\nwp turbopress-diagnostics cleanup orphan_postmeta # simulate\nwp turbopress-diagnostics cleanup orphan_postmeta --execute # delete, asks first\n<\/code><\/pre>\n\nWhat this plugin does not do<\/h4>\n\n
\n
\n
\/wp-content\/plugins\/turbopress-database-diagnostics\/<\/code> or install it through Plugins \u2192 Add New.<\/li>\n\n
Is it safe to run this on a production site?<\/h3><\/dt>\n
INFORMATION_SCHEMA<\/code>, all of them bounded. Nothing runs during normal page loads.<\/p>\n\nWhy does it say \"not attributed\" instead of naming a plugin?<\/h3><\/dt>\n
A plugin of mine is not recognised. Can I register its prefix?<\/h3><\/dt>\n
add_filter(\n 'turbopress_diagnostics_plugin_prefixes',\n function ( $prefixes, $plugins, $themes ) {\n $prefixes['acme'] = array(\n 'type' => 'plugin', \/\/ plugin, mu_plugin, theme,\n \/\/ removed_plugin, removed_theme\n 'id' => 'acme-widgets', \/\/ directory slug\n 'label' => 'Acme Widgets', \/\/ name shown in the report\n );\n\n return $prefixes;\n },\n 10,\n 3\n);\n<\/code><\/pre>\n\n$plugins<\/code> contains the installed plugins and must-use plugins keyed by slug, $themes<\/code> the installed themes keyed by stylesheet, so you can decide whether to register anything at all. Entries that do not follow this shape are discarded, because a malformed entry would produce a wrong statement about who is responsible for a payload.<\/p>\n\nCan I use this from WP-CLI?<\/h3><\/dt>\n
wp turbopress-diagnostics scan<\/code> prints the score and the figures behind it, wp turbopress-diagnostics report<\/code> the full JSON document, wp turbopress-diagnostics categories<\/code> what can be cleaned up, and wp turbopress-diagnostics cleanup <category><\/code> runs one category. Cleanup simulates unless you add --execute<\/code>, and asks for confirmation unless you add --yes<\/code>.<\/p>\n\nwp help turbopress-diagnostics lists every subcommand and option. The commands are also shown on the plugin screen, under the settings.\n<\/code><\/pre><\/dd>\nWhich other filters does the plugin provide?<\/h3><\/dt>\n
turbopress_diagnostics_table_prefixes registers table name prefixes so leftover tables of a plugin that is gone are named rather than ignored, in the same way as the option prefixes above.\n\nturbopress_diagnostics_count_time_budget sets how many seconds an exact orphan count may take on a large table before it falls back to a sample. The default is 5. The deadline is enforced by the database server, so an overrunning query is stopped rather than left to consume the PHP execution time. Raise it to trade a slower scan for an exact number.\n<\/code><\/pre><\/dd>\nThe plugin cannot read my OPcache statistics. Is something broken?<\/h3><\/dt>\n
opcache_get_status<\/code> into disable_functions<\/code>, or restricts it with opcache.restrict_api<\/code>. OPcache keeps working; only the counters are unreadable. The plugin tells that apart from a genuinely disabled OPcache, leaves it out of the score instead of counting it against your site, and still reports the configuration through opcache_get_configuration<\/code>, which usually survives. It also asks whether a WordPress core file is currently in the cache, which answers whether OPcache is doing its job even when the numbers are hidden.<\/p><\/dd>\nDoes the loopback request send data anywhere?<\/h3><\/dt>\n
Why does it need Redis credentials?<\/h3><\/dt>\n
Can I export the result?<\/h3><\/dt>\n
1.0.4<\/h4>\n\n
\n
autoload_memory<\/code> is now called autoload_decoded<\/code>, because that is what it measures.<\/li>\n<\/ul>\n\n1.0.3<\/h4>\n\n
\n
%i<\/code> placeholder of $wpdb->prepare()<\/code> instead of being quoted by hand and interpolated into the query. This raises the requirement to WordPress 6.2, which is where %i<\/code> arrived.<\/li>\ntpdiag<\/code>.<\/li>\n<\/ul>\n\n1.0.2<\/h4>\n\n
\n
wp turbopress-diagnostics<\/code>) and the four public filters, which are now turbopress_diagnostics_*<\/code>.<\/li>\n1.0.1<\/h4>\n\n
\n
update_core<\/code>, update_plugins<\/code> or update_themes<\/code> are marked separately, because WordPress skips the expiry lookup for those three names and so never clears them by reading them.<\/li>\n1.0.0<\/h4>\n\n
\n