DEV Community: WP Multitool

WP Multitool 1.9.7: the underscore in wp_ is a SQL wildcard

WP Multitool — Tue, 15 Sep 2026 06:49:48 +0000

Originally published on https://wpmultitool.com/2026/09/15/wp-multitool-1-9-7/

An underscore in a SQL LIKE pattern is a wildcard. It matches exactly one character, any character. Every WordPress table prefix ends in one. So does every transient option name.

I shipped two bugs on the back of that, and they went out in WP Multitool 1.9.7 as fixes. Here’s what happened.

The query that looked fine for years

Finding your own tables looks obvious:

SELECT TABLE_NAME FROM information_schema.TABLES
WHERE TABLE_NAME LIKE 'wp_%'

I ran that against a table holding four names to see what it really matches:

naive   LIKE 'wp_%'  =>  wp_posts, wpXanything, wp2_options
esc_like            =>  wp_posts

The underscore matched the X. It matched the 2. On a shared database with more than one WordPress install, or next to any table that happens to start with “wp”, that pattern reaches tables I have no business touching.

In my Database Optimizer that mattered twice. Table stats listed foreign tables as if they were yours. Worse, the optimize loop ran OPTIMIZE TABLE on them.

The same bug, one letter wide, in transients

Transient cleanup has the same shape:

SELECT option_name FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'

Three underscores in that prefix, three single-character wildcards. It matches _transient_timeout_something, which is what you want. It also matches xtransient_timeout_y, which is not a transient at all.

That inflated the transient counts I was showing people. And in the cleanup path it meant backing up and deleting options that were never transients. A plugin storing a setting under an unlucky name would have lost it.

The fix is one function

$wpdb->esc_like() escapes the LIKE metacharacters and leaves everything else alone. It does not escape quotes, so it goes inside prepare(), not instead of it:

$pattern = $wpdb->esc_like( $wpdb->prefix ) . '%';
$rows = $wpdb->get_col( $wpdb->prepare(
    "SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_NAME LIKE %s",
    $pattern
) );

The trailing % is appended after the escaping, because that one is meant to be a wildcard. esc_like( 'wp_' ) returns wp\_. That is the whole fix.

If you write WordPress code, go grep your own plugins for LIKE ' right now. I found mine by reading a query I’d read a dozen times before.

Then I went looking at the admin, and that went the same way

Someone messaged me that the buttons in the plugin admin looked off. Icons sitting a few pixels below their labels. On the Dashboard Widgets screen you had to hover a row before you could see which widget it referred to.

I went to fix the icons and ended up measuring all 17 admin screens instead – computed font size, contrast ratio, click target size, horizontal overflow, at five widths from 1440 down to 390.

409 elements had text under 14px. The muted grey I use for secondary text everywhere came in at 3.49:1, under the 4.5:1 AA floor. One entire screen – Updates – was rendering in the default light WordPress theme because its wrapper was missing a class, so the heading sat at 1.25:1 against the background. I had been looking at that page for months.

The hover bug had a cause I didn’t expect. WordPress core parks row action links off-screen at left:-119988px and only brings them back on hover. That is core behaviour for list tables, and the widget hook IDs were riding along with it.

The audit that gave itself a pass

This is the part I keep thinking about.

After the first round of fixes, my measuring script reported nothing left to fix. That was wrong. The check was “flag anything with a font size below 14px”, which silently skips anything at exactly 0.

An element at font-size: 0 renders invisible. Mine was scoring it as a pass. And it was the original reported bug – the widget hook IDs, still at 0px at phone width, certified clean by the thing I built to catch it.

WordPress core sets .row-actions span { font-size: 0 } at mobile widths. My rule set the colour and the font family on those IDs but never declared a font size, so core’s zero won uncontested. Two separate misses stacked on the same element.

A test that cannot fail the way the bug actually happens will pass forever. I’d rather learn that on a font size than on a payment.

What else is in 1.9.7

Site Doctor stopped reporting Performance Lab’s Server-Timing drop-in as a dead object cache. Every site running Performance Lab got a critical finding telling the owner to delete wp-content/object-cache.php. That file is not an object cache, its own header says so, and deleting it only breaks Server-Timing measurement. It also gets written straight back by the plugin, so the advice now names the constant that actually settles it – PERFLAB_DISABLE_OBJECT_CACHE_DROPIN.

Site Doctor also learned four LiteSpeed misconfigurations, read through LiteSpeed Cache’s own filter rather than raw options: the WooCommerce product update interval, Guest Mode blocked by a .htaccess PHP deny-all, Serve Stale turned off, and WebP Express endpoints missing from the allow-list. Nothing is written back, the remediation is copy-paste.

Frontend Optimizer can now stop the empty-cart WooCommerce session cookie for logged-out visitors. WooCommerce sets a session cookie speculatively, and a Set-Cookie on an anonymous request forces a cache bypass on every hit behind a CDN or page cache. It is skipped on cart, checkout, my-account and REST, and only fires when the cart is genuinely empty and the visitor is logged out.

The Action Scheduler screen updates its numbers in place after Unstick, Run Queue and Clean. It used to run the action, tell you it worked, and leave the old counts on screen with a note asking you to refresh.

And the admin sweep shipped: text raised above 14px, contrast fixed, focus rings you can see when you tab, click targets at 24px or more, no sideways scrolling on a phone, and the native blue-and-white checkboxes replaced with the plugin’s own toggle. All 1505 strings are translated across six languages.

Updating

If you use Database Optimizer or clean transients, take this one. The two LIKE fixes are the reason it leads the changelog.

Auto-updates handle it if you have them on. Otherwise it’s in your Plugins screen, or on the downloads page with your licence key.

Why Is My WordPress Admin So Slow? A Diagnostic Guide

WP Multitool — Mon, 14 Sep 2026 08:15:18 +0000

Originally published on https://wpmultitool.com/2026/09/13/why-is-my-wordpress-admin-so-slow/

Why is my WordPress admin so slow? Most slow-admin reports land in my inbox sounding the same. One wordpress.org poster put it perfectly: pages “are taking 20-30 Seconds to load any page only in /wp-admin/. The frontend of site is running smoothly without any issue.”

The short answer is hiding in the question. Your homepage is cached. Your dashboard never is. Page cache hands saved HTML to logged-out visitors and steps aside the moment it sees a login cookie, so every wp-admin click runs the whole stack: PHP boots, every active plugin loads its admin code, the database answers whatever that screen asks for. A slow admin is your site’s real, uncached speed, with nothing hiding it.

The causes are a short list, and you can find yours in about fifteen minutes. Here’s the order I check them on client sites, cheapest test first.

Step 0: Prove it’s the server, not the browser

Before touching anything, open the slow admin page, hit F12, go to the Network tab and reload. Click the first request (the HTML document) and open its Timing panel. “Waiting for server response” is your TTFB: everything the server did before the browser received a single byte.

Admin TTFB	What it means
Under ~600ms	Normal for uncached WordPress. If the page still feels slow, your problem is JavaScript, not PHP.
600ms to 2s	Backend work worth digging into. Keep reading.
Over 2s	Something specific is broken. Keep reading, it’s probably one loud culprit.

If TTFB is fine but the editor still lags, that’s a different problem (browser JS, metaboxes, autosave). This post is about server-side slowness.

Once you’ve confirmed it’s the server, match your symptom to a starting point:

What you see	Start at
Every admin screen equally slow	Autoloaded options, then object cache
Dashboard home is the slow one	Dashboard widgets, external HTTP calls, update checks
Editor lags, saving feels heavy	Heartbeat, autosave, metaboxes
Plugin list or settings screens crawl	License checks and other phone-home calls
Slow only when several people are logged in	Heartbeat ticks eating PHP workers
Slow some hours, fine others	Update checks firing through a broken object-cache gate

What Site Health already knows about your admin

Go to Tools → Site Health. Two of its checks are aimed straight at this problem.

“Autoloaded options could affect performance” – since WordPress 6.6, Site Health measures the total size of your autoloaded options and flags the site once it passes 800,000 bytes. If you see this warning, that’s very likely your answer. Skip to the next section.

“Page cache is detected but the server response time is still slow” – people paste this exact string into Google. Two things worth knowing about it. First, the test requests your homepage three times and takes the median; under 600ms is “good” (that threshold lives in core as site_status_good_response_time_threshold, filterable if you disagree with it). Second, the message means even your cached front end is slow to produce, a bigger problem than a slow admin. If Site Health is green while wp-admin drags, don’t be surprised. Site Health can only measure the public side; admin slowness is invisible to it.

Weigh your autoloaded options

Every row in wp_options has an autoload flag. Rows marked for autoload get pulled into PHP memory in a single query at the start of every request: front end, admin, admin-ajax, REST, everything. It’s a good optimization for a handful of small settings. Over years of installing and removing plugins it stops being small.

Check the total (via WP-CLI, wp db query, or phpMyAdmin):

SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb,
       COUNT(*) AS rows_n
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

Then see who the weight belongs to:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY bytes DESC
LIMIT 10;

I ran both on a test site of mine (WP 7.1, WooCommerce, a normal plugin stack). Result: 997KB across 355 rows. The top offenders:

option_name	size	belongs to
wpseo_taxonomy_meta	293KB	Yoast SEO
wpseo_titles	152KB	Yoast SEO
woocommerce_marketplace_suggestions	140KB	WooCommerce
elementor_remote_info_library	86KB	Elementor
wc_stripe_cached_payment_methods	84KB	Stripe gateway

Yoast isn’t even installed on that site anymore. It left about 445KB of autoloaded settings behind, and WordPress happily loads them on every request. The WooCommerce and Stripe entries are cached data that never needed autoload in the first place.

You’d think WordPress 6.6 fixed this. Partly. Since 6.6, an option saved without an explicit autoload flag gets stored as auto-off once it exceeds 150KB, and Site Health reports the total. But nothing is cleaned retroactively, and plugins that explicitly ask for autoload keep it, which is why my 293KB wpseo_taxonomy_meta still says on. The details are in the 6.6 dev note if you want the mechanics.

The fix: delete options left by plugins you removed, and flip autoload off for big options the site still needs but not on every request. I wrote the full procedure, including how to tell a leftover from a live option, in the autoload bloat guide. If you’d rather not run SQL by hand, the Autoloader Optimizer module in WP Multitool does this analysis and the cleanup.

Make sure your object cache is actually caching

A persistent object cache (Redis or Memcached) is the biggest admin speedup available on a query-bound site, because wp-admin runs everything uncached and every repeated lookup hits MySQL without one. If your host offers Redis, use it. One caveat worth knowing: it won’t rescue a bloated autoload set. The alloptions blob still lands in PHP memory on every request, it just arrives from Redis instead of MySQL.

The catch: “Redis: Connected” in a plugin’s settings page proves the socket opened. It says nothing about whether your data is being cached. I’ve seen Redis connected with maxmemory-policy set to noeviction: once memory fills, every write fails silently and you’re paying the Redis latency for zero benefit. Or the options group sitting on the ignore list, so the one table that matters most bypasses the cache on every request.

Checks that matter: the object-cache.php drop-in actually exists in wp-content, the hit rate is healthy, there’s headroom under maxmemory, and the eviction policy isn’t noeviction. I wrote a whole post on this failure mode: Redis: Connected Is Not Working. WP Multitool’s Site Doctor runs these checks against the live server, and it’s in the Lite edition ($9 one-time), no Pro license needed.

Watch admin-ajax.php while you’re doing nothing

Open wp-admin, filter the Network tab to admin-ajax, and just sit there. You’ll likely see requests firing on a timer while you touch nothing.

That’s the Heartbeat API. It ticks somewhere between every 15 and 120 seconds per open admin screen, depending on the screen, powering autosave, post locks and session warnings. Every tick is a POST to admin-ajax.php, and every one boots the entire WordPress stack. The official AJAX docs put it plainly: all WordPress AJAX requests must be sent to admin-ajax.php. So every AJAX call goes through one file, with a full bootstrap and no page cache.

On a solo admin session it’s minor. With three editors holding post edit screens open, you get a steady stream of uncached full-boot requests competing for PHP workers with your real clicks. Throttle it to 60 seconds (Heartbeat Control is free), but keep it enabled in the editor, because that’s what autosave and post locking run on.

If you see admin-ajax requests that aren’t the heartbeat, repeating every few seconds with plugin-specific action names, some plugin is polling your server while you work. Worth finding out which.

Catch the plugin doing the damage

When the checks above come back clean and admin is still slow, it’s usually one plugin loading something heavy on every admin screen. The tool is Query Monitor (free, by John Blackbourn). Install it, open the slow screen, and read:

Queries by component – which plugin owns the query time. A plugin running 200 queries on a dashboard it has no business touching shows up immediately.
HTTP API calls – external requests blocking the page render. One wordpress.org thread I keep coming back to had a 13-second wp-admin caused entirely by outbound HTTP calls: update checks, license pings, notification feeds, each taking 0.3 to 0.8s.
Scripts and styles enqueued – plugins that load their entire UI on every admin page.

The toggle test works too (deactivate half, test, bisect), but do it on staging. I covered the full isolation method in how to find which plugin is slowing WordPress.

The api.wordpress.org tax, briefly

WordPress checks api.wordpress.org for core, plugin and theme updates roughly twice a day, gated by a last_checked timestamp inside the update transients. If your object cache drops those transients (dead Redis, aggressive flushing, an orphaned drop-in), the gate falls through and WordPress fires a blocking update check on admin page loads. I measured this and wrote it up separately: why WordPress hammers api.wordpress.org on every admin page load. If your admin is intermittently slow, fine for hours then suddenly 10 seconds, this is the first thing to suspect.

WooCommerce adds its own layer

Everything above applies double to WooCommerce admin. On top of it, WooCommerce queues background work through Action Scheduler, and the wp_actionscheduler_actions table quietly accumulates completed and failed rows. On a busy store that table can grow to hundreds of thousands of rows, and admin screens that scan the queue get slower with it. Worth a look if the Orders and Products screens are your slow ones specifically.

The order I actually run this in

TTFB in the Network tab – is it the server at all?
Site Health – autoload warning? Page-cache-but-slow warning?
Autoload size SQL – over ~800KB, trim it before anything else.
Object cache verified working – connected and actually caching.
admin-ajax in the Network tab – heartbeat flood or a polling plugin.
Query Monitor on the slowest screen – queries by component, HTTP calls.
Fix the thing you measured. Retest. Stop when it’s fast.

Every slow admin I’ve fixed had one dominant cause, and it was almost never the one the site owner suspected going in. That’s the argument for measuring first.

FAQ

Why is my WordPress admin slow but the website is fast?

Because the public site is served from page cache and wp-admin never is. Every admin click runs the full PHP/database/plugin stack, so the dashboard exposes your site’s real backend speed.

What is a good wp-admin load time?

Core’s Site Health uses 600ms median server response as its “good” threshold. For wp-admin, under a second TTFB feels normal, 1 to 3 seconds means something wants attention, and over 3 seconds means something is broken.

Does Redis object cache speed up wp-admin?

Usually, yes. wp-admin is query-heavy and uncached, so serving repeated lookups from memory helps more there than on the cached front end. Verify it’s actually caching, not just connected: hit rate, memory headroom, and a sane eviction policy all matter.

WordPress MCP: The Three Kinds of AI Plugins

WP Multitool — Mon, 07 Sep 2026 08:15:16 +0000

Originally published on https://wpmultitool.com/2026/09/07/wordpress-mcp-three-kinds-of-ai/

“AI plugin” means three different things in WordPress now, and most roundups I read mix them into one list. A plugin that writes your product descriptions and a plugin that lets Claude run PHP on your server share a category in every “best AI plugins” article I’ve read. They shouldn’t. What follows is a map of WordPress MCP and AI-agent plugins, built from a survey of the field on 2026-09-02 and hands-on tests I ran on live local sites.

I don’t rank by WordPress.org active-install counts. That number is trivially spoofable, and ranking by it rewards a plugin for being popular rather than for being good. Everything here is ranked on what the agent is allowed to do, what is on by default, where credentials and site data end up, and whether actions are reversible.

If you want the deep test of what an MCP client actually receives from the two hosts below, that is the companion piece: what an AI agent sees when it connects to WordPress. Short version: both Albert and Novamira expose exactly the same three gateway tools. The differences sit behind that door.

The three kinds

Kind	What it does	Agent touches your site?	Examples from this survey
Text generators	Write copy, images, SEO meta	No – output goes to you, not to your database	Yoast/Rank Math AI, GetGenie, Divi AI, CodeWP
MCP content-admin servers	Let an external AI client (Claude, ChatGPT) read and edit content over MCP	Yes – curated, typed actions on posts, pages, users, media	Albert, Agent Abilities for MCP, Royal MCP, Easy MCP AI
PHP-execution hosts	Let the agent run code, shell commands, and file operations inside WordPress	Yes – effectively unrestricted admin-level code	Novamira, Cowboy MCP Power Mode, Angie Super Admin, AI Engine YOLO

The border between the second and third kind is the whole security conversation. Both connect through the same door, and on both of the hosts I tested, that door is the official WordPress MCP Adapter exposing three meta-tools: discover abilities, get ability info, execute ability.

What the Abilities API actually is

WordPress 6.9 shipped the Abilities API: a standard way for a plugin to register a typed, permission-checked action, wp_register_ability. The official MCP Adapter turns registered abilities into an MCP server, so an external client like Claude Desktop can discover and execute them over OAuth. The introduction post on the developer blog is the canonical description.

The consequence for buyers: a host that speaks the Abilities API can surface abilities from any plugin that registers them, without integration work on either side. The consequence for plugin authors: register once, work everywhere.

On 2026-09-02 the WordPress.org plugin directory returned 384 plugins matching “mcp” and 1,513 matching “AI assistant”. Many of those are noise for this map: SEO plugins that mention MCP in their copy, chat widgets, wrappers. The buckets below are the ones that actually operate a site or speak the standard.

The category map (2026-09-02)

Official building blocks

The canonical AI plugin (1.3.0) ships an Abilities Explorer and lists an MCP server as coming. The MCP Adapter itself is at 0.6.1. Automattic’s earlier wordpress-mcp plugin was archived in January 2026 in its favor. WordPress.com runs a hosted MCP with write abilities on paid plans. If you are picking a self-hosted route today, the adapter plus a host plugin is the pattern both products I tested build on.

Curated MCP servers

Plugin	The bet	What I verified or read
Albert	Curated CRUD, production-shaped defaults	Tested hands-on: writes off by default in code, privacy layer, per-block editing, no code execution
Agent Abilities for MCP	Governance first	153 abilities, off by default, official adapter, audit log, least-privilege user. The governance benchmark in this category
Royal MCP	Undo as a feature	200+ tools, OAuth, 72-hour undo window
Easy MCP AI	Scale	243 tools, acquired by Themeisle, auto-discovers abilities
miniOrange Secure MCP	Enterprise posture	OAuth 2.1, human-in-the-loop, DLP; optional vendor gateway
WPVibe	Convenience over custody	Relays through wpvibe.ai and stores application passwords, encrypted, off-site. The trust-model outlier
Enable Abilities for MCP	Adapter-native	Capable, but abilities default ON. Wrong default for this class

PHP-execution hosts

Plugin	The bet	What I verified or read
Novamira	The agent as site operator	Tested hands-on: 41 own abilities including PHP, filesystem, WP-CLI; all MCP-public behind the gateway with Hub toggles as the gate
Cowboy MCP	Typed tools plus safety nets on live sites	Undo and DB checkpoints, Power Mode for WP-CLI/files. Publishes its own comparison page against Novamira
Angie Super Admin Mode	Opt-in power inside a chat product	Filesystem/DB/PHP behind a toggle; MCP added in 1.1.14
AI Engine YOLO	The escape hatch, honestly labeled	GitHub-only companion to AI Engine, explicitly not for production

AI Engine deserves its own line here: the official plugin ships an MCP server and a workspace with approval steps, and explicitly refuses to include PHP execution. The YOLO companion exists for people who want that. That is the cleanest default posture I found in the chat products.

Chat agents and the rest

In-admin chat agents (AI Engine, Angie, Uncanny Automator, Hostinger, SiteGround) put the model inside wp-admin instead of connecting an external client. SiteGround’s is the cautionary tale in this bucket: a 1.6-star rating with 81 one-star reviews at survey time, mostly about being auto-installed without consent. Auto-installing a plugin without consent is worse than anything on its feature list. Text generators (CodeWP, GetGenie, the SEO suites’ AI) are a different category entirely and I left them out of the comparison.

The head-to-head that matters: behind the same three tools

I tested Albert 1.3.1 and Novamira Free 1.12.2 on live local sites, connected an MCP client to both, and captured everything. The tool lists are identical: three adapter meta-tools each, no per-ability tools, no pagination. So comparing them on “MCP support” is comparing identical things. The differences:

The catalog. Novamira registers 41 of its own abilities, including three code-execution abilities, eight filesystem abilities, a WP-CLI ability, and an admin-access ability. All of them were MCP-public on my test site, with the Hub’s toggles as the gate. Albert ships 35 abilities of pure CRUD. No PHP, no filesystem, no WP-CLI anywhere in the plugin.

The consent screen. Novamira’s OAuth consent lists the grant in plain words: execute PHP and WP-CLI, read/write/delete server files, create temporary administrator access. Albert’s consent names the app and the code destination but doesn’t enumerate the grant. Novamira’s screen is the more honest of the two.

The domain lock. When I cloned the site to a new hostname, Novamira disabled its entire MCP surface until an admin re-enabled it. A stolen copy of the site won’t serve MCP on the attacker’s host. I found no equivalent in Albert and didn’t test a configured Albert install on a moved hostname.

Albert shipped 1.4.0 the evening I finished testing, and it changes none of the above: a new Context screen that tells assistants what your site is, file sending from assistants, an admin redesign, WordPress 7.1 support. On a fresh 1.4.0 install the Abilities screen shows 46 rows with one contributing plugin, against 44 on the 1.3.1 I tested.

For a second opinion on the PHP-host model, Cowboy MCP publishes its own comparison page against Novamira, linked from its WordPress.org page. My survey read it as the typed-tools-with-undo-on-live-sites bet, positioned against Novamira’s PHP-on-staging-with-backups model. A competitor publishing a comparison against the category leader is worth your reading time, whatever you end up choosing, and it is why I cite it.

The one documentation failure I found

On 2026-09-02, Albert’s own pages stated its ability count as 15, 35+, and 100+ in three different places, and none matched the 44 rows its admin screen showed on a fresh install. That was the only claim of Albert’s that failed in my ten-claim test. Everything else I attacked, from write-defaults to privacy masking to the no-phone-home claim, held. Albert shipped 1.4.0 the evening I tested: the fresh-install screen now shows 46 rows, the wp.org page’s 35+ claim is gone, and the homepage still says 15 and 100+. Checkable numbers, checked and dated.

That’s the standard every table on this page should meet, including mine.

How I would choose

The survey behind this post ended with a recommendation I still stand behind after the hands-on tests: staging plus Novamira or Cowboy for agency work where the agent builds and fixes things; Albert or Enable Abilities for content CRUD only; and never PHP execution on production. The tests moved one word for me: Albert’s write defaults and privacy layer held up under attack, so “Albert for content CRUD” is a stronger recommendation now than it was on paper.

Where a diagnostics plugin sits

I make WP Multitool. It registers six read-only abilities: a whole-site quickstart scan, a health snapshot, an autoload report, slow-query stats, Redis diagnostics, and a Site Doctor scan. The opt-in is off by default. The abilities are annotated read-only, which is what keeps them available under Albert’s default policy of disabling everything non-read-only.

On Albert, all six appeared in its admin UI and in the agent’s discovery list. On Novamira, all six appeared in the Hub and in the live registry, and the quickstart scan executed end-to-end through its gateway. Zero host-specific code on my side, either way. Hosts will come and go – the registration surface is the part that should outlast them, and it’s the bet I’ve made with six read-only abilities.

If you run agents against WordPress sites, the practical writeup for pointing them at the CLI side is how to make your AI agent use WP Multitool, and the Novamira-specific pairing, including the skill file I ship inside the plugin, is in the combo post.

What I did not verify

Search volume numbers. I found competing guides already ranking for “wordpress MCP” (smartwp.com, June 2026; nexterwp.com, July 2026), which is demand evidence, but I loaded no keyword tool.
The current release state of every plugin in the map. The survey is dated 2026-09-02. Six of the listed plugins shipped a release in the week before it. Re-check versions before you buy anything off this table; I will re-check before this publishes.
Product pages I could not load: CodeWP pricing, WPTurbo, AutoWP, AI Mojo, WPBot, Divi AI. They stay out of the comparison tables.
Whether Albert and Novamira coexist on one site.
Novamira’s own data handling and its Chat feature. I tested Albert’s privacy layer; Novamira’s stayed out of scope.

Disclosure

I make WP Multitool, a paid diagnostics plugin. As of 1.9.6 it can register six read-only Abilities and it ships a Novamira skill file. I’m not affiliated with Dynamic.ooo, with Albert, Cowboy, or with any other plugin here. I tested Albert and Novamira on local copies. WP Multitool is a data provider to these agents, not a competitor. I benefit if more sites adopt the Abilities API, whichever host they pick.

Category survey dated 2026-09-02; hands-on tests run 2026-09-03 against Albert 1.3.1 and Novamira Free 1.12.2. Install counts deliberately absent from every table. The companion post with the full test capture is what an AI agent sees when it connects to WordPress.

WordPress MCP: What an AI Agent Actually Sees

WP Multitool — Fri, 04 Sep 2026 10:26:26 +0000

Two WordPress plugins promise to let an AI agent run your site over MCP: Albert, the AI Butler, and Novamira. I write a plugin that feeds data to agents like these, so I wanted to know what my plugin looks like from the agent's side of the connection. I set up two throwaway sites: a fresh one running Albert 1.3.1 from the plugin directory, and a clone of my own dev site running Novamira Free, updated to 1.12.2 from the GitHub release so it carried realistic data. Then I connected a real MCP client to each and counted the tools the agent gets.

Three tools. On both.

If you're evaluating WordPress MCP hosts, that number is the start of every comparison that matters.

How I tested

Albert ran on a fresh local install. Novamira ran on the clone, which is worth being precise about: the clone carried Novamira 1.11.6 from my dev site, and I updated it to 1.12.2 before testing, so what you read below went through the real version-change upgrade path. Albert came from the WordPress.org plugin directory; Novamira is distributed from its own site as a direct download. The client was the official MCP Inspector, connected over Streamable HTTP with OAuth 2.0 and PKCE. The category survey behind this post ran on 2026-09-02; every test below ran on 2026-09-03, against the versions current at that time.

I didn't use production sites. Nothing here touched a live store.

The same three tools, twice

Here is the complete tool list an authenticated MCP client receives from Novamira (names only; the raw capture carries title, description, and schemas):

{
  "tools": [
    { "name": "mcp-adapter-discover-abilities" },
    { "name": "mcp-adapter-get-ability-info" },
    { "name": "mcp-adapter-execute-ability" }
  ]
}

Albert returns the same three names. I checked both responses for a pagination cursor, because a truncated list would fake this result. Neither response has one. Three tools is the complete list on both hosts.

That surprises people who have seen either product's admin screen. Albert's Abilities page listed 44 rows on my fresh install, and six of those were my own plugin's. Without a contributing plugin it's 38. Novamira's Hub lists 41 of its own abilities plus everything other plugins register. Neither set becomes MCP tools. Both hosts bundle the official WordPress MCP Adapter, and both pass it only the adapter's three built-in meta-tools: discover abilities, get ability info, execute ability. An agent works by listing abilities, then executing one by ID through the gateway tool.

I verified this in Novamira's source as well, because a three-tool list is a big claim. DefaultServerFactory::create() hardwires the three adapter abilities as tools and auto-discovers only resources and prompts. The adapter does contain a mechanism for turning abilities into tools, and Novamira flags its abilities as MCP-public. Nothing surfaces as a fourth tool. The three routes Novamira serves, including the OAuth one, are mirrors of the same server.

So the tool surface, the part the agent sees first, is identical. What separates these products is everything behind the door.

How both hosts gate what the agent can do

Both hosts strip disabled abilities from the registry, so a disabled ability is invisible to discovery and to execution. Albert does this in code: on a fresh install it stores zero plugin options and disables every ability that is not marked read-only. I asked the gateway to run a disabled write ability, albert/create-post, and got back:

Ability 'albert/create-post' not found

The gateway does not say permission denied. From the agent's perspective the ability does not exist. After I toggled albert/edit-page-block on in Albert's admin, the same execution path ran it.

Novamira's Hub states the same model in its own words: "Disabled abilities are removed from registry discovery and MCP execution while AI Abilities are enabled on the Configuration page." Its dangerous abilities are off by default and need a confirmation dialog to enable.

Different catalogs behind the same door

Novamira ships 41 of its own abilities. The Hub's category rows include code execution (3 abilities), filesystem (8), Gutenberg (13), and admin access (1), plus a WP-CLI ability. On my clone, after enabling the surface, all 41 were registered and flagged MCP-public, with the Hub toggles as the gate. This matches what Novamira advertises itself as: the plugin whose product is running arbitrary PHP inside your WordPress, with a 30-second limit, through a sandbox at wp-content/novamira-sandbox/ that the vendor's own docs describe as not a security boundary.

Albert ships 35 built-in abilities. All of them are CRUD on content, users, and media. There's no PHP execution, no filesystem access, and no WP-CLI anywhere in the plugin. Writes and deletes are off by default through the code blocklist described above.

The consent screens, quoted

Both hosts use OAuth 2.0 with PKCE, and both walked my client through a consent screen before issuing tokens. The screens say different things.

Novamira's consent, verbatim:

MCP Inspector is requesting full access to your WordPress site.
[...]
This grant can:
Execute PHP and WP-CLI.
Read, write, and delete server files.
Change WordPress content and settings.
Create temporary administrator access.
Execute REST-visible abilities registered by compatible plugins.

I appreciate this screen. A non-technical site owner approving a connection sees, in plain words, that the application can run code and mint a temporary administrator. That is honest framing of a dangerous grant.

Albert's consent names the application, shows where the access code will be sent, warns when a client registered itself a minute ago, and shows which WordPress user is authorizing. It doesn't enumerate what the connection can do. Since Albert's catalog contains no code execution, the grant is smaller, but the screen does not say so. You have to know the product to know what you approved.

The security detail worth more attention: the domain lock

While setting up the Novamira test I cloned my dev site to a new hostname. Novamira noticed:

Novamira AI Abilities were disabled because the site domain changed (enabled on wpmultitool.loc). Re-enable them from the Configuration page if this is intentional.

The entire MCP surface, disabled, because the site moved. The lock lives in one option, novamira_ai_abilities_domain, and is enforced in code against the current hostname.

I checked the source before praising this, and it holds up. A stolen copy of a WordPress site, database and files and all, will not serve MCP on the attacker's hostname until an admin re-enables it. That is a real anti-exfiltration property. Novamira documents the lock in its own documentation, and in my read of both products it deserves far more prominence than Novamira gives it.

Albert has no equivalent state on a fresh install, and I didn't test a configured Albert install on a moved hostname. If someone wants to know, that's a separate test.

Small differences worth knowing

Endpoints split by auth mode. Novamira serves OAuth clients and application-password clients on different routes. /wp-json/mcp/novamira-oauth answers OAuth clients with a proper 401 challenge pointing at the OAuth metadata. /wp-json/mcp/novamira serves application-password clients with a bare REST 401. The server's own greeting states the split. Albert serves one route, /wp-json/albert/v1/mcp, with both discovery endpoints answering 200.

Skills surface as prompts. Novamira's four built-in skills appear in the MCP prompts list, and its discover-ability output carries an extra novamira_instructions field with agent guidance. The gateway itself instructs the agent. Albert's meta-tools are stock adapter tools.

Albert keeps an audit log. Every ability execution lands in a dedicated table with the ability name, user, status, and timestamp. Input, output, and client columns are empty in the free version, which matches the "full activity history" upsell on its dashboard.

Albert's privacy layer works. I tested it with a realistic user record. The default mode anonymizes. Strict mode masked the record even for my admin session: the email came back as p***@e***.com and the name as "Customer #2". Revealing real data requires an explicit per-call argument plus the gating capability. One nuance from my adversarial review pass: a bare top-level name field is only masked inside customer context, unless the ability opts in to name masking. The person-record abilities opt in. Email masking is unconditional.

Albert's per-block editing is surgical. I built a 42-block page, enabled exactly one write ability, and asked the gateway to replace the block at position 5, a single heading. One heading changed. The other nine headings, every paragraph, and the closing block stayed byte-identical, and the page grew by 60 bytes. The June support thread about truncated page output was a client-side limit, and the per-block design sidesteps it: an edit never round-trips the whole page. The input schema even accepts an expect argument so the edit refuses to apply if the target block changed underneath you.

The comparison in one table

Every row restates something tested or quoted above.

	Albert 1.3.1	Novamira Free 1.12.2
MCP tools exposed	3, the adapter's meta-tools	3, the same names
Adapter	official WordPress MCP Adapter	official WordPress MCP Adapter, one server mirrored across three routes
Own abilities	35, all CRUD on content, users, and media	41, including code execution, filesystem, Gutenberg, admin access, WP-CLI
Writes by default	off; only abilities marked read-only start on	dangerous abilities off, confirmation dialog to enable
PHP execution	none anywhere in the plugin	yes, 30-second limit, through a sandbox the vendor's docs describe as not a security boundary
OAuth consent screen	names the app, shows the code destination, warns on fresh clients, shows the authorizing user; does not enumerate capabilities	enumerates the full grant in plain words
Domain lock	none on a fresh install; not tested on a moved site	yes; a hostname change disables the surface until an admin re-enables it
MCP route	one: `/wp-json/albert/v1/mcp`	two, split by auth mode: `/wp-json/mcp/novamira-oauth` and `/wp-json/mcp/novamira`

What this means for plugin developers

I write a plugin that feeds data to agents like these. This section is what my plugin looks like from the agent's side.

My plugin, WP Multitool, registers six read-only abilities: a whole-site quickstart scan, a health snapshot, an autoload report, slow-query stats, Redis diagnostics, and a Site Doctor scan. They sit behind an opt-in that is off by default. For these tests I turned it on. There's nothing in my code that knows about Albert or Novamira.

On Albert, all six appeared in its Abilities admin screen, grouped under a third-party supplier filter, and in the agent's discover-ability list. On Novamira, all six appeared in its Hub under "Registered by other plugins". Then I executed the quickstart ability through both gateways. Same request shape on both:

{
  "ability_name": "wp-multitool/quickstart",
  "parameters": {}
}

On the Novamira clone it returned seven findings, including the ones that matter on a real site: 974 KB of autoloaded options, 319,475 stored revisions, captured slow queries, and the Site Doctor checks. On the fresh Albert site it returned the Site Doctor findings for that install.

One detail mattered more than I expected. Albert disables every ability that is not annotated read-only. My abilities carry readonly: true in their registration, so they survive that policy and stay available. A plugin registering write abilities without annotations would arrive switched off.

That is the actual story of the Abilities API, and the official introduction from the WordPress team states it in its own words: "Once registered, that ability is discoverable and executable from PHP, JavaScript, and the REST API," and the adapter "lets AI tools (like Claude Desktop, Claude Code, Cursor, and VS Code) discover and call WordPress Abilities directly." My test is the smallest possible proof, and it ran on both hosts I could test hands-on.

If you want the reverse direction, pointing an agent at a WordPress site's CLI instead of its API, I wrote that up earlier: how to make your AI agent use WP Multitool. The Novamira-specific pairing, including the skill file I ship, is in the combo post.

What I did not check

Data privacy on Novamira. I tested Albert's privacy layer. I didn't run anything similar on the Novamira side.
Novamira Chat, the in-dashboard agent. It exists as a separate feature and stayed out of scope.
Albert on a moved or cloned site, for the domain-lock comparison.
A second OAuth session as a non-admin user. Albert's permission pipeline is verified in source. Novamira's docs say every ability requires manage_options, and I didn't verify that in code. Both live connections ran as admin.
Whether Albert and Novamira coexist on one site. The research I did beforehand marked that unverified and I didn't verify it here.
ChatGPT as the client. It connects from OpenAI's servers, so it cannot reach a local test site. The equivalent real-client test would be connecting Claude to WordPress with Claude Desktop or Claude Code.

Disclosure

I make WP Multitool, a paid diagnostics plugin. As of 1.9.6 it can register six read-only Abilities and it ships a Novamira skill file. I'm not affiliated with Dynamic.ooo, with Albert, or with any other host here. I tested both on local copies: Albert on a fresh site, Novamira on a clone of my own dev site. WP Multitool is a data provider to these agents, not a competitor. I benefit if more sites adopt the Abilities API, whichever host they pick.

Both hosts earned their facts here. In my read, Novamira's consent screen and domain lock are better than its marketing gives them credit for. Albert's defaults and privacy layer are better than its ability-count copy, which is the one thing its documentation gets wrong: the admin screen shows 44 abilities on a fresh install with one contributing plugin, while three of its own pages say 15, 35+, and 100+. I counted. So can you.

Survey 2026-09-02; tests 2026-09-03, against Albert 1.3.1 and Novamira Free 1.12.2. Raw tool lists and execution responses are archived; screenshots above are from the test sessions.

Originally published at WP Multitool.

WP Multitool x Novamira – powerful combo

WP Multitool — Sat, 29 Aug 2026 08:15:17 +0000

Originally published on https://wpmultitool.com/2026/08/28/wp-multitool-x-novamira-powerful-combo/

Novamira gives an AI agent PHP, WP-CLI and the database on a WordPress site. That is a lot of rope. I wanted it to diagnose a slow site without inventing SQL and without running cleanup on a guess.

Sorry, your browser cannot play this Short. Download the 29-second video.

Get WP Multitool. Let your agent use it with Novamira.

WP Multitool 1.9.6 ships six read-only WordPress Abilities for that job. They sit behind the Site Doctor Agent access toggle. Default is off. They report findings. They change nothing.

Why Abilities, not another MCP server

Novamira is an MCP server. I am not going to ship a second one. WordPress 6.9 already has an Abilities API. I marked these public the way the official Adapter docs ask. I installed Novamira Free 1.11.6 on a local copy of this site. Abilities Hub listed all six under a WP Multitool group, status Enabled, MCP type tool. I have not installed Novamira on production.

The CLI I already had for this: wp multitool quickstart, health, autoload, slow-queries, redis. The abilities wrap those reads. They are the same family of JSON, not byte-identical: I dropped CLI extras that carry host names, and slow-queries is stats, not the query list. They do not wrap clean, autoload optimize, or frontend enable-all. An application password or OAuth token with manage_options is already an administrator. A typed tool that deletes revisions is an accident.

If you want the CLI playbook instead, I wrote that earlier: How to make your AI agent use WP Multitool. This post is the Novamira path.

What 1.9.6 actually ships

One toggle: WP Admin → WP Multitool → Site Doctor (or Tools → Site Doctor if you moved the menu). Agent access is a checkbox on that page. Off until you turn it on. WordPress 6.9 or newer. Below 6.9 the checkbox is not shown. I did not bump the plugin’s WordPress minimum. It stays 5.0. The scan ability already existed in 1.9.x. 1.9.6 is the public flag plus five more reads behind that same toggle.

Six names:

Ability	What it returns
wp-multitool/quickstart	Worst-first findings across config, autoload, database bloat and captured slow queries
wp-multitool/site-rescue-scan	Cache, OPcache, stacked optimizers, WooCommerce gateway checks
wp-multitool/health	PHP, memory, object cache, autoload size, revisions, transients
wp-multitool/autoload	Oversized option names and sizes. Not values.
wp-multitool/slow-queries	Log totals only: how many, how many unfixed, worst milliseconds. Not the SQL.
wp-multitool/redis	Whether Redis is actually in play, and the 21-check probe I described in Redis “connected” is not the same as working

Start with quickstart. Drill with the others. A source marked unavailable was skipped – treat that as “not checked”, not as “healthy”.

The JSON is the same family as the CLI. quickstart returns findings (each with severity, source, title, why), a per-severity summary, and a sources map. I dropped the CLI extras that carry host names. slow-queries is stats, not the query list, because I do not want SQL on a public MCP tool. autoload lists option names and kilobytes, never the option value.

Same termination condition as the CLI loop: read summary, stop when critical and warn are zero. Scan, tell the human, scan again after they act. The agent does not get to declare victory on its own write.

Permission is manage_options. Treat the payload as for that conversation. Never print DB_PASSWORD, auth keys or salts.

How to turn it on

Install WP Multitool 1.9.6 or newer. The changelog is here.
WordPress 6.9 or newer.
Enable the Site Doctor module if it is off.
Open the Site Doctor page. Turn Agent access on. Save.
Connect your AI client through Novamira the way their docs say (OAuth or an application password).

If the tools are missing after that, check the toggle, the plugin version, and WordPress 6.9. On Novamira 1.11.6 they showed up in Hub once Agent access was on. A different Novamira build might differ. Do not fall back to wp eval or a handmade SELECT. That is the whole point of this surface.

The Novamira skill

Novamira skills are one Markdown file. YAML frontmatter, then instructions. Their docs say the agent skims description and loads the body when it matches. I have not uploaded this file to a live Novamira Skills screen. I flattened the ClawHub skill into that shape: under 800 words, abilities instead of raw SQL, no write commands.

It is not in the plugin zip. docs/ is stripped from the release. It is not on ClawHub either – that package is the WP-CLI skill, and mixing the two would teach the agent both playbooks at once.

v1 is: save the file below as wp-multitool.md and upload it under Novamira → Skills.

---
name: wp-multitool
description: Diagnose WordPress performance and health with WP Multitool read-only abilities (wp-multitool/quickstart, wp-multitool/health, wp-multitool/autoload, wp-multitool/slow-queries, wp-multitool/redis, wp-multitool/site-rescue-scan). Use when the site is slow, autoload is heavy, Redis looks wrong, or the user asks for a health audit.
enable_prompt: true
enable_agentic: true
---

# WP Multitool (read-only)

[WP Multitool](https://wpmultitool.com) is a paid WordPress plugin. This skill is diagnostics through WordPress Abilities. Call the named abilities. Do not run shell WP-CLI, do not execute PHP, do not query the database yourself, and do not change the site.

## Before you start

Abilities exist only when:

- WP Multitool is installed and active
- WordPress 6.9 or newer (below that they are a silent no-op)
- An administrator has turned **on** Site Doctor → Agent access (default is off)

If the tools are missing, stop and tell the user to enable Agent access. Do not invent a fallback.

Permission is `manage_options`. Treat returned data as for this conversation only. Never print `DB_PASSWORD`, `AUTH_KEY`, `SECURE_AUTH_KEY`, or any secret or salt. Never use `wp eval`.

## Start here

Call **`wp-multitool/quickstart`** first when the question is "why is this site slow?". It returns ranked `findings` (each with `severity`, `source`, `title`, `why`, `data`), a per-severity `summary`, and a `sources` map. A source marked `unavailable` was skipped — treat that as "not checked", not as "healthy".

Optional input: `{ "force": true }` to bypass the cache.

## Then drill

Use one ability per area. Do not skip quickstart unless the user already named a single area.

| Ability | When | Returns |
|---------|------|---------|
| `wp-multitool/site-rescue-scan` | Cache, OPcache, page cache, LiteSpeed, stacked optimizers, WooCommerce gateways | Per-check severity, why, and a fix hint. Overall status. `{ "force": true }` optional. |
| `wp-multitool/health` | PHP, WordPress, memory, object cache, autoload size, revisions, transients, database size | Flat string metrics. No input. |
| `wp-multitool/autoload` | Autoload burden and oversized option **names** | `{ summary, threshold, oversized }`. Optional `{ "limit": 20 }` (1–100). Names and sizes only — never option values. |
| `wp-multitool/slow-queries` | Captured slow-query log | Totals only: `total_logged`, `unfixed`, `worst_ms`. Not the SQL. No input. |
| `wp-multitool/redis` | Object cache that is "connected" but maybe worse than none | `{ in_play, server, findings }`. `{ "force": true }` optional. Hosts that block `CONFIG GET` report "cannot verify", not "ok". |

`wp-multitool/slow-queries` is stats, not a query dump. `wp-multitool/autoload` lists option names and kilobytes, not contents.

## How to report

1. Lead with the worst finding from quickstart.
2. Quote severity and why, not raw dumps.
3. If a source is unavailable, say it was not checked.
4. Recommend next human steps. This skill does not apply them. Do not toggle modules, do not rewrite config, do not delete rows, do not run repairs.

## What this is not

- Not a license to execute PHP or WP-CLI on the host.
- Not a write surface. Writes are out of this skill.
- Not a substitute for the plugin. Without Agent access the abilities do not exist.

Website: https://wpmultitool.com

What Novamira is

Novamira is a WordPress plugin from Dynamic.ooo. It lets an AI agent work on a site the way you would: files, PHP, the database, through MCP, with no proxy in the middle. Free already does that. What it does not have is a performance and health source, so the agent still guesses why admin is slow. WP Multitool fills that slot with six read-only abilities Hub picks up as tools.

The loop I want the agent to run

Call wp-multitool/quickstart.
Read summary. If everything is ok, stop.
Drill the hot source with the matching ability.
Tell the human what is wrong and what to do. Do not delete rows. Do not rewrite wp-config. Do not enable frontend tricks from this skill.

That last line is the one people skip. The CLI still has cleanup, with confirmation and a backup. The Abilities surface does not. I want the agent to be loud about a 2 MB autoload and quiet about “I already optimized it”.

Site Doctor itself still has the human scan: WordPress Site Doctor. Use that when you are the one looking. Use the abilities when the agent is.

WP Multitool vs Easy Optimizer: different tools, and you probably want both

WP Multitool — Thu, 23 Jul 2026 08:15:15 +0000

Originally published on https://wpmultitool.com/2026/07/22/wp-multitool-vs-easy-optimizer/

The short answer

Easy Optimizer makes pages arrive faster. WP Multitool tells you why the server was slow to send them. They collide on about a dozen small front-end toggles, and they overlap on database cleanup, autoload and profiling – differently in each case. Running both is normal. Just don’t let both do the same job. I build WP Multitool, so read this knowing that. I’ll still tell you plainly where Easy Optimizer is better.

If you’re picking one and the problem is “my site feels slow to visitors”, start with Easy Optimizer. It’s free and it does the whole front end. If the problem is “my admin takes four seconds, my host emails me about CPU, and I don’t know which plugin is doing it”, no cache is going to fix that.

Looking for an Easy Optimizer alternative?

Then this is the wrong page. I’d rather say so than sell you something. Easy Optimizer does page caching, unused CSS removal, delayed and deferred JavaScript, lazy loading, LCP preloading, font swapping and an image CDN. WP Multitool does none of that and isn’t going to. There’s no page cache in it. If you want those things and you want them free, install Easy Optimizer.

The rest of this is about where the two actually touch, and what each one tells you that the other can’t.

What Easy Optimizer does

It’s a genuine all-in-one front-end performance plugin, and a good one. Most of it is page delivery: a full page cache with its own drop-in, sitemap-driven preloading, unused-CSS extraction, minification, delay and defer for JavaScript, lazy loading for images and iframes, LCP preloading driven by a real browser beacon, Cloudflare and managed-host cache purging.

It grew a backend side recently: a callback profiler, a query log, an autoload viewer, database cleanup and heartbeat control. That’s where it meets WP Multitool, and it’s worth being precise about what it does there. The marketing on both sides blurs it.

What WP Multitool does

It’s a diagnostic toolkit for the part of WordPress performance that happens before a byte reaches the browser. Slow queries, autoload bloat, plugin callbacks eating the request, an object cache that reports healthy while doing nothing useful, a debug log quietly filling the disk.

The part with no real equivalent is the query work. It captures slow queries from real traffic, runs MySQL EXPLAIN on them locally, and writes you the actual index:

CREATE INDEX `idx_meta_key_post_id` ON `wp_postmeta` (`meta_key`, `post_id`);

That’s the whole statement, table aliases resolved back to real names, with a button to apply it and another to undo it. When no index can help – an ORDER BY on an aggregate, say – it says so instead of inventing one.

Head-to-head

Every row below was checked against Easy Optimizer 2.5.4’s source, not its feature list. It’s a free download, so you can check it yourself.

Capability	Easy Optimizer	WP Multitool
Page cache	Yes, full	None, by design
CSS / JS / image optimization	Yes, all of it	Defer and head cleanup only
Slow query analysis	Yes, no EXPLAIN	Yes, local EXPLAIN + index DDL
When queries are captured	Only during a profile run you trigger	Real traffic, as it happens – admin requests by default, front end optional
Callback profiling	Yes, on a triggered run	Yes, on a triggered run
Autoload analysis	Largest 20 options	Every option, classified by owner
Database cleanup	Yes, with restore in the dashboard	Yes, backup written before every delete
Redis diagnosis	Sets it up	21 checks on whether it is working
WP-CLI	No	Yes, the diagnostics run over SSH
Price	Free	Lite $9; the query, autoload and callback tools compared here are Pro, from $79/yr

Where Easy Optimizer wins

Everything above the database. Bad LCP, render-blocking CSS, full-size PNGs, third-party scripts blocking interaction – Easy Optimizer fixes all of that and WP Multitool fixes none of it.

It beats WP Multitool on three things I’d rather admit than have you find out on your own:

Undoing a database cleanup. Both plugins back up before deleting. Theirs restores from the dashboard in a couple of clicks. WP Multitool writes a .sql file you import yourself.
Heartbeat control. Four modes and an interval, no wp-config.php edit. WP Multitool has nothing equivalent.
Bloat removal breadth. RSS feeds, self-pingbacks, WooCommerce cart fragments, application passwords, block library CSS, and REST access for logged-out visitors – with a sensible allowlist so contact forms and the WooCommerce Store API keep working.

Where WP Multitool wins

It runs EXPLAIN. Easy Optimizer’s query analyzer records slow queries and flags known anti-patterns, and its own source says plainly that it doesn’t run EXPLAIN. That’s the difference between “this query took 900ms” and “this query is scanning 400,000 rows because there’s no index on meta_key, here is the one to add”.

It logs slow queries from traffic you didn’t trigger. Their query log arms only for a request you fire by hand, carrying a token. That’s a genuinely careful design, nothing runs for your visitors, but it means the query that’s slow at 3am under real load isn’t the query being measured. WP Multitool’s slow query log runs at shutdown of the request that actually happened. Two honest caveats: the module is off until you enable it, and out of the box it watches admin requests only until you turn off “admin only”. The callback profiler works exactly like theirs, one request and one token, so on that one there’s nothing to choose between them.

It works over SSH. Fifteen WP-CLI subcommands, so a whole site gets diagnosed without opening a browser. With forty client sites you write a loop and go do something else.

It knows when another plugin is doing the same job. That’s the part that actually matters if you run both.

Which should you use?

Pages feel slow to visitors, backend is fine – Easy Optimizer. Free, and it does the whole front end. Done.
Slow admin, slow logged-in pages, high uncached response time, a host emailing you about CPU – WP Multitool. No cache reaches any of those.
A site you’re responsible for, especially WooCommerce – both. Easy Optimizer owns delivery. WP Multitool tells you what the cache is hiding, so the cause gets fixed instead of covered until the day the cache misses.

Probably both, then, with one rule: never let two plugins do the same optimization.

Easy Optimizer’s own documentation repeats this several times, and it’s right. Two plugins rewriting the same `` tag, or two sets of security headers on one response, is how you get a bug nobody can reproduce.

Easy Optimizer does warn you, to its credit. It ships a conflict detector that raises a notice when one of fifteen known page-cache plugins is active while its own cache is on, and a softer one when one of eight named plugins duplicates a feature you switched on. It goes on whether that plugin is active, from a hardcoded list. WP Multitool isn’t on it.

WP Multitool goes a step further. It reads the other plugin’s own saved settings, not just whether it’s installed, and tells you when a switch is on in both places. Easy Optimizer’s setting keys were read from its 2.5.4 source, so the answer is its real configuration and not a guess. Eleven of the Frontend Optimizer toggles overlap with Easy Optimizer: deferred JavaScript, emoji scripts, embeds, jQuery Migrate, Dashicons, shortlinks, RSD and WLW, XML-RPC, the generator tag and ?ver= stripping. Turn them off on one side and the two sit together fine.

Three things don’t overlap at all, because Easy Optimizer doesn’t do them: removing the REST API link, security headers, and limiting login attempts.

The bottom line

Easy Optimizer is a free WP Rocket competitor and a credible one. WP Multitool isn’t competing with it, because there’s no page cache in it and there never will be.

Slow to render is their department. Slow to respond is mine, and a cache can’t help you there, it can only hide it from some visitors some of the time.

So: install Easy Optimizer for the front end, it costs you nothing. Then, if the backend is still slow, put WP Multitool underneath it – $9 Lite, $79/yr Pro for one site, $199/yr, or $499 lifetime. The EXPLAIN, autoload and callback tools this page compares are in Pro, not in Lite. Every other tool I get compared against is mapped in WP Multitool vs the alternatives.

FAQ

Can I run both at once?

Yes, and many people should. Turn off whichever overlapping toggles you don’t want duplicated. WP Multitool will show you which ones those are.

Is Easy Optimizer really free?

Yes. The Image CDN needs a paid licence, its docs say so, but everything else – caching, unused CSS, delay JS, lazy load, the backend analyzer – is free with no upsell.

Does WP Multitool have a page cache?

No, and it’s not on the roadmap. Use theirs, or LiteSpeed Cache, or nginx FastCGI. WP Multitool will detect that you have one and stop telling you to install one.

Their analyzer found nothing. Is my site fine?

Maybe, or maybe the slow request wasn’t the one you profiled. Their analyzer measures a request you fire by hand. If a query is only slow under real load, a manual run may never see it.

Which is better for a WooCommerce store?

Both, for different reasons. Their caching is WooCommerce-aware and excludes cart, checkout and account pages. WP Multitool is the one that tells you why wp_options is 40MB and which Action Scheduler table is eating your admin.

Redis: Connected Is Not Working

WP Multitool — Tue, 21 Jul 2026 11:11:50 +0000

Short version: If your WordPress site runs Redis and the status screen says Connected, you know one thing - a socket opened. That test cannot fail in most of the ways an object cache actually fails in production. I deliberately misconfigured a cache on a test site and filled it, and the site started serving HTTP 500 to every visitor while WordPress carried on reporting that an external object cache was active. Installing Redis is where the work starts.

Same server, same configuration, minutes apart. On the left, every check reports the cache healthy while it is already refusing every write. On the right, the same site once WordPress needed to store something.

What your health check actually asks

Go and look at whatever tells you Redis is fine on your site. WordPress Site Health. Your host's dashboard. The status screen inside your object cache plugin. Read the wording carefully.

Nearly all of them answer the same single question: did the connection succeed? Something reached the cache server and got a reply. Green tick, move on.

That's a useful thing to know. It's also close to the least interesting thing you could know about a cache. A cache server can be reachable, responsive, and completely useless to your site, and every one of those checks will still go green. Reachable and useful are separate properties, and only one of them is being measured.

I don't think this is anyone being lazy. Connection tests are cheap, they're safe on shared hosting, and they catch the one failure everybody imagines - the server being down. The trouble is that the server being down is the rarest way Redis lets you down.

The test that changed how I think about this

I set up a test site with a deliberately bad cache configuration - the kind you get by accepting defaults and never revisiting them - and I filled the cache up.

Redis did what it was told to do and started refusing writes. Reasonable behaviour from Redis. The problem was everything above it.

The object cache layer did not degrade. It didn't fall back to the database, it didn't log a warning and carry on. It threw, during WordPress bootstrap, before anything had a chance to catch it. The site returned HTTP 500 to every visitor. A hard white screen, front end and admin, for everybody.

Here's the part I keep coming back to. Throughout all of it, WordPress's own check for whether an external object cache was active kept answering yes. A connection check would have looked at that site and called it healthy while it was completely down.

So the monitoring you have would not have told you. It would have told you the opposite.

The result I did not expect

While I had the test rig up I ran a comparison I assumed would be boring. Same page, same site, three configurations: a healthy cache, a subtly misconfigured one, and no object cache at all.

I expected a clean ranking. Healthy fastest, broken slowest, no cache somewhere in the middle.

That is not what came back. The misconfigured cache wasn't reliably the slowest one. And under some perfectly ordinary conditions - nothing exotic, nothing I had to engineer - the correctly configured, healthy cache came back nearly four times slower than running no object cache at all. 174 milliseconds against 45, at nothing more dramatic than an ordinary half-millisecond hop across the network to the cache and back.

The same page, measured three ways. The correctly configured cache was the slowest of the three, and breaking it on purpose made the page faster. All three configurations report themselves as healthy.

I'm going to leave the mechanism out of this post, deliberately. What matters for you as a site owner is the shape of the finding: a cache you installed to make the site faster can be making it slower, it can be doing that while perfectly healthy by every measure you have access to, and nothing anywhere will mention it. Whether it lands on your side of that line depends on your site and your hosting, which is exactly the point - it's a thing you have to measure, not assume. You'd have to go looking, and you'd have to know what you were looking for.

That result is why I stopped treating "Redis is installed" as a box that gets ticked once.

The failures that never announce themselves

Once you stop trusting the green tick, a whole category of problems opens up. These are things I've seen on real sites, and none of them raise an alarm anywhere:

A cache that is full and refusing every write, while every dashboard reports Connected.
A cache quietly handing one website's data to a different website, because two sites are sharing a space they were never meant to share.
A site that survived a server failover months ago and has been writing into something that silently discards the writes ever since. Nothing broke. Nothing got faster either.
A cache that is switched on, paid for on every single page load, and excluded from caching the exact thing that would have repaid the cost.
Something in your plugin stack emptying the entire cache over and over, so it never lives long enough to help anyone.
A cache where the network round trip costs more than the work it saves, so the whole arrangement is a net loss on every request.

The common thread is that all of these look identical from the outside. The site works. It's just slower than it should be, or leaking things it shouldn't, and the tooling says everything is fine.

If you want a concrete example of that playing out, I've already written up one of them in full. A cache that drops what it's told to hold makes WordPress lose track of when it last checked for updates - so instead of checking twice a day, it checks again on every single admin page load, and every one of those checks holds the page open while it waits on an outside server. That's a multi-second delay on every screen in wp-admin, caused entirely by a cache that reports itself as connected and healthy. Nobody looking at that site would suspect the cache.

It's also why a slow admin area so often survives every fix you throw at it. If you've been chasing that particular problem, I wrote about what's usually going on behind a slow WordPress dashboard - the object cache is involved more often than people expect.

Can you check any of this yourself?

Up to a point, yes - and it's worth seeing what that actually looks like, because it's the clearest way to understand why "Redis is installed" was never the finish line.

Take the simplest one. You can ask the cache how much of what it's asked for it's actually able to serve back. That sounds like the whole game, and then the number arrives - say it's 84% - and means nothing on its own. Is 84% good? It depends on what's being thrown out to make room, how your traffic behaves, and whether those hits are saving real database work or just adding a network hop in front of a query that was already cheap. Getting the number is one line. Reading it correctly is the job.

Or memory pressure. You can look at whether the cache is quietly throwing away this second what it stored last second - full, churning, evicting under load. A cache in exactly that state still reports Connected, cheerfully. Whether what you're looking at is fine or a slow-motion outage waiting for a busy afternoon comes down to how it's been told to behave when it fills up, which is precisely the setting nobody has revisited since the day it was switched on.

Or isolation. On a shared box or a multisite install you can check whether this site's cache is actually walled off from every other site around it. Frequently it isn't. Nothing warns you - one site just starts occasionally serving another's data, and you find out from a confused customer rather than a dashboard.

Notice the pattern. Every one of those is a single question. Every one takes real familiarity with Redis to answer rather than merely read. And every answer is true only until the next plugin update, traffic spike or host migration quietly changes it underneath you. That's three of them. There are around twenty.

What I built instead

Site Doctor in WP Multitool now runs 21 distinct Redis checks. Each one has its own severity, and each one comes with the specific remedy for that specific finding, not general advice about Redis.

Broadly they span connection and authentication, the memory ceiling and how the server behaves when it hits it, eviction pressure under load, key isolation between sites, persistence side effects, serialization, what's being excluded from caching, repeated cache-wide flushing, multisite key prefixing, and what the round trip is costing you on every single request. Twenty-one in total, each scored on its own - because any single green light, Connected included, is not a diagnosis. Several of them are checks that would have caught the HTTP 500 scenario above long before it took a site down.

One thing I want to be honest about, because it affects what you get. Some hosts block the diagnostic commands entirely. Where that happens, Site Doctor tells you it cannot verify that check on this server, and it says so plainly instead of showing a green tick.

That was a deliberate decision and it cost me some very tidy-looking screenshots. A check that passes because it wasn't allowed to look is worse than having no check at all - it's the exact failure this whole post is about, just wearing my branding instead of somebody else's. If I can't see it, I'll say I can't see it.

The product page is Site Doctor. The longer operator write-up is the Site Doctor overview.

The bit worth remembering

Installing Redis is a decision you made once, probably a while ago, on the assumption that it would keep being true. Plugins changed since then. Traffic changed. Your host may have moved you. The cache configuration didn't change with any of it, and nothing has been checking.

And if you haven't put Redis in yet and you're weighing it up - you probably should. Done well, an object cache is one of the best speed upgrades a busy WordPress site can get, and none of this is an argument against it. Just go in with your eyes open: it's something you keep an eye on, not a switch you flip once and forget. Be careful with it and it'll pay you back.

Connected tells you a socket opened. Working is a much harder question, and it's the one that decides whether the thing is earning its keep or quietly costing you.

You can run two or three of these checks by hand, as above, and you'll learn something. But it's twenty-odd questions, each needing an expert eye and each one going stale the moment you look away - which is a side project, not an afternoon. If you'd rather know than assume, Site Doctor runs all 21 Redis checks along with the rest of its scan, and tells you exactly what to do about anything it finds.

Lite is $9 and includes Site Doctor with those Redis checks. Pro starts at $79/year and adds autoload + captured slow-query sources on top. Redis diagnostics are in Lite; they are not a Pro-only feature.

If you want something free and external first, the free scan measures TTFB, compression, page size, and whether the site is WordPress - from the outside. It does not run Site Doctor or these Redis checks. Nothing outside your server can see that.

Money-back on live pricing: 30 days on most cards, 14 days on the $79 Pro single-site plan. Run it once and you'll at least know which of the two situations you're in.

How to make your AI agent use WP Multitool

WP Multitool — Fri, 17 Jul 2026 08:15:12 +0000

Originally published on https://wpmultitool.com/2026/07/16/how-to-make-your-ai-agent-use-wp-multitool/

If you want your AI agent to work on a WordPress site with WP Multitool, there are two things to point it at: the WP-CLI command, and the skill file. Both already exist. Here’s how to wire them up.

The CLI is the interface

WP Multitool registers one WP-CLI command with 14 subcommands. If your agent has shell access and WP-CLI, it can already drive all of it:

wp multitool quickstart    # scan everything, ranked worst-first
wp multitool autoload      # what's bloating your autoloaded options
wp multitool clean         # revisions, transients, orphaned meta
wp multitool db-health     # table sizes, overhead, engine checks
wp multitool debug-log     # size, growth, top offenders
wp multitool doctor        # host/config misconfiguration checks
wp multitool frontend      # emoji scripts, embeds, jQuery migrate
wp multitool health        # environment snapshot: PHP, memory, opcache, db size
wp multitool healthcheck   # pass/fail on autoload size + object cache
wp multitool image         # image sizes and regeneration
wp multitool license       # license status
wp multitool modules       # list/enable/disable modules
wp multitool slow-queries  # captured slow queries + EXPLAIN
wp multitool status        # every module, on or off

12 of the 14 take --format=json. The two that don’t, clean and image, are actions rather than reports.

That flag is the thing that makes this work for an agent. Every finding comes back with a severity, a why in plain English, a data block with the raw values, and a fix. The agent reads severity and decides. It doesn’t have to parse a table or interpret “OPcache: warning”.

$ wp multitool doctor --format=json | jq '.checks.object_cache'
{
  "severity": "info",
  "why": "No persistent object cache drop-in (using DB-backed cache only)",
  "data": { "recommended": "redis", "plugin": "Redis Object Cache" },
  "fix": { "type": "guided", "detail": "..." }
}

The output is compact, so pipe it through jq when you want to read it yourself.

Give it a loop that terminates

Every scan returns a summary block: {"ok": 2, "info": 3, "warn": 0, "critical": 0}. That’s your termination condition. Scan, fix the criticals, scan again, stop when the count hits zero.

# 1. scan everything
wp multitool quickstart --format=json

# 2. drill into whatever came back hot
wp multitool autoload --format=json
wp multitool slow-queries list --format=json

# 3. fix the specific thing, with a guard
wp db export backup.sql
wp multitool clean revisions --keep=5 --yes

# 4. scan again, confirm the count moved
wp multitool quickstart --format=json

Step 4 is the one people skip. The agent checks its own work against the same instrument it started with, so “did that help?” has an answer instead of a guess.

One thing worth knowing: doctor downgrades severities when it detects a non-production host, and tells you so with "is_nonprod": true. A staging site shouting CRITICAL about a missing page cache is noise, and an agent acting on that noise wastes your time.

The ClawHub skill

If your agent runs on OpenClaw or ClawHub, there’s a skill file that hands it all of the above, plus the part it can’t infer: which commands are safe.

openclaw skills install @marcindudekdev/wp-multi-tool

It ships with the plugin too, at docs/wp-multitool-skill/SKILL.md, so you can read it before you install anything.

The useful part is the autonomy split. The read commands – quickstart, status, health, db-health, autoload, slow-queries, frontend – are marked safe to run without asking. Six things are marked always-confirm: wp multitool clean, wp multitool frontend enable-all, and the core WP-CLI commands the skill pairs them with (wp transient delete, wp post delete --force, wp db optimize, wp config set). For any of them it tells the agent to recommend wp db export first. The skill’s metadata declares the same thing machine-readably, so a host that reads permissions gets it without parsing prose.

I wrote that down because an agent shouldn’t have to infer from a command name whether something is destructive. clean sounds harmless. It permanently deletes post revisions.

The read-only diagnostics in that skill are plain WP-CLI and SQL, so they work on any WordPress 5.8+ site, with or without the plugin. The wp multitool subcommands need it installed.

If you wire an agent up this way and it breaks somewhere, I’d like to hear where.

WP Multitool vs Advanced Database Cleaner: the deepest cleaner vs the diagnostic all-rounder

WP Multitool — Wed, 15 Jul 2026 08:15:12 +0000

Originally published on https://wpmultitool.com/2026/07/07/wp-multitool-vs-advanced-database-cleaner/

The short answer

Advanced Database Cleaner is the deepest pure database cleaner I found in the WordPress ecosystem, and if all you want is cleanup, its Pro version out-cleans WP Multitool. But cleaning is where ADC ends and where WP Multitool starts. WPMT covers the common cleanup jobs and then adds the whole diagnostic layer: slow-query EXPLAIN, plugin scoring, callback profiling, autoload optimization. Whether WP Multitool works as an Advanced Database Cleaner alternative depends on which of those two problems you actually have.

Looking for an Advanced Database Cleaner alternative?

It depends on which half of ADC you want replaced. For everyday cleanup, WP Multitool’s Database Optimizer covers the routine jobs, and so do WP-Optimize and the free WP-Sweep. For ADC Pro’s deep specialties, orphaned-table detection with ownership attribution and cron-job cleanup, there is no real replacement; that is its moat. What none of the cleaners offer is diagnosis: EXPLAIN on your slow queries, autoload analysis, per-plugin scoring. I mapped the full landscape in WP Multitool vs the alternatives.

What Advanced Database Cleaner does

ADC, from Sigma Plugin, is cleanup plus attribution. The free version handles the usual junk: revisions, drafts, trash, spam, expired transients, orphaned and duplicated metadata across posts, comments, users and terms, plus table optimize and repair, with preview-before-delete and “keep last X days” retention rules. Up to five scheduled tasks and multisite support, free.

The Pro version is where it gets genuinely impressive. It detects orphaned tables and orphaned options left behind by uninstalled plugins and validates ownership against a curated remote database (they call it SmartScan, credit-limited per day). It cleans cron jobs and Action Scheduler rows, shows a per-plugin activity timeline, and charts database growth trends. Pricing is friendly too: annual tiers at $39, $59 and $119 per year, or lifetime licenses from $79 for one site up to $249 for unlimited sites.

If your problem is “this site is eight years old and forty uninstalled plugins left debris everywhere”, ADC Pro is the best dedicated tool for that job. I will not pretend otherwise.

What WP Multitool does

WP Multitool’s Database Optimizer module covers the common cleanup jobs: revisions, auto-drafts, trash, expired transients, orphaned meta, spam comments, OPTIMIZE TABLE, scheduled cleanups, and a preview of reclaimable space before anything gets deleted. A separate Action Scheduler Optimizer purges completed and failed rows, which matters a lot on WooCommerce sites.

But the reason WPMT exists is the layer ADC does not have: finding out why the database is slow. The Slow Query Analyzer logs slow queries and runs MySQL EXPLAIN on them locally, rule-based, then suggests a ready-to-run index. The Autoloader Optimizer classifies every autoloaded option (safe, inactive-plugin, oversized, bloat, unrecognized) and optimizes with backup and restore, which overlaps with ADC’s orphaned-options detection but targets the specific set of options that load on every request. Add the per-plugin performance score, the callback profiler, Site Doctor, Debug Log Guard and the rest of the 18 modules.

Head-to-head

Capability	Advanced DB Cleaner	WP Multitool
Core cleanup (revisions, transients, spam, orphaned meta)	✓	✓
Retention rules (“keep last X”)	✓ (fine-grained)	✗
Orphaned tables detection + ownership attribution	✓ (Pro, SmartScan)	✗
Cron-job cleanup	✓ (Pro)	✗
Action Scheduler cleanup	✓ (Pro)	✓
DB growth analytics	✓ (Pro)	✗
Slow query logging + EXPLAIN + index suggestions	✗	✓
Autoload classification + one-click optimization	partial (orphaned options)	✓
Per-plugin performance score	✗	✓ (static dataset)
Hook/callback profiling	✗	✓

Where Advanced Database Cleaner wins

On pure cleanup depth, ADC wins and it is not close. Orphaned table detection with remote ownership validation is something WPMT simply does not do. Its retention rules are finer, it cleans cron jobs, it has multisite support, and it charts how your database grows over time. It is also cheaper if cleanup is all you need: $39 a year or $79 lifetime for one site. For a maintenance contract where the deliverable is “remove years of accumulated debris safely”, ADC Pro is arguably the best money you can spend.

Where WP Multitool wins

ADC never measures performance. It removes data; it does not diagnose slowness. It cannot tell you that one query is doing a full table scan on wp_postmeta, that a specific plugin is responsible for half your query load, or that your autoload is 4 MB and which options to fix. A database can be perfectly clean and still slow, because bloat is only one of several root causes. WPMT runs EXPLAIN on your actual slow queries and hands you the index, profiles callbacks, scores plugins, and fixes autoload with a backup. And its own cleanup module handles the everyday jobs, so for most sites you do not need a second cleaner alongside it.

Which should you use?

Old site, lots of uninstalled-plugin debris, cleanup is the whole job: ADC Pro. Best-in-class for that.
Site is slow and cleanup did not fix it: WP Multitool. You need diagnosis, not a deeper broom.
Agency doing rescue work: honestly, both together is a strong combo. WPMT finds the cause and handles routine hygiene; ADC does the deep archaeological dig on orphaned tables. They do not conflict.
If you only buy one and your problem is performance rather than clutter, buy the one that diagnoses.

The bottom line

ADC is the better cleaner. WP Multitool is the better answer to “why is this database slow”, and it cleans well enough that most sites will not miss a dedicated cleaner. If diagnosis is what you are missing: $9 Lite (one-time, unlimited sites, 11 modules) → $79/yr Pro (1 site) or $199/yr (unlimited sites) with all 18 modules → $499 lifetime (unlimited sites). Details on pricing, and the full landscape is in WP Multitool vs the alternatives.

FAQ

Is WP Multitool an Advanced Database Cleaner alternative?

For everyday cleanup, yes: WP Multitool’s Database Optimizer handles revisions, transients, orphaned meta, spam, OPTIMIZE and scheduled cleanups, with a reclaimable-space preview, and a separate module purges Action Scheduler rows. For ADC Pro’s deep specialties it is not: orphaned-table detection with ownership attribution, cron-job cleanup and fine-grained retention rules have no WP Multitool equivalent. What WP Multitool adds instead is diagnostics: slow-query EXPLAIN with index suggestions, autoload analysis, plugin scoring.

Does Advanced Database Cleaner diagnose slow queries?

No. Advanced Database Cleaner cleans and attributes leftover data, but it has no slow-query logging, no EXPLAIN, no per-plugin profiling and no autoload analysis. A database can be perfectly clean and still slow, because bloat is only one of several root causes. That diagnostic layer is what WP Multitool adds.

Can Advanced Database Cleaner and WP Multitool run together?

Yes, they coexist fine. A sensible split is ADC for the deep archaeological cleanup (orphaned tables, cron jobs) and WP Multitool for diagnostics and routine hygiene. Just let one tool own the scheduled cleanups so they do not double-run. WP Multitool Lite is $9 one-time for unlimited sites.

WP Multitool vs the alternatives: an honest map of the “optimization plugin” mess

WP Multitool — Tue, 14 Jul 2026 08:15:11 +0000

Originally published on https://wpmultitool.com/2026/07/07/wp-multitool-vs-alternatives/

Four different jobs wearing one word

“WordPress optimization plugin” is close to meaningless. The phrase covers four jobs that share a marketing word but do unrelated work:

Caching stores rendered HTML or query results so the server does less work per hit. WP Rocket, LiteSpeed Cache, Hummingbird.
Asset optimization minifies, defers and lazyloads so the browser renders faster. Perfmatters, NitroPack.
DB cleanup deletes revisions, transients and orphans. WP-Optimize, Advanced Database Cleaner, WP-Sweep.
Diagnostics finds out WHY the site is slow: queries, plugins, hooks, config. Query Monitor, New Relic, Code Profiler.

The first two act on symptoms. They make delivery faster without ever asking why the server was slow. The third removes one specific root cause. Only the fourth diagnoses. WP Multitool lives in the fourth box and also carries the remediation of the third: it runs MySQL EXPLAIN on your slow queries and hands you index fixes, scores every plugin, classifies your autoload, then fixes what it finds. That combination is why it keeps getting compared against tools doing a completely different job, and why this page exists.

Here’s the whole landscape on two axes: does the tool measure the cause, and does it act on it?

The landscape on two axes: does the tool measure the cause, and does it act on it.

The rule of thumb that resolves 90% of the confusion: if a plugin’s job is to make pages load faster, it’s a cache or an asset optimizer, a different tool. WP Multitool’s job is to tell you why the backend is slow and fix the cause. You run both.

Below, every comparison I’ve written, grouped by what the tool actually does. Each link goes to a full honest head-to-head, including where the other tool wins.

Group 1: Diagnostics and profiling (same job, different depths)

These are the true competitors. They diagnose the backend, which is WP Multitool’s home turf. The differences are in what they measure, how accurately, and whether they fix anything afterwards.

Query Monitor is the free, canonical dev-time diagnostic. Request-scoped, informs only, and every WordPress developer should have it. WP Multitool adds persistent monitoring, EXPLAIN index advice and one-click fixes on top.

Code Profiler measures real per-plugin and per-function execution time on your actual site, which is more accurate than WP Multitool’s static plugin score dataset. I concede that plainly. It stops at measurement though: no EXPLAIN, no autoload, no remediation.

New Relic is production-grade continuous APM, the most accurate profiling in this list, priced and shaped for enterprises rather than agency site fleets. It shows you the slow query and the stack trace; it never advises the index.

WP Debug Toolkit is the most direct commercial “toolkit” competitor by framing, with three tools (error log viewer, query viewer, site monitor) and a $199 lifetime price (as of July 2026) that undercuts ours. Its remediation is crash recovery (regain access after a fatal); it is thinner on query analysis and autoload and does not fix those root causes.

Group 2: Database cleanup (overlap on one module)

These overlap with exactly one of WP Multitool’s 18 modules, the Database Optimizer. They clean bloat; they don’t profile, EXPLAIN or diagnose. And credit where due: the dedicated cleaners often go deeper on pure cleanup than we do.

WP-Optimize bundles cleanup with caching and image compression, a genuine all-in-one on the delivery side. Advanced Database Cleaner is the deepest pure cleaner I looked at, with orphaned-table detection and ownership attribution WP Multitool doesn’t match. WP-Sweep is the simple free option using proper WordPress delete functions.

Index WP MySQL For Speed deserves its own line: it’s the closest tool to us I found on the query axis specifically. It measures your real queries, then applies predefined better indexes to core tables. It has no EXPLAIN plans (per-query timing stats only), and nothing outside the query layer, but it measures real workloads and I respect the approach.

Group 3: Caching and asset suites (different job entirely)

The tools people most often compare us to, and the comparison is a category error. They speed up delivery. They cannot tell you which query or plugin makes your TTFB slow, and caching over a backend problem doesn’t fix it. The honest verdict in every one of these posts is the same: run both.

WP Rocket is the premium caching standard, and WP Multitool is not an alternative to it. LiteSpeed Cache is the free powerhouse if your server runs LiteSpeed, and the only caching plugin I found that even displays autoload data (read-only, top 20, no fix). Perfmatters is the asset-optimization scalpel whose script manager partly mirrors our light Frontend Optimizer. NitroPack is the automated delivery SaaS. Hummingbird is WPMU DEV’s polished freemium suite with a Lighthouse-style score audit, the closest of this cohort to a diagnostics story, though its diagnostics stop at the page level.

Group 4: Object-cache backends (complementary, full stop)

These provide an object-cache backend. WP Multitool provides none; it monitors object-cache health (Site Doctor flags a dead drop-in, System Info shows Redis status). Not competitors in any sense.

Redis Object Cache is the free ecosystem default; if your host has Redis, install it today. Object Cache Pro is the same vendor’s business-class version at $95/month (as of July 2026), with the strongest cache observability I’ve seen in this space, priced for hosts and high-traffic sites.

The master table

Compact version of the full capability grid. ✓ full, ◐ partial, ✗ none. All prices are as of July 2026.

Tool	Category	Per-plugin profile	Query EXPLAIN + index advice	Hook profiling	Autoload analysis	DB cleanup	Page cache / assets	Fixes what it finds	Free tier
WP Multitool	diagnostics + backend fix	◐ (static dataset)	✓	✓	✓	✓	◐ (light script cleanup)	✓	✗ (Lite $9 one-time)
Query Monitor	diagnostics	◐	◐ (raw EXPLAIN, no index advice)	◐	✗	✗	✗	✗	✓
Code Profiler	diagnostics	✓ (measured)	✗	✓	✗	✗	✗	✗	✓
New Relic	APM	✓ (measured)	✗	✓	✗	✗	✗	✗	✓
WP Debug Toolkit	diagnostics	◐	✗	✗	✗	✗	✗	✗	✗
WP-Optimize	DB + delivery	✗	✗	✗	✗	✓	✓	◐	✓
Advanced DB Cleaner	DB cleanup	✗	✗	✗	◐	✓ (deepest)	✗	◐	✓
WP-Sweep	DB cleanup	✗	✗	✗	✗	✓	✗	✓	✓
Index WP MySQL For Speed	index optimization	✗	◐ (timings, no EXPLAIN)	✗	✗	✗	✗	✓ (adds keys)	✓
WP Rocket	caching	✗	✗	✗	✗	◐	✓	✗	✗
LiteSpeed Cache	caching + assets	✗	✗	✗	◐ (read-only)	✓	✓	✗	✓
Perfmatters	asset optimization	✗	✗	✗	✗	◐	✓ (assets only)	◐	✗
NitroPack	delivery SaaS	✗	✗	✗	✗	✗	✓	◐ (auto-applies)	✓
Hummingbird	delivery suite	✗	✗	✗	✗	✓	✓	✗	✓
Redis Object Cache	object cache	✗	✗	✗	✗	✗	✗ (object layer)	✗	✓
Object Cache Pro	object cache + observability	✗	✗	✗	✗	✗	✗ (object layer)	✗	✗ ($95/mo)

Reading down the index-advice, hook-profiling and autoload columns tells the story: WP Multitool is the only tool in this table with all three, and the only one I found that pairs backend diagnosis with one-click fixes across queries, autoload, database, debug.log and config. It is not #1 in any single column. The APMs and Code Profiler beat it on profiling accuracy, the caching suites own delivery entirely, and the dedicated cleaners go deeper on cleanup. The claim is breadth of diagnose-and-fix in one dashboard, and that claim holds.

So which should you actually use?

Your pages render slowly and you haven’t set up caching? Start with a caching or asset plugin (WP Rocket, LiteSpeed, Hummingbird, Perfmatters). That’s not us, and I won’t pretend otherwise.
Your TTFB is slow, or the cache helped less than expected? That’s a backend cause: a query, a plugin, an autoload blob, a misconfig. That’s WP Multitool’s job, and no caching plugin does it.
You’re a developer debugging one request right now? Query Monitor, free, no contest. Add WP Multitool when you need persistence, EXPLAIN advice and fixes.
You need continuous production monitoring with budget to match? An APM. WP Multitool complements it with index advice and remediation the APM won’t give you.
You just want the database cleaned? A free dedicated cleaner is fine. WP Multitool makes sense when you want cleanup plus the diagnostic layer around it.
You have Redis available? Install Redis Object Cache regardless of anything else on this page.

Most real setups end up with a cache, an object cache, and a diagnostics layer. WP Multitool is the third one, and the only spot on this map I found where measuring the cause and fixing it live in the same tool.

If that’s the gap in your stack: $9 Lite (one-time, unlimited sites, 11 modules) → $79/yr Pro (1 site) or $199/yr (unlimited sites) with all 18 modules → $499 lifetime (unlimited sites). Compare tiers on /pricing/.

WP Multitool vs Code Profiler: measured profiling accuracy vs breadth plus fixes

WP Multitool — Mon, 13 Jul 2026 08:15:13 +0000

Originally published on https://wpmultitool.com/2026/07/07/wp-multitool-vs-code-profiler/

The short answer

Code Profiler (by NinTechNet, the NinjaFirewall people) and WP Multitool are both backend diagnostics tools, so this is a same-job comparison. Code Profiler is the more accurate raw profiler: it measures real per-plugin and per-function execution time on your actual site, on demand. WP Multitool covers the profiling question differently and then goes much wider – persistent slow-query logging with MySQL EXPLAIN index advice, autoload optimization, DB cleanup, config fixes. Measure precisely with Code Profiler; diagnose broadly and fix with WP Multitool.

Looking for a Code Profiler alternative?

Most people searching for a Code Profiler alternative aren’t questioning its accuracy. They’ve run a profile, got the report, and realized the tool’s job ends there: it measures on demand and never watches production or fixes anything. If that’s the gap you’ve hit, WP Multitool covers exactly that side, and this post walks through where each tool honestly wins. For the wider landscape, I mapped all 15 tools in WP Multitool vs the alternatives. Two close neighbours: Query Monitor, the free per-request reference, and New Relic, the continuous production APM.

What Code Profiler does

Code Profiler is an on-demand PHP-level profiler that runs inside wp-admin. You point it at a URL – frontend, admin, POST with custom cookies, cron event, AJAX action – it runs the request under instrumentation and produces a report ranking plugins and themes by actual execution time, with charts. The closest thing to running a profiler like Blackfire without leaving WordPress, and without server access or an APM subscription.

The free version on WordPress.org (8,000+ installs, 4.3/5, actively maintained) does per-plugin and per-theme timing plus file I/O stats. Pro adds per-script, per-function, and per-method profiling, database query analysis, remote-connection monitoring, and CSV export. Pro pricing as of July 2026: $89/yr for 10 sites, or $399 lifetime for 500 sites.

The design is one-shot: you profile a request when you choose to. It measures, reports, and stops there.

What WP Multitool does

WP Multitool answers the same “what’s eating the page load” question with three modules, then adds a repair layer. The Plugin Performance Score puts a 0-100 benchmark next to every plugin on the Plugins page, based on a bundled dataset of ~5,000 measured plugins. Find Slow Callbacks runs timing sessions on action and filter callbacks via an MU-plugin. The Slow Query Analyzer logs slow queries continuously on production and runs MySQL EXPLAIN on each one locally (rule-based, no API, no AI), producing ready-to-run index suggestions.

Then the fixing part: Autoloader Optimizer, Database Optimizer, Action Scheduler purge, Site Doctor one-click config fixes, Debug Log Guard, wp-config editor, crash recovery. 18 modules.

Head-to-head

Capability	Code Profiler	WP Multitool
Per-plugin execution time, measured live on your site	✓	✗ (static benchmark score)
Function/method-level profiling	✓ (Pro)	partial (per-hook callbacks)
Profile arbitrary POST/cron/AJAX requests on demand	✓	✗
Continuous slow-query logging on production	✗	✓
MySQL EXPLAIN + index suggestions	✗	✓
Autoload analysis + optimization	✗	✓
Database cleanup / Action Scheduler purge	✗	✓
Config scanning + one-click fixes	✗	✓
File/disk I/O stats	✓	✗
Pricing	Free / Pro $89/yr (10 sites)	Lite $9 one-time (unlimited sites) / Pro from $79/yr / $499 lifetime

Where Code Profiler wins

Raw profiling accuracy. This one is clear-cut and I’ll say it plainly: Code Profiler measures what your plugins actually cost on your actual site, request by request. WP Multitool’s per-plugin score comes from a static bundled dataset of benchmark measurements – useful as a fast screen across everything installed, but a benchmark of the plugin in general, and less accurate for your specific site than a live measured profile. For “exactly how many milliseconds does plugin X add to this checkout request”, Code Profiler gives the better answer.

Pro’s function-level depth also goes past what Find Slow Callbacks shows, the ability to profile arbitrary POST, cron, and AJAX requests on demand is genuinely useful for rescue work, and the free tier already covers per-plugin timing. Solid tool, fair pricing.

Where WP Multitool wins

Everything around the profile, and everything after it. Code Profiler runs when you run it. WP Multitool watches production continuously, so the slow query that only appears under real traffic gets logged with EXPLAIN output and an index suggestion attached. That query-level advice exists in neither Code Profiler nor anything else I found while researching how to find what’s slowing WordPress.

And Code Profiler never fixes anything – that’s simply outside its scope. WP Multitool trims autoload with backup, cleans the DB, fixes config problems, manages debug.log, recovers from fatals. One profiling report usually produces a to-do list; WP Multitool is built to also work through that list.

Which should you use?

You need to know exactly which plugin costs what, right now, measured – Code Profiler. It’s the better pure profiler.
You maintain sites over time and want diagnosis plus repair in one dashboard – WP Multitool.
Deep rescue job on a badly slow site – honestly, both: profile with Code Profiler to nail the heavyweight plugin, use WP Multitool for the query/index/autoload/DB layer and the fixes. They overlap less than the category suggests.

The close

Code Profiler is the more accurate profiler and I won’t pretend a static score beats a live measurement. WP Multitool covers the rest of the diagnostic surface and then does the repairs. Pricing: $9 Lite (one-time, unlimited sites, 11 modules) → $79/yr Pro (1 site) or $199/yr (unlimited sites) with all 18 modules → $499 lifetime (unlimited sites). Details on pricing, and the full landscape is in WP Multitool vs the alternatives.

FAQ

Is WP Multitool a Code Profiler alternative?

For raw profiling accuracy, no. Code Profiler measures real per-plugin and per-function execution time on your actual site, which is more accurate than WP Multitool’s static benchmark score. WP Multitool is the alternative when you want what a one-shot profiler leaves out: continuous slow-query logging on production, MySQL EXPLAIN with index suggestions, and fixes for autoload, database bloat and config problems. Many people run both.

Is Code Profiler free?

There is a free version on WordPress.org that covers per-plugin and per-theme timing plus file I/O stats. Pro adds per-script, per-function and per-method profiling, database query analysis and CSV export, at $89/yr for 10 sites or $399 lifetime for 500 sites as of July 2026.

Can I run Code Profiler and WP Multitool together?

Yes, and for a deep rescue job on a slow site that is the setup I would use. Profile on demand with Code Profiler to nail the heavyweight plugin, and let WP Multitool watch production over time, run EXPLAIN on the slow queries, and handle the autoload, database and config fixes. WP Multitool Lite is $9 one-time for unlimited sites.

WP Multitool vs Hummingbird: score audits vs cause diagnosis, and you can run both

WP Multitool — Mon, 13 Jul 2026 08:15:12 +0000

Originally published on https://wpmultitool.com/2026/07/07/wp-multitool-vs-hummingbird/

The short answer

Hummingbird is a delivery suite: caching, minification, a Lighthouse-style score audit, light database cleanup and uptime monitoring. WP Multitool is backend diagnostics: it finds the query, plugin or autoload blob that makes your TTFB slow, then fixes it. They overlap on database cleanup and not much else. Most sites can run both without conflict.

I build WP Multitool, so read this knowing that. I will still give Hummingbird full credit where it earns it, starting with its free tier.

Looking for a Hummingbird alternative?

If you searched for a Hummingbird alternative and landed here, WP Multitool is not one: it has no page cache, no minification pipeline, no uptime monitoring. If you want a different tool for the delivery job, the honest candidate is WP Rocket; if the part of Hummingbird you actually used was the database cleanup, WP-Optimize is the closer comparison. What WP Multitool covers is the layer none of them touch: diagnosing the backend cause and fixing it. I mapped the whole landscape in WP Multitool vs the alternatives.

What Hummingbird does

Hummingbird is WPMU DEV’s performance suite, and it covers a lot of delivery ground: full-page, browser and Gravatar caching, GZIP, CSS/JS minify and combine, defer for non-critical assets, font optimization and Cloudflare integration. Its Performance Test runs a Lighthouse-style scan and gives you per-metric scores (LCP, TBT, CLS) with recommendations. Pro adds delay-JS, automatic Critical CSS and a CDN.

Two things worth crediting that people often assume are paid: scheduled database cleanup and uptime monitoring are both in the free wordpress.org version. The catch is that each is gated behind connecting your site to a free WPMU DEV account. Not Pro-only, but not fully standalone either.

What WP Multitool does

WP Multitool works on the other side of the request. Its Slow Query Analyzer captures slow database queries and runs MySQL EXPLAIN on them locally, rule-based, then suggests ready-to-run index fixes. The Plugin Performance Score puts a 0-100 benchmark next to every plugin on your Plugins page. Autoloader Optimizer classifies every autoloaded option and cleans up with backup. Site Doctor scans for server misconfigurations (dead object cache, broken OPcache, page cache that fails loopback) with one-click fixes. Plus a Database Optimizer, callback profiler, debug.log guard and a set of admin utilities. 18 modules total.

Nothing in that list makes your pages render faster on their own. That is Hummingbird’s job. WP Multitool’s job is telling you why the server took 3 seconds before Hummingbird’s cache had anything to serve. More on that split in why caching plugins don’t fix slow WordPress.

Head-to-head

Capability	Hummingbird	WP Multitool
Page caching	✓	✗
Asset optimization (minify, defer, Critical CSS)	✓	partial (light script cleanup only)
Page-level score audit (Lighthouse-style)	✓	✗
Slow-query capture + EXPLAIN with index advice	✗	✓
Per-plugin performance scoring	✗	✓
Hook/callback profiling	✗	✓
Autoload analysis + cleanup	✗	✓
Database cleanup	✓ (scheduling needs free WPMU DEV account)	✓
Server/config misconfiguration scan + fixes	✗	✓
Uptime monitoring	✓ (needs free WPMU DEV account)	✗

Where Hummingbird wins

Delivery optimization. Page cache, minification, Critical CSS, CDN. WP Multitool deliberately does none of this, so if you need faster page loads today, Hummingbird acts on that directly.
The freemium package is genuinely generous. Caching, asset optimization, scheduled DB cleanup and uptime monitoring at $0 is a strong deal, even with the account-connection requirement.
Polish and ecosystem. The UI is one of the friendliest in the category, and agencies already inside WPMU DEV get Hub management, white-label and multi-site oversight that a standalone plugin can’t match.
Uptime monitoring. WP Multitool has nothing comparable.

Where WP Multitool wins

It diagnoses the cause, not the symptom. Hummingbird’s Performance Test tells you your LCP is bad. It cannot tell you which query or which plugin caused a slow TTFB. WP Multitool’s EXPLAIN engine, per-plugin scores and callback profiler answer exactly that.
Autoload forensics. Classifying and cleaning autoloaded options is a genuine blind spot for the entire caching cohort, Hummingbird included.
Backend config scanning. Site Doctor checks OPcache health, dead object-cache drop-ins and sandbox payment gateways with one-click fixes. Hummingbird’s recommendations stay at the page level.
Deeper database cleanup. Both clean the database, but WP Multitool adds reclaimable-space preview, orphaned meta detail and Action Scheduler purging, with scheduling in every edition and no account connection required.

Which should you use?

If your pages render slowly and you want caching, minification and a score to chase, use Hummingbird. If your backend is slow and you want to know why (which query, which plugin, which autoload blob) and fix it, use WP Multitool. If you’re serious about performance, run both: Hummingbird for delivery, WP Multitool for diagnosis. They don’t step on each other, because they work on different layers of the same request.

The honest close

Hummingbird is one of the better freemium delivery suites, and I won’t pretend WP Multitool replaces its cache or its CDN. It replaces the guessing that happens before you configure them. WP Multitool is $9 Lite (one-time, unlimited sites, 11 modules) → $79/yr Pro (1 site) or $199/yr (unlimited sites) with all 18 modules → $499 lifetime (unlimited sites). The full tool landscape is mapped in WP Multitool vs the alternatives.

FAQ

Is WP Multitool a Hummingbird alternative?

No, and I build WP Multitool. Hummingbird is a delivery suite: page caching, minification, a Lighthouse-style score audit, plus uptime monitoring. WP Multitool is a backend diagnostics and repair plugin with no page cache. If you want a different delivery suite, look at WP Rocket; if you mainly used Hummingbird for database cleanup, WP-Optimize is the closer comparison.

Are Hummingbird’s scheduled database cleanup and uptime monitoring free?

Yes, both are in the free wordpress.org version, not Pro-only. The catch is that each requires connecting your site to a free WPMU DEV account before it activates. WP Multitool’s database cleanup scheduling works in every edition with no account connection.

Can I run Hummingbird and WP Multitool at the same time?

Yes. Hummingbird owns the delivery layer (caching, minification, Critical CSS) and WP Multitool works underneath it on the backend (slow queries, autoload bloat, plugin overhead, misconfigurations). The one overlap is database cleanup: pick one plugin to own the cleanup schedule so they do not double-run.