Override ou module PrestaShop : comment choisir
PrestaShop offre deux façons de modifier son comportement sans toucher au cœur du logiciel : l’override, qui étend une classe existante depuis le dossier override/, et le module, qui s’accroche à des points prévus par le système de hooks. Le choix n’est pas une question de préférence, il dépend de ce que PrestaShop permet réellement de faire à cet endroit précis.
Comment trancher
-
Chercher d’abord un hook adapté
PrestaShop expose des dizaines de hooks à des points précis du cycle d’affichage et de traitement des commandes. S’il en existe un qui correspond au besoin, un module suffit.
-
Évaluer si le comportement natif doit être modifié
Un hook permet d’ajouter du comportement à un endroit donné, pas de remplacer une logique existante. Si le besoin est de changer un calcul ou une règle déjà codée dans le cœur, aucun hook ne le permet, et l’override devient la seule option native.
-
Mesurer l’impact d’un override sur les mises à jour
Un override ne remplace aucun fichier du cœur : PrestaShop charge depuis le dossier override/ une classe qui étend la classe d’origine — Product étend ProductCore — et n’en redéfinit que les méthodes visées. À chaque montée de version, ces méthodes doivent être recomparées à celles de la classe d’origine, qui a pu changer entre-temps.
-
Documenter tout override créé
Un override non documenté, découvert des mois plus tard lors d’une mise à jour, coûte un temps de diagnostic largement supérieur au temps qu’aurait pris sa documentation initiale.
Ce qui distingue réellement les deux approches
Un module s’installe et se désinstalle proprement : il s’accroche à des hooks (par exemple displayHeader ou actionValidateOrder) via la méthode registerHook(), et chaque hook auquel il souscrit correspond à une méthode nommée sur le même modèle, comme hookDisplayHeader(). Désactiver ou supprimer le module retire proprement son comportement, sans laisser de trace dans le cœur.
Un override, lui, vit dans le dossier override/ (par exemple override/classes ou override/controllers) : PrestaShop y charge une classe qui étend la classe …Core du cœur — class Product extends ProductCore — et n’en redéfinit que les méthodes voulues, les autres continuant de venir du cœur. Aucun fichier natif n’est modifié ni remplacé. C’est plus puissant, parce que ça permet de changer un comportement que le système de hooks ne permettrait jamais d’atteindre, mais aussi plus fragile : si le cœur PrestaShop modifie la classe d’origine à une version ultérieure, l’override peut devenir incompatible, voire provoquer une erreur bloquante.
Dans la pratique, la plupart des modules distribués sur le marché n’utilisent que des hooks, précisément parce que c’est la méthode qui garantit la compatibilité la plus longue. Les overrides restent réservés aux besoins réellement impossibles à couvrir autrement.
Les erreurs courantes
- Créer un override alors qu’un hook existant aurait suffi, ce qui complique inutilement les futures mises à jour.
- Compter sur la superposition de plusieurs overrides de la même méthode provenant de modules différents : PrestaShop refuse. Module::addOverride lève une exception et l’installation du second module échoue avec un message explicite du type « Unable to install override: The method … in the class … is already overridden ». C’est le premier override installé qui reste en place.
- Oublier qu’un override survit à la désinstallation du module qui l’a créé, s’il n’a pas prévu de le retirer proprement lors de sa désinstallation.
- Modifier un override sans avoir conservé une trace de la classe d’origine, rendant impossible la comparaison lors d’une mise à jour.
Le cas intermédiaire des services et des événements Symfony
Sur PrestaShop 1.7 et plus, une troisième voie existe pour certains besoins avancés : le système d’événements et de services de Symfony, sur lequel repose désormais une partie du back-office. Un module peut y écouter un événement Symfony plutôt qu’un hook PrestaShop classique, ce qui reste plus proche dans l’esprit du module que de l’override, mais demande une connaissance plus poussée du framework sous-jacent.
Cette option reste réservée à des besoins spécifiques au nouveau back-office ; pour la grande majorité des modifications côté front ou côté logique métier classique, le choix se limite bien à hook contre override.
Questions fréquentes
Un thème personnalisé compte-t-il comme un override ?
Peut-on avoir plusieurs overrides sur des classes différentes sans risque ?
Comment savoir si un module utilise des overrides ou seulement des hooks ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.