PrestaShop module conflicts are one of the most common causes of failures: the store worked fine, then after installing or updating a module you get a white screen, a 500 error or a broken layout. Modules override each other on hooks, collide through core overrides or require different PHP versions. The diagnosis is systematic isolation — without it you end up swapping modules blindly. Below is the full procedure: from a safety backup to a compatibility report. A specialist fix: 200–600 PLN net.
Key takeaway: You diagnose module conflicts through isolation: 1) back up files and database, 2) save the module list before changes, 3) disable modules in batches (half, then half of that half) — the fastest way to the culprit, 4) when the panel is down, disable via the database (
UPDATE ps_module SET active = 0), 5) re-enable suspects one by one and test, 6) check theoverride/directory — duplicate classes are a classic conflict, 7) compare module requirements (PHP, PrestaShop versions) and changelogs.
Symptoms of a module conflict
A conflict does not always look like a failure. Signs that two modules are fighting over the same place
-
a white screen or 500 error after installing/updating a module,
-
elements disappearing or duplicating on the page (two carts, two banners),
-
the checkout works only with another shipping module disabled,
-
strange cart, discount or shipping cost behaviour,
-
performance dropping after enabling a specific module,
-
JavaScript errors in the browser console (Parcel Locker map, payment widgets).
-
## Step 1: Backup and module list
Before disabling your first module
- back up the files and database,
- save the current module list with versions (panel → Modules → Module Manager; a screenshot is enough),
- note the exact time and circumstances of the problem — after which change did it start.
-
Point 3 is crucial: if the problem appeared after installing module X, the suspects are module X and its neighbours on the hooks — not the whole store.
-
## Step 2: Disable in batches — the halving method
Instead of disabling modules one by one (with 40 modules that takes hours), use the halving method
- disable half the modules (e.g. all payment and shipping ones),
- check whether the problem is gone,
- if yes — the culprit is in the disabled half; if no — in the other one,
- keep halving the suspect group until 1–3 modules remain,
- re-enable them one by one, testing after each.
For an error on a specific page (cart, product) narrow down first to modules hooked to that page: panel → Modules → Positions (Transplantations) → select the hook.
- ## Step 3: Disabling via the database when the panel is down
When the white screen affects the panel too, disable modules via the database
UPDATE ps_module SET active = 0 WHERE name = 'module_name';
- Find module names with:
SELECT name, active FROM ps_module ORDER BY name;. After disabling, clear the cache (var/cache) and check the store. To re-enable:SET active = 1. Before touching the database, dump it — a typo in an UPDATE can surprise you.
Warning: Do not delete modules via the database — deleting a row without uninstalling the module leaves orphaned tables, hooks and configuration entries. Disable (
active = 0), do not delete.
- ## Step 4: Check the overrides
Overrides are the most common source of conflicts invisible in the module list
-
any module can add files to
override/, -
two modules overriding the same class (e.g.
Cart.php,Order.php) override each other, -
after a core update an override may reference a removed method — hence 500 errors.
-
How to check: compare the
override/directory against a clean installation (the originaloverride/contains onlyindex.php). Every.phpfile is a modification by some module. If two modules modify the same class, pick one (or move the logic to hooks). More on overrides: PrestaShop modules and customisations. -
## Step 5: Check version compatibility
Some "conflicts" are plain incompatibility
| What to check | Where | Typical problem |
|---|---|---|
| Module PHP version | module composer.json / docs |
Module requires PHP 7.4, server has 8.3 |
| PrestaShop version | module tab | Module for 1.7 on a 9.x store |
| Module dependencies | module panel | Missing required library (e.g. intl) |
| Class name conflicts | error logs | Cannot redeclare class |
The logs will say it directly: Cannot redeclare = two definitions of the same class, Call to undefined method = the module calls a method that does not exist in this core version. Reading logs: PrestaShop logs.
- ## Step 6: Test on staging
Test every module change on a store copy
- installing a new module → test on staging → only then production,
- updating a module → changelog + staging + full purchase path,
- before a core update → a list of modules compatible with the new version.
If the store has no test environment, setting one up is the best investment in stability — details in post-update problems.
Frequently asked questions
After installing a module the store shows a white screen — what to do?
Disable that module via the panel (and if the panel is down — via the database: UPDATE ps_module SET active = 0 WHERE name = 'name'), clear the cache and check the store. Then enable the module on an environment copy with debug mode and read the error — most often it is a missing dependency or a conflict with another module.
How do I quickly find the module causing a conflict?
- Use the halving method: disable half the modules, check whether the problem is gone, and narrow down to the half containing the culprit. For an error on a specific page (e.g. the cart) start with modules hooked to that page.
Can a module conflict affect only the checkout?
Yes — payment and shipping modules override the same checkout elements and most often come into conflict. Symptoms: missing payment methods, an error when placing an order, a Parcel Locker map that fails to load. Procedure: checkout not working.
How do I avoid module conflicts in the future?
Install modules in batches on staging, check version compatibility before updates, avoid abandoned modules (not updated for years), keep a list of modules with versions and read changelogs. More best practices: PrestaShop modules and customisations.
Sources and tools
- PrestaShop DevDocs — modules and hooks
- PrestaShop — developer documentation
- PrestaShop Addons — module compatibility
👉 A module took the store down? We will diagnose the conflict and restore operation — contact form or kontakt@informatix.com.pl. See also PrestaShop technical help.
📖 See also: PrestaShop white screen, 500 error and post-update problems.