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