# Override or module on PrestaShop: how to choose

> PrestaShop offers two ways to change its behaviour without touching the software's core: the override, which extends an existing class from the override/ folder, and the module, which hooks into points provided by the hook system. The choice isn't a matter of preference; it depends on what PrestaShop actually allows at that specific point.

- Source canonique : [https://allaux.fr/en/guides/override-ou-module-prestashop](https://allaux.fr/en/guides/override-ou-module-prestashop)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Always favour a module when a hook exists for the need at hand: it's the intended method, and the most stable over time. Reserve the override for cases where no hook allows intervention, knowing it will need re-checking at every major version upgrade.

## How to decide

1. **Look for a suitable hook first** — PrestaShop exposes dozens of hooks at specific points in the display and order-processing cycle. If one matches the need, a module is enough.
2. **Assess whether native behaviour needs to change** — A hook lets you add behaviour at a given point, not replace existing logic. If the need is to change a calculation or rule already coded into the core, no hook allows that, and the override becomes the only native option.
3. **Weigh the impact of an override on updates** — An override replaces no core file at all: from the override/ folder PrestaShop loads a class that extends the original one — Product extends ProductCore — and redefines only the methods you target. At every version upgrade, those methods have to be compared again with the original class, which may have changed.
4. **Document every override created** — An undocumented override, discovered months later during an update, costs far more diagnostic time than documenting it up front would have taken.

## What actually sets the two approaches apart

A module installs and uninstalls cleanly: it hooks into points (for example displayHeader or actionValidateOrder) via the registerHook() method, and every hook it subscribes to corresponds to a method named on the same pattern, such as hookDisplayHeader(). Disabling or removing the module cleanly removes its behaviour, leaving no trace in the core.

An override, on the other hand, lives in the override/ folder (for example override/classes or override/controllers) : PrestaShop loads a class there that extends the core …Core class — class Product extends ProductCore — and redefines only the methods you need, the rest still coming from the core. No native file is edited or replaced. It's more powerful, because it lets you change behaviour the hook system could never reach, but also more fragile: if the PrestaShop core modifies the original class in a later version, the override can become incompatible, or even cause a blocking error.

In practice, most modules distributed on the market use only hooks, precisely because that's the method that guarantees the longest compatibility. Overrides remain reserved for needs that are genuinely impossible to cover any other way.

## Common mistakes

- Creating an override when an existing hook would have sufficed, needlessly complicating future updates.
- Counting on stacking several overrides of the same method from different modules: PrestaShop refuses. Module::addOverride throws an exception and the second module's installation fails with an explicit message along the lines of "Unable to install override: The method … in the class … is already overridden". It is the first override installed that stays in place.
- Forgetting that an override survives the uninstallation of the module that created it, if that module didn't plan to remove it cleanly on uninstall.
- Editing an override without keeping a copy of the original class, making comparison impossible at the next update.

## The middle ground of Symfony services and events

On PrestaShop 1.7 and later, a third path exists for certain advanced needs: the Symfony service and event system, which now underpins part of the back office. A module can listen to a Symfony event instead of a classic PrestaShop hook, which stays closer in spirit to the module approach than to the override, but requires deeper knowledge of the underlying framework.

This option remains reserved for needs specific to the newer back office; for the vast majority of front-end or standard business-logic changes, the choice really does come down to hook versus override.

## FAQ

### Does a custom theme count as an override?

No, theme customisation goes through template files (.tpl) and sometimes CSS or JavaScript, a mechanism separate from overrides, which concern the core's PHP classes.

### Can I have several overrides on different classes without risk?

Yes, as long as each override targets a different class, there's no conflict between them. The risk of conflict only appears when two overrides target the same class.

### How can I tell if a module uses overrides or only hooks?

The module's folder contains an override/ subfolder if it creates one. The absence of this folder indicates a module that relies entirely on the hook system.