WordPress Maintenance

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 …

The W series has covered what to check before a major upgrade, when to apply it, and what can go wrong. This fourth part covers the remaining question: how to actually run it. Once the preparation is in place and the timing is right, this is the command sequence to follow — one stage at a time, with a confirmation step at each boundary. Why not use the admin dashboard Update button The WordPress admin screen has an “Update All” button that runs core, plugin, and theme updates in a single operation. This is the approach to avoid for major upgrades. The reason is loss of isolation. When core plus …

If you run WordPress maintenance for clients on Xserver, sooner or later you hit this: SSH was working fine this morning, and now your connection dies the instant it touches the host. No key change on your side, no obvious server-side incident. Just Connection closed by …, and the silence deepens every time you retry. A recent escalation to Xserver support gave us an official answer about what’s actually going on. Worth writing down what an operator needs to know. What the symptom looks like In our observation, the symptom moves through two stages. Lighter: Connection closed by [Xserver IP] — connection killed at the sshd layer before it’s established …

With the pre-upgrade checklist of seven items and the calibration framework for when to apply, we’ve covered preparation and timing for WordPress major upgrades. The third installment is “what can go wrong” — the failures that actually happened in past majors, organized into five patterns. The examples are tied to specific releases (5.0 / 5.6 / 6.0), but the point is that the same structural patterns repeat in new majors. Carrying these as types in your head pays off when 7.0 or 8.0 lands and you need to triage fast. Pattern 1 — “Editor-adjacent UI extensions” disappear en masse (5.0 Gutenberg) The most operationally impactful incident when WordPress 5.0 standardized …

The companion to the seven things to check before a WordPress major upgrade is the question that comes right after: when do you actually apply it? A new WordPress major drops today. Do you ship it to production tonight? Tomorrow? In a week? Hold for the next scheduled monthly maintenance? This call tends to live in tribal knowledge, but a few clear axes combined together give you a calibration framework you can apply every time without re-deciding from scratch. Here are five axes worth using. Premise — majors are not security patches The first thing to anchor: a major upgrade is not a security patch. WordPress ships security fixes via …

WordPress major version upgrades (5.x → 6.x, and eventually 6.x → 7.x) are a different animal from minor releases. Minor releases (like 6.4.1 → 6.4.2) are mostly bug fixes with low compatibility risk. Majors land API deprecations, raised PHP minimum requirements, and core block replacements all at once — and those things hit operations hard. The “just hit Update in the admin and patch whatever breaks” workflow can survive on a single personal site, but it tends to fall apart under multi-site maintenance — simultaneous failures across sites overwhelm root-cause triage. This post collects the things worth verifying before you run a major upgrade, as a seven-item checklist. 1. Has …

For sites where SSH isn’t available, we drive maintenance through Playwright by automating the WordPress admin UI. Plugin updates, theme updates, translation updates — all running fine. Until one day, only the Core (WordPress itself) update started failing. The error was Locator.click: strict mode violation — familiar to anyone who’s used Playwright, the one that fires when a locator matches multiple elements. Tracing it back, the root cause turned out to be a structural quirk of the WordPress admin UI sitting right at the trap line. This post walks through the bug from the angle of Playwright’s strict mode and making .first a habit. Strict mode violation is “your selector …

A client asked: “After I run a cross-site update check, can each site show — right in the site list — how many plugin updates are still pending?” Visually the answer was obvious: a small red badge on the top-right of the 🔌 plugins button, like an unread-notification count. Easy to specify. The harder question was where the data comes from. We could have added a fresh API endpoint and a new cache to hold “pending count per site.” But doing that would have doubled state management, and we already had a cache that knew this. We routed through the existing one. Here’s the reasoning behind that decision. Reuse the …

When you maintain a number of WordPress sites, showing the “last maintenance date” in the site list is the obvious move. A column of dates like 2026-05-21. But in actual use, that alone falls short. A client put it well: “Besides the last maintenance date, it’d help to also show how many days have passed. And it’d be even better if the color changed at 15 / 30 / 60 days so I can see the risk level.” This post walks through that step — from “absolute date” to “relative elapsed days + color” — including the small design details. Why a date alone isn’t enough An absolute date like …

Our multi-site maintenance tool fires wp plugin list –format=json against the sites it manages. One day, against a specific shared host (Xserver in Japan), this call started failing — and the failure mode was unusually subtle. Both the SSH connection test and the WP-CLI path test (wp –version) came back green. Users saw “all diagnostics pass, but the actual operation fails,” a frustrating asymmetry. Tracing it back, the root cause was PHP Deprecated warnings emitted by older WP-CLI (2.x) under PHP 8.2+ leaking into the JSON output. This post walks through the three-layer defense we used to structurally absorb the noise without losing real failures. What was happening — Deprecated …