Nous constatons que chaque boutique PrestaShop envoie chaque semaine une série d'e-mails sans que personne n'y prête attention : confirmations de commande, avis d'expédition, réinitialisations de mot de passe, messages de bienvenue. Puis, un client transfère l'un de ces e-mails en demandant : « Attendez, est-ce vraiment de vous ? » Le modèle conserve son aspect PrestaShop classique, vieux de plusieurs années, mais, curieusement, le système d'e-mails est désormais la partie qui paraît moderne et bien conçue.
Personnaliser les modèles d'e-mails PrestaShop ne se résume pas à une seule tâche. Il s'agit plutôt de deux problèmes qui se ressemblent. Le premier concerne l'apparence de l'e-mail, et le second, son envoi et son contexte. La plupart des tutoriels ne traitent que du premier point. Cet article aborde les deux, car un e-commerçant qui ne modifie que le modèle visuel se heurtera inévitablement à un obstacle lorsqu'il souhaitera une notification personnalisée, par exemple un e-mail de réapprovisionnement de votre commande en attente, que PrestaShop n'envoie pas par défaut.
1.0 Comment PrestaShop gère réellement les e-mails
Modifier les modèles revient à altérer les résultats de la logique sans toucher à la logique elle-même. Il serait utile de bien comprendre la structure du système avant d'apporter des modifications, car PrestaShop divise sa fonctionnalité de traitement des e-mails en deux couches distinctes situées à des emplacements totalement différents.
La première couche que vous verrez en travaillant dans l'interface d'administration est celle de PrestaShop. Chaque e-mail envoyé par PrestaShop est important. Il peut s'agir d'un e-mail de confirmation de commande, d'une facture, d'un e-mail vous permettant de réinitialiser votre mot de passe ou de confirmer votre inscription à la newsletter. Pour chaque e-mail, il existe un fichier HTML et un fichier texte, selon la langue. Ces versions sont enregistrées dans des fichiers distincts pour chaque langue et stockées dans le dossier « mails » de votre installation.
La couche logique est constituée de code. Dans PrestaShop, du code PHP, au sein du noyau ou d'un module, appelle la méthode `Mail::Send()` . Cette méthode permet à PrestaShop 1.7 et 8.x d'envoyer des e-mails transactionnels lors d'un événement. Les flux d'administration plus récents, basés sur Symfony, utilisent également cette méthode. Bien que certains modules utilisent leurs propres services de messagerie, il n'existe pas de service centralisant la méthode `Mail::Send()` dans tous les modules du noyau. Cette méthode `Mail::Send()` gère le chargement du fichier de modèle, les variables nécessaires et le destinataire de l'e-mail (confirmation de commande, statut, changement de mot de passe, etc.). Modifier le fichier de modèle affecte le résultat de cette logique, mais pas la logique elle-même.
La fonction Mail::Send() nécessite les paramètres suivants :
- $id_lang
- $template (nom du fichier, sans son extension)
- $sujet
- $template_vars (tableau contenant les variables permettant de remplacer celles du modèle)
- $à
- $to_name
- $à partir de
- $from_name
et d'autres paramètres potentiels comme $attachment.
Il prend également en charge le mode SMTP et impose un chemin de modèle personnalisé ainsi que `$id_order`. En pratique, la création d'un module d'e-mail personnalisé se résume principalement à la construction correcte du tableau `$template_vars` et à la vérification que `$template` pointe vers le fichier approprié. L' appel à la méthode `Mail::Send()` nécessite rarement plus.
Cette distinction est importante car de nombreux commerçants rencontrent des difficultés. Ils disent : « J’ai modifié le modèle, mais rien n’a changé » ou « Comment ajouter un e-mail automatisé ? » Ces problèmes proviennent d’une confusion entre les deux niveaux.
1.1 La couche modèle en pratique
Pour modifier l'apparence d'un modèle, il faut commencer par l'interface d'administration.
- Cliquez sur Améliorer > International > Traductions (ce chemin s'applique à PrestaShop 1.7 et 8.x ; pour PrestaShop 1.6, utilisez Localisation > Traductions). Choisissez Modifier les traductions, puis sélectionnez Traductions par e-mail comme type de traduction.
La page Traductions sous Améliorer > International
- Choisissez si vous modifiez le corps ou le sujet.
Type de traduction d'e-mail avec contenu de l'objet sélectionné
- Choisissez le thème, généralement Core (aucun thème sélectionné), sauf si vous utilisez une substitution de thème spécifique, et la langue que vous souhaitez modifier.
Traductions des e-mails définies sur Corps, avec thème et langue sélectionnés
- Cliquez sur Modifier, puis choisissez l'e-mail concerné dans la liste, comme un e-mail de création de compte ou de confirmation de commande.
La liste des e-mails principaux et des e-mails des modules s'affiche après avoir cliqué sur Modifier.
Liste des e-mails principaux étendue, affichant les noms des modèles individuels
Liste complète des modèles d'e-mails principaux disponibles pour la traduction
Le modèle de compte sélectionné, avec les onglets Afficher HTML / Modifier HTML / Afficher/Modifier TXT
Une fois cela fait, vous verrez trois options : un aperçu de la version HTML, une version HTML modifiable qui vous permet de passer au code source si vous souhaitez ignorer l’ éditeur WYSIWYG , et une version en texte brut.
Modifiez la version HTML du message électronique à l'aide de l'éditeur WYSIWYG intégré.
Modifiez systématiquement les versions HTML et texte brut, car certains clients de messagerie et certains utilisateurs ayant désactivé l'affichage des images ne lisent que la version texte. Si vous omettez cette étape, la moitié de vos destinataires recevra un e-mail qui ne correspond pas à l'e-mail personnalisé que vous venez de créer.
Afficher/Modifier la version TXT du modèle d'e-mail du compte
Si vous préférez travailler avec des fichiers, les mêmes modèles sont accessibles via FTP ou SFTP dans le dossier « mails ». Ce dossier est organisé par langue. Modifier le fichier account.html dans ce dossier, puis le télécharger à nouveau, produit le même résultat qu'avec l'éditeur du back-office.
Nous constatons l'absence de sécurité avec l'outil WYSIWYG. La moindre erreur dans les balises Smarty ou Twig du code du modèle entraînera un échec du rendu. Il est donc crucial de tester vos modifications via FTP sur le site de test de votre boutique. Un point pratique souvent source de confusion : les modifications de modèle sont spécifiques au thème et à la langue. Si votre boutique utilise un thème personnalisé et que vous avez modifié « Core (aucun thème sélectionné) », vos e-mails en production continueront d'utiliser le thème par défaut. Vérifiez toujours le thème actif avant de conclure qu'une modification n'a pas été prise en compte ; ce simple détail est à l'origine de nombreuses demandes d'assistance concernant l'absence de modifications. Autre point important : sur PrestaShop 8.x, si la boutique utilise le thème d'e-mail basé sur Twig au lieu du système de modèles classique, les e-mails peuvent ne pas apparaître dans l'écran des traductions. Consultez le menu Améliorer > Design > Thème d'e-mail pour vérifier la présence d'une option de traduction avant de supposer que l'écran classique contient tous les e-mails envoyés par la boutique. Tout d'abord, vérifiez à nouveau le menu sur PrestaShop car PrestaShop modifie constamment l'emplacement de la gestion des e-mails lors de ses mises à jour vers Symfony.
Si un thème remplace les modèles de courriel, ces fichiers se trouveront dans le dossier themes/ /mails/ /, qui suit la même structure de dossiers que le répertoire principal mails/. Un fichier nommé account.html placé à cet emplacement sera utilisé à la place de celui du répertoire principal mails/ pour les boutiques utilisant ce thème.
Il s'agit du même mécanisme de remplacement que les thèmes utilisent déjà pour les modèles de vitrine, appliqué ici aux e-mails.
Dans PrestaShop 9.x, la section « Design » > « Thème d’e-mail » affiche les options « Générer des e-mails » et « Traduire les e-mails » pour les thèmes d’e-mail basés sur Twig.
2.0 Erreurs de montage courantes à éviter
Quelques tendances se dégagent régulièrement lorsque les propriétaires de magasins commencent à personnaliser eux-mêmes leurs modèles :
- Modification uniquement de la version HTML. La version texte n'hérite pas automatiquement des modifications, et ce type de désynchronisation entre les modèles TXT et HTML après une mise à jour de traduction est un problème fréquemment signalé dans le système de suivi des problèmes de PrestaShop, même sans rapport de bug officiel.
- La suppression accidentelle des variables de modèle est possible. Les balises telles que {firstname}, {order_name} ou {id_order} sont des espaces réservés qui seront renseignés par le script de génération d'e-mails lors de l'envoi. Cependant, si le code HTML entourant la variable de modèle est modifié, celle-ci peut devenir inutilisable et cesser de fonctionner correctement. Les balises peuvent ne plus s'afficher correctement, disparaître ou apparaître telles quelles dans l'e-mail au lieu d'être résolues.
- Ne pas vider le cache après une modification peut entraîner des problèmes. PrestaShop génère des modèles, et un cache obsolète est la cause la plus fréquente de la non-affichage d'un e-mail après modification et test. Vous devez le vider depuis le back-office, dans la section Paramètres avancés > Performances, car c'est le cache du modèle Smarty qui est actualisé à cet endroit. La commande `bin/console cache: clear` vide un autre cache du framework Symfony et ne peut pas être utilisée en remplacement. Cette règle s'applique également aux modèles de thème surchargés : un thème fournissant ses propres modèles d'e-mail dans le répertoire `themes/`. Le dossier /mails/ les génère et les met en cache comme le fait PrestaShop, vos modifications n'apparaîtront donc pas tant que vous n'aurez pas vidé ce cache.
- Il est erroné de supposer que les modifications de l'objet se trouvent au même endroit que celles du corps du message. L'objet est une option à sélectionner dans le menu déroulant de l'écran Traductions ; il est donc facile de la manquer lors d'une première lecture.
- Tester l'e-mail dans un navigateur ou une boîte de réception peut être trompeur. L'aperçu du back-office affiche l'e-mail dans le contexte CSS du thème d'administration. Cela concerne les logiciels de messagerie comme Gmail, Outlook ou Apple Mail, dont les fonctionnalités CSS sont limitées. Ce qui semble correct dans l'aperçu peut s'avérer catastrophique après l'envoi.
- La deuxième étape consiste à informer vos clients du retour en stock d'un article en rupture de stock. Vous pouvez également configurer une alerte pour votre équipe d'entrepôt dès qu'une commande contient un article fragile. Malheureusement, aucun modèle PrestaShop ne propose ces fonctionnalités, car aucun déclencheur n'est actuellement disponible.
Il ne s'agit pas de problèmes exotiques. Les modèles sont la raison pour laquelle l'expression « modifier le modèle, enregistrer et passer à autre chose » se transforme souvent en une séance de débogage d'une heure.
3.0 Quand la modification d'un modèle ne suffit pas
C'est là que la deuxième couche prend toute son importance. Par exemple, vous pourriez avoir besoin d'informer vos clients de la disponibilité des produits qu'ils ont commandés, même s'ils étaient initialement en rupture de stock. Vous pourriez également vouloir avertir les magasiniers lorsqu'une commande contient un article fragile. PrestaShop ne propose pas de messages prédéfinis pour ce type d'alertes, car aucun signal n'est prévu pour ces situations.
Il s'agit d'un problème de logique, et non d'un problème de modèle. Il doit être résolu au niveau du module.
Le système de modules de PrestaShop expose des points d'événement (hooks) dans le code source auxquels les modules peuvent associer du code personnalisé, et plusieurs d'entre eux se déclenchent lors d'événements liés au cycle de vie des commandes et des clients (actionOrderStatusUpdate et actionOrderStatusPostUpdate pour les changements de statut de commande, actionCustomerAccountAdd (pour la création de compte, etc.). Un module conçu pour gérer un e-mail transactionnel personnalisé effectue généralement deux actions :
- Ce système écoute l'événement déclencheur. Pour une notification de réapprovisionnement, cela peut impliquer de se connecter aux mises à jour des quantités en stock. Pour un e-mail basé sur le statut d'une commande, cela signifie réagir à l'événement `actionOrderStatusUpdate`, qui se déclenche juste avant l'enregistrement du nouveau statut, ou à `actionOrderStatusPostUpdate`, qui se déclenche juste après. Ces deux événements ne sont pas interchangeables, car le code connecté au premier ne verra pas encore le nouveau statut enregistré dans la base de données.
- Appels Courriel::Envoyer() avec un nouveau modèle. Plutôt que de réutiliser un fichier modèle existant, un e-mail personnalisé bien conçu définit sa propre paire HTML/TXT placée soit dans le module lui-même mails dans un sous-dossier ou ajouté au dossier de langue de la boutique, et lui transmet les variables spécifiques dont le nouveau modèle a besoin.
PrestaShop propose plusieurs hooks d'envoi d'e-mails, chacun ayant une fonction différente. Choisir le bon permet de conserver un module léger et d'éviter les surcharges inutiles de classes Mail.
3.1 actionEmailSendBefore
Il s'agit du meilleur moyen de modifier les données principales d'un e-mail avant son envoi. Il fonctionne avec le destinataire, l'objet et les variables de modèle, et permet même d'empêcher l'envoi de l'e-mail.
Utilisez-le lorsque votre exigence concerne le contenu de l'e-mail plutôt que son apparence finale.
Exemple : Modifier le destinataire et l’objet
fonction publique hookActionEmailSendBefore($params) { // Rediriger l'e-mail pendant les tests $params['to'] = '[email protected]'; // Mettre à jour le sujet $params['subject'] = '[TEST] ' . $params['subject']; } Exemple : Annuler un e-mail de manière conditionnelle fonction publique hookActionEmailSendBefore($params) { si ($params['template'] === 'order_conf') { retourner faux; // Arrêter l'envoi de cet e-mail } }
3.2 actionEmailAddBeforeContent
Utilisez ce hook lorsque vous souhaitez simplement ajouter du contenu avant le corps de l'e-mail généré au format HTML ou TXT. Il est particulièrement adapté aux notifications qui doivent apparaître en haut de nombreux e-mails transactionnels. Le modèle d'e-mail original reste inchangé.
Le modèle d'e-mail original reste inchangé.
Exemple : Ajouter une mention au-dessus du contenu de l’e-mail
fonction publique hookActionEmailAddBeforeContent($params) { retour ' Important : Veuillez conserver ce courriel pour vos archives. '; }
3.3 actionEmailAddAfterContent
Ce hook fonctionne de la même manière que le précédent, sauf que le contenu est ajouté après le corps de l'e-mail généré.
Utilisez-le pour les informations qui ont naturellement leur place dans le pied de page.
Exemple : Ajouter des informations de support
fonction publique hookActionEmailAddAfterContent($params) { retour ' Besoin d'aide ? Contactez notre équipe d'assistance à tout moment. '; }
3.4 actionMailAlterMessageBeforeSend
Ce point d'extension est destiné à une personnalisation avancée. Au lieu de modifier les données du modèle, il permet d'accéder à l'objet message final juste avant sa distribution.
Choisissez ce point d'accroche lorsque votre besoin concerne l'objet mail lui-même plutôt que le contenu du modèle.
Exemple : Ajouter un en-tête de courriel personnalisé
fonction publique hookActionMailAlterMessageBeforeSend($params) { /** @var \Symfony\Component\Mime\Email $message */ $message = $params['message']; $message>getHeaders()>addTextHeader( 'XModuleSource', « Mon module personnalisé » ); }
3.5 Guide de décision rapide
En pratique, il est conseillé d'utiliser systématiquement `actionEmailSendBefore` pour la logique métier, les hooks de contenu pour l'injection simple du corps du message, et de réserver `actionMailAlterMessageBeforeSend` pour une personnalisation avancée au niveau du message. Cette approche garantit la compatibilité de votre module avec le système de messagerie natif de PrestaShop sans nécessiter de surcharges.
Pour les cas non couverts par les hooks natifs mentionnés ci-dessus, certains modules tiers vont plus loin : plutôt que chaque module ne surcharge individuellement la classe Mail de PrestaShop , un module comme prestashopmailhook effectue cette surcharge une seule fois et la réexpose comme son propre hook, actionMailSend, qui se déclenche à chaque envoi d' e-mail, qu'il réussisse ou non. Il est important de préciser qu'il s'agit toujours d'une surcharge de la classe Mail de base, présentant le même risque de fragilité lors des mises à jour, décrit précédemment. Son principal avantage réside dans le fait que d'autres modules peuvent inspecter ou modifier un message, changer le système d'envoi, ajouter des variables personnalisées ou bloquer un message sous certaines conditions, le tout en réagissant au même hook au lieu de surcharger Mail indépendamment, ce qui est à l'origine des conflits entre modules. Avant d'installer un tel module, vérifiez sa compatibilité avec votre version de PrestaShop (ps_versions_compliancy), car une surcharge de Mail non maintenue correspond exactement au type de surcharge évoqué dans cet article.
3.6 Exemple pratique : E-mail personnalisé déclenché par le statut de la commande
Supposons que vous souhaitiez envoyer par courriel à un client un message personnalisé de « remerciement et conseils d'entretien » spécifiquement lorsqu'une commande liée à une certaine catégorie de produits est expédiée ; or, le modèle de confirmation d'expédition par défaut ne peut pas le faire, car il ne tient pas compte des catégories de produits.
Concrètement, cette solution se présente comme suit :
- Un petit module personnalisé s'enregistre sur le actionOrderStatusUpdate (ou actionOrderStatusPostUpdate) crochet.
- Dans la méthode de hook, le module vérifie si la commande contient un produit de la catégorie concernée et suit les commandes pour lesquelles il a déjà envoyé un e-mail, car ce hook peut se déclencher plusieurs fois pour la même transition de statut dans certains flux, et le fait qu'un client reçoive le même « merci » deux fois est considéré comme un bug.
- Si la correspondance est établie, le module charge sa propre paire de modèles (et non le modèle d'expédition principal) et appelle la méthode d'envoi de courriel avec les variables spécifiques à la commande : nom du client, nom du produit, lien de suivi, en échappant toute valeur fournie par le client avant qu'elle n'apparaisse dans le modèle HTML, car une variable non échappée constitue une véritable ouverture pour l'injection de contenu stocké.
- L'e-mail principal de confirmation d'expédition est toujours envoyé comme d'habitude ; il s'agit d'un e-mail supplémentaire ajouté en plus.
C’est très différent de la modification du modèle d’expédition, car modifier ce modèle enverrait le message à toutes les commandes expédiées, et non seulement à celles que vous souhaitez.
Le module de points de fidélité de Knowband (kbloyaltypoints) illustre parfaitement ce principe. Il s'active lors de l' événement actionOrderStatusUpdate et chaque règle de fidélité configurée définit sa propre condition (par exemple, un montant minimum d'achat) ainsi que son propre e-mail de notification. Lorsqu'une commande passe à l'un des statuts configurés dans les paramètres généraux du module (« attribuée » ou « annulée »), le mécanisme se déclenche, vérifie la conformité de la commande avec la règle correspondante et, le cas échéant, envoie l'e-mail de notification associé (créé avec l'objet et le modèle WYSIWYG propres au module, et non le modèle par défaut des statuts de commande) pour informer le client de l'attribution ou de l'annulation de ses points de fidélité.
Module Points de fidélité - Paramètres généraux, où sont configurés les statuts de commande qui déclenchent l'attribution/l'annulation de points.
Le modèle d'onglet Notifications propre à la règle correspond à l'e-mail envoyé au client lorsque le hook de statut de commande lui attribue ses points de fidélité.
Ce que le client reçoit réellement dans sa boîte de réception une fois que le déclencheur est activé et que l'e-mail de notification de la règle est envoyé.
Consultez le module en question ici : Module de points de fidélité Knowband
4.0 Déterminer l'approche dont vous avez réellement besoin
Avant d'entamer toute personnalisation, il est judicieux de procéder à une brève vérification des décisions :
- Vous souhaitez simplement modifier le texte, les couleurs ou ajouter un logo à un e-mail existant ? Restez sur l’écran Traductions. Aucun code n’est requis.
- Je veuxVous souhaitez que vos e-mails transactionnels aient une apparence sensiblement différente : une nouvelle mise en page, une structure différente et un système de design cohérent avec votre marque ? Vous modifiez encore les fichiers modèles, mais prévoyez de repenser entièrement le code HTML/TXT (idéalement avec un HTML basé sur des tableaux pour la compatibilité avec les clients de messagerie) plutôt que de corriger le modèle par défaut élément par élément.
- Vous souhaitez envoyer un nouvel e-mail qui n'existe pas encore, ou déclencher un e-mail existant sous certaines conditions ? Cela nécessite un module avec une logique de hook ; la couche de modèles seule ne suffit pas.
- Vous gérez de nombreux modèles pour plusieurs boutiques ou langues et vous ne souhaitez pas les modifier manuellement un par un ? C’est là qu’intervient un Un module dédié à la gestion des modèles d'e-mails ou un pack de modèles préconfigurés justifie son coût, car il gère généralement la synchronisation multi-boutiques et multilingue que l'écran par défaut rend fastidieuse.
- Créer un élément réutilisable d'un projet à l'autre, comme une bibliothèque partagée de logique d'e-mails transactionnels ? Cela suggère de développer un petit SDK interne ou une bibliothèque d'assistance plutôt que de dupliquer le code. Courriel::Envoyer() appels entre plusieurs modules.
5.0 Liste de vérification rapide avant le lancement
Avant de mettre en ligne toute personnalisation d'e-mail, veuillez suivre les étapes suivantes :
- Les versions HTML et TXT ont été mises à jour et enregistrées.
- Le thème correct a été sélectionné lors de la modification (et non pas simplement « Core » par défaut).
- Toutes les variables du modèle sont intactes et s'affichent correctement lors d'un envoi de test.
- Cache vidé après la modification
- Effectuez l'envoi de test dans au moins deux boîtes de réception réelles (et pas seulement dans l'aperçu de l'administrateur).
- L'objet a été modifié séparément, si nécessaire.
- Pour une logique personnalisée : le hook est confirmé pour se déclencher uniquement dans les conditions prévues, et non à chaque commande.
- Les paramètres SMTP ont été vérifiés dans Paramètres avancés > Courriel, le test ne masque donc pas un problème de distribution.
Un point important à souligner : le journal d'envoi de PrestaShop indique que l'appel à Mail::Send() a été effectué et que le message a été transmis, mais cela ne prouve pas qu'il est arrivé dans la boîte de réception. Une configuration incorrecte du serveur SMTP (hôte, port ou identifiants) dans les Paramètres avancés > E-mail peut faire apparaître ces e-mails comme envoyés dans le journal, alors qu'aucun message n'a réellement été expédié. Après toute modification des paramètres du serveur de messagerie, vérifiez systématiquement la bonne réception des e-mails dans une boîte de réception.
6.0 Poser les bases
Les e-mails transactionnels sont bien plus importants que ce que la plupart des commerçants imaginent ; ils font partie des rares communications que les clients lisent réellement, car ils attendent les détails de leur commande ou de leur compte. Un modèle d'e-mail générique et impersonnel ne contribue pas vraiment à maintenir la confiance du client. Cependant, la solution ne réside pas toujours dans la modification du code HTML ; parfois, une simple correction suffit, et d'autres fois, le module doit savoir quand cet e-mail doit être généré.
Si vous venez de commencer votre projet, il est déconseillé de faire deux choses à la fois. Commencez par corriger vos modèles, ce qui donnera à votre boutique une apparence très professionnelle. Ensuite, vous pourrez créer des hooks personnalisés basés sur une logique spécifique, si cela s'avère nécessaire, comme mentionné précédemment.
7.0 La version courte
Chaque e-mail PrestaShop pose deux problèmes distincts : son apparence et son déclenchement. Modifier un modèle ne résout que le premier.
Les modifications d'ordre esthétique se font dans l'écran Traductions ; aucun code n'est nécessaire. Une nouvelle notification, ou un e-mail existant devant être déclenché sous de nouvelles conditions, nécessite un module s'insérant dans un événement PrestaShop et appelant directement la méthode Mail::Send().
Avant même de créer un module complet, les hooks de messagerie de PrestaShop, actionEmailSendBefore et ses homologues, peuvent déjà réécrire, étendre ou annuler un envoi sans qu'il soit nécessaire de remplacer la classe Mail.
Un dernier point important : l’entrée « envoyé » dans le journal des messages indique seulement que la fonction Mail::Send() a été appelée, et non que le message est bien arrivé dans la boîte de réception. Il est donc essentiel de toujours vérifier la bonne réception du message.
Merci pour la lecture.
Pour toute question ou assistance concernant les performances ou la migration de votre site web, nos experts sont à votre disposition. Contactez l'équipe Knowband à l'adresse [email protected] dès aujourd'hui pour obtenir des plugins e-commerce fiables et adaptés à vos besoins.
