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

Incompatible PrestaShop modules after a migration

A module that ran without issue for years can silently disappear or crash outright after a PrestaShop migration. It’s almost never random: there’s always a specific technical mechanism behind it, and it can be checked before migrating.

Describe my issue Send a message

How a module declares its compatibility

Every PrestaShop module declares the version range it works with in its config.xml file, using the <compatibility><min> and <max> tags. The same information also exists in the module’s main PHP class, as the $ps_versions_compliancy property. The official Addons marketplace relies on this declaration to show whether a module is offered as compatible with a given version: if a module has never been updated to cover the target version, it simply no longer appears as available for it.

This declaration alone doesn’t guarantee the module will actually work: it states the publisher’s intent, not the result of exhaustive testing. But its absence is a reliable signal: a module whose compatibility range stops before the target version has no chance of working correctly anyway.

The four mechanisms that make a module incompatible

  • The payment hook changed name between PrestaShop 1.6 and 1.7: displayPayment (1.6) is replaced by paymentOptions (1.7, 8 and 9). A payment module written for 1.6 and never updated simply stops appearing at checkout, with no error message: this is a frequent and sneaky cause of 'the module has disappeared'.
  • Many older modules use curly-brace syntax to access arrays or strings, for example $array{0} instead of $array[0]. This syntax was removed in PHP 8 and causes a fatal error as soon as the module runs on a server upgraded to PHP 8, regardless of the PrestaShop version installed.
  • The override system, which replaces files in the override/ folder to modify a core class or controller, breaks at every major migration if the original class changed signature or structure between the two versions: the override can then either stop being called at all, or trigger a PHP error at runtime.
  • A module declared compatible on paper may still never have been genuinely tested on the target version by its publisher, especially for poorly maintained or abandoned modules: the compatibility declaration in config.xml reflects intent, not exhaustive testing.

How I check compatibility before migrating

  1. Read the config.xml of every installed module

    I check the compatibility range declared in every module actually installed on the shop, including ones that seem minor.

  2. Check the module’s Addons listing

    I look up the module’s page on the official marketplace to see which versions the publisher advertises as compatible, and whether an updated version exists.

  3. Test on a copy of the shop

    A compatibility declaration never replaces a real test. I migrate on a copy first and exercise each module’s main functions before approving the switch.

  4. Manually review overrides and customisations

    A module or customisation built on many overrides needs a systematic manual review, not just an automated test, because an override error can stay silent until a specific action triggers it.

What to do when a module has no official equivalent on the target version

When a module simply doesn’t exist for the target version, I first look for an equivalent module from another publisher: the feature itself is rarely unique, even if that specific module no longer is. If nothing on the market fits, I build a custom module suited to the new architecture, keeping the original module’s business logic without inheriting its now-outdated code.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

version-depart
version-arrivee
catalogue
modules-tiers (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 did my payment module vanish from checkout after the migration, with no error at all?
It’s most likely tied to the hook change between 1.6 and 1.7: displayPayment is replaced by paymentOptions. A payment module that was never updated no longer hooks into the new one and disappears without an error message.
Can a module marked compatible on Addons still crash?
Yes, the compatibility declaration in config.xml reflects the publisher’s intent, not exhaustive testing on my exact setup. That’s why a real test on a copy of the shop remains essential.
Why does a module that worked perfectly suddenly crash after a move to PHP 8?
Often because of curly-brace array access syntax, like $array{0}, which PHP 8 removed. This fatal error has nothing to do with the PrestaShop version, it comes purely from the PHP version change.
Can an override that worked on 1.6 really break without anyone touching its code?
Yes, if the class it overrides changed signature or structure in the new version. The override then either stops being called, or causes a PHP error at runtime.
What do you do if no equivalent module exists for my target version?
I first look for an alternative from another publisher. If nothing fits, I build a custom module that keeps the original module’s business logic, adapted to the new version’s architecture.

Related pages