# Updating a theme and its plugins before a major upgrade

> Before upgrading, the order in which I update matters as much as the update itself. Plugins first, theme next, WordPress core last: reversing this order exposes a window where the theme and plugins run on a WordPress version they’ve never met.

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

## Direct answer

> First check whether the active theme is a child theme: Appearance, Themes labels it, and its folder holds little more than a style.css and a functions.php. If there is none and theme files have been edited, updating the parent theme overwrites them for good. Then keep the order: plugins, then theme, then WordPress core, reloading a public page between each step.

## Why the order changes everything

A plugin or theme is never tested by its author against a WordPress version that doesn’t exist yet. Updating core first immediately puts the site into a configuration nobody has validated: the active theme and plugins then run on a newer version than the one they were built and tested against.

Plugin authors, on the other hand, generally ship compatibility updates before an official major WordPress release, because they follow the beta versions and development notes. The theme usually follows a little behind, especially if it depends on third-party plugins itself (a page builder, a theme framework). WordPress core remains the most stable component and the best covered by backward compatibility: it’s the last piece to move, once everything depending on it has already proven it works with the new version.

The specific risk of a theme edited directly, without a child theme, deserves its own mention: any update to that theme overwrites the edited files, whether it happens before or after core. If the site is in that situation, the first step isn’t updating the theme but migrating the customisations into a child theme first, otherwise every theme update wipes out the work already done.

## Typical fallout from updating core first

- Theme functions calling a core function deprecated in the new version, before the theme has been adapted
- Plugins throwing a fatal error on load because they target an earlier WordPress version
- The block editor behaving differently on layouts built with the old theme version
- Customisations added directly into theme files, overwritten at the next theme update
- A prolonged unstable period where each component gets updated in a rush, one by one, in reaction to failures

## The order I follow, step by step

1. **Check whether a child theme exists** — If the active theme is edited directly, I migrate customisations into a child theme first. Without this step, any update to the parent theme wipes out the work on it.
2. **Update plugins, one at a time** — I start with plugins, checking the site still works after each one, rather than updating them all in one batch with no checkpoint in between.
3. **Update the theme (or parent theme only)** — Once plugins are stable, I update the theme. If a child theme is in place, only the parent gets replaced; customisations in the child theme stay untouched.
4. **Check the site before touching core** — I go through the key pages and the checkout with plugins and theme up to date but core still on the old version, to isolate the source of any remaining issue.
5. **Update WordPress core last** — This is the point of no return: once core is updated, rolling back means a full restore rather than a simple undo, whereas reverting a single plugin or theme stays quick.

## Theme edited without a child theme

> If the active theme’s code has been edited directly, any update to that theme overwrites the changes, whatever order is otherwise followed. Migrating to a child theme comes before any update.

## Related pages

- **Creating a WordPress child theme** — The method for isolating customisations from the parent theme before any update. ([/guides/creer-theme-enfant-wordpress](/guides/creer-theme-enfant-wordpress))
- **Checking plugin compatibility before an update** — How to know, plugin by plugin, what’s likely to break before starting. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **Updating WordPress to a major version** — What actually breaks during a major version jump, beyond the update order itself. ([/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress](/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress))
- **Preparing a major update** — The general checklist to follow before any significant version upgrade. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))

## FAQ

### Why not update core first, since it’s the foundation of everything?

Because the theme and plugins haven’t been tested against that new version yet. The in-between period runs on a combination nobody has validated, which is exactly what you’re trying to avoid.

### Should I update every plugin at once?

No, I prefer updating them one at a time with a check in between, to spot immediately which one causes trouble rather than testing ten changes at once afterwards.

### My theme is edited directly, should I update it anyway?

Not in that state. The first step is creating a child theme and moving the customisations into it. Updating a directly edited theme wipes out that work, whatever timing is chosen.

### What if a plugin doesn’t yet have a version compatible with the upcoming core release?

I delay the core update until a compatible version ships, or I look for an equivalent plugin if the current one is no longer actively maintained.

### How much time passes between each step?

I check the site works after each step before moving to the next, which usually takes one to two days in total for a shop with several active plugins.