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

Everything broke after installing a module

"I installed a customer review module and now the carrier no longer shows." That sentence comes up regularly, and it is not absurd at all. A module is not an isolated brick: it adds code, creates tables, hooks into locations it does not own, and loads its own scripts on pages that have nothing to do with it.

Describe my issue Send a message

What a module really changes

At installation, a module does far more than drop files in place. It registers hooks: points on the site where its code will run, often a dozen of them, sometimes on pages it does not visibly change. It creates its tables and sometimes adds columns to existing ones. It adds its stylesheets and scripts to the loading queue, where order matters. And it may install an override, a file replacing a core behaviour for the whole site.

Two modules overriding the same behaviour conflict: the second overwrites the first, or partially replaces it. That is the most frequent cause of a bug appearing far from the installed module, and it is also the one that survives uninstallation, because an override file is not always removed cleanly.

Isolating the module responsible

  1. Confirm the chronology

    Did the fault exist before? On a site where several people work, the apparent coincidence is not always the real cause. An update run the same day is just as serious a candidate.

  2. Deactivate rather than uninstall

    Deactivation is reversible and keeps the settings. Uninstalling often removes the configuration, the tables and sometimes entered data. On a payment or shipping module, the difference is major.

  3. Work in halves

    With many recent modules, deactivating half at a time splits the field on every attempt. Far faster than one by one, and still reversible.

  4. Check the override directory

    An override file dated the day of installation, named after a core class, identifies the culprit even after the module is deactivated.

  5. Look at the browser console

    When the symptom is a dead button or a frozen menu, the script error names the faulty file, and that file path contains the module name.

The clashes I meet most

  • Two modules overriding the same core behaviour: the last installed wins, and the first one’s feature disappears with no message.
  • Two modules loading the same script library in different versions: the page loads both, and the second overwrites the first.
  • A cache or optimisation module bundling and compressing files: it breaks another module’s scripts that assumed a specific loading order.
  • A module hooked into the checkout failing silently, leaving a button with no effect rather than an error message.
  • A module installed on a CMS version other than the one it declares compatibility with: it appears to work and fails on one particular case.

Carry on with the right page

Describe your need in one minute

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

type
existant
stack (facultatif)
utilisateurs (facultatif)
echeance (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

The module has nothing to do with the broken feature. Is it really the cause?
Common, and perfectly logical. A module hooks into shared locations and loads its scripts across the whole site. The link is not functional, it is technical: same location, same file, same overridden behaviour.
Should I uninstall the module or fix it?
It depends what it brings. If a maintained alternative exists, replacing is healthier than adapting. If the module is essential and well written, adjusting the loading order or the hook is often enough.
How do I test a module safely?
On a copy of the site, never straight in production. A staging environment does not have to be full infrastructure: a copy of the files and the database, on an address closed to indexing, is enough for this kind of test.
Is a free module riskier than a paid one?
Price is not the indicator. What matters is the date of the last update, the declared compatibility with your version, and whether the publisher still ships. An abandoned paid module is riskier than a maintained free one.
Can you tell in advance whether two modules will clash?
Partly: comparing the locations they hook into and the overrides they install gives a first opinion before installation. The rest is verified on a copy, not on the live shop.

Related pages