Available for projects & agency overflow · Quick reply, from the person who does the work

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.

Describe my issue Send a message

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.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.