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 block editor (Gutenberg).
Symptom: Custom meta boxes assuming the classic editor (TinyMCE), custom field UIs, and third-party plugin editor extensions stopped working simultaneously. Content itself wasn't broken — but the editing UI vanished.
Cause: Code written against the classic editor's DOM and hooks loses its anchor points in Gutenberg's React-based UI. Simple add_meta_box() extensions kept working, but anything hooked directly into a TinyMCE instance fell over completely.
The fix pattern: Run the Classic Editor plugin to preserve the old UI temporarily, while planning the migration to Gutenberg-aware forks or replacement plugins. "Inventory editor-adjacent plugin dependencies before applying the upgrade" makes the migration scope visible up front.
What this incident demonstrates is that the flagship feature of a major release maximizes impact on the surrounding ecosystem. The same structure will repeat with any future "new editor feature" or "new admin UI."
Pattern 2 — A wholesale JS library bump triggers cascading breakage (5.6 jQuery 3.x)
When WordPress 5.6 jumped jQuery from the 1.x series to 3.x.
Symptom: Front-end JS goes dark. Broadly-used jQuery plugins for sliders, modals, form validation, etc. stop working, and the site's "dynamic parts" break across themes and plugins.
Cause: jQuery 3.x removes APIs that had been deprecated for years — $.live(), parts of $.bind() semantics, parts of the $.ajax Promise interface. Code depending on them doesn't error syntactically — it fails silently at runtime.
The fix pattern: Bring in jquery-migrate to provide a compatibility layer for the deprecated APIs, then refactor JS based on the console warnings it logs. Opening the browser dev-tools Console while clicking through staging becomes a required step.
The lesson here is that "the front-end isn't visible from an admin check." That's why the staging verification in W1 includes "do the critical front-end pages render correctly" — exactly this pattern is why.
Pattern 3 — Raised PHP minimum trips syntax errors in old plugins
Unlike the previous two, this is a general pattern that recurs across many majors, not tied to a specific release. The notable boundaries are PHP 7.4 → 8.0 and PHP 8.1 → 8.2 (the dynamic property deprecation).
Symptom: After the upgrade, specific plugins show as "deactivated" in the admin, or the site is white-screened with a Fatal error. The error log shows PHP Parse error or PHP Fatal error: Cannot use ... in write context.
Cause: Each new PHP version tightens syntax and the type system. A plugin's "slightly old code" can no longer be parsed under newer PHP. Or, a warning becomes a deprecation, and depending on display settings, looks fatal.
The fix pattern: Before the upgrade, run wp plugin list --format=json against the new PHP environment and verify the JSON comes back clean (alongside the trap of operational tools breaking from deprecated noise). Plugins with old "Tested up to" deserve replacement evaluation prior to the major upgrade.
What's particularly painful is the "PHP raised, but old plugins kept" in-between state. The PHP version may satisfy WordPress's minimum while the plugin lags behind PHP's new version — and the site still breaks.
Pattern 4 — Theme structure changes invalidate child-theme customizations (6.0 FSE)
When Full Site Editing (FSE) matured in WordPress 6.0.
Symptom: Existing Classic Theme customizations don't break on the 6.x upgrade itself — but the moment you switch to a Block Theme, the template-parts/*.php overrides your child theme provided stop being effective. The traditional template hierarchy (header.php, footer.php) is replaced by HTML templates (block-templates/*.html) in Block Themes.
Cause: Block Themes have a fundamentally different file structure from Classic Themes. The child-theme override mechanism relies on the old filename conventions, so it can't reach into the Block Theme's HTML template structure.
The fix pattern: Two paths — keep the Classic Theme for the foreseeable future, or commit to a child-theme redesign as part of migrating to a Block Theme. "Should we migrate the client's theme?" and "Should we upgrade WordPress?" become separate decisions.
The takeaway is that major releases create transition periods. When two systems coexist — Classic Theme and Block Theme — having a documented operational rule for "which one do we stay on" pays off.
Pattern 5 — Tiny internal API tweaks quietly break external integrations
The first four are relatively easy to notice. This last one is the slowest to discover.
Symptom: Everything looks normal immediately after the upgrade. Days or weeks later, "the API integration where an external system POSTs into WordPress has stopped working" comes to light. Auto-posting and auto-updates from CRMs, core business systems, or internal workflows fail silently with no error log entries.
Cause: REST API scope changes, subtle authentication tweaks, CORS header expectations, X-WP-Nonce lifetime changes — small items buried in the "Developer Notes" section of the official release notes that break external auth flows.
The fix pattern: The one-week soak in staging from W2 exists exactly to catch this pattern. The failure mode doesn't show up in an immediate post-upgrade admin click-through — it only surfaces with time and real traffic. Run Site Health's Loopback test, let cron jobs cycle, leave staging running for a stretch and watch.
For sites with external integrations, "every integration's auth path, tested end-to-end" must be on the major-upgrade checklist.
Closing — knowing the patterns lets you handle future failures
Stacking the five patterns shows the common axes:
- Editor and UI surfaces concentrate breakage when flagship features ship (Pattern 1)
- JS / PHP major version dependencies trigger cascading failures (Patterns 2 & 3)
- Structural pre-condition changes create a "transition period" with two systems coexisting (Pattern 4)
- Silent breakage only surfaces with time (Pattern 5)
These structures will recur in some form in the next major (7.0 or 8.0).
| The full series relationship |
|---|
| W1 = what to verify (seven-item pre-flight checklist) |
| W2 = when to apply (five calibration axes) |
| W3 = what can go wrong (five typical failure patterns) ← this post |
| W4 = how to run it (WP-CLI commands and checkpoints for each stage) |
Aligning the whole upgrade lifecycle as "preparation → timing → risk prediction" sharpens operational decisions. When WordPress 7.0 drops, starting with "which of the five past patterns does this match?" tends to point you at the right response faster.
The "types" here aren't visible when you only operate one site. Maintaining a portfolio of sites, you tend to meet at least one of them in some form on every major. Moving from reactive triage per incident to predictive pattern matching — that shift is, in my view, the core of making maintenance work sustainable as a practice.
Top comments (2)
Pattern 2 is the one that catches maintenance teams out, because uptime checks stay green the whole time and, like you said, the front end isn't visible from an admin check. What's helped me is comparing screenshots of a few key pages before and after each update, plus a quick error check, so a broken page shows up even when the site still "responds".
Disclosure: I build WP Foreman, which does before/after screenshots on updates. On the one-week staging soak from W2: do you hold a major on every site for that week, or roll it to a small group of sites first?
On the soak: the article’s approach isn’t one rule for every site. The staging soak scales with the site’s risk profile: a few days for low-risk sites, about a week for mid-size corporate and blog sites, and two weeks (after x.0.2) for commerce, booking and membership sites. It also recommends upgrading in waves by risk instead of all sites on the same day, so low-risk sites go first and act as the small group before the high-risk ones.