Chez Mintfull, on a mis les mains dans des boutiques PrestaShop plus souvent qu'on ne compte… et s’il y a bien un sujet sur lequel on voit revenir les mêmes erreurs, c’est les hooks. Mal choisis, mal utilisés, mal compris : les pièges sont nombreux, surtout quand on veut créer un module PrestaShop sans connaître tous les rouages du système. Grâce à notre expérience dans le développement de modules Prestashop, on a de multiples bonnes pratiques que l'on applique sur chaque module développé.
On décortique ici les mauvaises pratiques courantes liées aux hooks, avec un seul objectif : vous aider à exploiter les bons, au bon moment, pour un code propre, robuste et durable.
Petit rappel : c’est quoi un hook PrestaShop ?
Un hook sur Prestashop, c’est un point d’accroche exposé par PrestaShop sur l'ensemble des pages de votre site. Le CMS en propose des centaines, dans son cœur comme dans ses fichiers de template, pour permettre aux modules de s’y brancher. C’est ce qui rend PrestaShop aussi modulaire : au lieu de modifier directement le noyau, on s’insère proprement à des endroits clés sur chacune des pages.
Il existe deux grandes familles de hooks :
-
Les hooks visuels, qui permettent d’afficher du contenu dans le front-office ou le back-office
-
Les hooks logiques, qui déclenchent du code à des moments précis du cycle de vie (création de commande, validation de paiement, inscription client...)
Bien utiliser les hooks, c’est donc savoir où et quand accrocher son module pour qu’il joue sa partition sans fausse note et sans venir interférer avec les autres modules.
Erreur 1 – Mal choisir son hook (ex : le piège d’actionValidateOrder)
C’est une erreur qu’on retrouve souvent dans les modules développés à la va-vite : utiliser un hook « qui marche » sans vérifier le moment exact où il est exécuté. Exemple typique : actionValidateOrder.
Ce hook est souvent employé pour déclencher une action juste après qu’une commande soit validée. Mais en réalité, il s’exécute avant que la commande ne soit entièrement enregistrée dans la base. Résultat : certaines données critiques comme invoice_date, l’ID de facture ou l’état final ne sont pas encore disponibles.
Et contrairement à une idée reçue, le hook actionOrderStatusPostUpdate n’est pas une solution parfaite : lui aussi s’exécute avant que le changement de statut ne soit entièrement persisté. Il peut être utile pour suivre l’évolution du statut, mais pas pour modifier une commande en toute sécurité.
La bonne alternative, compatible avec toutes les versions 1.7.x, reste actionOrderHistoryAddAfter. Ce hook est déclenché après l’enregistrement complet de l’historique de commande, ce qui garantit que toutes les infos sont sauvegardés. Cependant, car rien n'est jamais parfait, ce hook va s'exécuterait à chaque changement de statut. Il faut donc être vigilant
Le hook actionValidateOrderAfter qui intervient une fois que la commande est validée et stable., par exemple, n’est disponible qu’à partir de PrestaShop 8. Si vous êtes encore sur 1.7.8, mieux vaut utiliser actionOrderHistoryAddAfter avec précaution. On détaille d’ailleurs comment anticiper la fin de vie de PrestaShop 1.7 et sécuriser vos modules pour l’avenir.
Erreur 2 – Injecter du code métier dans un hook de rendu
Certains hooks ne sont pas faits pour exécuter de la logique métier. C’est le cas de displayHeader, souvent détourné de son usage initial. Ce hook est prévu pour injecter des ressources CSS ou JS dans la balise
Y ajouter des traitements lourds (appels API, génération dynamique, écritures en base, etc.) est une très mauvaise idée :
-
Ça alourdit les temps de chargement
-
Ça rend le comportement du site imprévisible
-
Et surtout, ça rompt la logique d’isolation des responsabilités
Injecter du code métier dans displayHeader, c’est typiquement le genre de pratique qui plombe les performances de votre front. On en parle justement dans notre article dédié à l’optimisation PrestaShop, où chaque milliseconde compte.
Prenez un exemple concret :
public function hookDisplayHeader($params) {
// Mauvaise pratique : exécuter ici des traitements métiers ou du code conditionnel
}
Préférez toujours une tâche cron dédiée ou un hook logique plus pertinent (actionFrontControllerSetMedia, actionDispatcher, etc.). Et limitez displayHeader à son usage de base : ajouter des appels de CSS ou JS addCSS() ou addJS() ou ajouter des informations pertinentes dans le header de votre site.
Erreur 3 – Court-circuiter le cycle PrestaShop avec du SQL brut
Vous avez besoin d'ajouter ou de modifier un enregistrement en base ? Pas de souci. Mais attention : ne le faites jamais en direct via une requête SQL si l’objet concerné est couvert par un ObjectModel.
Exemple à ne pas reproduire :
Db::getInstance()->execute("UPDATE ".\_DB\_PREFIX\_."orders SET invoice\_date = NOW() WHERE id\_order = ".(int)$id\_order);
Pourquoi c’est dangereux ? Parce que vous :
-
Bypassez les hooks automatiques (
actionObjectOrderUpdateAfter, etc.) -
Oubliez la gestion multiboutique
-
Ne mettez pas à jour les caches internes
Bref : vous coupez court au cycle natif de PrestaShop, ce qui rend votre script fragile, et parfois invisible pour d’autres modules.
La bonne méthode :
$order = new Order($id\_order);
$order->invoice\_date = date('Y-m-d H:i:s');
$order->save();
C’est plus long à écrire, certes. Mais c’est bien plus stable à maintenir et en ajoutant cela, vous vous assurez d'exécuter l'ensemble des hooks Prestashop.
Erreur 4 – Ignorer l’ordre d’exécution des modules
Quand plusieurs modules sont accrochés à un même hook, l’ordre dans lequel ils s’exécutent n’est pas garanti. Et ça peut poser de vrais problèmes, surtout si un module dépend du travail d’un autre.
Imaginez : le module A modifie le contenu d’un produit, et le module B le lit. Si B passe avant A, il récupère une version obsolète.
Heureusement, que vous soyez sur PrestaShop 1.6, Prestashop 1.7 ou mêmes les versions supérieurs, vous pouvez gérer cet ordre de deux façons :
-
Dans le back-office via Design > Positions, avec un simple glisser-déposer
-
En code, via le paramètre de priorité lors du
registerHook()
Si vous développez un module qui doit passer en premier (ou en dernier), ne laissez pas le hasard décider. Documentez vos dépendances, testez en contexte, et imposez l’ordre si besoin.
Erreur 5 – Oublier la gestion d’erreur dans les hooks critiques
Certaines étapes sont trop sensibles pour laisser passer des erreurs silencieuses. C’est le cas de :
-
La validation de paiement (
actionPaymentConfirmation) -
La création ou la connexion d’un client (
actionCustomerAccountAdd,actionCustomerLoginAfter) -
La modification de commandes (
actionObjectOrderUpdateAfter)
Une simple exception non capturée dans l’un de ces hooks peut casser tout le processus, afficher une erreur 500 en front, ou pire : ne laisser aucune trace visible du bug.
D’où l’importance d’enrober vos traitements dans un try/catch, et de logger proprement toute anomalie :
public function hookActionPaymentConfirmation($params) {
try {
// Traitement critique
} catch (\\Exception $e) {
Logger::addLog("Erreur dans hookActionPaymentConfirmation : ".$e->getMessage(), 3);
}
}
Ne laissez jamais une exception "monter toute seule" dans un hook sensible.
Autres mauvaises pratiques à éviter
-
Oublier de return dans un hook filtre : certains hooks, comme
filterProductSearch, sont en chaîne. Si vous ne retournez pas$params, les autres modules ne peuvent pas poursuivre le traitement. -
Utiliser un hook absent du thème : tous les thèmes ne déclarent pas les mêmes hooks. Par exemple,
displayFooterpeut être manquant. Vérifiez dans vos templates. -
Utiliser des hooks obsolètes : certains modules utilisent encore Header (obsolète depuis la 1.7) au lieu de displayHeader. Mettez à jour vos références.
-
Oublier de se désenregistrer proprement : un module qui oublie unregisterHook() dans sa méthode uninstall() peut rester accroché à un hook fantôme. Résultat : comportement fantôme et bugs en cascade.
Ce qu’on applique chez Mintfull pour des modules clean et durables
On ne prétend pas être parfait. Mais chez Mintfull, on s’impose une vraie rigueur :
-
Choix raisonné des hooks selon les reco de Presta
-
On évite le SQL sauvage quand un ObjectModel existe
-
Gestion fine des priorités d’exécution
-
Traitement des erreurs systématiquement loggué
Et surtout, on teste en conditions réelles. Chaque module développé (on en a plus de 50 au compteur) passe par un process clair : cahier des charges métier, structuration du script, vérification multiboutique si nécessaire, multi-langue, compatibilité montante.
Notre objectif : créer des modules qui durent, qu’on puisse maintenir dans 6 mois, et qui s’intègrent proprement à l’écosystème PrestaShop 1.7 ou Prestashop 8.
Bonus : vous pouvez aussi proposer vos propres hooks à la communauté
C’est souvent oublié, mais PrestaShop est un projet open source. Vous n’êtes pas limité aux hooks existants : vous pouvez en créer dans vos modules, mais aussi proposer de nouveaux points d’accroche directement au cœur du CMS via une merge request.
Vous avez identifié un besoin générique qui manque dans le cycle natif ? Ouvrez une issue sur GitHub, discutez avec la communauté, soumettez un patch. Chaque contribution compte.
En contribuant au projet, vous rendez le projet plus flexible, plus solide, et vous aidez des centaines d’autres développeurs. C’est aussi ça, l’esprit open source 💪
