ix
ix

informatix

PL version Book a discovery call
Home / Blog / PrestaShop Module Conflict — How to Diagnose [2026]
• 6 min read •

PrestaShop Module Conflict — How to Diagnose [2026]

Module conflicts are one of the most common causes of PrestaShop failures. Diagnosis through isolation: the halving method, disabling via ps_module, override control and PHP/PrestaShop version compatibility checks.

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 the override/ 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

  1. back up the files and database,
  2. save the current module list with versions (panel → Modules → Module Manager; a screenshot is enough),
  3. 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

  1. disable half the modules (e.g. all payment and shipping ones),
  2. check whether the problem is gone,
  3. if yes — the culprit is in the disabled half; if no — in the other one,
  4. keep halving the suspect group until 1–3 modules remain,
  5. 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 original override/ contains only index.php). Every .php file 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


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

Free PDF

Web app requirements checklist

12 control questions to answer before talking to a vendor — faster estimates, fewer hidden costs.

Related posts

13.10.2026

PrestaShop Help — Common Problems & Fixes [2026]

White screen, 500 error, broken checkout, missing emails — the most common PrestaShop failures have known repair procedures: backup, logs, debug mode, module isolation, testing. Ad-hoc fixes 200–600 PLN net, diagnostics with a report 500–1,500 PLN net, hourly packages from 900 PLN.

Read more

21.10.2026

PrestaShop White Screen — Fix It Step by Step [2026]

A white screen in PrestaShop means PHP error display is off — the cause is in the logs. A 6-step repair procedure: backup, debug mode, logs, the most common causes (memory, permissions, cache), module isolation and a full purchase path test.

Read more