Answers to common questions about setup, features, pricing, cancellation, and troubleshooting.
Back to Top--skip-plugins=<offending plugin name>) that excludes only the broken plugin from loading, so even if it is throwing a fatal error, the rollback itself is guaranteed to execute. Sites with "Aggressive Auto-Fix Mode" enabled will additionally restore the DB and files together to the pre-update state as a last resort if the site is still broken. Note that themes are updated in bulk and are therefore not subject to per-theme rollback. Severe database corruption and browser-only (no-SSH) mode may also fall outside the scope of automatic recovery.
When a post-core HTTP check detects an issue, the app first rolls back the core to its previous version. What happens next depends on the rollback outcome β there are two paths:
In the latter case, please verify and repair the core (via the WordPress dashboard or manual SSH as needed) before re-running maintenance. The execution log will explicitly state "Subsequent updates halted after core rollback", and this is reflected in the report and email notification.
For most use cases, leaving this OFF (default) handles the majority of issues. Turning it ON adds a last-resort comprehensive recovery layer that activates only if the site is still broken after the main maintenance run completes.
| Feature | OFF (default) |
ON |
|---|---|---|
| π¦ At maintenance start | ||
| DB backup before updates | β | β |
| π§ During each update (one plugin at a time + core) | ||
| Pinpoint rollback Post-update HTTP check β 5xx / 4xx regression / unreachable detected β roll back to previous version β verify recovery | β | β |
| WP-CLI safe mode (per-operation skip strategy) Full skip for core/DB/translation; full load for plugin/theme detect/update; targeted skip for rollback | β | β |
| π Post-maintenance verification | ||
| Home-page HTTP check & screenshot comparison | β | β |
| Identify responsible plugin from fatal logs and deactivate β» Requires SSH to be configured | β | β |
| Email notification (success / attention / error) | β | β |
| β‘ Last-resort recovery (if the site is still broken after the steps above) | ||
| Full DB rollback (restore from backup) | β | β |
| Bulk file rollback for all updated plugins / core β» Premium plugins not on WordPress.org are excluded from file restoration (deactivated only) | β | β |
Force cache flush (wp cache flush + cache directory clear) | β | β |
| Automatic theme switch (to Twenty series temporarily) β» If no Twenty series theme is installed, the switch is skipped and a warning is sent | β | β |
| Additional plugin deactivation (if log analysis finds another cause) | β | β |
| wp doctor health diagnostic | β | β |
When to enable it
Important notes
A good approach: start with it OFF β the rows under π¦ / π§ / π already cover most failures. Turn it ON only when you encounter complex incidents that those layers couldn't resolve.
No. Themes are not subject to per-theme rollback. Theme updates run as a single bulk operation (wp theme update --all), so if the site breaks afterwards, there is no way to identify which specific theme caused the failure.
Plugin and WordPress core updates are run one-by-one with an HTTP check between each, which is why pinpoint rollback works for them. Themes can't be handled the same way by design.
What happens when a theme update breaks the site:
Note: theme-related failures are statistically less than 1/10 the frequency of plugin-related failures in production, which is why this is a deliberate priority trade-off.
Yes β reliably. The app dynamically attaches a targeted skip directive (--skip-plugins=<target plugin name>) to the WP-CLI rollback command, which causes WordPress to skip loading only that specific broken plugin while keeping everything else loaded.
As a result, even if the just-updated plugin is throwing a fatal error, the WP-CLI process performing the rollback is unaffected by it and can complete the file replacement (restoring the previous version) reliably. Other healthy plugins and paid plugins remain loaded so their custom update filters keep firing normally.
The actual sequence:
wp plugin install X --version=OLD --force --skip-plugins=XNote: PHP-CLI (command line) and PHP-FPM (web) run as separate processes. Even if the web side is completely down due to a fatal, the SSH-side rollback runs independently.
wpmm_backups/ folder within the WordPress installation directory) and locally on the PC running the app. During maintenance, a backup_YYYYMMDD_HHMMSS.sql file is automatically created and downloaded to your local machine via SSH/SFTP. Only the latest 3 generations are kept both on the server and locally β older files are automatically removed so the disk does not fill up over time.wpmm_backups/ folder on the server is protected by two layers of defense, applied automatically..htaccess blocks all requests: On Apache-based hosts (Xserver, Sakura, Heteml, ConoHa WING, and most major shared hosting), the folder includes an .htaccess file that returns 403 Forbidden for everything inside. Even if someone guesses the URL of a SQL file, the server refuses to serve it. The rules are written to work on both Apache 2.2 and 2.4.index.php as an Nginx fallback: For Nginx-based hosts that ignore .htaccess, the folder also contains an index.php that returns 403 Forbidden directly via PHP β providing the same protection through a different mechanism./opt/php-8.2/bin/php /usr/bin/wp). This works for the majority of sites./opt/php-8.3/bin/php /usr/bin/wp). Leave blank to use the profile value.wp over SSH (CLI side) are managed separately. The CLI side defaults to an old PHP (7.0 series), which then fails to parse modern WP-CLI compatibility code./opt/php-<version>/bin/php /usr/bin/wp/opt/php-7.4/bin/php /usr/bin/wp/opt/php-8.1/bin/php /usr/bin/wp/opt/php-8.3/bin/php /usr/bin/wpNew in v1.6.2. Open the dashboard via the "Plugin Updates" button in the toolbar, tick the (site Γ plugin) pairs you want, then click "Update Selected Plugins" in the footer. Only the plugins you selected will be updated.
The only difference from a regular maintenance run is the scope:
This is fundamentally different from other tools' "Update All" buttons. Those run without a safety net and can't recover from failures at the plugin level. With Selected Plugin Update, you keep the full safety policy while narrowing the scope.
The log history shows a "Selected Update" tag along with the target plugin names. PDF/HTML reports also include a clear notice that "core, themes, and translations were intentionally not updated in this run," so you can use the same artifact for client reporting.
The app runs on the following environments:
| Item | Windows | Mac |
|---|---|---|
| OS | Windows 10 / 11 (64-bit) | macOS 13.5 Ventura or later |
| CPU | 64-bit processor | Intel / Apple Silicon |
| RAM | 4 GB or more recommended | |
| Required | Internet connection, WordPress 5.0 or later | |
SSH uses a key pair instead of a password. The private key is a file stored on your computer; the public key is registered on the server. Both are required to connect.
How to generate a key on major hosts:
For full step-by-step instructions, see the "Before You Start" section in the User Guide.
Enter the file path to where you saved the private key on your computer.
~/.ssh/your-key.pemC:\Users\YourName\.ssh\your-key.pemWe recommend moving the downloaded key file into your .ssh folder (create it if it doesn't exist), then entering that path.
In most cases, leave it blank. SiteGround, AWS Bitnami images, and most major hosts include WP-CLI by default β leaving this field empty will work automatically.
Only fill this in if you have installed WP-CLI at a custom path, or if the connection test reports "WP-CLI not found." If that happens, see the next FAQ item for a GUI-only fix.
Try the new "π Diagnose" button (v1.5.9 or later), located next to the "Test Connection" button in the SSH profile editor. The diagnostic observes your server in read-only mode and proposes a suggested WP-CLI Path as a best-effort reference. It has been empirically tested across 4 host types. The suggestion is not guaranteed to be correct β please verify with the connection test before saving.
If the diagnose suggestion doesn't help, install WP-CLI manually with this single SSH command:
mkdir -p ~/bin && cd ~/bin && \
curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
mv wp-cli.phar wp && chmod 755 wp && ~/bin/wp --infoIf ~/bin/wp --info prints WP-CLI's version banner, you're done. Most hosts have ~/bin in $PATH, so leaving "wp" in the WP-CLI Path field will work; otherwise enter the absolute path /home/<username>/bin/wp.
β οΈ Avoid uploading wp-cli.phar via web file manager or FTP. Web-based file managers and some FTP clients can corrupt the PHAR signature in transit, leading to a runtime "broken signature" error. We've reproduced this on multiple hosts. Downloading directly on the server via SSH+curl is the most reliable approach.
Detailed step-by-step instructions are in the User Guide under "What is SSH & WP-CLI?" β "If the connection test reports 'WP-CLI not found'."
Your source IP address is most likely being temporarily blocked by the hosting provider. Many shared hosting providers, including Xserver, have a protection mechanism that refuses connections from a source IP after a short burst of SSH authentication failures. Xserver support officially confirmed to us that they use fail2ban to temporarily block source IPs that exceed the authentication retry limit (the specific thresholds and ban duration are kept private for security reasons).
This often happens when you manage multiple SSH keys in ~/.ssh/ or in an SSH agent. A single connection can end up offering several keys before reaching the intended one β and if the keys the server doesn't accept are tried first, the failure count can hit the provider's threshold.
As of v1.6.5, the app is hardened to use only the single key you specified in the site settings, so this situation should no longer arise from the app's behavior. If you are on v1.6.4 or earlier, please consider updating to the latest version.
If you're currently being blocked:
ssh -i ~/.ssh/your_key -o IdentitiesOnly=yes -o IdentityAgent=none -p 10022 username@hostname 'echo ok'The error message has two severity levels: mild = Connection closed by [server IP] port 10022 (TCP completes but the server closes the connection immediately), severe = Connection refused (rejected at the TCP layer). Both are symptoms of the same fail2ban mechanism, and continued retries while blocked tend to escalate from mild to severe.
Note: this protection mechanism applies to any SSH client (Tera Term, the macOS Terminal, your IDE, etc.), not just this app. If you manage many sites from the same machine, we recommend assigning a dedicated key per server and making sure each connection (in this app's site settings, or in your ~/.ssh/config) explicitly points to that one key.
Yes β the warning was intentionally removed in v1.6.5.
The app uses the paramiko Python SSH library internally. Unlike the OpenSSH command-line client (ssh / scp), paramiko does not enforce the StrictModes check on private key files, so a key file with 644 permissions can usually still be used to connect successfully.
v1.6.3 and v1.6.4 displayed the warning as a precaution, but the "fix and continue" auto-retry path it triggered was contributing to repeated connection attempts in some environments, which in turn could cause the hosting provider's protection mechanism to temporarily block the source IP. We removed the warning in v1.6.5 for that reason.
The general recommendation for private key permissions hasn't changed. On Mac / Linux, chmod 600 ~/.ssh/your_key is still the OpenSSH-recommended setting; on Windows, granting "full control to the current user only, with inheritance disabled" via icacls is the equivalent. It's not strictly required for this app to function, but if you also use the OpenSSH command-line client, or if your PC is in a shared environment, we recommend tightening the permissions manually.
Some shared hosts (Heteml in Japan, certain CloudLinux/cPanel configurations, etc.) only expose versioned PHP commands like php8.3 and don't put a plain php on the shell PATH. The WP-CLI shebang #!/usr/bin/env php then fails because env can't locate php.
The fix is to set the WP-CLI Path to the absolute PHP binary plus the WP-CLI file, for example:
/usr/local/bin/php8.3 /home/users/0/<username>/bin/wpThe "π Diagnose" button (v1.5.9 or later) detects this situation automatically and proposes the absolute-path form of the command. Click "β Insert this value into the WP-CLI Path field" to apply, then re-run the connection test to verify.
The proposed value is a best-effort suggestion only. Always verify with the connection test, since host-specific quirks may make the suggestion inaccurate.
Yes. As of v1.6.0, the "π Diagnose" result in the SSH profile editor includes a "π¦ Install WP-CLI automatically" section when applicable (only shown when WP-CLI is missing AND the home directory is writable AND GitHub is reachable). This installs the WP-CLI PHAR onto your server over SSH, in one click.
A two-stage workflow prevents accidental damage:
~/wpmm_install_test_<timestamp>/wp. Your existing ~/bin/wp is completely untouched, so you can try the install safely.wp file already exists, it is preserved as wp.broken_backup_<timestamp> (the latest 3 backups are kept automatically).No broken state is left behind on failure. The pipeline downloads to a tmp file, validates the size, runs --info for behaviour verification, and only then atomically renames the file into its final location. If any step fails, the tmp is deleted and any prior wp backup is automatically restored.
Every SSH command, stdout, stderr, and exit code is saved to logs/install_wpcli_<timestamp>.json for later inspection.
Supported hosts: any server with a writable home directory, either curl or wget, and outbound HTTPS access to GitHub (most shared hosts qualify). Restricted environments that block outbound HTTPS (some managed hosting setups) will receive an explicit error message.
Added in v1.5.9, the Diagnose button is next to "Test Connection" in the SSH profile editor. It connects to your server over SSH and runs read-only commands to observe:
php lives (PATH or absolute candidates)~/bin and whether it actually runsFrom these observations it proposes the most likely WP-CLI Path as a best-effort reference. No files are written to your server (it briefly creates and immediately deletes a single ~/.wpmm_diag_test_$$ file solely to test write permission).
β οΈ The suggestion is not a guarantee. Host-specific quirks (custom PHP selectors, chroot environments, proxy constraints, etc.) may not be fully covered, so the proposed value can be inaccurate. Always verify with the "Test Connection" button after applying the suggestion.
Empirically tested on Xserver, Sakura Internet, ConoHa WING, and Heteml. The same patterns are likely to work on most major hosts (SiteGround, Bluehost, DreamHost, Hostinger, etc.) but this hasn't been formally validated.
Yes β two complementary systems are available: categories and tags.
Manage them under β Settings β "Categories & Tags". Assign them in the site add/edit dialog, and filter the list with the dropdowns above the registered-site table.
The tag filter has both OR (any of the selected) and AND (all selected) modes, and works in combination with the text search.
Yes. Click the "π Logs βΊ" link in the "Last Run" column of any row in the registered-site list. The log dialog opens scoped to just that site.
Renaming a site keeps its log history intact. Each site has a stable internal identifier, so logs from before and after a rename appear under the same scope.
Click "Show all logs" at the top of the dialog to leave the scoped view. Older logs (recorded before v1.5.8) don't have the internal identifier, so they fall back to site-name matching.
Yes β three flexible options are available:
In every case, a confirmation dialog shows the **exact number of entries** that will be deleted. "Delete all" only appears when there is no filter at all β kept as the explicit last resort.
A confirmation dialog appears before deletion so your site data stays safe.
Site data itself (SSH info, WordPress paths, history, etc.) is never affected by category/tag operations.
Yes β fully supported since v1.6.2. The WordPress tab of the site edit screen now includes a collapsible "π Basic auth (optional Β· only if the site is HTTP basic-auth protected)" section where you can enter a username and password. The password is stored encrypted.
Basic auth credentials are used by these processes:
SSH / WP-CLI updates themselves are not affected by basic auth, so if you don't use the three features above, the credentials are optional. The same section contains a "π Test connection + capture thumbnail" button that verifies connectivity and captures the site list thumbnail in a single click.
Recommended for: staging environments, dev environments, internal sites, and any other WordPress site protected by HTTP basic authentication.
Sometimes a flood of "PHP Deprecated: ... is deprecated" warnings appears and fetching the plugin list or detecting available updates fails. These warnings are emitted by the server when an older version of WP-CLI is combined with a newer PHP (8.2 or later). Neither the app nor your site is broken.
This is addressed in v1.6.8. The app now suppresses these warnings and reliably extracts the result even when it is buried in warning output, so the plugin list and update detection succeed. Please update to v1.6.8 or later and try again.
If you are able to update the server-side WP-CLI to a newer version (2.8 or later), the warnings stop appearing altogether. If you're not sure how, please ask your hosting provider's support.
wpmm_backups/ folder within the WordPress installation directory (the folder specified as "WordPress Path" in the site settings), named backup_YYYYMMDD_HHMMSS.sql. You can retrieve them manually via FTP or your hosting control panel's file manager.wpmm_backups/ folder is protected by .htaccess and index.php files to block external access.
~/.ssh/id_rsa) from the old PC to the new oneNew in v1.6.2. Open it via the "Plugin Updates" button in the toolbar. It's a manager-style dashboard that shows every "plugin update available" across all your sites in a single view.
Entries are grouped by plugin name, so for example you'll see "Elementor: 3 sites need updating (4.0.0 β 4.0.8)" β making it obvious which plugin is outdated where. Expanding a row reveals which sites are affected and their before/after versions.
When to use which:
In the dashboard, tick the checkboxes and click "Update Selected Plugins" to update only the chosen (site Γ plugin) pairs. The full safety net (DB backup, HTTP checks, pinpoint rollback, visual verification, summary email) runs exactly as in a regular maintenance.
For large site collections, the initial scan can take 30β60 seconds (parallel SSH). Results are cached in the browser for 24 hours and shown instantly on the next launch (cache is automatically invalidated after running maintenance, so you always see fresh data when it matters).
/wp-login.php. Check that the "WordPress Admin URL" in the site settings matches the current login URL.
10022 (note: not the standard 22), SAKURA Internet (Standard plan or higher) = 22, ConoHa WING = 8022. Other hosts (e.g. Heteml) usually use 22 by default, but the port may be customized per server, so always confirm in the SSH settings screen of your hosting control panel.chmod 600 on Mac/Linux or icacls (current user only, full control, inheritance disabled) on Windows with a single click. Only file attributes on your computer are changed β the key contents and the server are not modified.openssl ec -in sakura_key.pem -out converted_key.pemchmod 600 converted_key.pem. Or just upgrade to v1.6.3 or later, which handles this automatically.)
.ppk file as the "Private key path" in the site settings.wpmm_backups/ folder within the WordPress installation directory (the folder set as "WordPress Path" in your site settings), named backup_YYYYMMDD_HHMMSS.sql. Retrieve it manually via FTP or your hosting file manager.
.exe installer. It will overwrite the existing installation automatically..dmg and drag the .app to the Applications folder. When prompted with "Replace existing item?", click Replace.
The version badges added in v1.6.2 appear on each site card as Core 6.9 / PHP 8.3. These values are captured and refreshed on every maintenance run.
Common reasons a badge is missing:
The Core / PHP toolbar filters only work for sites whose version is already captured. The "Unknown (not yet run)" filter option makes it easy to find "sites that haven't been run yet."
Badges show a short form (major.minor only); hover over them to see the full version (e.g. 6.9.4) in a tooltip.
PHP Deprecated: Creation of dynamic property ..." errors. What's wrong?
This happens on servers running PHP 8.2 or later when the server-bundled WP-CLI is a slightly older version (often seen on Xserver and similar shared hosts).
PHP 8.2 changed "creation of dynamic properties" to be deprecated. Older WP-CLI versions emit a large volume of these deprecation warnings internally. The app's SSH test and WP-CLI path test use simple command invocations that pass even with the warning noise, but commands like wp plugin list --format=json that return structured data fail to parse because the warnings get mixed into the output.
As of v1.6.6, the app absorbs this warning noise automatically, so this issue resolves itself once you update. If you are on v1.6.5 or earlier, please consider updating to the latest version.
Note that SSH-based maintenance execution itself is unaffected β only plugin list fetching and the cross-site dashboard are impacted.
PHP Parse error: syntax error, unexpected '?'" errors. What's wrong?
This is caused by an old PHP version being invoked when you SSH in (PHP 7.0 or earlier). Modern WordPress core code includes nullable type hints like ?string (introduced in PHP 7.1), so old PHP fails with a syntax error when it tries to parse it.
The PHP that serves the website is often a newer version, so the site itself loads fine, but commands executed via SSH end up invoking the older PHP. This is a common gap on Xserver and other shared hosts that maintain separate PHP versions for web and CLI.
In the site edit dialog β "π₯ SSH" tab β "WP-CLI path (optional override)", specify a WP-CLI command that runs through a newer PHP. For Xserver:
/opt/php-8.0/bin/php /usr/bin/wp
Any PHP version available on Xserver ("PHP Ver. switch" in the server panel) will work (PHP 7.4 / 8.0 / 8.1 / 8.2). PHP 8.0 or later is recommended.
Save and retry the plugin fetch. The WP-CLI path override is per-site, so other sites' settings are unaffected.
As of v1.6.6, the site list shows maintenance progress via frame colors. Each color means:
The green and red states persist for 24 hours, so you can look back later and see "which sites were run today, and which ones errored." When you start a new maintenance run, the green/red frames of sites that aren't included in the new run are preserved.
Also, as of v1.6.8, when maintenance finishes the selection checkboxes for the sites you just ran are cleared automatically. You can still tell which sites were maintained from the green/red frames described above (shown for 24 hours).
If your OS has "reduce motion" accessibility settings enabled (supported on macOS / Windows / Linux), the pulsing animation is replaced with a static border.
As of v1.6.6, the site list shows a "pending updates" count badge on the top-right of each site's π Plugins button. The red number is the count of plugins waiting for an update on that site.
The badge is shown when:
The badge is retained for 30 days, and hovering over it shows a tooltip with "last fetched: N days ago" so you can judge the data freshness. When you run maintenance on a site, that site's badge updates (or disappears) automatically β other sites' badges are unaffected.
Counts of 100+ are displayed as "99+" to keep the badge compact. Sites with 0 pending updates show no badge.
As of v1.6.6, the site list shows a "days since last maintenance" badge next to the last maintenance date. The color depends on the elapsed days, so sites that haven't been maintained recently stand out at a glance.
| Elapsed days | Color | Meaning |
|---|---|---|
| 0β14 days | Green | Recent β all good |
| 15β29 days | Gray | Standard β acceptable |
| 30β59 days | Amber | Caution |
| 60+ days | Red | Action needed |
The elapsed days are recalculated against the current clock, so the badge updates from "16 days ago" β "31 days ago" automatically as time passes.
Yes, this is a spec change in v1.6.6. Site list selections (maintenance queue checkboxes) are now preserved across these operations:
If you select sites across multiple pages, the "N selected Β· Clear all" chip in the toolbar shows the total count, and clicking "Clear all" wipes the entire selection at once.
Note: selections are automatically cleared when the app restarts. This prevents the case where stale checkboxes from a previous session cause unintended sites to be maintained.
Selections are tracked by each site's internal ID, so adding, removing, or reordering sites doesn't break the selection.