Engineering Notes

When maintenance ends with an error, the plugin update badge disappears — designing a backend marker and frontend count sync

The WordPress maintenance tool shows a badge on each site card when there are pending plugin updates. Under normal operation, when maintenance completes successfully, the badge clears until the next dashboard scan picks up fresh data. That’s correct behavior. But a report came in: when maintenance ends with a warning or an SSH error partway through, the badge disappears even if plugins were left unupdated. “If the update didn’t finish, I need to know — but the badge is telling me there’s nothing left to do.” Why the badge was disappearing Tracing the bug, the root cause was in the frontend badge-update logic, which was built on a hard-coded assumption: …

Read more
WordPress Maintenance

A csh bug we thought we fixed came back in a new feature — designing a login-shell-independent SSH command wrapper

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 …

Read more
Engineering Notes

Deploying and committing to git are not the same done — the trap of assuming uploaded means synced

Near the end of a release, every file transfer to the production server succeeded, and the version file that triggers distribution was updated too. With that confirmed, the release got reported as complete — except the local git repository never actually had those changes committed. Note: “Deploying” here means transferring changed files to the production server (via scp, for example) so they’re actually live for users. “git push” is a separate operation that records the change history in a remote repository. What happened This release involved transferring seven files to the production server: five landing-page update-notice files, the version file that triggers distribution, and a progress-log file. The transfer itself …

Read more
Engineering Notes

Checking that a count did not change — a sanity check before writing a reorder API result

Building a drag-and-drop reorder feature for a list of items means sending the new order to the server and saving it. If there’s even a small flaw in the reordering logic, that save can quietly persist data with items missing or duplicated. Note: A “sanity check” here means a lightweight check that the result of a process satisfies a condition that should obviously hold — not a thorough validation, just a last-resort check for “is this clearly wrong?” The shape of the reorder logic The new order from a drag-and-drop interaction arrives at the server as an array of IDs. The server reorders the existing data to match. # Place …

Read more
Engineering Notes

A version bump that got left behind — fixing it with a single source of truth and a –check gate

A version bump that got left behind — fixing it with a single source of truth and a –check gate Bumping a desktop app’s version number sounds like a one-line change. In practice it can mean editing five different files at once. During one release, exactly one of those files got missed, and an installer nearly got built carrying the old version number. Note: A “version bump” just means incrementing the version number — say, from 1.6.9 to 1.6.10. The operation sounds trivial, but it can end up scattered across multiple files in practice. What happened This app’s version number lives in five separate places: The VERSION variable in version.py …

Read more
WordPress Maintenance

Do not show users a raw Playwright error — translating exceptions into friendly messages

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 …

Read more
WordPress Maintenance

When “select all” checkboxes do not actually select anything — verifying after check(), not just trusting it

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 …

Read more
WordPress Maintenance

When update-core.php version scraping goes wrong — telling a plugin version number apart from WordPress core

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 …

Read more
WordPress Maintenance

Browser-based updates getting stuck on the “Confirm your admin email” screen — why Playwright stalls in wp-admin

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? …

Read more
WordPress Maintenance

Why scheduled posts don’t publish on time — inspecting WP-Cron with WP-CLI

A post scheduled to publish at a specific time doesn’t go live when expected. A plugin’s recurring email notification never arrives. This tends to happen on low-traffic sites, and there’s a specific reason for it. Note: WP-Cron is WordPress’s built-in scheduling system. It sounds like the OS-level cron daemon, but the underlying mechanism is quite different. WordPress’s WP-Cron doesn’t work like a real OS cron daemon. On every page load, WordPress checks whether any scheduled task is past its due time and, if so, runs it. This is what’s known as “pseudo-cron” — and its weakness is that nothing runs without a page visit. Schedule a post to publish at …

Read more