My site broke after an update
An update that breaks something almost never changed just one thing. It replaced the core, sometimes the database structure, often files other components relied on, and it left behind pieces that did not follow. Understanding what really moved decides what comes next: fix, or roll back.
What an update really changes
Three things change at once. The core code is replaced: functions removed or renamed are no longer available to the modules that called them. The database structure may evolve: new columns, new tables, converted data. And the compiled cache becomes stale: it refers to files that no longer exist in the same shape.
What does not change is the customisations: overrides, edits made directly in core files, an adapted theme. They remain written for the old version. That is where the breakage happens in most cases, and it is also why an update goes smoothly for one merchant and badly for another on exactly the same version.
Frame the problem before deciding
-
Describe precisely what no longer works
One feature, one page, one user role, or the whole site? A limited fault gets fixed; an entire site down justifies an immediate rollback.
-
Check whether the database was modified
This is the decisive point. If the update converted data, restoring files alone will not be enough, and a full restore loses every order taken since.
-
Clear the caches before concluding
A notable share of post-update symptoms come from a stale compiled cache. The cheapest check on the list.
-
List components that were not updated
Modules, plugins, theme: those still on their previous version are the first suspects. Each one’s last update date is a reliable clue.
-
Read the error log for that period
It names the file and the function at fault. That is what separates a targeted fix from blind deactivation.
Fix rather than retreat
In most situations I handle, a targeted fix is preferable to a rollback. An incompatible module can be replaced, updated, or its call adapted. An override written for the old version can be rewritten. A theme using a removed function can be adjusted on the few files concerned.
- Rolling back still makes sense when the update has just run and no new data has been recorded.
- It stops making sense as soon as the shop has resumed trading.
- In every case, a copy of the current state is taken before any handling, including before a restore.
Carry on with the right page
-
Preparing a major update
What to check beforehand so the situation does not repeat.
-
Restoring after a failed update
The procedure when rolling back genuinely is the right option.
-
Plugin conflict after an update
The isolation method when two components fight over the same function.
-
Payment method gone after an update
The costliest case, when it is payment that stopped appearing.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.