# 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.

- Source canonique : [https://allaux.fr/en/prestashop/migration/modules-incompatibles](https://allaux.fr/en/prestashop/migration/modules-incompatibles)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> On a copy, search the modules/ folder for three precise patterns: brace syntax such as $array{0}, removed in PHP 8 and fatal; the displayPayment hook, ignored since 1.7 in favour of paymentOptions; and files in override/ whose core class has changed signature. Those three searches account for most modules that go missing after a migration.

## 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

- **Checklist before a PrestaShop migration** — What to inventory and back up before starting a migration, whatever the starting or target version. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Moving PrestaShop to PHP 8** — What it means when a host drops PHP 7 and the move to PHP 8 breaks old code. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **PrestaShop migration from 1.6 to 1.7** — Partial move to Symfony, the Classic theme to rebuild, the displayPayment hook gone: what the jump from 1.6 to 1.7 really breaks. ([/prestashop/migration/1-6-vers-1-7](/prestashop/migration/1-6-vers-1-7))

## FAQ

### 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.