Guide · Updates
WordPress updates: an update is not a button
What actually gets updated, why an update sometimes breaks something, and what gets decided around the click. This page will not tell you where to click.
Not every site updates the same way
The dashboard shows a red dot and offers to update everything in one click. The click works most of the time. The problem is not the button. It is what happens on the occasions when it does not work, and the fact that you then no longer know what to look at.
Not every WordPress site updates the same way. The core, the plugins and the themes can follow different rules depending on the age of the site, its configuration, and choices made in the admin. That is precisely why a site can accumulate gaps without simply being “a year behind”.
These behaviours are configurable, through settings in the admin as well as constants and filters on the server side, which WordPress documents in detail. In other words, two neighbouring sites can be in very different states without anyone having decided anything recently.
So the first thing to do on a site you are taking over is to look at where it actually stands, rather than assume.
Why an update breaks something
Rarely because of the core itself. Almost always because of what surrounds it.
Dependencies you cannot see
A plugin assumes a certain version of WordPress, a certain version of PHP, and sometimes the presence of another plugin. Those assumptions are written nowhere in your dashboard. When one of them stops being true, the function that depended on it stops, sometimes with no visible error at all.
That is why a form stops sending email when nobody has touched the form.
The case of abandoned plugins
A plugin whose vendor no longer ships anything keeps working, right up until the day the rest moves on without it. It does not break all at once: it gradually stops being compatible. This is the most common situation on sites older than three years, and the longest to untangle when nobody saw it coming.
Worth remembering
An update almost never breaks a current site. It breaks a site that is behind, because it catches up several versions at once. The risk grows with the time since the last pass, not with the act of updating.
“Update everything” is not a strategy
The gesture looks responsible. It also makes diagnosis impossible.
If twelve things change at the same time and the site drifts, you are left with twelve suspects, and the only way to find the right one is to undo all of it. If the same twelve updates are done in batches, with a check between each, the culprit narrows to two or three items in a few minutes.
Order matters too. The core first, then the theme, then the plugins: each layer rests on the one below, and doing it the other way produces temporary incompatibilities that are hard to read.
It is not slower. It is simply fewer clicks at once, and far less work on the day something goes wrong.
What gets looked at before, what gets checked after
Before touching anything, a backup. That is basic practice, true for everyone and not only for us: having a point to return to turns an incident into an inconvenience.
A backup can be part of a maintenance intervention when it is needed. Repère does not currently provide standalone backup infrastructure with a guaranteed frequency, retention and off-site copies run as a separate service.
After the work, we check two things: that the site responds, and that forms are still delivering. Those are the two points that break most often after an update, and the two whose absence is noticed latest.
A form that has stopped delivering may produce no visible error at all. Sometimes the problem only surfaces after a missed enquiry.
Stop having to think about it
The updates get done, the record stays written, and you stop seeing the red dot.
Request coverageWhen an update fails
The first instinct is usually the wrong one: rerun every update, deactivate plugins at random, install a plugin that claims to fix it. Each of those adds a variable to a problem that already has too many.
What helps, in order: write down what was just done, look at whether the problem affects the whole site or a single page, and change nothing else in the meantime. A single broken page points to a block, a form or a page builder. A whole site down points to the theme, a central plugin, or a platform version.
If you have a point to return to, going back to it is often fastest, then redoing the updates one at a time. That is what we do when something has broken.
What it looks like when someone handles it
Depending on the plan, the site is seen every month, twice a month, or every week. Updates are done in batches, in order, and the two checks follow. Every pass stays written down, dated, and counted in time.
It is not dramatic. That is exactly the point. What remains is knowing what it represents as a budget.
Common questions
Should everything be updated as soon as a version ships?
For security fixes, the sooner the better. For the rest, waiting a few days after a major release avoids the problems found by whoever updated first. Waiting six months, on the other hand, creates the backlog that will make the next update risky.
Can automatic plugin updates be turned on?
They can, and it is set in the admin. It is reasonable for simple, well-maintained plugins. It is less reasonable for the ones your layout or a core function depends on, because the update would happen with nobody checking afterwards.
My site is several versions behind. Is that serious?
It is common and it can be caught up. It is done in stages rather than all at once, with a point to return to at each step. That is the work we do when taking a site on, before regular upkeep begins.
Your site should be
looked after.
Tell us what you have. We come back with a clear proposal.
Request coverage