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.
How to decide
-
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.
-
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.
-
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.
-
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.
Frequently asked questions
Does a custom theme count as an override?
Can I have several overrides on different classes without risk?
How can I tell if a module uses overrides or only hooks?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.