WordPress Maintenance

WordPress ships with a built-in way to store data temporarily — save something for a fixed window of time, and it stops being valid once that window closes. This is the transient API, and both WordPress core and countless plugins lean on it to cache things like external API responses or the results of expensive calculations. It’s a genuinely useful mechanism, but used without understanding how it actually behaves, expired entries can pile up and quietly bloat the database. Note: the transient API is WordPress core’s name for a small set of PHP functions — set_transient(), get_transient(), delete_transient() — built around the idea of a cache entry with an expiration. …

A WordPress database doesn’t tidy itself up over time. Spam comments pile up, expired transients linger, post revisions accumulate, and tables left behind by uninstalled plugins never quite go away. All of that adds up to bloated tables, and occasionally to actual table corruption. This is territory the admin dashboard barely shows you — but WP-CLI reaches it directly with two short commands: wp db check and wp db optimize. Note: WP-CLI’s wp db subcommands operate directly on the MySQL (or MariaDB) database WordPress uses, without going through the admin dashboard. Connection details are read automatically from wp-config.php. wp db check — verifying table health wp db check Under the …

Anyone managing several WordPress environments — production, staging, or separate installs for different languages — ends up re-typing SSH connection details and install paths every time they run a command. Building that connection string by hand each time invites mistakes: a copy-paste error, or reusing a stale path, can send a command to the wrong environment entirely. That risk matters most for write commands — bulk plugin updates or database operations — where hitting the wrong target has real consequences. WP-CLI has a built-in feature for exactly this problem: aliases. Note: A WP-CLI “alias” assigns a short name (like @production) to a set of connection details — an SSH target …

Comparing pricing models across four WordPress maintenance tools — what the shape of a price reveals about cost structure Background While surveying the major WordPress maintenance tools (ManageWP, MainWP, WP Umbrella, and InfiniteWP), one thing stood out once their pricing was laid side by side: this isn’t just a matter of “cheaper vs. more expensive.” The shape of the pricing itself differs completely from company to company. And that shape isn’t arbitrary — it closely mirrors how each company actually delivers its service. Four companies, four pricing shapes ManageWP: free core, stacked per-site add-ons The core dashboard is free. Features like Backup, Security, Reports, and White-Label are sold separately as …

The excluded-plugin setting that Playwright ignored — fixing browser-mode updates and false residual warnings The symptom In browser-mode maintenance (Playwright, no SSH), plugins marked as “excluded from update checks” were still being updated. After the run, a “plugin updates remaining” WARNING email arrived every time. The excluded plugins were intentionally left behind, but the residual check treated them as unfinished updates and fired a warning — a two-part problem: wrong behavior and a misleading alert. SSH path vs. Playwright path On SSH-capable sites, WP-CLI’s –skip-plugins flag carries the ignored_plugins list into the update command. That path already excluded them correctly. The Playwright path was different. browser_update_remaining_plugins() worked by clicking the …

In May 2026, bash commands sent over SSH stopped working correctly on WordPress sites hosted on Sakura Internet. The root cause: Sakura’s default login shell is csh, which can’t interpret bash syntax. We patched the codebase, consolidating all bash-syntax c.run() calls behind a _safe_run helper, and the problem went away. (That original incident is documented in the csh login-shell portability article.) Then in June 2026, a report came in: DB backups were failing every single time on all Sakura-hosted sites with an “SSH update error.” Why the same problem came back The cause: a new feature had walked into the same trap. The v1.6.9 development cycle added progress monitoring to …

Don’t show users a raw Playwright error — translating exceptions into friendly messages When something fails in Playwright, the exception message comes with a long block of debug information starting with Call log:. That’s useful while debugging, but showing it as-is to someone using a maintenance tool tells them nothing about what actually went wrong. Note: Stringifying a Playwright exception object usually produces not just the description of what failed, but several lines logging what the library internally tried to do along the way. The shape of the problem When Playwright times out, the exception message looks something like this: Timeout 30000ms exceeded. Call log: – navigating to "https://example.com/wp-admin/", waiting …

WordPress’s plugin and theme update screens both have a “select all” checkbox. Calling check() on it with Playwright succeeds — no error, no exception. But look at the individual checkboxes afterward, and sometimes none of them are actually checked. Note: Playwright’s check() ticks a checkbox. The click itself can succeed even if the page’s JavaScript handler never fires, leaving what the form actually submits out of sync with what the screen visually shows. What actually happens The “select all” checkbox is usually wired up with a JavaScript handler: clicking it is supposed to check every individual checkbox underneath it. Playwright’s check(force=True) can force the DOM state of that one checkbox …

On hosting without SSH access, a common pattern is to open update-core.php (the WordPress update screen) with Playwright and read “what version is WordPress core currently running” straight off the page text. In one deployment, the recorded core version came back as something like 1.7.11 — a number that has never existed for WordPress core. Note: update-core.php is the WordPress admin’s “Updates” page, listing pending updates for core, plugins, themes, and translations all on one screen. What was actually happening That page doesn’t only show the core version string — it’s packed with version numbers belonging to pending plugin and translation updates too. A line like “Update Plugin X to …

On hosting environments without SSH access, the fallback is browser automation: Playwright logs into wp-admin and drives the plugin update screen directly. That works fine for months — until one day the script stops dead before it ever reaches the update screen. Note: Playwright is a browser automation tool. It reproduces clicks a human would make, but as code. What the “confirm your admin email” screen is Since WordPress 5.3, wp-admin shows a periodic prompt — roughly every six months — asking the site owner to confirm they still have access to the registered admin email address. It’s a core WordPress feature, not a plugin. Is this still your address? …