Updating WordPress to a major version
What genuinely breaks during a major version update — theme, plugins, PHP — and how to check it before running the update on the live site.
What a major version actually changes
A WordPress major version isn’t just security fixes: it can change core behaviour, deprecate internal PHP functions, or overhaul the content editor. Two historical shifts show the scale a major change can reach: WordPress 5.0 made the Gutenberg block editor the default, replacing the classic editor, and WordPress 5.9 introduced full site editing with block themes. A classic theme still works after 5.9 — it isn’t a forced switch — but it’s the kind of behaviour change a major version can introduce without warning an unprepared site.
Switching editor deserves its own method, which I cover on the dedicated page about moving to Gutenberg. Here, I stick to the general method for a major version update, applicable to any major release, past or future.
The real causes of failure after a version update
- A theme built on core functions or hooks whose behaviour has changed, or disappeared
- A plugin calling a PHP function deprecated by the core, triggering a fatal error instead of a simple notice
- A plugin abandoned by its author, never tested against the new version, silently breaking a feature with no visible error
- A change in editor or REST API behaviour that breaks a bespoke customisation
How I run a major version update
-
Full backup
Files and database, before touching anything. This is what makes it possible to roll back if testing reveals a serious problem.
-
Test environment
I duplicate the site on a separate environment, matching production’s server configuration, before touching anything.
-
Checking each plugin
I go through every active plugin and the theme: last update date, stated compatibility, changelog. A plugin left unmaintained for a long time is the first suspect.
-
Update on the test environment
I run the version update on the copy with debugging enabled, to see errors and warnings surface before they reach the live site.
-
Full functional check
I check the site’s display, content editing, the WooCommerce checkout if present, and forms, before signing off on the switch.
-
Update in production
Once the copy is validated, I run the same update on the live site, during a low-traffic window.
Related pages
-
Checking plugin compatibility before an update
The method to know, before clicking "update", whether a theme or plugin will survive the move to the new version.
-
Updating theme and plugins before the core
The order to update theme, premium plugins and WordPress core in, and why reversing it causes most of the failures I see.
-
Moving to Gutenberg from the classic editor
What switching to the block editor actually changes, and how to prepare for it without losing formatting.
-
Preparing a major update
The general preparation guide, applicable to WordPress as much as to other software cores.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.