# 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.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress](https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Run the upgrade on a clone first, theme included, then open every template you have overridden in the child theme: that is where a major version breaks, rarely in the core itself. In production, disable caching and launch the update from Dashboard, Updates outside peak hours. If the admin stops responding, recovery mode is still reachable through the link sent by email.

## 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

1. **Full backup** — Files and database, before touching anything. This is what makes it possible to roll back if testing reveals a serious problem.
2. **Test environment** — I duplicate the site on a separate environment, matching production’s server configuration, before touching anything.
3. **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.
4. **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.
5. **Full functional check** — I check the site’s display, content editing, the WooCommerce checkout if present, and forms, before signing off on the switch.
6. **Update in production** — Once the copy is validated, I run the same update on the live site, during a low-traffic window.

## The point of no return

> It’s the moment you update directly in production without going through a test environment first. Without that step, an incompatible theme or plugin shows up live, in front of visitors, and the only option left is a full backup restore.

## Checking after the update

> I check the server error log, the display of key pages, content editing and publishing, and the behaviour of every critical plugin in the following days, not just at the moment of the switch.

## 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. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **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. ([/wordpress-woocommerce/mise-a-jour/theme-et-extensions-avant-montee-version](/wordpress-woocommerce/mise-a-jour/theme-et-extensions-avant-montee-version))
- **Moving to Gutenberg from the classic editor** — What switching to the block editor actually changes, and how to prepare for it without losing formatting. ([/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique](/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique))
- **Preparing a major update** — The general preparation guide, applicable to WordPress as much as to other software cores. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))

## FAQ

### Should I update as soon as a new major version is released?

Not usually. I generally wait a few weeks for theme and plugin authors to publish their own compatibility fixes, unless the new version patches an actively exploited security flaw.

### Is moving to Gutenberg or full site editing mandatory?

No. A classic theme still works after WordPress 5.9, and the Classic Editor plugin remains maintained by the WordPress team. These are options, not switches forced by a major version update.

### What if a critical plugin isn’t compatible yet?

I delay the core update until the plugin publishes a compatible release, or I look for a maintained alternative if the author has abandoned it.

### Can you roll back to the previous version after an update?

WordPress doesn’t offer a reliable native rollback for a major version. The only safe method is restoring the full backup taken before the update.

### Does a WordPress major update also affect WooCommerce?

WordPress core and WooCommerce update separately, but their compatibility needs checking together: a new WordPress major version can expose an issue in a WooCommerce plugin that hasn’t kept pace.