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

- Source canonique : [https://allaux.fr/en/problemes/bugs-apres-installation-d-un-module](https://allaux.fr/en/problemes/bugs-apres-installation-d-un-module)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Disable before uninstalling: on PrestaShop use Modules > Module Manager, then Design > Positions to see which hooks the module occupies. On WordPress, if the admin is unreachable, rename wp-content/plugins to plugins-off over FTP: everything switches off at once and you re-enable one by one. Then read var/logs/ or wp-content/debug.log for the exact 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.

## Uninstalling does not always restore the original state

> A properly written module removes its hooks, its tables and its files. Many only do so partially: overrides left in place, added columns never dropped, orphan settings in the database. That is why a backup taken before installation is worth more than the uninstall procedure itself.

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

- **A module refuses to install** — If the problem is installation itself rather than its consequences. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))
- **Plugin conflict after an update** — The WordPress isolation method, when two plugins fight over the same function. ([/wordpress-woocommerce/problemes/conflit-extensions-apres-mise-a-jour](/wordpress-woocommerce/problemes/conflit-extensions-apres-mise-a-jour))
- **Override or module on PrestaShop** — Why an override is the most frequent source of conflict, and when to avoid it. ([/guides/override-ou-module-prestashop](/guides/override-ou-module-prestashop))
- **Hooks explained** — The mechanism by which a module runs inside pages it does not own. ([/glossaire/hook](/glossaire/hook))

## FAQ

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