Two modules treading on each other
Each module works perfectly on its own. Enabled together, they break the cart, empty a page or lock the admin. A conflict can’t be guessed from the descriptions: it is proven by isolation, and there is a method for that.
What points to a conflict rather than a bug
- The failure appeared exactly when a module was installed, with no other change
- Disabling the offending module fixes it, but the other module loses its function
- A page stops halfway through, the lower part no longer renders
- A button stops responding, and the browser console shows a script error
- The back office becomes inaccessible immediately after an activation
The four shapes of conflict I meet
The override conflict. On PrestaShop, a module can replace the behaviour of a core class by dropping an override file. Two modules wanting to replace the same method of the same class cannot coexist: the second refuses to install, or worse, silently overwrites the first if the files were placed by hand. It is the most common cause of a module that «does nothing any more» while still being active.
The ordering conflict. Two modules hooked at the same place run one after the other, and the second can undo what the first did: recalculate a total, replace content, redefine a price. The order is adjustable, and changing it is sometimes all it takes.
The library conflict. Two modules each load their own version of the same JavaScript library. The page loads both, the second overwrites the first, and everything depending on the initial version stops. This is visible in the browser console, not in the server logs.
The name conflict. Two extensions declare a function or class with the same name, and PHP stops dead with a fatal redeclaration error. On WordPress that is a classic among extensions bundling the same third-party library without precaution.
How I find the culprit without breaking the store
-
Work on a copy, not in production
Isolating by successive deactivation isn’t acceptable on a store that is selling. I duplicate the site and do there what would be unacceptable live.
-
Read the logs before touching anything
A fatal redeclaration error names the file and the line: the conflict is identified in a minute, with no deactivation at all.
-
Halving rather than one-by-one
I disable half the modules, test, then split the remaining half. On a store with many modules, this sharply reduces the number of attempts.
-
Check the browser console in parallel
A JavaScript conflict leaves no server-side trace. If the page loads but a button stays inert, the answer is in the console, not in the PHP logs.
Once the culprit is known, four possible outcomes
The simplest: change the execution order, when the conflict comes from one result overwriting another. The second: fold one module’s function into a single module that does both, which removes the conflict at the root. The third: replace one of the two with something that doesn’t override the same thing. The fourth, the least durable, is to fix the offending module in its own code — but that fix vanishes at its next update unless it is isolated.
I always flag when the conflict comes from a fragile practice rather than an accident: a module that drops a core class override just to add a field, or that bundles its own copy of a common library, will produce further conflicts later with other modules. Replacing it sometimes costs less than patching it every time.
Related pages
-
Extension conflict after an update
The same subject on WordPress, when the trigger is an update rather than an install.
-
A module refuses to install
When the conflict blocks installation itself rather than operation.
-
Override or module on PrestaShop
Why class overriding is the technique that produces the most conflicts.
-
PrestaShop 500 error
When the conflict shows up as a blank page or a server error.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.