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

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

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

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.

Related pages