Blog

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

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 …

A forgotten password, a security plugin that blocked your own IP by mistake, a plugin bug that turns the admin screen white — the causes vary, but the result is the same: you can’t log in to wp-admin. Note: WP-CLI is a command-line tool for managing WordPress, invoked as wp. It operates directly on the server, without going through a browser. This is exactly the situation where WP-CLI is useful. It works here because it never touches wp-login.php — it reads and writes the WordPress database and filesystem directly, so a broken login screen doesn’t affect it at all. Why WP-CLI keeps working when wp-admin doesn’t A normal login follows …

After a domain migration or HTTPS switch, “all plugin settings are gone” or “Elementor layouts are broken” is a common outcome. The cause, in most cases, is running a string replacement against the WordPress database without accounting for PHP serialized data. WordPress stores plugin configurations, custom field values, and widget settings in PHP’s serialized format. Standard SQL replacements — phpMyAdmin’s find-and-replace, raw UPDATE statements, sed on a .sql dump — rewrite the string value without updating the length metadata that serialization embeds alongside it. The result is a database that appears intact but returns false on every read of the affected values. wp search-replace handles this correctly. Understanding why makes …

Verifying a WordPress major upgrade — a 7-step post-upgrade checklist You followed the step-by-step WP-CLI procedure from W4, the terminal printed “Success: Core updated successfully,” and the session is over. Stopping there is the most common place for post-upgrade problems to slip through undetected. WP-CLI’s “success” means the core files were replaced. It doesn’t mean the site is working. Whether the database migration completed cleanly, whether plugins are compatible with the new core, whether forms submit, whether carts process — these require human verification after the command finishes. This checklist pairs with the pre-upgrade checklist from W1. Where W4 covers what to run, this covers what to check when the …

Getting ready for WordPress 7.0 — three things to check now: PHP requirements, FSE migration, and editor extensions Five failure patterns from past WordPress major upgrades ended with the observation that “the same structures will recur in some form in the next major (7.0 or 8.0).” This post applies that pattern knowledge to WordPress 7.0 specifically — not as a list of things that will happen, but as a preparatory checklist for what you can verify now. This sits alongside the seven-item pre-flight checklist from W1 rather than replacing it. Think of it as the 7.0-specific supplement. Item 1 — PHP minimum requirement increase (W3 pattern 3 again) W3’s pattern …