Five failure patterns from past WordPress major upgrades — what 5.0 Gutenberg through 6.0 FSE taught maintenance teams

With , 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 ). 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: )