When an update breaks a module or wipes your changes

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.

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.