# When an update breaks a module or wipes your changes

> The module worked, you accepted the update it offered, and it has been broken since — or it works, but the adaptations made for you have vanished. That isn’t bad luck: a major version change rewrites the module’s configuration, its tables and its files, and that transition is the most fragile moment of its life.

- Source canonique : [https://allaux.fr/en/modules/module-casse-apres-une-mise-a-jour](https://allaux.fr/en/modules/module-casse-apres-une-mise-a-jour)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Do not launch the update again: replaying an interrupted upgrade script leaves the database in a worse state. Read the real error first, in var/logs/ (1.7, 8, 9) or in the server PHP log: it names the missing method or column. Then compare the module’s rows in ps_configuration with the backup taken before the update.

## What a module update actually does

Updating a module isn’t just replacing files. On PrestaShop as on WordPress, a well-written module runs an upgrade routine on the way: it can add database columns, rename configuration keys, migrate old settings into a new format, or attach itself to different display points.

Three things can go wrong. The routine stops halfway, and the database is left in an intermediate state the module can’t read back. Old settings aren’t carried over, and the module restarts on its defaults, which looks exactly like a module that does nothing. Or the new version requires a PHP or platform version higher than yours, and fails silently on load.

The most confusing case is the one where the module seems to work, but only part of its settings survived. You hunt for a bug where there is only lost configuration.

## What to do, and in what order

1. **Don’t re-run the update repeatedly** — Re-running an upgrade routine that failed halfway can worsen the database, because it replays operations already performed. An intermediate state can be repaired; a state replayed three times much less so.
2. **Read the server error log** — An unmet version requirement, a missing method or a non-existent column appear there by name. That is what separates an incompatibility from lost settings.
3. **Compare configuration before and after** — If you have an earlier backup, the module’s configuration values are in it and can be compared. That is often where the full explanation sits.
4. **Roll back, if that is possible** — Downgrading is only safe if the database wasn’t altered by the upgrade. Otherwise restoring a full site backup is the only reliable way back.

## Rolling back isn’t symmetrical

> Putting back a module’s older files does not undo the changes the update made in the database. An old module reading a new structure produces different errors from the first ones, and you end up with two problems instead of one. That is why the full backup, files and database together, is taken before, never after.

## The special case of payment and shipping modules

Those deserve separate attention, because their failure isn’t visible on the home page but at the last step of checkout, which is where you lose the sale. A new major version frequently changes how the module receives callbacks from the provider, and those callbacks arrive at an address registered with the provider, not inside your store. If the update changes that address, it has to be updated on both sides.

After any payment module update I place a real end-to-end order in production conditions and check that the order is created with the correct status. That is the only test that proves anything.

## The other outcome: the update that wipes your changes

The opposite symptom exists and is often confused with the previous one: the module isn’t broken, it has simply gone back to what it was. An update replaces the module’s files with those of the new version. It doesn’t compare, it doesn’t merge, it overwrites. Everything written inside the module folder disappears, with no warning and no trace. The signature is recognisable: a bespoke feature that vanishes twice a year, always after maintenance, and that nobody links to the update because the interval is long.

The second effect is nastier: as long as the change holds, it effectively blocks updates. Since nobody wants to lose it again, the module stays on an old version, piles up incompatibilities and ends up producing exactly the failure described above, only worse, on the day the update becomes unavoidable.

When a module declares no extension point and builds its output without a template you can override, there is no elegant answer, and I would rather say so than suggest otherwise. Three options remain, in this order of preference: ask the module’s publisher to add an extension point, which costs nothing and is sometimes accepted; duplicate the module under another name and own it as yours, knowing you give up its updates and become its maintainer; or keep the change separately as a documented patch, to be reapplied after each update. What I don’t do: modify a module and say nothing. An undocumented change inside code someone will update in six months is a trap for the next person, including when that person is me.

## Four ways to adapt a module without editing it

- **Use the extension points provided** — Many modules declare their own hook points. A properly written third-party module can be extended from outside, without touching a single one of its lines.
- **Override the template from the theme** — On PrestaShop, a theme can supply its own version of a module's template. On WooCommerce, the equivalent mechanism goes through a dedicated folder in the child theme. The change then lives in the theme, not in the module. ([/guides/creer-theme-enfant-wordpress](/guides/creer-theme-enfant-wordpress))
- **Write a small companion module** — A dedicated module that hooks after the original and alters its result. That is the cleanest option when the change affects behaviour and not just display. ([/guides/override-ou-module-prestashop](/guides/override-ou-module-prestashop))
- **Use the translation system** — When the change is only wording, it goes through the platform's translation system, which exists for that and survives updates.

## Check what the licence says before editing

> Some commercial module licences forbid modification, and an unauthorised change can cut you off from support exactly when you need it. Checking takes five minutes and avoids an unpleasant surprise on the day of an outage.

## Related pages

- **Testing a module before production** — How to avoid the problem entirely: update on a copy first. ([/modules/tester-un-module-avant-la-production](/modules/tester-un-module-avant-la-production))
- **Backing up the store before work starts** — The backup that makes rolling back possible, files and database together. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **A payment method disappears after an update** — The specific case of a payment module no longer showing at checkout. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Restoring after a failed update** — The recovery procedure on the WordPress and WooCommerce side. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Maintaining a custom module over time** — How a module written for you is designed to stay adaptable without being edited. ([/modules/maintenir-un-module-dans-le-temps](/modules/maintenir-un-module-dans-le-temps))

## FAQ

### Should I refuse module updates?

No. A module left un-updated eventually becomes incompatible with the platform and may carry known vulnerabilities. What must be avoided is the update applied straight to production with no backup and no prior test.

### The module shows a database error since the update

That is the signature of an interrupted upgrade routine: an expected column or table doesn’t exist. The fix is to complete the missing migration, not to reinstall the module, which would lose existing data.

### My settings have vanished, can they be recovered?

Often yes, if they are still in the database under their old keys, or in an earlier backup. That is data recovery work, separate from fixing the module itself.

### How do I know a new version is compatible before installing it?

The module listing states the platform and PHP versions it requires, and the description file shipped with the module states them too. When the two disagree, the shipped file is what counts.

### How do I know whether my changes were overwritten?

By comparing the module's files with the published version: the differences stand out. On a site with no version control that is the only way, and it is also why I put changes somewhere other than inside the module.

### Does a template override in the theme really survive?

It survives module updates, yes. However, if the module changes its data structure, the overridden template may stop showing the right thing: it has to be rechecked after every major version change of the module.