DEV Community: WP Multitool

Which of Your Plugins Is the Heaviest? Now You Can See It on the Plugins Page.

WP Multitool — Thu, 18 Jun 2026 08:15:11 +0000

Originally published on https://wpmultitool.com/2026/04/08/plugin-performance-score/

New in WP Multitool 1.1.19 – Plugin Performance Score is the newest module in WP Multitool. It adds real benchmark data to your WordPress Plugins page so you can see exactly which plugins are the heaviest. Here’s what it does and why it matters.

Every WordPress developer has had this moment

The site is slow, you open Query Monitor, and you see 180 database queries. But which plugin is responsible for most of them?

Query Monitor tells you what happened during a single page load. It’s a debugger – and QM4 just made that debugger a lot better with a new timeline view and client-side rendering. But it still doesn’t answer the fundamental question: is this plugin heavy in general, or just heavy on this particular page?

That’s two different problems. And nobody was solving the first one with real data.

The problem with guessing

When I help people audit their plugin stacks, the conversation usually goes like this: “I think Elementor is heavy.” “I heard Jetpack is a resource hog.” “Someone on Reddit said WooCommerce adds 70 queries.”

Some of those are right. Some are outdated. And most people don’t have time to benchmark every plugin themselves. They just install stuff and hope for the best.

What if you could see each plugin’s performance impact right on the Plugins page? Not based on opinions – based on actual measurements.

Plugin Performance Score

The Performance column on the Plugins page – every plugin gets a score based on real benchmark data.
That’s what the new module in WP Multitool 1.1.19 does. It adds a Performance column to your WordPress Plugins page showing three things for each installed plugin:

A score from 0 to 100
PHP memory usage
Number of database queries

The data comes from makewpfast.com, where we benchmark plugins in isolated Docker containers. No caching, no interference from other plugins, just a clean WordPress install with one plugin active at a time. We measure memory and queries, then calculate a score.

Here’s what it looks like for some plugins you probably have installed:

Plugin
Score
Memory
Queries

Akismet
92
4 MB
5

Contact Form 7
82
6 MB
5

Jetpack
71
6 MB
9

Elementor
50
6 MB
42

WooCommerce
26
16 MB
70

No surprises for the extremes – WooCommerce is heavy, Akismet is light. But the middle is interesting. Jetpack scores lower than Contact Form 7 even though both use 6 MB of memory, because Jetpack runs nearly twice the queries. The score reflects that.

How scoring works

I didn’t want the score to be some black box number. It’s a formula you can verify yourself.

The baseline is a clean WordPress install – about 4 MB memory and 4 database queries. Everything above that is overhead. The formula uses a logarithmic scale, which means the first 10 extra queries hurt your score more than going from 100 to 110. That makes sense intuitively – if your plugin adds 10 queries to a minimal site, that’s a big deal. If it adds 10 more on top of 100, that’s noise.

Two important properties: the score is deterministic (same memory and queries always produce the same number), and it doesn’t change when we add new plugins to the database. If a future plugin uses 50 MB and 300 queries, it’ll score 0 – but WooCommerce stays at 26. No one else’s score shifts.

We have data for about 5,000 plugins. If yours isn’t in there, you’ll see a dash instead of a score. We’re working on expanding coverage.

What to do with this information

The score isn’t telling you to uninstall WooCommerce. If you run a store, you need it. But it does tell you where to focus your optimization effort.

If you see a plugin scoring below 50 and you’re not sure you need it – that’s a conversation worth having. If you see three plugins in the 60-70 range doing similar things, maybe it’s time to consolidate.

And if your site has autoload bloat, the heaviest plugins are usually the biggest contributors. Now you can see that connection at a glance instead of guessing.

The module loads the benchmark data from a static file bundled with the plugin. No external API calls, no performance impact on your site. It’s about 220 KB and gets cached by PHP’s opcache after the first load. The column only appears on the Plugins page – it doesn’t touch your frontend or any other admin page.

Try it

Plugin Performance Score ships with WP Multitool 1.1.19, enabled by default. Install the plugin, go to your Plugins page, and the Performance column is there.

Click any score badge to see the full benchmark report on makewpfast.com.

This is one of 14 modules included. Get WP Multitool – $199/year

WP Multitool 1.1.20: Action Scheduler + Image Analysis

WP Multitool — Thu, 18 Jun 2026 08:15:09 +0000

Originally published on https://wpmultitool.com/2026/04/23/wp-multitool-1-1-20-action-scheduler-image-analysis/

Published April 22, 2026 · WP Multitool 1.1.20

WP Multitool 1.1.20 ships two new modules: Action Scheduler Optimizer and smarter Image Size Analysis. If you run WooCommerce, the first one solves a problem you probably have right now. The second can cut your upload time in half by killing image sizes WordPress generates but never uses. Plus 9 targeted bug fixes.

Here’s what’s new and why it matters.

Action Scheduler Optimizer

If your site runs WooCommerce, you have an Action Scheduler table. It grows silently in the background — processing order emails, syncing inventory, firing scheduled hooks. On busy stores, it grows to millions of rows. The table gets slower. Every page request that needs to check the queue takes longer. Your database server strains under the weight of data that should have been cleaned months ago.

Most site owners don’t find out until something breaks. A backup fails because the database dump is 4GB. A database query times out. WP-CLI’s action-scheduler status returns a number you weren’t expecting.

The new Action Scheduler Optimizer module gives you a dashboard for the queue — and the tools to fix it.

What the module shows you

The dashboard surfaces five numbers immediately: total actions, pending count, failed actions, past-due items, and current processing rate (actions per hour). Below that, a full status breakdown by state — Complete, Cancelled, In Progress, Failed, Past-Due, Stuck — with the oldest action’s age for each group.

The recommendations panel flags issues automatically. If you have past-due actions piling up — a classic sign that the queue runner isn’t keeping up — it tells you exactly what’s happening and suggests a fix.

Cleanup tools

The Cleanup section shows what’s eligible for deletion, grouped by type and age. Completed actions, failed actions, logs, orphaned entries — each with counts based on your configured retention periods. You see the counts before you delete anything.

Three cleanup modes:

Purge — removes old completed and cancelled actions based on your retention settings
Optimize Tables — runs OPTIMIZE TABLE on Action Scheduler tables to reclaim disk space after bulk deletions
Nuclear Clean — wipes all non-pending actions. For sites where the queue has gotten completely out of hand. Requires typing a confirmation phrase.

Performance Tuner

The tuner exposes Action Scheduler’s runtime settings — the ones that are usually buried in code or require a developer to change. Batch size, time limit, concurrent batches, lock timeout. Each setting shows the current value, the default, and a number field you can adjust directly from the admin.

For most WooCommerce sites, the defaults are fine. For high-volume stores processing thousands of orders per day, being able to increase batch size or concurrent batches without touching code is genuinely useful.

Auto-Cleanup cron

Set it and forget it. Enable auto-cleanup and configure retention periods: how many days to keep completed, failed, cancelled, and log entries. By default the cron runs every 6 hours — configurable to hourly, every 12 hours, or daily. The queue stays manageable without manual intervention.

Top Hooks table

At the bottom of the page: a breakdown of action hooks by total count, pending, complete, and failed. This is how you find which WooCommerce process (or third-party plugin) is generating the most queue load. If one hook has 50,000 entries and everything else has under 100, that’s your culprit.

Action Scheduler Optimizer is available in both the Lite edition ($9) and the full Pro version. If you’re on WooCommerce and haven’t tried WP Multitool yet, the Lite edition ($9) includes this module.

Image Manager: Size Analysis

WordPress generates multiple size variants for every image you upload. Thumbnail, medium, large, medium-large — that’s the default set. Themes add their own. Plugins add theirs. WooCommerce adds product image sizes. Page builders add responsive breakpoints.

By the time you’ve been running a site for a year, you might have 15–20 registered image sizes. Half of them may never appear in any post or template. The other half might be duplicates of each other with different names but identical dimensions.

The Image Manager already lets you disable sizes and regenerate thumbnails. Version 1.1.20 adds a smart analysis tool: Find Sizes to Disable.

What the analysis does

Click the button and the analyzer scans your registered image sizes against two criteria:

Duplicates — sizes with identical or near-identical dimensions. The analysis flags them and identifies which is the “original” that other sizes duplicate. Keeping both wastes disk space on every image upload.
Unused — sizes that have zero actual image files generated, or that don’t appear in your content or theme templates. These are registered but never used. Disabling them stops WordPress from generating them on future uploads.

Each flagged size shows why it’s flagged (DUPLICATE or UNUSED badge), what it’s a duplicate of, and how many image files exist for it. You can disable it directly from the analysis results.

Why this matters

Every active image size means WordPress generates an extra file on every image upload. A site with 20 registered sizes generates 20 files per upload. Cut it to 10 and you halve the upload time, disk usage, and backup size for new images.

The analysis doesn’t remove existing files — it prevents new ones from being generated. For cleanup of existing files, the Image Manager’s existing disable-and-delete workflow handles that.

9 Bug Fixes

This release includes 9 fixes from a systematic code review across the Action Scheduler Optimizer and Image Manager modules. Some highlights:

Critical: Action Scheduler stats showed 0 rows — TABLE_ROWS/DATA_LENGTH case mismatch in the analyzer. Fixed.
Critical: Image size unused scan could miss results on sites with large image libraries — added group_concat_max_len=10MB before the scan query.
Critical: Cleanup with retention set to 0 days previously deleted everything instead of treating 0 as “disabled.” Fixed — 0 now means skip that type.
High: Disk usage scanning used an O(N²) loop per image. Replaced with a single-pass cached result.

Remaining fixes cover a missing capability check, an unbounded UPDATE query in the queue runner, and legacy use of global $screen. No new features — just problems that shouldn’t have been there.

How to Update

If you’re on the Yearly or Lifetime plan, the download is available in your Polar account. If you bought through the plugin dashboard, the update appears in WordPress → Plugins automatically.

The Lite edition ($9) doesn’t include Image Manager with Size Analysis (Pro module), but Action Scheduler Optimizer and the bug fixes are available in Lite. If you’ve been meaning to upgrade: the $499 lifetime license covers all current and future modules — no annual renewal.

As always: test on staging before updating production. The update takes 30 seconds. The testing should take longer.

Get WP Multitool

Lite Edition ($9) — includes Action Scheduler Optimizer, Database Optimizer, Frontend Optimizer, and more
Pro Yearly — $199/yr — all 13 modules including Image Manager, Slow Query AI Analyzer, Config Manager
Lifetime — $499 one-time — everything, forever, no renewals

Not sure if it’s worth it? The 6-plugin problem post explains what WP Multitool replaces and why one tool beats six.

Tools I Actually Use and Recommend

WP Multitool — Wed, 17 Jun 2026 08:29:54 +0000

Originally published on https://wpmultitool.com/2026/04/10/tools-i-actually-use-and-recommend/

Every “best tools” list on the internet is the same. Someone ranks 47 tools they’ve never used, stuffs affiliate links into every paragraph, and calls it a “definitive guide.” You read it, learn nothing, and close the tab.

This is not that.

These are tools I actually use, have tested, or genuinely think are worth your time. No affiliate links. No rankings. No “best of 2026” nonsense. Just honest takes from someone who builds WordPress sites and SaaS products for a living.

I’ll keep updating this list as I find new things worth recommending. Think of it as a living document – if something stops being good, it comes off the list.

WP Multitool

Ok, I’m putting my own tool first because I’m biased and I’m not going to pretend otherwise. WP Multitool is a WordPress optimization plugin I built because I was tired of installing 6 different plugins just to keep a site healthy.

It does slow query analysis, autoload optimization, database cleanup, plugin performance scoring, and a bunch of other things that used to require separate tools. One plugin instead of six. That’s the whole pitch.

Is it perfect? No. I’m still actively developing it. But it solves real problems I kept running into on client sites, and now it solves them in one place. If you’re managing WordPress sites and constantly juggling performance plugins – take a look.

wp-loc

I built wp-loc because setting up local WordPress environments shouldn’t require a PhD in Docker networking. One command – wp-test create mysite.loc – and you get a fully working WordPress install with SSL, WP-CLI, Redis, and proper database setup. No clicking through wizards, no GUI apps eating your RAM in the background.

It’s Docker-based, so each site is completely isolated. You can run multiple sites at once, migrate from remote servers, manage databases – all from the terminal. It handles the annoying stuff automatically: SSL certificates, port conflicts with MAMP, DNS routing to .loc domains.

If you’re a WordPress developer on macOS who lives in the terminal, this is how local development should work. It’s open source and free.

NerdSip

I have a problem. I want to learn new things – AI concepts, business strategy, random technical topics – but I don’t have time to sit through a 4-hour Udemy course. And honestly, most of what I want to learn doesn’t need 4 hours. I just need the key concepts.

NerdSip solves exactly that. You pick a topic – literally anything – and it generates a 5-minute micro-course with 7 bite-sized lessons, quizzes, and infographics. The whole thing was built by two physicists, which probably explains why the content structure actually makes sense.

What I like about it: you can learn something useful in the time it takes to drink a coffee. Instead of scrolling Twitter for 10 minutes, you actually come away knowing something new. The free tier gives you 2 courses per day, which is honestly enough for most people. There’s a Plus plan at €4.99/month if you want more. Works on both iOS and Android.

Is it going to replace a proper deep-dive course? No. But for staying sharp across different topics without committing your entire evening – it’s genuinely useful.

LandingBoost

Here’s the thing about building landing pages – most of us WordPress developers are decent at the technical side but not exactly conversion rate optimization experts. You build a page, it looks good, you publish it, and then… you hope for the best?

LandingBoost is a free AI-powered landing page analyzer. You paste your URL, wait about 60 seconds, and get a conversion score with specific feedback on what’s working and what isn’t. That’s it. No signup wall, no “book a demo” nonsense.

I find it especially useful when I’m building landing pages for side projects or client sites and want a quick sanity check before going live. It catches things you stop noticing after staring at the same page for hours – weak CTAs, missing trust signals, confusing layouts. Think of it as a second pair of eyes that actually knows something about conversions. If you want to see how it holds up in practice, Bob’s Tech Review put together a detailed hands-on review that walks through the scoring on real pages.

Why Does My Site Suck?

This one’s also mine, and it scratches a different itch than LandingBoost. Where LandingBoost looks at how well a single page converts, Why Does My Site Suck? runs a whole-site sanity check – 330 automated checks that score your URL from 0 to 100 across SEO, performance, security, accessibility, and AI/LLM visibility.

It’s free and there’s no signup. You paste a URL, wait a bit, and get a blunt breakdown of what’s broken and what to fix first. I use it as a quick gut-check before handing a site to a client, or when I just want to know whether a site is fundamentally healthy before digging into the details. It won’t replace a proper manual audit, but it catches the obvious stuff fast – and it pairs nicely with LandingBoost when you want both the whole-site view and the page-level conversion read.

What’s next

Like I said, this is a living list. I’ll add new tools as I discover them and remove anything that stops being worth it. If you’re building something useful for WordPress developers or indie makers and think it belongs here – let me know.

WP Multitool 1.2.0: Updates Now Come To You

WP Multitool — Wed, 17 Jun 2026 08:15:14 +0000

Originally published on https://wpmultitool.com/2026/05/06/wp-multitool-1-2-0-auto-updates/

Published May 6, 2026 · WP Multitool 1.2.0

Until today, every release of WP Multitool meant the same chore for our customers. Download the zip from Polar. Go to Plugins, Add New, Upload. Click through “replace existing”. Repeat on every site you maintain.

That ends with 1.2.0.

What changed

There’s a new module called Auto Updater. You enable it once, paste your license key, and from that point on WP Multitool shows up in WordPress’s normal Updates screen like any other plugin. One click and you’re current.

Behind the scenes it talks to wpmultitool.com, checks your license, and pulls a signed zip with a 30-minute expiry. If your license gets refunded or revoked, the next check fails and updates stop. No drama, no manual cleanup.

It’s gated to Pro. Lite skips the whole thing because there’s nothing to license-check.

Why it took this long

Honest answer? I wanted to ship the plugin first and figure out distribution second. WordPress.org isn’t an option for a paid plugin like this, and the existing third-party update SaaS options either lock you into their stack or charge per-customer fees that don’t make sense at our scale.

So I built it. The license server is a few REST endpoints in the marketing site theme. The plugin side is one self-contained module that hooks into WordPress’s update transient. About 800 lines of PHP total, both ends combined. No framework, no SaaS dependency, no recurring cost.

A real fix for the slow-log table errors

One of you reported that hitting “Repair Setup” in Slow Callback Finder showed this: “Cannot create database table. Check database user permissions.” Their MySQL user actually had CREATE permission. The error was wrong.

What was happening: the plugin called WordPress’s dbDelta() to install the table, checked if the table existed afterwards, and if it didn’t, blamed permissions. It never read $wpdb->last_error. So the real reason was getting swallowed.

If you’ve ever fought with dbDelta(), you know how picky it is. KEY vs INDEX matters. Whitespace matters. It silently fails on some MySQL and MariaDB builds, especially older LiteSpeed stacks. The fact that it works most of the time made the failure mode worse, because nobody questioned it.

1.2.0 replaces dbDelta() for the slow-log tables with a small Schema_Manager class. Explicit CREATE TABLE IF NOT EXISTS. Captures $wpdb->last_error after every statement. Falls back through four charsets (utf8mb4_unicode_520_ci, then utf8mb4_unicode_ci, then utf8mb4_general_ci, then plain utf8) and two storage engines (InnoDB, then whatever the server defaults to) before giving up. When it does fail, the error message now contains the actual MySQL error instead of a guess.

This affects two modules: Slow Callback Finder and Slow Query AI Analyzer. If you ever saw the old error and gave up, try again on 1.2.0.

One thing I considered along the way was wrapping the install in a transaction. Then I remembered MySQL and MariaDB do an implicit COMMIT before and after every DDL statement, so a transaction around CREATE TABLE does nothing. If you’ve wondered why other plugins don’t bother, that’s why.

Tested on fresh installs and on sites with a custom $table_prefix – the customer’s case was wp_plugins_. Works.

Upgrade no longer hangs during maintenance mode

Smaller one. WordPress briefly drops a .maintenance file when an update runs. While that file is there, your admin URL serves a “be right back” page. Normally it’s gone in a second.

The auto-updater was hitting the admin URL during the upgrade to detect the new version, and if maintenance mode lingered (say, because another plugin was updating at the same time) it would wait, then sometimes hang the upgrade entirely.

1.2.0 checks for the .maintenance file and the 503 status before doing that refresh, and skips it if it’s there. WordPress finishes the upgrade without the plugin getting in the way.

Found this dogfooding the auto-updater on a site that had a Yoast update queued at the same time. Felt unhelpful to ship 1.2.0 with the new updater half-broken under real-world conditions, so it got fixed before release.

What you should do

If you already own a WP Multitool Pro license:

Update to 1.2.0 manually one last time (yes, the irony isn’t lost on me).
Go to WP Multitool, Updates.
Paste the license key from your Polar download email.
Done. Future updates will appear in your normal Updates screen.

If you’re on Lite or you haven’t bought yet, nothing changes for you. Lite stays manual, which is fine because Lite ships rarely.

About your license key

Your license key was in the email Polar sent when you bought WP Multitool. If you can’t find that email, the key is also on your Polar dashboard at polar.sh/dashboard/purchases – click the WP Multitool order and the key is on the order page.

Didn’t get the email at all, or the dashboard shows nothing? Send me a note at support@wpmultitool.com and I’ll find your record and resend the key.

If you hit any rough edge with 1.2.0, reply to the announcement email or open an issue. I read all of them.

– Marcin

The WordPress Safety Net You Only Notice When You Need It

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

Originally published on https://wpmultitool.com/2026/05/20/wp-multitool-fatal-error-recovery/

The scenario nobody likes

You’re editing a plugin file in wp-admin/plugin-editor.php. You’re tired. You forget a semicolon. You hit Update File and the next request white-screens the site. You’re locked out of wp-admin. Your only way back in is… wp-admin.

If you’ve lived through this, you know the feeling.

WordPress has had a fix for this since 5.2. It’s called Recovery Mode. Most people don’t know it exists, and even when they do, the default flow has an awkward weakness – it emails you a recovery link from the same site that just broke.

This post is about what Recovery Mode actually does, why the default flow is awkward, and what WP Multitool changes about it. I’ll also be honest about what it can’t fix. There’s a sudo gate inside WordPress that we don’t bypass on purpose.

What core gives you

When a plugin or theme triggers a fatal error on an admin page, WordPress doesn’t just show the “There has been a critical error on this website” page and give up. It also:

Notes which extension caused the crash.
Generates a one-time recovery link (a URL with rm_token and rm_key params).
Emails that link to the site’s admin email.
When you click the emailed link, WordPress validates the key, drops a recovery cookie, asks you for your password one more time, and finally lets you into a special “Recovery Mode” version of wp-admin where the broken plugin or theme has been paused. It’s still installed, just skipped on every page load until you say otherwise.

It’s a clever design. The pause means you can keep using the rest of the site. The one-time link means an attacker who scraped the email later can’t replay it. The extra password gate means a hijacked browser session alone isn’t enough to disable security plugins.

But there’s one assumption baked in that bites in practice.

The email is the problem

The recovery link has to leave the server somehow. Core ships it by email. That’s where it falls apart:

Only the “main” admin gets the email. WordPress sends the recovery link to the single admin_email option, not to every administrator on the site. If five people share admin rights, four of them are watching the site go down without a link to fix it.
That admin email is often a ghost address. Set during install years ago. Belongs to a developer who left. Points at a Gmail inbox nobody checks. Points at info@ with a 90% spam ratio. The link expires before anyone notices it arrived.
If your SMTP plugin was the one that crashed, no email goes out at all.
If your DNS or mail server is having a bad day, no email goes out at all.
If the email lands in spam, you might miss it during the exact 60 seconds you’re trying to recover.
If you’re a freelancer working on a client’s site and the admin email is somebody else’s address, congratulations, you can’t help your client until they forward you a one-time link they don’t understand.

None of these are core’s fault. They’re real failure modes that turn a 30-second fix into a 30-minute scramble, or a much longer outage when the link lands in an inbox nobody opens.

The default white screen. The email link is supposedly on its way.

What WP Multitool does differently

If you’re already logged in as an admin when the fatal happens, WP Multitool’s drop-in (wp-content/fatal-error-handler.php) catches the crash before WordPress emails anything. It:

Generates the same Recovery Mode URL core would have emailed. Same rm_token and rm_key, same machinery, same security model.
Redirects your browser to it directly. No inbox detour.
Then steps out of the way and lets core handle the rest – validate key, set cookie, ask for password, drop you into Recovery Mode.

That’s the entire change. We don’t replace Recovery Mode. We don’t reinvent the security gate. We skip the email leg of the chain when it’s pointless, because you’re literally already at the keyboard.

Recovery Mode dashboard, with the “Exit Recovery Mode” button top right.

The broken plugin is paused. The rest of the site keeps working.

What you’ll actually click

The full flow looks like this from your point of view:

You’re in wp-admin doing something. A fatal error happens.
Your browser briefly visits wp-login.php?action=enter_recovery_mode&rm_token=...&rm_key=... and then ?action=entered_recovery_mode. You’ll see the URL bar flash through these.
You land on a familiar-looking login form with one extra notice at the top – “Recovery Mode Initialized. Please log in to continue.”
You type your password. Yes, the same one you just used. See “the sudo gate” below.
You’re in wp-admin with a yellow Recovery Mode banner. The broken plugin is listed as paused. Fix the code or click Disable. Click Exit Recovery Mode when you’re done.

No inbox. No “where’s the email.” No forwarding it to yourself from another device.

The sudo gate (and why we don’t kill it)

You’re going to enter your password one more time during this flow. We deliberately left that step in place.

Recovery Mode lets you disable any plugin or theme, see file paths and stack traces, and inspect a half-broken site. It’s a privileged context, like sudo. WordPress wants one fresh credential confirmation before granting it. Three good reasons for that:

Cookie-only sessions aren’t enough. If your browser session was hijacked and the attacker triggered a fatal to get into Recovery Mode (where they could disable Wordfence), a password gate stops them.
The recovery link can leak. Even if you skip the email like we do, the URL might still end up in browser history, a reverse proxy log, a screen share recording. The password requirement makes that URL useless without the credential.
The recovery key is one-time. Combined with the fresh password entry, an attacker who somehow sniffed the URL mid-flight can’t replay it.

So even with our shortcut, you’ll see the login form once. If you weren’t logged in when the crash happened, you’ll see it twice – once to be admin again, once to be sudo-admin. That’s a WordPress design floor we don’t try to dig under.

Clean state once you’re inside Recovery Mode.

What it doesn’t do

A few honest caveats:

It doesn’t help logged-out visitors. If a non-admin visitor triggers the fatal first, our drop-in falls through to WordPress’s default behavior. Recovery Mode is for the person fixing the site, not the person browsing it.
It doesn’t catch errors in WordPress core files. Only plugin and theme fatals trigger recovery, by core’s design, not ours. If you’re editing wp-includes/, you’re on your own (and you shouldn’t be editing those).
It doesn’t replace backups. Recovery Mode pauses the broken extension. It doesn’t undo whatever data damage the bad code did before it died. If you’re touching anything in production, have a recent backup.
It doesn’t make you immune to bad code. It just makes the consequences cheaper to fix.

And there's a failure mode past all of this: the site is already fully down, you have no admin access, and the recovery email landed in an inbox nobody checks. At that point you're out of prevention and into triage — emergency WordPress repair gets a crashed site diagnosed and back online in about an hour.

How to see it work yourself

Install WP Multitool, make sure it’s active, then drop a one-line plugin into wp-content/plugins/:

<?php /** Plugin Name: Crash Test */ add_action( 'admin_init', function () { this_function_does_not_exist(); } );

Activate it from the Plugins page. The next admin pageload will fatal, and you’ll be in Recovery Mode about half a second later.
Disable Crash Test from inside Recovery Mode, then click Exit Recovery Mode. Site is back.

No email was sent. No DNS was consulted. (Don’t try this on a production site. Obviously.)

The cleanup companion

Once you’ve disabled the broken plugin and fixed the code, you’ll want to re-activate it. The standard WordPress plugins page makes this two clicks (Deactivate, Activate). Fine for one plugin, annoying when you’re iterating on a fix. WP Multitool’s Plugin Reactivator module adds a one-click Reactivate link to each row on the plugins page. That’s exactly the affordance you want during a “fix, test, fix again” cycle.

Your WordPress media library is hiding gigabytes you can’t see

WP Multitool — Tue, 16 Jun 2026 15:09:24 +0000

Originally published on https://wpmultitool.com/2026/06/02/reclaim-wordpress-image-storage/

Every time you upload one image, WordPress quietly makes five or six more. Thumbnail, medium, medium_large, large – then your theme adds a couple, WooCommerce adds three, and whatever gallery plugin you installed last year adds two you’ve never looked at.

On a small blog that’s fine. On a real site with a few thousand images, it adds up to gigabytes of derivative files. And here’s the part that bugs me – a lot of those sizes are duplicates of each other (640×640 vs 600×600, who can tell?), or they were registered by a plugin you deleted months ago and nothing references them anymore.

You’re paying for that storage. You’re backing it up. You’re syncing it. For files nothing ever loads.

What we changed

WP Multitool’s Image Manager already had an analyzer – “Find Sizes to Disable” – that scanned your registered sizes and flagged the duplicates and the unused ones. Useful, but it only told you. You still had to go clean up by hand.

Now it actually does the work. Run the analyzer and you get a “Reclaim space” button on every flagged size. There’s a per-row version, and a bulk one for unused sizes. Click it and it walks your whole media library, deletes the generated files for that size, and tells you how many megabytes it freed.

That’s the whole point – turn “here’s what’s wasting space” into “ok, it’s gone.”

One flagged size, one button. “Reclaim space” deletes the generated files for that size across the whole library – and Regenerate is right there if you change your mind.

The safety stuff, because this is your media library

I’m not going to ship a feature that can wreck someone’s images, so let me be clear about what it touches.

It only deletes the intermediate files – the image-640x480.webp derivatives. Your original upload is never touched. The code literally can’t reach the original; it only ever resolves the size files in the attachment metadata.

It’s reversible. Every size keeps its “Regenerate” button. Reclaimed something you actually needed? One click and WordPress rebuilds it from the original. No backup restore, no drama.

And when you reclaim a size, it also disables future generation of that size. Otherwise you’d delete the files today and the next upload would recreate them tomorrow. Reclaiming and disabling go together.

Knowing what’s actually used

The hard part of all this isn’t deleting files. It’s being sure a size is really unused before you nuke it.

So the detection got smarter. It now scans your post content (classic markup and Gutenberg’s sizeSlug), Elementor’s _elementor_data, media image widgets, and your active theme’s PHP files. There’s a new “Content refs” column that tells you where each size shows up – content, Elementor, widget, theme. If a size is referenced, you’ll see it, and you won’t disable it by accident.

If nothing references it, the column says “none detected” and the tooltip says to verify before disabling. Not “safe to delete.” Verify. There’s a difference, and I’ll get to why in a second.

Every registered size, annotated: duplicates, theme sizes, what’s unused, and the new Content refs column showing where each size actually shows up before you touch it.

What it won’t do

I’d rather tell you the limits than have you find them the hard way.

Detection has blind spots. If your images are served from an edge cache like Cloudflare, those requests never hit your origin, so I can’t see them in logs. If a size is used in some dynamic context – a REST endpoint, an OG image generated on the fly, an email template – a content scan won’t catch it. Deeply nested page-builder JSON can hide references too.

That’s why the UI never says “safe to delete.” It says “no reference found, verify before disabling.” You know your site. The tool narrows it down; you make the call. And since everything’s reversible, the cost of being wrong is one click.

It also doesn’t recompress your images or convert anything to WebP/AVIF. That’s a different job. This is about sizes you don’t need at all, not squeezing the ones you keep.

Built for the servers people actually run

A lot of WordPress runs on cheap shared hosting with a tight max_execution_time. So the scan is on-demand only – it never runs on page load, only when you click the button. It reads the database row by row instead of pulling everything into memory, stops scanning a size the moment it finds a reference, and has a hard cap on how many rows it’ll touch. Hit a site big enough to reach that cap and it tells you the results might be incomplete instead of timing out and giving you nothing.

I tested it on a site with 1000 images and 1200 posts. The scan came back in under a second. The interesting bit – the reference scanning was basically free; the time goes into checking actual disk usage across the library. Good to know for what we optimize next.

Try it

All of this shipped in WP Multitool 1.3.0. If you’ve got a media library that’s grown over a few years, run the analyzer once. I think most people will be surprised how much is sitting there doing nothing. Don’t have it yet? Grab WP Multitool and point it at your worst offender of a site.

Next up I want to push the usage detection further – reading server access logs to see which sizes actually get requested, not just which ones are referenced in content. That closes the edge-cache gap. More on that when it’s working.

Site Doctor: the WordPress problems you can’t see, found and fixed

WP Multitool — Tue, 16 Jun 2026 15:09:22 +0000

Originally published on https://wpmultitool.com/2026/06/16/wordpress-site-doctor/

A health monitor for your WordPress site. The flatline spots are where the money leaks.

The problems that don’t show up anywhere

The site loads. Nothing is on fire. And yet OPcache is thrashing because its key table is full, so PHP recompiles on half your requests. There’s an object-cache.php drop-in still pointing at a Redis server that died three months ago, quietly erroring on every page. The homepage misses the page cache on every single hit and nobody noticed, because it still renders, just three seconds slower than it should. Most of what slows a WordPress site down is invisible from the dashboard.

I fix real client sites for a living, and the same handful of misconfigurations come up again and again. They’re never in the obvious place. You find them by SSHing in, reading opcache_get_status() by hand, curling your own homepage to read the cache header, squinting at wp_options. Every time. So I turned that checklist into a module. It’s called Site Doctor, and it’s the headline of 1.4.

What the WordPress Site Doctor health check does

Site Doctor is an on-demand WordPress health check that scans five production misconfigurations WordPress hides from you (OPcache state, a dead object-cache drop-in, LiteSpeed misconfiguration, page-cache misses, and WooCommerce gateways stuck in test mode) and hands you the exact fix for each one.

You click Run scan (or run wp multitool doctor from the command line) and it checks the things that actually cost you, then tells you how to fix each one. It’s read-only and it never runs on a normal page load. The scan fires once, when you ask it to, and caches the result. It’s a diagnostic tool you reach for, not another thing bolted to every request.

One scan, five checks, a fix on every finding. This is the real module, not a mock-up.
Here’s what it looks at:

OPcache health. Not just on or off. It catches the states that actually hurt: out-of-memory restarts, a full key table forcing recompiles, a populated cache with a low hit rate. When something’s wrong it hands you a sized php.ini snippet calculated from your live numbers, not generic advice.
The object-cache drop-in. A present-but-dead drop-in (the file is there, the backend isn’t answering) is flagged critical, because that’s the silent killer: it can error on every request while the site still limps along. It identifies the vendor and tells you the safe move.
Page caching, via one real loopback request. It fires a single request at your own homepage and reads the cache header. HIT or MISS, LiteSpeed or Cloudflare or Varnish or Kinsta. A cache layer that’s present but missing on every hit is worth knowing about.
LiteSpeed misconfiguration detection for sites running LSCWP, the kind of thing that silently stops LiteSpeed from caching even though the plugin is active.
WooCommerce payment gateways stuck in test mode. A live shop with a gateway still in sandbox can’t actually take money. It catches the enabled-but-test-mode gateways (including the Przelewy24 wizard bug that saves a localized label instead of “production”) so you find out before a customer does.

It deliberately does not duplicate what other modules already do well: cleaning expired transients and chasing down overdue cron live in the Database Optimizer and the Site Health view. Site Doctor sticks to the configuration problems nothing else surfaces.

Detect and fix, not just a wall of red

I have a rule for Site Doctor: a check isn’t allowed to ship unless it comes with a fix. Finding a problem and shrugging is what most “health check” tools do, and it’s useless when you’re tired and just want the site fast again.

So every finding carries remediation. Not “consider tuning your cache”, but the actual change to make, with the real values. OPcache flags a problem and hands you a sized php.ini snippet calculated from your live numbers. A gateway in test mode tells you the exact setting to flip. I don’t want a plugin auto-changing this stuff behind your back from PHP. Flipping a payment gateway live is your call, not the scanner’s. So the fix is concrete guidance you act on, not a button that guesses.

One more thing I care about: it doesn’t cry wolf on your laptop. Site Doctor has a staging-guard that quietly downgrades severities on dev hosts (.loc, .local, staging. subdomains, and so on). A dead object cache on your local clone is expected. On production it’s critical. Same check, different stakes, and the tool knows the difference.

Site Doctor ships enabled out of the box. It’s admin-only and adds nothing to a page load, so there’s no reason to hide it.

And when wp-admin won’t even load

Site Doctor assumes you can reach the dashboard. Sometimes you can’t, and that’s the other half of 1.4: a small WP-CLI rescue kit for when wp-admin is the thing that’s broken. Usually it ran out of memory, because the dashboard is the heaviest page on the site.

The number-one cause of that is a bloated autoload set, the options WordPress loads into memory on every request. Plugins you deactivated months ago leave megabytes of it behind. Three commands, in the order you’d use them:

Analyze, optimize, restore. Every step reports exactly what it did, and the backup means restore is always one command away.
wp multitool autoload analyze classifies every autoloaded option and flags the safe-to-trim ones, specifically the leftovers from plugins that aren’t active anymore. optimize disables autoload for those, after writing a backup. restore puts every flag back exactly as it was and reports the exact count, so if it didn’t help you’re one command from where you started. There’s also wp multitool modules to enable and disable modules from the command line when you can’t reach the toggles.

I’ll be honest about the autoload win, because the internet oversells it. It mostly moves TTFB on sites with a big autoload set and no persistent object cache. On Redis or Memcached the blob is already cached and the gain shrinks to memory. On a query-bound site the real problem is usually the queries, which is the last new tool.

Catch an N+1 query storm in one page load

The classic WordPress performance killer is the N+1 query: a plugin runs the same query once per item in a loop, so a page with 50 products fires 50 near-identical queries instead of one. Finding these usually means leaving query logging on and digging, which you don’t want running on a live site.

1.4 adds a one-shot probe. wp multitool slow-queries probe fires a single request at your front end with query logging on for that one request only, gated behind a one-time token, then switches logging straight back off.

One real page load, 81 queries captured. The top row ran 54 times. That’s an N+1, flagged automatically.
That 54× in the first column is the whole point. One query running 54 times on a single page load is an N+1 waving its arms at you, and where an index would help, the probe hands you the exact CREATE INDEX statement.

Less overhead out of the box

The profiling modules now ship off. On a fresh install, the Slow Query Analyzer and Find Slow Callbacks start disabled. They’re diagnostic tools you reach for when hunting a problem, so a fresh install adds no per-request profiling cost until you turn one on. Existing sites keep whatever you already had.
A low-memory warning now fires in the health checks and CLI when your configured memory limit is low, with the exact constant to raise in wp-config.php. Better to know before the dashboard dies, not after.

The safety net that can’t be switched off by accident

One hardening note. WP Multitool’s Fatal Error Recovery, the thing that gets you back into a white-screened site, is now a deliberate always-on safety net. It’s no longer owned by any toggleable module, so disabling modules (from the dashboard or the new CLI commands) can never strip a site of its crash recovery. The one feature you’d most want during an outage is the one you can’t turn off by mistake.

The point

Site Doctor is the part of this release I’m most happy with, because it’s the checklist I actually run on real sites, turned into one button. Most WordPress tooling tells you a site is “healthy” when it loads. The interesting problems are the ones that don’t announce themselves: the dead cache, the thrashing opcode cache, the query fired fifty times. 1.4 is about finding those, and fixing them.

WP Multitool 1.4 is available now, and existing license holders get it through the in-plugin updater, no re-download needed. New to it? You can get WP Multitool, or skim the full 1.4 changelog for everything that shipped.

Do You Really Need 6 WordPress Plugins for Performance?

WP Multitool — Wed, 08 Apr 2026 13:40:50 +0000

I counted the plugins on a client's site last month. Six of them existed purely to help manage WordPress itself. Not to add features. Not to serve visitors. Just... maintenance tools.

Query Monitor for debugging. WP-Optimize for database cleanup. Health Check for troubleshooting. WP Config File Editor for constants. Asset CleanUp for frontend bloat. And WP-CLI commands scattered across five different terminal windows.

Six plugins. Six update cycles. Six potential conflicts. Six sets of admin pages cluttering the sidebar. All doing things that should probably be one tool.

The Plugin Stack Problem

Every plugin you install adds weight:

Memory overhead - each plugin loads its PHP files on every request, even if you only use it once a week
Autoload bloat - many plugins store options with autoload = yes, meaning they load on every single page request even when inactive
Update fatigue - six plugins means six update notifications, six changelogs to read, six chances for a breaking change
Conflict risk - more plugins means more hooks, more filters, more chances of stepping on each other

This isn't theoretical. On one client's site, the debugging and optimization plugins together were using several megabytes of extra memory per request. The tools meant to find performance problems were adding to the problem.

The Six-Plugin Stack (And What Each Does)

Here's the typical WordPress maintenance stack and what each plugin handles:

1. Query Monitor

What it does: Shows database queries, PHP errors, hooks, HTTP calls, template hierarchy on the current page.
Why you install it: Something is slow and you need to figure out what.
The gap: No persistent logging. No production monitoring. No fix suggestions. You close the tab, the data is gone.

2. WP-Optimize

What it does: Database cleanup (revisions, transients, orphaned data), image compression, basic caching.
Why you install it: The database has 50,000 post revisions and someone told you to clean them.
The gap: Doesn't tell you which queries are slow. Doesn't touch autoload settings. Cleanup without diagnosis.

3. Health Check & Troubleshooting

What it does: System info, troubleshooting mode that disables plugins/themes for your session only while other visitors see the normal site.
Why you install it: You need to figure out which plugin is causing a conflict without taking the site down.
The gap: The troubleshooting mode is genuinely clever. But outside of conflict diagnosis, it sits there doing nothing. You use it twice a year.

4. WP Config File Editor

What it does: GUI for editing wp-config.php constants (WP_DEBUG, memory limits, etc.)
Why you install it: Because editing wp-config.php via SSH/FTP is annoying and error-prone.
The gap: A narrow tool for a narrow job. Works, but it's one more plugin in the pile.

5. Asset CleanUp (Perfmatters, etc.)

What it does: Removes unnecessary scripts and styles from pages, defers JavaScript, disables features like emojis and dashicons.
Why you install it: PageSpeed Insights told you to "eliminate render-blocking resources."
The gap: The free version handles per-page script unloading well. But site-wide rules, more granular control, and advanced features are premium ($49+).

6. WP-CLI

What it does: Command-line interface for WordPress management.
Why you use it: Database queries, cache management, cron jobs, bulk operations.
The gap: Not a plugin, but part of the stack. Requires SSH access and command-line knowledge.

Total: 5 plugins + 1 CLI tool. Each one loading its own PHP files, hooks, and options on every request.

The One-Plugin Alternative

Here's how WP Multitool's 14 modules map to each of these tools:

Your Current Plugin	WP Multitool Module	What Changes
Query Monitor	Slow Query Analyzer + Find Slow Callbacks	Persistent logging, EXPLAIN analysis, production-safe monitoring. Still use QM for quick debugging - they complement each other.
WP-Optimize	Database Optimizer + Autoloader Optimizer	Same cleanup, plus autoload optimization that WP-Optimize doesn't touch. No image compression or caching (use a dedicated caching plugin).
Health Check	System Info + Plugin Reactivator	Server diagnostics + one-click plugin reactivation for troubleshooting.
WP Config File Editor	Config Manager	Edit wp-config.php constants from admin. Backup before changes. Actively maintained.
Asset CleanUp	Frontend Optimizer	Defer scripts, remove jQuery Migrate, disable dashicons/emojis, clean head. The 80% of Asset CleanUp you actually use.
WP-CLI (for performance)	`wp multitool` CLI commands	7 subcommands: status, health, db-health, autoload, slow-queries, frontend, clean.

Plus 6 modules that none of those plugins offer:

Plugin Performance Score - benchmark scores for every installed plugin, right on the Plugins page
Image Manager - manage and remove unused image sizes
Shortcode Inspector - find and test every registered shortcode
Quick Updater - drag-drop plugin updates from ZIP files
Package Downloader - download any installed plugin/theme as ZIP
Dashboard Widget Manager - control what shows on the admin dashboard

The Math

Let's do the honest calculation:

	6-Plugin Stack	WP Multitool
Plugins to maintain	5-6	1
Admin menu items	5-8	1 (with subpages)
Update notifications	5-6/month	1/month
Combined cost	$0-$250+ (if using premium versions)	$199/year
Conflict risk	Moderate (overlapping hooks)	None (one codebase)
Modules you can disable	Sometimes	Always (enable only what you need)

The cost comparison depends on your stack. If you're using all free versions, WP Multitool costs more. If you're paying for Asset CleanUp Pro and WP-Optimize Premium (starting at $49/year each), the math is closer to even - and you get significantly more functionality.

What You Lose

I'm not going to pretend WP Multitool replaces everything perfectly. Here's what you'd miss:

Query Monitor's breadth - QM shows hooks, template hierarchy, conditionals, HTTP calls. WP Multitool focuses on query and callback performance. I still recommend keeping QM installed for deep debugging sessions.
WP-Optimize's image compression - WP Multitool doesn't compress images. Use ShortPixel, Imagify, or similar.
WP-Optimize's page caching - WP Multitool doesn't cache. Use WP Super Cache, W3 Total Cache, or your host's caching.
Health Check's troubleshooting mode - The "enable safe mode for your session" feature is unique to Health Check. WP Multitool's Reactivator is simpler.

So realistically, you might go from 6 tools to 3: WP Multitool + a caching plugin + QM for the occasional deep dive. That's still cutting your maintenance stack in half.

When This Makes Sense

This consolidation makes sense if:

You manage multiple WordPress sites and want fewer plugins to track
You're hitting memory limits and need to reduce plugin overhead
You want autoload optimization and slow query detection that none of the free plugins offer
You're tired of 6 different admin interfaces for related tasks

Stick with the individual plugins if:

You only need one specific feature (just cleanup? WP-Optimize is fine)
Budget is zero (most of the 6-plugin stack is free)
You have a workflow that works and change isn't worth the disruption

Try It

The full module list with documentation is at wpmultitool.com. Every module can be enabled or disabled independently - you don't have to use all 14.

Use code startups2026 for 10% off if any of this resonated.

And if you want to read more about why caching plugins don't fix slow sites or how to read a MySQL EXPLAIN plan - those are the rabbit holes that led me to build this thing in the first place.

Originally published at https://wpmultitool.com/blog/do-you-need-6-wordpress-plugins/

WP-Optimize Cleans Your Database. That's About It.

WP Multitool — Wed, 08 Apr 2026 13:40:48 +0000

Every WordPress developer has that moment. The site is slow, someone says "just install WP-Optimize," and you clean up 5,000 post revisions. The site loads 200ms faster. You feel good about it.

Then a week later, it's slow again. Because the problem was never the revisions.

If you've been looking for a wp-optimize alternative that goes deeper than database cleanup, this comparison breaks down where each tool fits - and where it doesn't.

What WP-Optimize Does

WP-Optimize by Team Updraft (the same team behind UpdraftPlus) has been around for years. Over 1 million active installs. It does three things:

1. Database Cleanup

This is the core feature. It removes:

Post revisions
Auto-drafts
Trashed posts
Spam and trashed comments
Expired transients
Orphaned postmeta and commentmeta
Pingbacks and trackbacks

You can schedule these cleanups to run automatically. The premium version adds multisite support and more granular control.

2. Image Compression

Even the free version includes image compression via reSmush.it - lossy and lossless compression, WebP conversion, and bulk optimization. The premium version adds lazy loading and unused image size removal.

3. Page Caching

WP-Optimize added caching in recent versions. Page caching with preloading, browser caching headers, and GZIP compression.

That's the full picture. Database cleanup, image compression (even in the free version), and caching. Three features, one plugin.

Where WP-Optimize Stops

Here's what WP-Optimize doesn't touch:

It doesn't tell you WHY your database is slow. It removes old data, but it never looks at which queries are actually causing problems. You might have 50 slow queries from a WooCommerce meta_query, and cleaning up revisions won't help with any of them.

It doesn't analyze autoload bloat. The wp_options table is often the biggest performance killer in WordPress, and the problem isn't old data - it's autoloaded options from plugins you deactivated months ago. WP-Optimize doesn't touch autoload settings. If you want to understand why autoload matters, I wrote about the wp_options autoload trap in detail.

It doesn't help with debugging. No slow query detection, no callback profiling, no system diagnostics. If something is wrong, WP-Optimize can't tell you what.

It doesn't manage your configuration. Need to toggle WP_DEBUG or change WP_MEMORY_LIMIT? You're editing wp-config.php by hand.

What WP Multitool Does Differently

WP Multitool isn't a database cleanup plugin. It's 14 modules covering optimization, debugging, and site management. But let me focus on the overlap first.

Database Cleanup: Both Do It

WP Multitool's Database Optimizer module handles the same cleanup tasks - revisions, transients, orphaned data, table optimization. No meaningful difference here. Both get the job done.

Autoload Optimization: Only WP Multitool

This is where it gets interesting. WP Multitool's Autoloader Optimizer scans every autoloaded option in wp_options and classifies them:

Active plugin options - never touched (safe)
Inactive plugin options - candidates for optimization
Oversized options (>10KB) - flagged for review
Known bloat patterns - tracker/cache leftovers

Then it disables autoload on the candidates. Not delete - just stop loading them on every single page request. With a full backup and one-click restore if anything breaks.

Depending on how many deactivated plugins left options behind, disabling their autoload can save 100KB-2MB of memory per request. WP-Optimize doesn't even look at this.

Slow Query Detection: Only WP Multitool

The Slow Query Analyzer monitors your database queries and catches the ones that take too long. Then it runs MySQL EXPLAIN to tell you exactly why - missing index, full table scan, bad join. And it gives you the SQL to fix it.

WP-Optimize cleans up old data. WP Multitool catches the queries that are slow right now.

Everything Else: Only WP Multitool

Here's the full list of what WP Multitool includes beyond what WP-Optimize offers:

Config Manager - edit wp-config.php from the admin, no SSH needed
Find Slow Callbacks - profile every hook callback to find bottlenecks
Frontend Optimizer - defer scripts, remove jQuery Migrate, disable dashicons, clean head
Plugin Performance Score - see which of your plugins is the heaviest, right on the Plugins page
System Info - PHP, MySQL, server config at a glance
Image Manager - manage image sizes, remove unused ones
Shortcode Inspector - find and test every shortcode on your site
Quick Updater - drag-drop plugin updates from ZIP
Package Downloader - download any plugin/theme as ZIP
Plugin Reactivator - one-click deactivate+reactivate for troubleshooting
Dashboard Widget Manager - control what shows on the dashboard

That's 14 modules replacing what used to take 6 separate plugins.

Side-by-Side Comparison

Feature	WP-Optimize (Free)	WP-Optimize (Premium)	WP Multitool
Database cleanup	Yes	Yes	Yes
Scheduled cleanup	Yes	Yes (more granular)	No
Image compression	Yes (via reSmush.it)	Yes + lazy loading	No
Page caching	Yes	Yes (advanced)	No
Autoload optimization	No	No	Yes
Slow query detection	No	No	Yes
EXPLAIN analysis	No	No	Yes
Config management	No	No	Yes
Hook profiling	No	No	Yes
Frontend optimization	No	No	Yes
Plugin benchmarks	No	No	Yes
System diagnostics	No	No	Yes
Multisite support	No	Yes	No
Price	Free	$49-$199/year	$199/year

Notice something? WP-Optimize and WP Multitool barely overlap. The only shared feature is database cleanup. Everything else is different.

When to Use Which

Use WP-Optimize when:

You just need database cleanup and maybe image compression
You want scheduled automatic cleanups
You need page caching and don't want a separate caching plugin
Budget is tight (free version covers the basics)
You're running multisite (premium feature)

Use WP Multitool when:

Database cleanup isn't solving your performance problems
You need to understand WHY your site is slow, not just clean old data
Autoload bloat is killing your memory usage
You want one plugin instead of six separate tools
You manage client sites and need debugging + optimization in one place

Use both when:

Honestly? There's less reason to run both than with Query Monitor. WP Multitool's Database Optimizer covers the cleanup. But if you're already using WP-Optimize for image compression and caching, there's no conflict - they don't overlap on anything else.

The Real Difference

WP-Optimize is a janitor. It cleans up after the mess.

WP Multitool is a mechanic. It finds what's broken and helps you fix it.

Both are useful. But if your site is slow and you've already cleaned the database, the janitor can't help you anymore. You need someone who can look under the hood.

Try It

WP-Optimize is on wordpress.org - solid choice if database cleanup is all you need.

If you need more, check out WP Multitool. Use code startups2026 for 10% off.

And if you're not sure whether your problem is old data or slow queries - read why caching plugins don't fix slow WordPress sites. It might save you hours of troubleshooting.

Originally published at https://wpmultitool.com/blog/wp-multitool-vs-wp-optimize/

Query Monitor Shows You the Problem. It Won't Fix It.

WP Multitool — Wed, 08 Apr 2026 13:27:57 +0000

You found the slow query. Now what?

That's the question I kept asking myself after staring at Query Monitor's panel for the hundredth time. It tells you which queries are slow. It shows you which plugin is responsible. It even highlights duplicates. But then it just... stops. If you've ever googled "query monitor alternative" hoping to find something that goes beyond diagnosis - this is the honest comparison I wish I'd had a year ago. Not a "our tool is better" sales pitch - an actual breakdown of when each tool makes sense.

What Query Monitor Does Well

Let me be clear - Query Monitor is an excellent plugin. John Blackbourn has maintained it for years, Automattic sponsors it, and it has 200,000+ active installs for a reason.

Here's what QM gives you:

Every database query on the current page - with execution time, caller function, and component attribution
PHP errors with full stack traces
HTTP API calls - response codes, timing, which plugin triggered them
Hooks and actions - every callback attached, in order
Enqueued scripts and stylesheets - including broken dependency chains
Template hierarchy - which template files loaded
Environment info - PHP version, database, server config
Conditional checks - is_single(), is_home(), all of them

The v4.0 rewrite with Preact made the UI faster too. For quick debugging sessions - "why is this page loading 47 queries?" - nothing beats it.

It's free, it's lightweight when you need it, and every WordPress developer should have it in their toolkit. I still use it.

Where QM Stops

Here's the problem. QM is a debugger. It shows you a snapshot of what's happening on one page, at one moment, while you're watching.

That creates three blind spots:

1. No Historical Data

QM shows the current page load. Close the tab, the data is gone. You can't answer "are slow queries getting worse this month?" or "which queries spiked after Tuesday's update?" There's no log. No trends. No baseline to compare against.

I've had situations where a client reports their site was slow yesterday evening. By the time I check, everything looks fine in QM. The slow query happened during a WooCommerce cron job at 11 PM. QM never saw it.

2. No Production Monitoring

QM is a dev tool. It adds overhead - it hooks into every query, every hook, every HTTP call to build its debug panel. That's fine during development, but you don't want that running on production 24/7.

But slow queries don't happen in your local Docker container with 50 products. They happen on production with 50,000 products, 200 concurrent users, and a cron job running in the background. The exact environment where QM shouldn't be active.

3. No Actionable Fixes

This is the biggest one. QM tells you: "this query took 1.2 seconds." Ok. Now what?

If you're a senior developer, you know to run EXPLAIN on it, check for missing indexes, maybe rewrite the query. But QM doesn't do any of that for you. It's a microscope, not a surgeon.

For a site owner or a junior dev, that slow query number is basically useless information. You know something is wrong but you don't know how to fix it.

What WP Multitool Does Differently

WP Multitool's Slow Query Analyzer approaches the problem from the other end. Instead of showing everything happening on one page, it continuously monitors for slow queries and then analyzes them.

Always-On Monitoring

A lightweight MU-plugin hooks into WordPress's query system and captures any query exceeding your threshold (default: 0.1 seconds). It uses WordPress's built-in SAVEQUERIES constant, so it works with the same mechanism QM uses - but selectively.

By default, it only monitors admin pages to keep overhead minimal. But you can flip the "Monitor Admin Only" toggle off, and it captures everything - frontend requests, cron jobs, REST API calls. That 11 PM WooCommerce cron job your client complained about? Logged. The query that only gets slow when wp_options hits 500 autoloaded rows? Logged.

Everything goes into a wp_slow_query_log table with auto-purge at 5,000 entries, so it doesn't bloat your database.

EXPLAIN-Based Analysis

Here's where it gets interesting. For each captured slow query, the analyzer runs MySQL's EXPLAIN command and breaks down what's actually happening:

EXPLAIN SELECT p.ID, p.post_title, pm.meta_value 
FROM wp_posts p 
JOIN wp_postmeta pm ON p.ID = pm.post_id 
WHERE pm.meta_key = '_price' 
AND pm.meta_value > 100 
ORDER BY pm.meta_value DESC;

Then it gives you:

A health score (1-10) based on the EXPLAIN output
Whether it's doing a full table scan
Which indexes exist and which are missing
A ready-to-run CREATE INDEX statement if one would help

If you've ever tried to read a MySQL EXPLAIN plan manually, you know it's not exactly beginner-friendly. The analyzer translates it into plain language.

Analysis at Shutdown

When a slow query is detected, the EXPLAIN analysis runs during WordPress's shutdown hook - after the response has been sent to the browser. So the visitor gets their page, and then the analysis happens. For queries that need re-analysis, there's also a WP-Cron batch process that picks them up later.

It Doesn't Auto-Fix Anything

This is important. WP Multitool suggests fixes - it will tell you "add this index" or "this query needs a rewrite." But it never runs those fixes automatically. You review, you decide, you execute. No surprises.

Side-by-Side Comparison

Here's the honest breakdown:

Feature	Query Monitor	WP Multitool (SQAA)
See queries on current page	Yes	No
PHP error tracking	Yes	No
Hook/action inspection	Yes	No
Template hierarchy	Yes	No
Script/style dependencies	Yes	No
HTTP API monitoring	Yes	No
Persistent query logging	No	Yes
Production-safe monitoring	No	Yes
EXPLAIN analysis	No	Yes
Index recommendations	No	Yes
Historical trends	No	Yes
Post-response analysis	N/A	Yes
Overhead	Moderate (hooks everything)	Low (only slow queries)
Price	Free	$199/year (14 modules)
Active installs	200,000+	New

Look at that table. QM wins on breadth of debugging data. WP Multitool wins on depth of query analysis and production monitoring. They're not really competing - they're solving different problems.

When to Use Which

Use Query Monitor when:

You're debugging a specific page that's loading slow right now
You need to trace which plugin is enqueuing a broken script
You want to see the full hook execution order
You're developing locally and need real-time feedback
You need to check template hierarchy or conditional functions
Budget is zero (QM is free and always will be)

Use WP Multitool when:

You need ongoing production monitoring for slow queries
You want to know WHY a query is slow, not just THAT it's slow
You need index recommendations you can actually implement
Your client reports "the site was slow yesterday" and you need data
You want historical trends to catch regressions after updates
You also need autoload optimization, config management, plugin performance scoring, and 11 other modules

Use both when:

You're a developer managing production WordPress sites. QM for active debugging sessions, WP Multitool for the 23 hours a day when you're not watching.

The Real Question

The comparison isn't really QM vs WP Multitool. It's debugging vs monitoring.

Debugging is reactive. Something breaks, you investigate, you fix it, you move on. QM is perfect for this.

Monitoring is proactive. You catch the problem before users complain - or better yet, before it becomes a problem. You see trends. You can prove that last week's plugin update added 3 slow queries that weren't there before. That's what the Slow Query Analyzer does.

Most WordPress sites need both. A site without debugging tools is flying blind during development. A site without monitoring is flying blind in production.

The difference is what happens between your debugging sessions. With QM alone, you have no idea what's happening while you're not looking. And in my experience, that's when the worst problems happen.

Try It

Query Monitor is on wordpress.org - install it if you haven't already. Seriously. Every developer should have it.

WP Multitool ships the Slow Query Analyzer as one of 14 modules. Check it out at wpmultitool.com - and if the comparison here helped you decide, use code startups2026 for 10% off.

If you're curious about reading those EXPLAIN plans yourself, I wrote a complete guide to MySQL EXPLAIN for WordPress that covers everything the analyzer does under the hood.

And if you're wondering whether your site even has slow query problems - caching alone won't save you. That's a different rabbit hole, but worth reading.

Originally published at https://wpmultitool.com/blog/wp-multitool-vs-query-monitor/

I Benchmarked 4,999 WordPress Plugins for Speed. Here Are the Results.

WP Multitool — Wed, 08 Apr 2026 13:25:39 +0000

I benchmarked 4,999 WordPress plugins for their exact speed impact. Here are the results.

The Setup

Each plugin was tested in a clean WordPress environment. Metrics captured:

TTFB (Time to First Byte) impact
Database queries added per page load
Memory usage overhead
HTTP requests added

No Lighthouse scores. No synthetic tests. Server-side measurement only.

The Big Findings

WooCommerce scored F

The most popular WordPress e-commerce plugin (5M+ active installs) is the heaviest plugin in the entire database. It adds 19 database queries to every single page load - not just product pages. Your blog post, your about page, your contact page - all taxed equally.

86% of plugins are fine

2,357 plugins scored A. Another 1,945 scored A-. That's 86% with negligible performance impact.

The popular advice of "fewer plugins = faster site" is wrong. It's not about count. It's about which plugins you install.

The 23x page builder gap

Elementor adds approximately 47ms to every page load. Beaver Builder adds 2ms. Same category, same purpose, 23x performance difference.

Contact Form 7 is invisible

0ms added load time. 0 extra database queries. 0 additional memory. If every plugin developer built like CF7, nobody would need performance optimization plugins.

Yoast SEO is surprisingly well-optimized

Despite being massive in scope, Yoast scores A. Credit where it's due.

Score Distribution

Grade	Count	Percentage
A	2,357	47%
A-	1,945	39%
B+	199	4%
B	113	2%
B-	150	3%
C+	67	1%
C	51	1%
C-	28	1%
D	8	0.2%
F	3	0.06%

The F-Grade Plugins

Only 3 plugins out of 4,999 scored F:

WooCommerce - 19 database queries per page load
EditorsKit - Gutenberg block toolkit
Cozy Blocks - Another Gutenberg toolkit

Notable Scores for Popular Plugins

Plugin	Score	Notes
Yoast SEO	A	Well optimized despite scope
Wordfence Security	A-	Better than expected for a security plugin
Contact Form 7	A	Zero measurable impact
Elementor	C-	Heavy page builder
Jetpack Boost	C	Ironic for a "speed" plugin
All in One SEO	C	Significant overhead
WooCommerce	F	19 queries per page

The Database

The full database is free to search at makewpfast.com. No signup, no paywall. Look up any of the 4,999 tested plugins before you install them.

Methodology

Each test runs on:

Clean WordPress install (latest version)
Default theme (Twenty Twenty-Four)
PHP 8.3, MySQL 8.0
Measured with SAVEQUERIES + server-side timing
5 page loads per test, averaged
Scores are relative to baseline (clean WP with no plugins)

If you think the methodology could be improved, I'm genuinely interested in feedback.

I built this as part of MakeWPFast, a WordPress plugin performance database. I also maintain WP Multitool - a developer toolkit for WordPress performance optimization.

Emergency WordPress Recovery: What to Do When Your Site Goes Down

WP Multitool — Wed, 08 Apr 2026 12:14:35 +0000

Originally published at https://makewpfast.com/emergency-wordpress-recovery-what-to-do-when-your-site-goes-down/

Your site is down. Visitors see an error page. Revenue is dropping by the minute. Panic sets in. Here is your emergency action plan — a calm, systematic approach to getting your WordPress site back online as fast as possible.

Step 1: Confirm the Outage (30 seconds)

Before doing anything, verify the site is actually down and it is not just your connection:

Try from a different device or network (mobile data)
Use an external uptime checker like downfor.io or isitdown.site
Check if it is the entire site or just wp-admin

Step 2: Identify the Error (2 minutes)

The error message tells you where to look:

White screen → PHP fatal error (check error logs)
500 Internal Server Error → Server-side issue (check error logs, .htaccess)
502/504 Gateway Timeout → PHP-FPM crashed or overloaded
Database connection error → MySQL is down or credentials are wrong
“Briefly unavailable for maintenance” → Stuck update (delete .maintenance file)
403 Forbidden → Permission issue or security plugin lockout
DNS or SSL error → Domain/hosting configuration issue

Step 3: Apply the Targeted Fix

PHP Fatal Error / White Screen

Check wp-content/debug.log or server error log
Rename the offending plugin/theme folder via FTP/SSH
If you cannot identify the cause, rename the entire plugins folder

Database Connection Error

Verify MySQL is running: systemctl status mysql
Check wp-config.php credentials match your database
Check if the database disk is full: df -h

Stuck Maintenance Mode

Delete the .maintenance file in your WordPress root directory. That is it.

Security Plugin Lockout

If a security plugin (Wordfence, Sucuri, iThemes) locked you out, rename its folder via FTP/SSH to deactivate it. Then log in and reconfigure.

Step 4: Verify the Fix

Load the homepage
Log into wp-admin
Test key functionality (forms, checkout, login)
Check the error log for new errors

When You Cannot Fix It Yourself

If you have gone through these steps and your site is still down — or if you do not have FTP/SSH access — you need professional help fast. fix-wp.com is built for exactly this moment. Submit your site, and AI-powered diagnostics identify and fix the issue, usually within an hour. A full backup is created before any changes, you get live progress updates, and you only pay if the fix works.

After Recovery: Build Your Safety Net

Set up automated daily backups (and test restoring them)
Enable uptime monitoring with instant alerts
Keep a recovery document with your hosting credentials and emergency steps
Maintain a staging environment for testing changes before they go live

Every site goes down eventually. The difference between an hour of downtime and a day of downtime is preparation.

    Get WordPress Performance Tips
    Join developers and agency owners who get backend optimization strategies, tool releases, and deep-dive guides.





        Join Free


    No spam. Unsubscribe anytime. We respect your privacy.