Le module ne s'affiche que lorsque la boutique n'est pas en mode catalogue et lorsque PrestaShop renvoie plus d'une devise active. S'il n'y a qu'une seule devise active, le hook ne renvoie rien et aucun sélecteur n'est affiché. Le placement dépend aussi du thème, qui doit rendre le hook displayNav2 dans la zone header ou navigation.

Chaque message personnel est construit à partir d'un spécimen : un vrai email exporté depuis votre propre logiciel de messagerie. Le module préserve sa structure, sa signature et sa partie texte brut et ne remplace que le corps pour chaque destinataire. Il n'y a ni pixels de tracking, ni liens réécrits, ni balisage de campagne : le message livré porte la même structure que les emails que votre équipe envoie à la main.

À la livraison, pas à la date de commande. L'article 9, paragraphe 2, point b) de la directive 2011/83/UE fait courir le délai à partir du jour où le consommateur prend physiquement possession du bien, ce qui arrive plusieurs jours après la commande dans la plupart des boutiques.

Le module détermine ce moment à partir de la meilleure source disponible, dans cet ordre : une date de livraison saisie manuellement, une date par expédition issue de MPR Warehouse Revolution, le premier passage de la commande dans un statut marqué comme livraison, la date de livraison enregistrée sur la commande, puis le transporteur.

Si rien n'est connu, aucune échéance n'est fixée et le délai n'a pas commencé. C'est volontaire : une date de départ devinée pourrait clore un droit dont le client dispose encore.

Oui. Le module vise PrestaShop 1.7.7 et versions ultérieures et fonctionne sous 1.7.x, 8.x et 9.x avec PHP 7.1 ou supérieur. Il s'enregistre sur les hooks de la page d'accueil (displayHome / displayHomeIntro) et peut aussi être intégré comme widget, sans modification du cœur.

Une licence à vie pour un domaine avec 3 mois de support et de mises à jour inclus. Les nouvelles versions s'installent par le canal de mise à jour standard depuis votre portail client, et des extensions de support sont disponibles sur la page produit.

Non. L'historique des campagnes, les listes de suppression, les preuves de consentement et le journal d'audit sont délibérément conservés en base de données à la désinstallation, car les enregistrements de suppression et de consentement sont des engagements envers vos clients. Les retirer est une opération de base de données séparée et délibérée.

Mail Revolution prend en charge PrestaShop 1.6 – 9.x sur PHP 7.1 ou plus récent, comme le reste du catalogue mypresta.rocks. Il est compatible multiboutique : campagnes, files et listes de suppression sont cloisonnées par boutique.

Non. Les lettres personnelles partent par la route mail propre de votre boutique et rien dans le module n'exige de compte externe. Pour les newsletters de diffusion, vous pouvez en option brancher un fournisseur SMTP comme identité newsletter dédiée, mais ce n'est pas nécessaire pour utiliser le module.

Les campagnes personnelles en mode manuel retiennent chaque message rendu. La file liste les destinataires par meilleur score d'abord et montre l'email exact que chaque client recevrait, avec le paragraphe personnalisé surligné. Un collègue nommément désigné approuve ou rejette chaque message ; les décisions sont enregistrées avec le compte employé et un horodatage, et modifier un message invalide les approbations antérieures.

Une réponse du client suffit pour se désinscrire des campagnes personnelles, et les newsletters portent toujours des en-têtes de désinscription en un clic. Désinscriptions, bounces et plaintes alimentent une liste de suppression vérifiée juste avant chaque envoi, et un garde-fou un-message-par-campagne empêche les contacts répétés.

La commande n'a qu'une seule échéance, et elle court à partir du dernier colis. L'article 9, paragraphe 2, point b) i) est explicite : lorsque plusieurs biens commandés ensemble sont livrés séparément, le délai commence à la réception du dernier.

C'est précisément là que les procédures de retour tenues à la main dérapent. Si la moitié arrive lundi et le reste vendredi, faire expirer la moitié du lundi en premier revient à refuser un retour que la boutique doit encore accepter.

Le module enregistre la livraison ligne par ligne, ce qui vous montre quand chaque article est arrivé, tout en appliquant une échéance unique à la commande. Les dates par ligne servent vos archives et ne peuvent jamais expirer avant l'échéance de la commande.

Non. Les factures et avoirs déjà émis ne sont jamais réécrits, pas plus que les paiements, les totaux, le détail des commandes, les transporteurs, l'historique, les mouvements de stock ou les expéditions. Une fusion change le propriétaire d'une commande, rien de la commande elle-même. Une adresse à laquelle une commande renvoie conserve son identifiant et tous les champs qui figurent sur vos documents : une ancienne facture décrit donc toujours la livraison réellement effectuée.

Il ajoute le Messenger officiel d'Intercom à votre boutique PrestaShop. Le module insère le loader Intercom juste avant la balise body fermante sur chaque page : vous collez votre App ID Intercom une seule fois au lieu de modifier les templates du thème. Le widget se charge exactement comme le snippet d'installation d'Intercom, en conservant votre boîte de réception, vos visites guidées et vos messages automatisés.

Non, et c'est volontaire. Ce module ne contient aucune téléphonie : pas de numérotation automatique, pas de SIP, pas de Twilio, pas d'enregistrement. Il recueille la demande, vous prévient et vous relance jusqu'à ce que vous la clôturiez. L'appel, vous le passez vous-même, depuis le lien cliquable de la file d'attente.

Si vous avez besoin de numérotation automatique, d'enregistrements ou de statistiques d'agents, il vous faut une plateforme téléphonique hébergée avec un abonnement. Ceci est l'alternative que vous possédez, pour les boutiques qui veulent simplement que le contact arrive et ne soit pas oublié.

Le module construit des événements GA4 à partir d'actions PrestaShop réelles plutôt que d'une simple balise de page vue. Il suit les vues produit, l'ajout au panier et les changements de quantité, le début du paiement, les achats finalisés, les recherches sur le site, les connexions client et la création de compte, chacun envoyé avec les paramètres e-commerce GA4 correspondants. Un générateur d'événements intégré permet aussi de définir des événements personnalisés.

Oui. Le module enregistre son propre sélecteur dans le hook displayNav2 et charge une feuille de style qui masque le sélecteur de devise desktop natif de PrestaShop avec #_desktop_ps_currencyselector { display: none !important; }. Le client voit le menu déroulant compact par symbole du module au lieu du bloc devise par défaut.

Il ne désinstalle ni ne modifie le module de devise natif de PrestaShop. Il rend simplement un menu déroulant de remplacement dans le hook header/navigation et masque le bloc desktop standard avec du CSS. Cela rend le changement réversible : désactivez ou désinstallez le module et le sélecteur natif peut réapparaître, à condition que le thème le rende encore.

Le remplacement utilise le symbole de la devise courante dans le toggle, affiche optionnellement le label ISO à côté, et liste les devises actives dans le dropdown. Les valeurs par défaut sont SHOW_LABEL=0 et SHOW_NAMES=1, donc le toggle reste compact tandis que le dropdown affiche encore les noms complets des devises. Chaque option est un lien nofollow construit avec les paramètres normaux de changement de devise de PrestaShop.

Le placement dépend toujours du thème. Si le thème n’appelle pas displayNav2 dans la zone header ou navigation, le module n’a nulle part où rendre le sélecteur même si les assets sont chargés.

Le module ne se rend que lorsque la boutique n’est pas en mode catalogue et lorsque PrestaShop renvoie plus d’une devise active. S’il n’y a qu’une seule devise active, le hook ne renvoie rien, donc aucun sélecteur ne s’affiche. Le placement dépend aussi du thème qui doit rendre le hook displayNav2 dans la zone header ou navigation.

Vérifiez d’abord ces points :

• Catalog mode : si le mode catalogue est activé, le sélecteur renvoie volontairement une chaîne vide.
• Nombre de devises : le module appelle la liste de devises actives de PrestaShop et se masque quand cette liste contient une seule devise ou aucune.
• Hook du thème : le sélecteur est rendu uniquement via displayNav2. Certains thèmes personnalisés suppriment ou déplacent ce hook.
• CSS du bloc natif : le module masque #_desktop_ps_currencyselector. Si vous cherchez seulement l’ancien bloc, il est volontairement masqué pendant que ce module est actif.

Si le sélecteur n’apparaît toujours pas après activation de plusieurs devises, inspectez la source de page pour mprcurrency-dropdown. Si ce markup manque, le hook ne se rend pas ou le module est sorti tôt. Si le markup existe mais que vous ne le voyez pas, le problème vient du CSS du thème ou de la mise en page header plutôt que de la disponibilité des devises.

Le module charge son propre CSS et JavaScript sur le front-office. Le JavaScript ouvre et ferme seulement le dropdown ; il ne crée pas le markup du sélecteur. Un sélecteur manquant est donc presque toujours dû au mode catalogue, à une configuration mono-devise, à un hook displayNav2 absent, ou à du styling thème qui masque le bloc rendu.

Oui, si vous l'activez. En configurant un secret d'API GA4, le module peut envoyer les achats côté serveur via le Measurement Protocol en solution de repli, de sorte qu'une commande reste enregistrée dans GA4 même lorsque la balise gtag.js du navigateur est bloquée par un bloqueur de publicités ou perdue sur une page en échec. Ce repli ne fonctionne que si vous l'activez et fournissez le secret d'API.

Pour une rétractation légale portant sur toute la commande, oui. L'article 13, paragraphe 1 exige le remboursement de tous les paiements reçus du consommateur et mentionne expressément les frais de livraison.

L'article 13, paragraphe 2 plafonne ce montant. Si le client a choisi une livraison plus chère que votre option standard la moins chère, vous ne devez que cette option standard : un surclassement en express n'est pas remboursable. Renseignez votre livraison standard la moins chère dans les réglages et le plafond s'applique automatiquement.

Deux cas diffèrent. Lorsqu'une partie seulement de la commande revient, le service de livraison a bien servi pour ce que le client garde, donc les frais ne sont pas remboursés par défaut. Lorsque le bien était défectueux, erroné ou manquant, les frais sont remboursés intégralement : il s'agit d'une mise en conformité, pas d'une rétractation.

Chaque montant est affiché avec la raison de son inclusion ou de son exclusion, avant votre validation.

Parce qu'un compte à rebours engage un humain, et qu'à 22h40 un samedi personne ne le tient. Une promesse rompue coûte plus de confiance qu'une promesse jamais faite.

Le module lit vos horaires et ne propose que ce que vous pouvez tenir : dès que possible tant que vous êtes réellement ouvert, ce matin, plus tard aujourd'hui, ou votre prochain jour d'ouverture. En dehors des heures, il annonce un rappel pendant les heures d'ouverture. La mention "généralement sous N minutes" n'apparaît que boutique ouverte.

Oui. Chaque fusion écrit un instantané chiffré de chaque ligne modifiée, et History & Undo vous propose un bouton tant que cet instantané existe, 30 jours par défaut. L'annulation refuse si elle écrasait quelque chose de modifié après la fusion, si l'identifiant d'un client absorbé a été réattribué, ou si une demande d'effacement RGPD a supprimé l'instantané. Les sessions client sont l'exception délibérée : la fusion les révoque et elles ne sont jamais restaurées, car rendre une session active ouverte serait une voie de détournement de compte.

Connectez-vous à votre compte Intercom sur app.intercom.com, ouvrez Réglages > Installation > Web et copiez l'App ID depuis le code d'installation. Collez-le dans le champ App ID du module et enregistrez. Tant qu'aucun App ID n'est renseigné, le widget reste inactif : le module ne produit jamais de script cassé ou vide sur votre boutique.

Le module parcourt votre base à la recherche de toute table portant une référence client, y compris des tables qu'il n'a jamais vues, et les liste sur l'écran Data Sources avec leur nombre de lignes et le risque d'un rattachement. Vous choisissez une stratégie par table. Rien n'est écrit dans une table sans stratégie. Une table impossible à annuler, une table avec déclencheur, une vue ou une table sans clé primaire bloque la fusion au lieu d'être traitée au mieux.

Le module prend en charge un chargement respectueux du consentement, afin que le suivi tienne compte de l'état de consentement du visiteur, et propose un identifiant utilisateur haché plutôt que le stockage d'identifiants bruts. Le comportement du consentement dépend des options activées et de la solution de consentement externe (par exemple une CMP) que vous connectez. Vous restez responsable de votre propre configuration de confidentialité et de consentement.

PrestaShop 1.6.x à 9.x, sur PHP 7.1 et supérieur. La version 1.0.0 a été installée et testée sur PrestaShop 1.6.1.24 avec PHP 7.1, 1.7.8.11, 8.2.1 et 9.2.0.

Le module choisit les hooks adaptés à la version qu'il trouve : les noms de 1.6 sur 1.6, les modernes à partir de 1.7, et il n'enregistre jamais deux hooks qui afficheraient le bouton deux fois sur la même page.

Oui. Lorsque « Transmettre les données utilisateur » est activé, le module envoie l'e-mail et le nom du client connecté à intercomSettings, si bien que les conversations arrivent déjà identifiées dans votre boîte Intercom. Les invités voient toujours le Messenger, mais de façon anonyme : aucune donnée personnelle n'est envoyée pour les visiteurs non connectés.

Oui. Le module tient ses propres enregistrements de retour et ne lit ni n'écrit jamais les tables de retours de PrestaShop : il fonctionne que cette fonction native soit active ou non.

Si vous laissez les retours natifs activés, rien n'entre en conflit : les deux coexistent et le module n'interfère pas avec le flux natif. La plupart des boutiques désactivent le natif, car le panneau client du module remplace le formulaire natif minimal et ajoute l'échéance dont ce formulaire n'a aucune notion.

Non. Il utilise les devises déjà configurées dans PrestaShop et construit des liens de changement avec SubmitCurrency=1&id_currency=.... Il ne crée pas de devises, ne modifie pas les taux de change et ne calcule pas les conversions. La disponibilité des devises, les taux et le comportement des prix restent gérés par la configuration devise de PrestaShop.

Le module lit les devises actives de PrestaShop, trouve la devise courante depuis le contexte client, et rend un lien pour chaque devise disponible. Cliquer un lien demande à PrestaShop de changer la devise sélectionnée du visiteur ; ensuite, PrestaShop gère conversion des prix, arrondis, affichage de taxe et formatage exactement comme d’habitude.

Utilisez les réglages de devise propres à PrestaShop pour les changements opérationnels : ajouter ou désactiver des devises, mettre à jour les taux de change, configurer la localisation et décider comment les prix doivent s’afficher. Utilisez ce module pour la présentation front-office du sélecteur : toggle symbole seul, code ISO optionnel dans le toggle, noms optionnels dans le dropdown, styling sensible au thème et empreinte compacte dans le header.

Une façon utile de le penser : PrestaShop possède la logique d’argent ; le module possède l’UI du dropdown. Si une devise manque dans le sélecteur, corrigez d’abord son état active/available dans PrestaShop. Si les valeurs de conversion sont fausses, mettez à jour les taux de change dans PrestaShop plutôt que dans ce module.

Le texte de consentement exact affiché au visiteur est conservé avec chaque demande, avec une empreinte à clé et un horodatage : vous montrez ce qui a été accepté, pas ce que la page affiche aujourd'hui.

Le module RGPD officiel peut exporter et effacer les demandes d'un client enregistré. Un invité ne laisse qu'un numéro, que ce module ne sait pas rattacher : la page de réglages propose donc une recherche qui exporte ou efface par numéro, avec la même validation que le formulaire. Les demandes sont aussi supprimées automatiquement après 30 ou 90 jours, et les adresses IP ne sont jamais conservées, seulement une empreinte à clé pour la limitation.

Oui. Vous choisissez si le Messenger s'affiche sur toutes les pages ou seulement certaines, activez ou non son affichage sur mobile, et définissez un délai en secondes pour que le widget se charge un peu après la page. Vous gardez ainsi une boutique rapide et n'affichez le chat que là où il aide réellement les clients.

Il note chaque paire sur des indices indépendants : même adresse e-mail, alias où les points Gmail ou un suffixe plus masquent la même boîte, même numéro de téléphone normalisé au format international, correspondance approchée du nom et de l'adresse postale dans le même code postal, même société ou même numéro de TVA, et commande invité correspondant à un compte enregistré. Les indices de même nature ne se cumulent pas, et les éléments contradictoires, numéros de TVA ou pays différents, retranchent des points. Vous pouvez modifier chaque pondération.

Non, et le supposer est une erreur fréquente et coûteuse. L'article 16, point m) n'exclut les contenus numériques sans support matériel que si trois conditions sont réunies : l'exécution a commencé, le consommateur a donné son accord exprès préalable, et il a reconnu qu'il perdait ainsi son droit de rétractation.

PrestaShop n'enregistre aucune de ces trois conditions. Le module considère donc qu'un produit virtuel conserve le droit de rétractation, jusqu'à ce que vous confirmiez dans les réglages que votre tunnel recueille réellement cet accord et cette reconnaissance.

Il se trompe volontairement du bon côté. Accorder un retour à tort coûte un remboursement ; le refuser à tort enfreint la directive.

Les biens confectionnés selon les spécifications du client sont un autre cas. L'article 16, point c) dépend du bien lui-même et non d'un accord : un produit personnalisable est donc exclu d'emblée.

Oui. Le module intègre une exclusion du trafic par employé et par adresse IP, de sorte que les visites des membres du personnel connectés ou des adresses IP que vous indiquez ne sont pas envoyées à GA4. Vos tests internes et l'activité du back-office restent ainsi en dehors de vos rapports d'analyse.

Oui. Le texte de la slide, titre, sous-titre et libellé du bouton, est stocké par langue, de sorte que chaque langue active de votre boutique peut afficher sa propre formulation tout en partageant la même mise en page et les mêmes images. Vous gérez les traductions directement dans l'administration du module.

Quatre mécanismes, tous côté serveur. Un pot de miel qu'un humain ne voit jamais. Un contrôle du délai qui rejette un envoi impossiblement rapide après le chargement. Une limitation par visiteur. Et la fusion des doublons : cliquer cinq fois produit un contact avec un compteur, pas cinq lignes.

Les numéros sont validés selon les règles internationales avant enregistrement, les absurdités n'atteignent donc jamais la file. Le module ne prétend volontairement pas vérifier qu'un numéro est joignable : rien ne le peut sans appeler.

Non. Banner Revolution se contente d'afficher les bannières, textes et liens d'appel à l'action que vous configurez. Il ne collecte aucune donnée personnelle des visiteurs et ne dépose aucun cookie de suivi ; il n'a donc pas d'incidence RGPD propre au-delà des pages vers lesquelles vous créez des liens.

Un panneau de diagnostic dans le back-office valide l'identifiant de mesure GA4 avant le démarrage du suivi et contrôle la remise des événements, avec gestion des nouvelles tentatives pour le Measurement Protocol. Un journal d'événements enregistre les événements construits et envoyés par le module, ce qui vous permet de confirmer l'arrivée des données dans GA4 avant de vous fier aux rapports.

Uniquement si vous l'activez, et il est livré désactivé. Une fois activé, il n'agit que sur les groupes au-dessus de votre seuil de certitude comportant au moins le nombre configuré d'indices indépendants, et il refuse tout groupe touchant une table inconnue, un déclencheur, une table non transactionnelle, ou présentant un conflit non résolu. Le préréglage le plus sûr le limite à replier une commande invité dans le compte enregistré qui possède déjà l'identité.

Vous pouvez l'activer, mais dans une boutique de l'Union européenne vous ne devriez pas. L'article 9, paragraphe 1 donne au consommateur le droit de se rétracter sans avoir à motiver sa décision : un champ obligatoire n'est donc pas conforme.

Le réglage est par conséquent désactivé par défaut, la liste des motifs est proposée de façon facultative, et le formulaire indique clairement au client qu'aucun motif n'est nécessaire. Les motifs que les clients donnent d'eux-mêmes sont tout de même enregistrés et affichés dans le back-office, et c'est là que se trouve généralement l'information utile.

Le module prend en charge PrestaShop 1.6 à 9.x, y compris 8.x, et fonctionne avec PHP 7.2 et plus récent. Toute la configuration se fait dans le back-office, sans avoir à modifier les templates de votre thème.

Oui. Les commutateurs d'emplacement couvrent le bouton flottant, la fiche produit, l'en-tête et un hook de thème personnalisé. Au-delà, vous pouvez n'afficher le widget que sur des produits, catégories et pages choisis, ou partout sauf sur eux, avec le même sélecteur que nos autres modules.

Si votre thème est particulier, activez le hook personnalisé et placez {hook h='displayMprCallback'} exactement où vous le souhaitez. Le module ne s'injecte jamais en cherchant des sélecteurs CSS.

Oui. Les comptes ne sont fusionnés qu'à l'intérieur d'un même domaine d'isolation client : la même boutique, ou le même groupe de boutiques lorsque le partage des clients est activé. Deux boutiques qui ne partagent pas leurs clients détiennent deux personnes distinctes du point de vue du consentement et de la loi ; ces correspondances sont donc affichées pour information et ne peuvent pas être fusionnées.

L'e-mail d'une nouvelle demande part immédiatement et ne dépend pas de cron. La relance de retard et la purge de conservation sont des tâches planifiées.

Si votre hébergeur n'a pas de cron, elles s'exécutent à l'occasion des requêtes normales : cela fonctionne, mais au mieux approximativement, et une boutique sans trafic ne les exécutera pas. Pour une planification fiable, pointez le cron de votre hébergeur sur l'URL indiquée dans l'écran des tâches planifiées. Le module signale dans le back-office lorsqu'il n'a rien exécuté récemment.

Chaque fusion, annulation et échec est ajouté à un journal d'audit chaîné par hachage : chaque entrée porte le hachage de la précédente, si bien qu'une entrée supprimée ou modifiée rompt la chaîne de façon visible. Le journal consigne ce qui s'est passé, quand, et quel employé l'a fait, ainsi que le nombre de lignes par table. Il ne contient aucune donnée client et s'exporte en CSV.

Non. Le bouton LINE flottant est ajouté via les hooks PrestaShop displayBeforeBodyClosingTag et displayHeader, vos fichiers de thème et de template ne sont donc jamais modifiés ni écrasés. La désinstallation retire le bouton proprement, sans rien laisser dans votre thème.

Non. Il ne modifie aucun template et ne surcharge aucun fichier du thème. Il agit via les hooks de presenter de PrestaShop, actionPresentProduct et actionPresentProductListing ajoutent les données loading et decoding aux tableaux d'images que votre thème affiche déjà, et via le hook filterHtmlContent pour les textes WYSIWYG. Votre thème garde le contrôle total du balisage ; le module ne fournit que les attributs. À la désinstallation, les attributs cessent simplement d'être ajoutés et rien n'est laissé modifié dans votre thème.

Le widget ouvre votre lien de contact LINE (https://line.me/ti/p/votre-LINE-ID) dans un nouvel onglet pour que le visiteur puisse démarrer une conversation dans l'application LINE. Il n'ajoute aucun message pré-rempli ou enregistré à ce lien : il transmet simplement le client à LINE.

Oui. Le module n'analyse ni ne réécrit le HTML final rendu d'une page. Il enrichit les données d'image au niveau du presenter avant l'exécution du template et ne traite que certains champs de contenu WYSIWYG. Comme il ne touche jamais à la sortie de la page, il peut fonctionner en toute sécurité avec le cache pleine page, le CCC et les CDN. Il n'y a aucun tampon de sortie à invalider, et les pages en cache restent valides.

Oui. Pour les images dans le contenu WYSIWYG, ajoutez la classe CSS d'exclusion (par défaut no-autolazy) à la balise img et le module l'ignore. C'est la méthode recommandée pour que votre image principale au-dessus de la ligne de flottaison se charge immédiatement, car mettre en lazy loading la plus grande image visible peut dégrader le Largest Contentful Paint. Les images data-URI intégrées et celles possédant déjà un attribut loading sont aussi ignorées automatiquement.

Oui. Le ciblage des pages permet d'afficher le bouton sur toutes les pages ou de le limiter à certaines, et une option mobile distincte permet de le masquer sur les téléphones. Un délai de chargement peut aussi retarder brièvement le bouton pour qu'il ne concurrence pas la page pendant son chargement.

C'est un indice pour le navigateur qui permet de décoder une image hors du thread principal, de sorte que le décodage d'une grande image risque moins de bloquer le défilement ou l'interaction. Il complète loading="lazy". Le module l'ajoute par défaut mais propose un unique interrupteur pour le désactiver si vous préférez, ne laissant que loading="lazy". Les attributs decoding existants ne sont jamais écrasés.

Les images produit sur la page produit, les images produit dans les listes de catégorie et de recherche, et les images intégrées au contenu WYSIWYG comme les descriptions de produit, de catégorie, de page CMS et de fabricant. Les deux premières sont gérées par les hooks de presenter produit ; la dernière par le hook de filtre de contenu. C'est une aide ciblée à la performance, elle ne compresse, ne redimensionne ni ne convertit aucune image, elle ajoute uniquement les attributs loading et decoding.

Le toggle fermé du header affiche toujours le symbole ou signe de la devise courante, comme $, €, £ ou le code ISO en fallback. Si Show ISO label in toggle est activé, le toggle affiche aussi le code ISO courant à côté du symbole. Le dropdown ouvert liste toujours chaque devise avec son symbole/signe, et si Show currency names in dropdown est activé, il affiche aussi le nom complet de la devise à côté de chaque symbole.

Le toggle ne rend pas de tooltip au survol. Les noms de devise sont utilisés dans les lignes du dropdown, y compris l'attribut title du lien pour chaque option de devise.

Oui. Le module enregistre son propre sélecteur dans le hook displayNav2 et charge une feuille de style qui masque le sélecteur de devise desktop natif de PrestaShop avec #_desktop_ps_currencyselector { display: none !important; }. Le client voit le dropdown compact à symbole du module à la place du bloc devise par défaut.

Activez le module, collez votre ActiveCampaign Account ID, puis enregistrez la configuration. L’Account ID est la valeur numérique affichée par ActiveCampaign dans Settings > Tracking > Site Tracking ; elle est stockée comme ACCOUNT_ID, et le module ne rendra pas le script front-office tant que ENABLED et ACCOUNT_ID ne sont pas tous deux présents.

• Dans PrestaShop, ouvrez la configuration du module ActiveCampaign.
• Activez Enable ActiveCampaign.
• Collez l’Account ID numérique, par exemple 123456789.
• Visitez une page front-office et confirmez que la source de page contient le script diffuser ActiveCampaign.

Quand il est actif, le hook displayBeforeBodyClosingTag charge le script diffuser d’ActiveCampaign, exécute vgo('setAccount', ...), active le tracking par défaut et appelle vgo('process'). Pour les clients connectés, il peut aussi transmettre l’email du client avec vgo('setEmail', ...).

Le script est inséré juste avant la balise de fermeture body, pas dans le head. C’est utile pour vérifier l’installation : cherchez dans la source de page rendue près du bas diffuser-cdn.app-us1.com/diffuser/diffuser.js, vgo('setAccount' et votre account ID. S’ils manquent, soit le module est désactivé, soit l’Account ID est vide, soit le thème n’exécute pas le hook displayBeforeBodyClosingTag.

La configuration possède aussi un champ optionnel EVENT_KEY, mais le hook front-office actuel est uniquement du site tracking. Il n’envoie pas d’appels personnalisés d’event tracking ActiveCampaign depuis ce chemin de code du module. Utilisez-le pour ajouter le snippet officiel de site tracking et identifier les clients connectés par email ; construisez l’automatisation d’événements personnalisés séparément si vous avez besoin d’un tracking ActiveCampaign plus profond.

Côté confidentialité, rappelez-vous que c’est un script de tracking. Associez-le à votre configuration de consentement si votre boutique exige un consentement marketing ou analytics avant de charger du tracking tiers, car ce module lui-même n’implémente pas de porte de consentement cookie.

Oui, les clients PrestaShop connectés sont identifiés par email dans le script de tracking ActiveCampaign. Le module lit le client courant depuis le contexte PrestaShop et envoie l’email uniquement lorsque le client est connecté ; les visiteurs anonymes sont suivis sans valeur email.

Le contrôle se produit dans le hook de fermeture body du front-office. Le tracking est rendu seulement lorsque le module est activé et qu’un ActiveCampaign Account ID est présent. Le hook assigne ensuite trois valeurs au template : l’account ID, l’email client, et un booléen indiquant si un email a été trouvé.

Dans le template, vgo('setEmail', ...) est entouré d’un contrôle logged-in, donc les invités ne reçoivent pas d’appel email vide. Chaque page suivie définit quand même l’account, active le page tracking par défaut et appelle vgo('process'). Cela permet à ActiveCampaign de relier les visites de pages connues à l’email du client connecté, tandis que les visites invité restent anonymes jusqu’à ce qu’ActiveCampaign puisse les identifier par une autre voie.

Logged in customer -> setAccount + setTrackByDefault + setEmail + process
Guest visitor -> setAccount + setTrackByDefault + process

Le réglage requis est l’ActiveCampaign Account ID, et le module doit être activé. Le code vérifie les deux avant de rendre le script front-office PrestaShop ; le champ Event Key est enregistré en configuration, mais le template de tracking actuel ne l’utilise pas.

À l’installation, ENABLED vaut par défaut 0, ACCOUNT_ID vaut par défaut une chaîne vide et EVENT_KEY vaut aussi par défaut une chaîne vide. L’avis de configuration requise ne déclare que ACCOUNT_ID comme requis, et le contrôle d’activation est simplement enabled plus un account ID non vide.

L’option admin décrit l’Account ID comme l’ID numérique du site tracking ActiveCampaign, mais cette source n’applique pas de validateur numérique avant rendu. Pour une configuration propre, copiez l’account ID exactement depuis les paramètres site tracking d’ActiveCampaign, activez le module, puis vérifiez la source de page pour le script diffuser.js et vgo('setAccount', ...).

ENABLED = 1
ACCOUNT_ID = 123456789
EVENT_KEY = optional, stored but not rendered by tracking.tpl

Les modules PrestaShop ont chacun besoin de tâches planifiées (feeds, nettoyages, synchronisations), mais câbler une ligne cron serveur séparée pour chacun est fragile. Un gestionnaire cron vous donne un endpoint unique protégé par token qui les exécute toutes. Avec Cron Manager, PrestaShop expose une URL comme /module/mprcron/cron?token=… (plus un point d’entrée cron.php pour les appels CLI ou HTTP avec options max-task et contexte) qui exécute chaque tâche enregistrée tour à tour. Pointez un seul cron serveur, ou un service externe comme cron-job.org, vers cette URL à l’intervalle choisi, et gérez les plannings individuels, l’état activé/désactivé et l’historique d’exécution depuis le back-office au lieu de modifier crontab. Gardez le token secret afin que des tiers ne puissent pas le déclencher, et commencez avec un intervalle de 5 à 15 minutes selon la sensibilité temporelle de vos tâches. La journalisation centralisée rend aussi une tâche échouée facile à repérer.

La commande CLI générée est une commande crontab sur une ligne utilisant le token partagé, par exemple * * * * * php /path/to/modules/mprcron/cron.php --token=TOKEN --max-seconds=300. Le point d’entrée exige un token, borne max_tasks entre 1 et 100, borne max_seconds entre 10 et 300, et utilise par défaut 20 tâches et 300 secondes. Le token partagé est généré comme une valeur hexadécimale de 64 caractères et validé avec hash_equals.

En interne, le package partagé possède deux tables : mpr_cron_task pour les tâches enregistrées et mpr_cron_log pour l’historique d’exécution. Chaque tâche stocke module, clé de tâche, libellé, callable ou payload, type d’exécuteur, planning, état activé, prochaine exécution, contexte, priorité et timeout. Le runner revendique une tâche avant de l’exécuter, enregistre les états completed, failed, skipped, timeout ou crashed, et écrit une ligne de log. En mode CLI, lorsque le cron.php local prend en charge les tâches isolées et que proc_open est disponible, chaque tâche peut s’exécuter dans un sous-processus afin qu’une tâche fatale n’arrête pas le reste du lot.

Non, ce module n’envoie pas d’événements ecommerce ActiveCampaign produit, panier, commande ou personnalisés. Son code PrestaShop charge seulement le site tracking, définit l’account, identifie optionnellement l’email d’un client connecté et appelle la fonction de traitement de page ActiveCampaign.

Le réglage enregistré EVENT_KEY est décrit comme optionnel pour les événements personnalisés, mais le template front-office ne le référence jamais. Il n’y a aucun appel d’événement purchase, cart, product ou checkout dans le template de tracking ; les seuls appels ActiveCampaign sont setAccount, setTrackByDefault, setEmail optionnel et process.

Pour les marchands, le résultat pratique est un suivi des visites de pages plutôt qu’un suivi ecommerce. Vous pouvez l’utiliser pour permettre à ActiveCampaign de voir les pages vues suivies et d’identifier les clients connectés par email, mais la valeur de commande, les IDs produit, le contenu du panier et les lignes d’article ne sont pas envoyés par ce module. Si vous en avez besoin, il faut une autre intégration ou du nouveau code qui se branche réellement sur les événements produit, panier et commande.

Une bonne section FAQ répond aux questions acheteurs avant qu’ils envoient un email et capte du trafic de recherche longue traîne. Pour en ajouter une à PrestaShop, utilisez FAQ Manager : il crée un hub FAQ public avec routes de catégorie, tag, recherche et question, affiche un onglet FAQ produit via displayProductExtraContent, et peut afficher du contenu FAQ en contexte catégorie comme bloc de colonne gauche/sidebar via displayLeftColumn. Vous stockez les questions, catégories, tags et assignations produit ou catégorie, donc la même réponse peut apparaître sur le hub et sur chaque produit concerné. Les clients peuvent soumettre leurs propres questions pour modération, et les réponses communautaires approuvées avec votes utiles ajoutent du contenu frais. Pour le SEO, donnez à chaque question indexable un titre et une méta-description uniques, gardez des réponses réellement utiles plutôt que des phrases d’une ligne, et utilisez le schema FAQ uniquement lorsqu’il est exact et encore utile pour votre cible de recherche/affichage.

En configuration pratique, commencez dans le menu admin FAQ : créez des catégories FAQ, puis ajoutez des questions avec texte de question multilingue, HTML de réponse, URL simplifiée, méta titre et méta description. Si l’URL simplifiée est laissée vide, les catégories génèrent un slug depuis le nom de catégorie et les questions génèrent un slug depuis le texte de question. Une question publique est visible uniquement lorsqu’elle est active, que sa date de publication est vide ou déjà passée, et que le groupe client courant est autorisé. Vous pouvez aussi définir une Answer Reveal Date, qui permet à la question d’exister avant que la réponse soit affichée.

• Utilisez Categories pour les hubs FAQ publics et pour associer des catégories FAQ aux catégories PrestaShop lorsque des blocs contextuels sur page catégorie sont utiles.
• Utilisez Questions pour les vraies entrées FAQ ; assignez directement des produits lorsqu’une question doit apparaître dans un onglet FAQ produit.
• Utilisez Tags pour améliorer la recherche FAQ, les pages de tags et la découverte interne.
• Utilisez Pending Questions et Additional Replies pour modérer les soumissions de visiteurs avant qu’elles deviennent publiques.

Pour les pages produit, ne vous appuyez pas sur de larges mappings de catégories lorsque vous avez besoin d’une FAQ produit exacte. L’onglet produit charge les questions depuis la table d’assignation directe produit-question et ne retourne rien si aucune question n’est assignée à ce produit. Les questions assignées à exactement un produit peuvent rendre une réponse dans le HTML initial de la page produit ; les questions partagées entre plusieurs produits sont traitées comme liées/partagées et leurs réponses sont chargées paresseusement à l’ouverture. Cela évite d’injecter de grands articles de dépannage dans chaque page produit et aide à éviter le contenu dupliqué bruyant.

Les pages catégorie ne sont pas rendues comme un onglet par ce module. L’intégration catégorie est un bloc de colonne gauche/sidebar qui charge un ensemble limité de questions pour la catégorie courante et les relie à l’expérience FAQ.

Les contrôles SEO sont volontairement granulaires. L’indexation du hub FAQ est activée par défaut, mais les pages catégorie, pages tag et pages question individuelles ne sont pas indexées sauf si l’interrupteur global correspondant est activé et, pour les catégories ou questions, si l’entité elle-même est marquée indexable. Les pages de recherche sont toujours noindex. Les champs méta titre et méta description se rabattent sur le titre visible, la description de catégorie ou l’extrait de réponse lorsqu’ils sont laissés vides, et les URL canoniques sont construites depuis le slug FAQ localisé, le slug de catégorie et le slug de question.

Le schema est un interrupteur, pas une magie automatique. Le réglage est SCHEMA_ENABLED et vaut par défaut 0 ; l’indication admin dit que Google a déprécié les rich results FAQ en mai 2026, donc traitez-le comme des données structurées optionnelles plutôt que comme un déclencheur garanti de rich results. La gestion des réponses planifiées n’est pas cohérente dans chaque chemin schema du code actuel : les builders JSON-LD front question et catégorie vérifient answer_visible, mais la sortie QAPage de niveau module dans l’en-tête lit directement questionData['answer'], et le chemin requête/build du schema du hub FAQ ne vérifie pas date_response ni answer_visible. Si vous utilisez des réponses différées, gardez le schema désactivé ou corrigez ces chemins avant de compter sur le schema pour masquer du contenu de réponse futur.

Le flux de soumission visiteur est modéré. Ask a Question est activé par défaut, valide le nom, l’email et le texte de question, plafonne le texte de question à 5000 caractères, utilise un champ honeypot, et stocke l’élément dans mprfaq_pending avec statut pending. La limite par défaut est ASK_MAX_PENDING=2 questions en attente par email et par catégorie produit de premier niveau ; définissez-la à 0 uniquement si vous voulez volontairement aucune limite de questions en attente. Si le visiteur pose une question depuis une page produit et qu’aucune catégorie FAQ n’est fournie, le contrôleur résout une catégorie depuis le contexte produit.

Les réponses publiques sont séparées de la réponse officielle. CA_ENABLED vaut par défaut 0 ; lorsqu’il est activé, le module peut exiger une connexion, valide les détails auteur, plafonne le texte de réponse à 5000 caractères, et enregistre la réponse comme pending. Les réponses additionnelles approuvées peuvent apparaître comme réponses communautaires et recevoir des votes. Les votes utiles sont limités à un vote par IP par question ou réponse, avec un cookie PrestaShop utilisé uniquement pour mémoriser l’état UI du visiteur.

FAQ_SLUG=faq
FAQ_HUB_INDEXABLE=1
FAQ_CATEGORY_INDEXABLE=0
FAQ_TAG_INDEXABLE=0
QUESTION_INDEXABLE=0
SCHEMA_ENABLED=0
ASK_ENABLED=1
ASK_MAX_PENDING=2
CA_ENABLED=0

Pour une FAQ SEO, la règle pratique est de garder le hub large, de rendre indexables seulement les fortes pages catégorie ou question autonomes, d’assigner directement les questions produit, et de laisser les petites réponses spécifiques au produit dans l’onglet produit. Cela donne aux clients les réponses au bon endroit tout en gardant l’index concentré sur les pages capables de vivre seules.

Le module gère des fiches catalogue digitales pour modules, thèmes et addons. Dans PrestaShop, chaque produit digital peut stocker nom technique, branche, version actuelle, champs de compatibilité, URLs documentation, démo et dépôt, changelog, mois de support et limites de domaines.

Oui, MPR FAQ peut collecter les questions clients pour validation. Dans PrestaShop, les questions en attente stockent le nom, l’e-mail, la question, le produit ou la catégorie FAQ, le statut, une réponse admin optionnelle et les dates avant publication.

Utilisez l'espace de nettoyage pour supprimer les anciens enregistrements pris en charge dans PrestaShop. Le module compte et supprime paniers abandonnés de plus de 30 jours sans commande, anciennes recherches, prix spécifiques expirés, logs, connexions, invités orphelins et mails.

Si vous avez seulement besoin d’un avis cookie clair accepter-ou-refuser, une bannière légère est l’implémentation la plus simple. Lightweight Cookie Banner rend la bannière depuis des hooks de niveau footer, stocke le choix du visiteur dans un cookie de consentement, et vous permet de configurer le texte de bannière, les boutons, couleurs, position, lien vers la politique de confidentialité et la durée du consentement avant de redemander (365 jours par défaut). Elle est volontairement minimale - sans scripts lourds - donc elle ne ralentira pas votre boutique. Utilisez-la lorsque votre empreinte de tracking est faible et que vous devez surtout informer les visiteurs et enregistrer leur choix. Si vous devez aussi bloquer les scripts jusqu’au consentement, loguer les consentements ou offrir des préférences granulaires par catégorie, une plateforme de consentement complète est plus adaptée. Associez toujours la bannière à une politique cookies et confidentialité exacte et à jour.

Le module est activé par défaut, position en bas à gauche, boutons côte à côte, thème sombre, COOKIE_EXPIRY de 365 jours, Google Consent Mode activé et DEFAULT_CONSENT défini à denied. Il peut s’afficher comme barre pleine largeur en haut ou en bas, bannière d’angle, bannière flottante en bas, ou modale centrée avec overlay. Le choix du visiteur est stocké dans le cookie first-party mprcookie_consent avec granted ou denied ; le JavaScript l’écrit avec path=/, SameSite=Lax, et Secure lorsque la boutique est en HTTPS.

Lorsque Google Consent Mode est activé, le hook d’en-tête injecte le signal de consentement par défaut et charge les assets/config head-safe ; il ne rend pas le balisage visible de la bannière. Le balisage de bannière est rendu depuis displayFooterAfter ou displayFooter, avec un garde pour ne sortir qu’une fois, et le script front envoie une mise à jour de consentement après acceptation ou refus du visiteur. Le module ne catégorise pas les cookies, ne réécrit pas les scripts tiers, et ne conserve pas de table de logs de consentement. Il avertit aussi lorsque Cookies Revolution est disponible, car un seul module de consentement cookie doit contrôler le front-office à la fois.

Le Meta (Facebook) Pixel suit les actions des acheteurs afin que vous puissiez mesurer les performances publicitaires et construire des audiences de retargeting. PrestaShop n’a pas de Pixel natif, donc vous l’ajoutez avec un module de tracking. Avec Facebook Pixel, saisissez votre Pixel ID et activez le suivi navigateur ; le module déclenche ensuite les événements ecommerce standards, PageView, ViewContent, AddToCart, InitiateCheckout, Search, AddToWishlist, CompleteRegistration et Purchase, avec des interrupteurs individuels pour activer ou désactiver certains événements. Pour des conversions précises malgré les pertes liées aux navigateurs et ad blockers, activez aussi la Conversions API côté serveur, qui envoie les événements Purchase à Meta avec un event ID correspondant afin que les hits navigateur et serveur soient dédupliqués. Vérifiez tout dans l’outil de test Events Manager de Meta avant de lancer vos campagnes, et assurez-vous que le déclenchement du Pixel respecte votre bannière de consentement cookie afin que le tracking ne s’exécute qu’après consentement marketing.

Le module s’installe avec ENABLED désactivé et un PIXEL_ID vide, donc aucun suivi navigateur ne démarre tant que vous ne l’avez pas configuré. Les Pixel IDs sont validés comme chiffres uniquement. La plupart des interrupteurs d’événements standards sont activés par défaut une fois le module lui-même activé, tandis que CAPI_ENABLED est désactivé par défaut et exige un Pixel ID plus CAPI_ACCESS_TOKEN. La version Graph API par défaut dans le module est v25.0, et un code d’événement de test optionnel peut être envoyé pendant la validation dans Meta Events Manager.

Le consentement est vérifié avant le rendu du template de tracking. Si Cookies Revolution est actif, le module lit la valeur marketing depuis mprcr_consent ; si Lightweight Cookie Banner est actif, il lit mprcookie_consent ; si aucun n’est actif et que le respect du consentement est activé, le module traite le consentement marketing comme disponible. La navigation des employés peut aussi être exclue. AddToCart est suivi via l’événement PrestaShop updateCart lorsqu’il est disponible, avec des replis de clic pour les anciens thèmes. Purchase est émis sur la confirmation de commande avec un event id déterministe de commande, et lorsque CAPI est configurée, le même achat est mis en file et traité via la file de conversion partagée, avec une tâche cron planifiée toutes les 300 secondes pour réessai/traitement.

Les acheteurs convertissent mieux lorsqu’ils peuvent voir quand une commande arrivera. Pour afficher une date de livraison estimée dans PrestaShop, utilisez Estimated Delivery Date : il ajoute vos jours de préparation configurés à la date courante et affiche le résultat sur la page produit via le bloc displayProductAdditionalInfo. Vous pouvez définir une heure limite quotidienne (les commandes passées après cette heure comptent à partir du lendemain), exclure les week-ends afin que samedis et dimanches ne soient pas comptés et qu’un résultat final tombant le week-end soit repoussé au lundi, et choisir le format de date affiché aux acheteurs. Le message apparaît automatiquement sur les pages produit éligibles, donnant une attente concrète de type « arrive avant » plutôt qu’un vague « expédié bientôt ». Gardez un délai de préparation réaliste et alignez l’heure limite sur votre vrai planning d’expédition, afin que la date promise corresponde à ce que les clients reçoivent. Des estimations exactes réduisent les tickets « où est ma commande ».

Les valeurs d’installation par défaut sont ENABLED=1, PROCESSING_DAYS=1, CUTOFF_HOUR=14, EXCLUDE_WEEKENDS=1 et DATE_FORMAT=l, F j. Le calcul utilise le DateTime courant du serveur, lit l’heure actuelle comme valeur entière sur 24 heures, et ajoute un jour de préparation supplémentaire lorsque l’heure actuelle est supérieure ou égale à l’heure limite. Il avance ensuite un jour à la fois jusqu’à ce que le nombre de jours de préparation configuré soit compté, en sautant samedi et dimanche lorsque l’exclusion des week-ends est activée.

Le message front-office reçoit aussi hours_left, qui est simplement la différence en heures entières jusqu’à l’heure limite lorsque la commande est encore avant cette heure. Ce module n’inspecte pas les plages de livraison transporteur, le statut de stock, les calendriers d’entrepôt, les jours fériés, le code postal de destination ou les délais spécifiques par produit. C’est une promesse simple de page produit basée sur des règles de préparation globales à la boutique, donc elle fonctionne mieux lorsque votre catalogue partage le même modèle d’expédition.

Avec le temps, une base de données PrestaShop se remplit de données dont vous n’avez plus besoin : paniers abandonnés, lignes de panier orphelines, prix spécifiques et règles panier expirés, anciens enregistrements de connexions et invités, statistiques de recherche, logs mail et 404, vues de pages et fils clients fermés. Sans contrôle, ces tables ralentissent les requêtes et gonflent les sauvegardes. Pour les nettoyer en sécurité, utilisez Cleanup Revolution : il regroupe chaque nettoyage en tâches nommées, compte les lignes affectées avant suppression, prend en charge les aperçus dry-run par défaut, et enregistre les vraies exécutions de suppression dans l’historique de nettoyage. Commencez par les paniers abandonnés de plus de 30 jours et les anciennes statistiques de recherche/connexion, vérifiez les nombres de l’aperçu, puis supprimez par lots. Faites toujours une sauvegarde de base de données d’abord. Pour une maintenance continue, planifiez les tâches au lieu de les lancer à la main ; consultez notre guide performance PrestaShop.

Before any real cleanup, make a fresh database backup and run the module preview first. Do not delete rows manually with SQL; use Cleanup Revolution's dry-run counts, review the affected tasks, then run the cleanup from the module in controlled batches.

mysqldump -u db_user -p db_name > prestashop-before-cleanup.sql

La configuration par défaut est volontairement prudente : le dry run est activé par défaut, le mode corbeille est activé, les paniers abandonnés valent par défaut 30 jours, de nombreux logs/statistiques 90 jours, les fils clients fermés 180 jours, les comptes vides 365 jours, et le moteur utilise des tailles de lot par tâche plus une limite totale de 50000. Une tâche sans ligne à retirer est ignorée par le runner groupé, et une vraie suppression de base de données se fait par lots plutôt qu’en une énorme instruction.

Un détail d’audit log compte : les exécutions dry-run retournent le nombre affecté avant que MPRCleanupLog::record() soit appelé, donc les aperçus dry-run ne sont pas écrits dans l’historique de nettoyage. Les vrais nettoyages de base de données sont logués avec dry_run = 0. Les actions manuelles du Back Office appellent DatabaseCleanupEngine::executeTask(..., $employeeID) ou DatabaseCleanupEngine::executeAll($dryRun, $employeeID) ; elles utilisent donc la valeur par défaut trigger_type = manual et enregistrent l’ID de l’employé lorsqu’il est disponible. Le nettoyage planifié de la base de données appelle MPRCleanupRevolution::cronDBCleanup(), qui transmet DatabaseCleanupEngine::executeAll(false, null, 'cron') ; ces lignes de journal enregistrent donc trigger_type = cron sans ID d’employé.

Le moteur de nettoyage de base de données inclut des tâches nommées pour paniers abandonnés, produits de panier orphelins, statistiques de recherche, prix spécifiques expirés, règles panier expirées avec quantité zéro, anciens logs, anciennes connexions, lignes de connexion orphelines, anciens invités, logs mail, logs 404, vues de pages, fils clients fermés et cache referrer. Il a aussi des nettoyages commerciaux plus risqués comme comptes invités sans commandes, adresses orphelines et anciens comptes enregistrés sans commandes ni paniers récents. Les valeurs cron par défaut répartissent le travail entre nettoyage de base de données, nettoyage de fichiers et fenêtres d’optimisation de tables, afin que vous puissiez automatiser la maintenance sans lancer toutes les opérations lourdes à la fois.

Le rendu en storefront est gère par le hook displayMprSubtitle. Le resolver peut détecter la page produit, catégorie, CMS, fabricant ou fournisseur courante, et les templates peuvent aussi transmettre un ID produit explicite si nécessaire.

Pour une conformité GDPR et ePrivacy complète, il faut plus qu’une bannière : les acheteurs doivent pouvoir accepter ou refuser les cookies par finalité. Cookies Revolution ajoute un consentement granulaire à PrestaShop avec les catégories standard, nécessaire, fonctionnel, analytics et marketing, et un panneau de préférences où les visiteurs peuvent tout accepter, refuser les catégories optionnelles ou enregistrer une sélection personnalisée ; leur choix est stocké dans un cookie de consentement. Il peut aussi bloquer les scripts de tracking correspondants jusqu’à l’obtention du consentement, en réécrivant les balises afin qu’elles ne s’exécutent que pour les catégories autorisées, et loguer les enregistrements de consentement avec des identifiants hachés pour votre piste d’audit. Le consentement préalable (pas de cases optionnelles précochées) et le retrait du consentement aussi facilement que son octroi sont des exigences légales, cela couvre les deux. Combinez-le avec Google Consent Mode v2 afin que vos tags Google s’ajustent automatiquement au choix de chaque acheteur.

À l’installation, le module crée des tables de catégories, cookies, règles de script, logs de consentement, résultats de scan et design. Les catégories initialisées sont necessary, functional, analytics et marketing ; necessary est requis et activé par défaut, tandis que les catégories optionnelles sont désactivées par défaut sauf si vous changez le mode de consentement par défaut. L’état navigateur stocké est compact, par exemple necessary:1|functional:0|analytics:0|marketing:0 dans mprcr_consent, avec un cookie séparé mprcr_version utilisé lorsque RECONSENT_ON_CHANGE est activé.

Le blocage de scripts fonctionne en deux couches. Sur la sortie serveur, le module réécrit les scripts externes correspondants en type="text/plain" avec data-cookiecategory et stocke la source originale dans data-original-src ; il peut aussi réécrire les scripts inline correspondants selon des règles de contenu de script. Côté navigateur, un MutationObserver vérifie les scripts injectés dynamiquement par rapport à la même liste de règles et les bloque si la catégorie correspondante n’est pas accordée. Lorsque le consentement est enregistré, le module met à jour Google Consent Mode, active les scripts autorisés, supprime les cookies des catégories révoquées lorsque configuré, déclenche mprcr:consent, et logue la décision via AJAX lorsque la journalisation est activée, avec un court throttle pour éviter le spam de logs en double.

Oui, vous pouvez bloquer par IP, plage CIDR, code pays ou motif user-agent, y compris avec un périmètre checkout-only. Le gestionnaire de bans PrestaShop vérifie d’abord les entrées whitelist, puis les règles de ban actives, et applique le périmètre full, checkout ou authentication selon le contexte de requête courant.

Le formulaire de ban prend en charge une IP unique, une IP wildcard comme 192.168.1.*, une plage IP comme 1.1.1.1-1.1.1.255, un CIDR comme 192.168.1.0/24, un code ISO pays et un motif user-agent. Les règles user-agent peuvent être du texte simple comparé sans tenir compte de la casse, ou une regex entourée de slashes.

Le périmètre est basé sur le contrôleur courant. Le périmètre checkout s’applique à order, orderopc, cart, supercheckout, onepagecheckout et checkout. Le périmètre login/auth s’applique à authentication, my-account, identity, registration et password. Les bans full sont vérifiés avant les bans spécifiques à un périmètre, donc un ban full bloque le visiteur partout.

• Activation : BAN_ENABLED est installé comme activé par défaut.
• Bans temporaires : un ban peut avoir date_expiry ; les bans actifs expirés sont désactivés pendant le chargement des bans actifs.
• Message : chaque ban peut avoir son propre message, sinon le module se rabat sur le message multilingue par défaut configuré.
• Multiboutique : les enregistrements de ban avec id_shop=0 s’appliquent globalement, tandis que les bans propres à une boutique ne s’appliquent que dans le contexte de boutique courant.

Checkout-only CIDR example:
ip_cidr = 203.0.113.0/24
ban_type = checkout
reason = Repeated fraudulent checkout attempts

Oui, il peut créer ou synchroniser un job cron-job.org lorsqu'il est configuré. La configuration admin PrestaShop peut tester la clé API cron-job.org, vérifier l'accèssibilite externe et pointer le job distant vers l'URL cron tokenisée de statut ou d'exécution du module.

Les ventes flash, promotions saisonnières et offres limitées fonctionnent mieux lorsqu’elles démarrent et s’arrêtent automatiquement. Pour planifier des remises temporelles dans PrestaShop, utilisez Smart Dynamic & Scheduled Discounts : créez des campagnes avec dates de début et de fin, et le hook de prix vérifie la fenêtre active, le périmètre produit, l’accès par groupe client et les limites d’usage, puis applique la meilleure remise éligible au prix produit sans travail manuel. Comme la remise est calculée au moment de l’affichage et du checkout, les prix reviennent automatiquement lorsque la fenêtre se ferme, pas besoin de se souvenir d’annuler une promo. Utilisez le ciblage par groupe client pour les offres réservées aux membres, et appuyez-vous sur la logique du meilleur prix pour garder les campagnes qui se chevauchent prévisibles. Affichez toujours le prix original à côté de l’offre afin que l’économie soit visible, et vérifiez que les prix planifiés respectent vos éventuelles règles de marge minimale.

Le modèle de campagne prend en charge des types de campagnes comme scheduled, recurring, flash sale, countdown, early bird et last chance, avec les types de remise percent, amount et fixed_price. Le périmètre produit peut être une assignation directe produit/déclinaison, des catégories avec sous-catégories optionnelles, des fabricants, des groupes clients, ou aucun périmètre du tout, auquel cas une campagne active peut s’appliquer à tous les produits. Les remises personnalisées par produit peuvent remplacer la remise de campagne lorsque la ligne produit n’hérite pas de la valeur par défaut.

Les campagnes récurrentes ajoutent des lignes de planning avec fenêtres quotidiennes, hebdomadaires, mensuelles ou personnalisées, heures de début/fin et fuseau horaire. L’usage est suivi par commande/produit/client dans mprdsd_campaign_usage, et le module vérifie les limites d’usage totales, par client et par quantité de produit avant d’appliquer une remise. Le hook de prix utilise volontairement le prix courant transmis par PrestaShop au lieu d’appeler Product::getPrice(), car cela rebouclerait dans le hook de prix. Il soustrait ensuite le montant de remise éligible le plus élevé du prix calculé courant et n’écrit jamais de lignes native specific-price, ce qui explique pourquoi la remise disparaît automatiquement lorsqu’aucune campagne n’est active.

Cela dépend du téléchargement dont vous parlez :

• Un module sous licence, oui. Les téléchargements sous licence sont liés à votre boutique : le contrôleur de téléchargement vérifie la propriété de la licence, sa validité, le nombre de téléchargements restants et le fait que la boutique sélectionnée est bien affectée à la licence avant d'émettre une URL de téléchargement tokenisée. C'est cette liaison qui maintient une licence payante rattachée à sa boutique.
• La démo gratuite de 30 jours, non. Indiquer votre e-mail et votre domaine d'installation au téléchargement est facultatif. La seule chose que cela vous apporte, c'est du confort plus tard : si vous achetez avec ce même e-mail, votre boutique peut vous proposer une activation en un clic. Sinon, vous collez simplement une clé de licence.

Pour l'ensemble du parcours, de l'essai à l'activation, puis au support, voir Fonctionnement des licences, de l'activation et du support.

Oui, le module fournit un espace back-office pour les tâches planifiées. Il peut lister les tâches des modules utilisant le CronTrait partage, lancer des tests, activer ou désactiver des tâches, modifier les fréquences, supprimer des tâches personnalisées, consulter les logs et appliquer des changements en masse.

Oui, il peut bloquer les scripts correspondants jusqu'àu consentement. Lorsque le blocage est actif, le hook de sortie transforme les scripts en type text/plain avec métadonnées de catégorie, puis le JavaScript front restaure seulement les scripts dont la catégorie est autorisée.

Oui, le mode dry-run prévisualise les résultats avant suppression. Le module l'active par défaut, utilise des tailles de lots par tâche et des limites de sécurité configurables, puis journalise déclencheur, lignes affectées, statut dry-run et employé pour l'administrateur PrestaShop.

PrestaShop n’a pas de blog intégré, donc pour publier des articles, guides et contenus SEO, vous ajoutez un module de blog. Blog Revolution crée un blog complet dans votre boutique : il enregistre des routes dédiées pour l’index du blog, les articles individuels, catégories, tags, auteurs, archives mensuelles, recherche et un flux RSS, et ajoute des blocs pour la page d’accueil, les colonnes latérales, le footer, les pages produit et les listings de style catégorie afin que vos derniers articles apparaissent dans toute la boutique. Comme le blog partage votre thème, votre design et votre configuration linguistique, les articles héritent automatiquement de votre branding et de vos URL multilingues. Un blog est l’un des investissements SEO PrestaShop les plus efficaces : il cible les requêtes informationnelles que vos pages produit et catégorie ne peuvent pas couvrir, crée des liens internes vers ces pages et attire des backlinks. Planifiez d’abord une structure de catégories, puis publiez régulièrement et liez chaque article aux produits pertinents.

Dans le code, ce n’est pas simplement un wrapper de page CMS. Le module crée ses propres tables pour les articles, traductions d’articles, catégories, tags, auteurs, commentaires, liens article-produit, suivi des vues/likes, images, restrictions de groupe et redirections de slugs. Les articles ont des champs SEO comme méta titre, méta description, méta keywords et URL canonique par langue, et le module peut sortir des données Open Graph, l’autodécouverte RSS, des liens hreflang et des liens de pagination précédent/suivant depuis le hook d’en-tête.

Le préfixe d’URL par défaut est blog, donc l’ensemble de routes généré inclut des chemins comme /blog, /blog/tag/{rewrite}, /blog/author/{slug}, /blog/archive/{year}/{month}, /blog/search et /blog/rss. Les valeurs par défaut supposent aussi 12 articles par page, une grille en trois colonnes, commentaires, notes, extraits, métadonnées auteur/date/vue/commentaire, partage social, schema, hreflang, Open Graph et RSS activés. Cela vous donne une surface de publication complète, mais vous devez quand même définir des règles éditoriales : quels articles lient vers les produits, quelles catégories correspondent aux termes commerciaux, et quelles anciennes URL doivent rediriger plutôt que retourner 404.

Les balises canoniques indiquent à Google quelle version d’une page est l’originale, évitant les problèmes de contenu dupliqué liés aux filtres, à la pagination et aux produits presque identiques. PrestaShop définit automatiquement les canoniques mais ne vous donne aucun moyen de les remplacer par page. Pour définir une canonique personnalisée pour un produit, une catégorie, une page CMS, un fabricant ou un fournisseur spécifique, utilisez Product Canonical Manager : créez une règle pour l’entité cible, saisissez l’URL que vous voulez faire créditer aux moteurs de recherche, et enregistrez une valeur différente par langue de boutique si nécessaire. Utilisez-le lorsque plusieurs produits sont des variantes d’un produit maître, lorsqu’une page CMS reprend un article de blog, ou lorsqu’une URL de campagne doit se consolider vers la page produit propre. Pour comprendre comment les canoniques, URL, schema et sitemaps s’articulent, consultez notre guide SEO PrestaShop.

Le module stocke les règles dans une table dédiée mprcanonical_rule et prend en charge les types d’entités product, category, cms, manufacturer et supplier. Chaque règle a une action : override remplace une canonique existante par l’URL de l’entité, add_missing en insère une uniquement lorsque la page n’a pas déjà de canonique, et custom utilise l’URL personnalisée multilingue enregistrée sur la règle. Les règles peuvent aussi définir noindex et nofollow.

Pour les règles produit, le résolveur peut correspondre à un produit spécifique, tous les produits, des produits par catégorie, fabricant ou fournisseur, et il prend en charge les exclusions de sélecteur. Lorsque plusieurs règles correspondent, la requête trie par priority DESC, donc la règle de priorité la plus élevée gagne pour l’URL canonique tandis que les drapeaux noindex/nofollow peuvent s’accumuler. Le hook de sortie modifie le head HTML final, il peut donc remplacer les balises canonical existantes, ajouter des directives robots, ajouter des liens hreflang lorsqu’activés, et normaliser les URL générées avec suppression de paramètres configurée, conversion en minuscules et gestion optionnelle du slash final.

Oui, il peut ignorer les samedis et dimanches lorsque l’exclusion des week-ends est activée. Le calcul PrestaShop ne compte pas ces jours pendant l’ajout du délai de préparation et reporte aussi un résultat final tombant le week-end au lundi.

Oui, l'espace admin affiche les compteurs avant d'exécuter les nettoyages. Dans PrestaShop, chaque tâche possède une requête de comptage, et le template montre le total ainsi que les détails par tâche avant l'action choisie.

Oui. Les règles de sous-titres produit peuvent cibler tous les produits, des produits précis, des produits dans des catégories, des produits par fabricant et des produits par fournisseur. Des règles d'exclusion peuvent aussi retirer certains produits ou correspondances de catégorie d'une règle plus large.

Oui, les IP whitelistées sont vérifiées avant les bans et ne sont jamais bloquées par le matcher de bans. Le module PrestaShop prend en charge les entrées whitelist par IP exacte ou plage CIDR, avec un filtrage sensible à la boutique afin que les enregistrements whitelist propres à une boutique ne s’appliquent que dans le contexte pertinent.

La whitelist est basée sur l’IP, pas sur le pays ou le user-agent. Dans le formulaire admin, vous saisissez soit un champ adresse IP, soit une plage CIDR, pas les deux. Le champ adresse IP est documenté pour une IP unique ou un wildcard comme 192.168.1.* ; le champ CIDR attend une notation comme 192.168.1.0/24.

Quand une requête est vérifiée, isBanned() appelle d’abord isWhitelisted(). Si l’IP visiteur correspond à une ligne whitelist, la fonction renvoie immédiatement false et aucun ban pays, user-agent, IP exacte ou CIDR n’est appliqué. C’est utile pour les IP bureau, développeur, prestataire de paiement ou monitoring qui ne doivent pas être bloquées par des règles larges de pays ou plage.

• Stockage : les lignes whitelist stockent adresse IP, CIDR, libellé, ID employé, ID boutique et date de création.
• Gestion boutique : quand le multishop est actif, la requête whitelist charge les lignes de la boutique courante et les lignes globales id_shop=0.
• Piège : une whitelist n’aide que si le module détecte la même vraie IP visiteur que celle que vous avez stockée. Si un proxy ou CDN change l’IP vue par PrestaShop, whitelistez l’adresse que PrestaShop reçoit réellement.

Oui, il prend en charge les événements Purchase côté serveur via Meta Conversions API. Dans PrestaShop, le module met les conversions d’achat en file, les envoie à la version Graph API configurée et utilise des event IDs cohérents entre navigateur et serveur.

Oui, il prend en charge des réponses supplémentaires approuvées et les votes utiles. Dans PrestaShop, les réponses stockent type d’auteur, références client ou employé, statut, compteurs de votes et contenu, tandis que les votes question et réponse sont suivis par entité et IP.

Oui, elle prend en charge Google Consent Mode v2 lorsque l'option est activée. Le module écrit une commande de consentement par défaut avant les tags et met à jour ad_storage, ad_user_data, ad_personalization et analytics_storage après acceptation ou refus dans PrestaShop.

Le module reste installé, mais hookDisplayHeader() ne renvoie rien, car isActive() exige le Brand ID. L'avis de configuration requise informe également votre équipe que le suivi est inactif tant que le Brand ID n'a pas été renseigné.

Oui, des tâches cron personnalisées peuvent être ajoutees depuis le contrôleur de tâches. Le formulaire admin PrestaShop valide module propriétaire, planning, contexte et type d'executeur, et prend en charge URL, callable et commande, avec les commandes limitées aux contextes cron ou test admin explicite.

Le générateur vérifie le journal des références du module, la table native orders et les références order_payment. Il essaie jusqu'à 10 candidats avant d'enregistrer une erreur et d'abandonner.

Le resolver trie les correspondances actives par priorité. En mode unique, il renvoie le sous-titre prioritaire ; en mode tous, il renvoie la liste triée afin que le template puisse afficher plusieurs sous-titres.

Oui, les choix de consentement peuvent être journalisés lorsque l'option est activée. Le contrôleur AJAX PrestaShop enregistre la carte de consentement, la source et la version, tandis que le modèle de log hache les identifiants visiteur, IP et user-agent.

Vous pouvez ajouter Criteo OneTag à PrestaShop en configurant un Criteo Partner ID numérique et en activant le suivi navigateur. Le module construit ensuite les evenements OneTag dans le header pour les pages e-commerce prises en charge et reste inactif si l'ID manque ou est invalide.

Vous pouvez collecter l'IP visiteur et les informations appareil avec ce module PrestaShop lorsque la collecte est activée. Il stocke ID client ou invité, ID boutique, adresse IP, données pays, détails appareil analyses et champs optionnels user-agent, OS, navigateur et résolution d'écran.

Oui, le module contient un chemin d’auto-ban authentication pour les connexions PrestaShop échouées, mais il ne s’exécute que lorsque l’enregistreur d’échecs de connexion du module est invoqué par l’intégration d’authentification. Chaque échec enregistré stocke l’IP visiteur, l’email tenté, le user agent, l’ID boutique et l’horodatage dans mprceiipban_failed_logins.

Les deux réglages qui contrôlent le ban sont MPRCEIIPBAN_AUTOBAN_THRESHOLD et MPRCEIIPBAN_AUTOBAN_WINDOW. Les valeurs par défaut d’installation sont threshold 0 et window 60 minutes, donc l’auto-ban est désactivé tant qu’un seuil positif n’est pas configuré. Lorsque le nombre d’échecs depuis la même IP dans la fenêtre configurée atteint le seuil, le module ajoute un ban auth avec le motif Auto-banned: X failed login attempts in Y min et une expiration une heure dans le futur.

Un ban auth est plus étroit qu’un ban complet : il cible les pages liées à l’authentification, tandis que les bans full existants restent prioritaires. Comme ce checkout source contient l’enregistreur et la logique de ban mais pas de fichier d’override d’authentification concret, vérifiez que votre build installée inclut l’intégration d’authentification avant de vous y fier comme seule protection de connexion.

Le compteur de seuil est basé sur l’IP. L’email échoué est stocké pour revue, mais countRecentFailedLogins() compte seulement les lignes avec le même ip_address plus récentes que la fenêtre configurée ; il ne compte pas séparément par email tenté. Le contrôle d’auto-ban évite aussi de créer un nouveau ban auth temporaire si l’IP est déjà sous ban full.

• Pour l’activer : définissez AUTOBAN_THRESHOLD sur un nombre positif comme 5 et gardez ou ajustez AUTOBAN_WINDOW en minutes.
• Ce qui est créé : une ligne active dans mprceiipban_banned avec ban_type=auth, l’IP visiteur et une date_expiry d’une heure.
• Nettoyage : les lignes d’échec de connexion sont couvertes par le chemin de purge du module, qui utilise le nombre de jours de rétention de logs configuré.

AUTOBAN_THRESHOLD = 5
AUTOBAN_WINDOW = 60
Result after 5 failures from one IP in 60 minutes: temporary auth ban for 1 hour

PrestaShop est livré avec une seule page de contact fixe, ce qui ne suffit pas lorsque vous avez besoin de demandes de devis, demandes B2B, entrées support ou inscriptions à des événements. Pour construire vos propres formulaires, utilisez Better Contact Form : il stocke les formulaires et leurs champs dans des tables dédiées et les rend via un contrôleur de module ou un hook, avec une gestion fonctionnelle des valeurs soumises pour les champs texte, email, téléphone, textarea, select, checkbox, URL et nombre. Vous pouvez créer plusieurs formulaires pour différents usages, les placer sur n’importe quelle page, et collecter des soumissions structurées au lieu d’emails en texte libre. Gardez chaque formulaire court, marquez clairement les champs requis, et ajoutez une protection anti-spam. Pour le GDPR, incluez une case de consentement et un lien vers votre politique de confidentialité afin que les données de demande soient collectées légalement.

Le template a aussi une branche d’input file, mais le processeur de soumission actuel lit les valeurs de champ via Tools::getValue() et ne gère pas $_FILES. Cela signifie que les champs fichier peuvent être affichés, mais les fichiers uploadés ne sont pas persistés comme valeurs de champ soumises dans l’implémentation actuelle. Ne comptez pas sur la collecte d’uploads de fichiers tant que la gestion de fichiers n’est pas ajoutée.

Les formulaires, champs, soumissions et valeurs individuelles de soumission sont stockés dans des tables séparées, donc une demande conserve à la fois une ligne de résumé et des données de champs structurées. Le renderer peut choisir un formulaire spécifique ou le formulaire actif par défaut, ne retourne rien lorsqu’un formulaire est inactif ou n’a aucun champ, et préremplit le nom/email du client connecté lorsque disponible.

Le traitement de soumission vérifie que le bouton submit a été posté, effectue les contrôles de champs requis, validation de type, validation d’options select, méthodes optionnelles de validation PrestaShop, application de la case GDPR, détection spam et persistance en base de données. La valeur cachée _mpr_ft n’est pas un token CSRF ; c’est un horodatage base64 utilisé par le contrôle anti-spam de timing. Honeypot et contrôle de temps anti-spam sont activés par défaut, avec un temps minimum de soumission par défaut de 3 secondes. Les soumissions spam sont quand même enregistrées avec is_spam et spam_reason, mais les emails admin/client ne sont envoyés que pour les soumissions non spam. Cela vous donne une piste d’audit sans laisser le trafic bot évident déclencher des notifications.

Les avis photo permettent aux acheteurs de joindre de vraies images produit à leurs notes, ce qui renforce la confiance et ajoute du contenu unique et riche en mots-clés à vos pages produit. PrestaShop n’a pas de fonctionnalité d’avis image intégrée, vous l’ajoutez donc avec un module d’avis. Avec Product and Store Reviews, activez les uploads d’images dans les réglages d’avis : le formulaire accepte alors les fichiers JPEG, PNG et WebP, applique votre taille maximale de fichier et votre nombre maximal d’images, redimensionne automatiquement les grands uploads, génère des miniatures, et attache les images à l’enregistrement d’avis sauvegardé. Les avis photo approuvés s’affichent avec le produit et alimentent les rich results de notation étoile. Définissez une limite raisonnable - par exemple 3 à 5 images par avis - et gardez la modération activée afin que seules les photos réelles et pertinentes soient publiées. Les photos client réduisent aussi les retours en fixant des attentes précises avant l’achat.

Dans la source locale, cette fonctionnalité se trouve dans le module mprcomments. Les uploads d’image sont activés par ALLOW_IMAGES, avec des valeurs par défaut de 3 images par avis et 2 MB par image. Le template d’avis produit utilise un input fichier multiple nommé review_images[] et accepte image/jpeg, image/png et image/webp. L’uploader valide le type MIME, la taille de fichier et les dimensions d’image, puis redimensionne les grandes images à un maximum de 1200 par 1200 pixels et crée des miniatures de 150 par 150.

L’avis est d’abord enregistré avec le statut pending ou approved selon les réglages de modération, puis les uploads d’image sont traités immédiatement contre cet ID d’avis enregistré. L’approbation contrôle la visibilité publique, pas l’attachement des images. La validation normale des avis s’applique d’abord : le contenu de l’avis doit respecter la longueur minimale, la note doit être entre 1 et 5, les invités sont bloqués sauf autorisation, les doublons d’avis client sont vérifiés, et la modération peut laisser l’avis en attente au lieu de le rendre public immédiatement. Les données structurées reposent volontairement sur les avis produit natifs ; les avis d’entreprise importés sont exclus du schema produit, et le renderer de schema limite les éléments d’avis intégrés tout en sortant quand même la note agrégée lorsque des avis natifs existent.

Les clients peuvent soumettre des galeries de projets depuis le parcours front-office du module. Dans PrestaShop, le showcase enregistre projets, titres et descriptions multilingues, images, catégorie et statut de modération, avec 20 images et 5 Mo par image par défaut.

Non. Le module vérifie si mprcheckoutrevolution est installé et activé. Lorsqu'il est actif, ce module lui cède l'interface de modification des commandes au lieu de gérer lui-même les hooks de modification de commande.

Dans PrestaShop, le H1 de page catégorie est le nom de la catégorie ; modifier le titre pour le SEO change donc normalement vos libellés de menu et fils d’Ariane, ce que vous ne voulez généralement pas. La solution consiste à remplacer le H1 indépendamment. Avec Custom Category H1, vous stockez une valeur H1 séparée par catégorie et le module l’insère dans la page catégorie via les hooks PrestaShop, en laissant le nom de l’objet Category (et donc la navigation et les fils d’Ariane) intact. Cela vous permet de cibler un titre riche en mots-clés comme « Receveurs de douche étanches pour salles d’eau » tandis que le menu reste court, par exemple « Receveurs ». Notez que les catégories racines sont volontairement exclues, car elles ne rendent pas une page catégorie front-office normale où un H1 visible acheteur s’appliquerait. Utilisez un H1 clair et unique par catégorie et gardez-le aligné avec la balise title de cette page, consultez notre guide SEO PrestaShop.

Le module stocke les remplacements dans des tables dédiées pour les lignes d’override, les valeurs de langue et les assignations de catégories. Les valeurs par défaut sont activé, afficher le champ dans l’édition de catégorie, remplacer le nom de page catégorie dans le contenu catégorie filtré, appliquer la même valeur aux libellés de listing produit, se rabattre sur la langue par défaut, se rabattre d’une valeur spécifique boutique vers une valeur toutes boutiques, retirer les balises HTML et normaliser les espaces. Le repli vers catégorie parente existe mais est désactivé par défaut pour éviter les titres dupliqués entre catégories enfants.

Pour le travail SEO en masse, un override peut être assigné à plusieurs catégories. Si un marchand modifie ensuite directement une catégorie et que cette catégorie appartient à un override partagé, le code détache cette catégorie seule et crée un override local à la catégorie, en laissant l’override partagé pour les autres. La valeur H1 peut utiliser des placeholders comme {category_name}, {nb_products}, {page}, {page_label}, {shop_name} et {lang}. La pagination peut aussi ajouter automatiquement un libellé de page lorsqu’elle est activée. Le module change les données de catégorie rendues ; il ne renomme pas l’enregistrement de catégorie PrestaShop stocké.

Il enregistre displayHeader, displayOrderConfirmation, actionValidateOrder et actionCustomerAccountAdd. Ces hooks rendent le tracking navigateur et mettent en queue les données de conversion liées aux commandes ou inscriptions.

Le formulaire propose la virgule, le point-virgule, la tabulation et le pipe. Le contrôleur convertit l'option tab en véritable caractère de tabulation avant de diffuser le CSV.

Le schéma inclut des tables pour les équipes, employés d'équipe, mappings équipe-statut, statuts de workflow et traductions, historique de commande, commentaires de commande, rappels, notifications et préférences de notification des employés.

Non. Le code de détection vérifie si la référence produit commence par mpr-pack-. Le contenu du pack est ensuite lu depuis la table propre au module mpr_pack_content.

Le hook vérifie actionDispatcherBefore et ne traite que Dispatcher::FC_FRONT et Dispatcher::FC_MODULE. Les dispatches Back Office sont ignorés.

hookPaymentOptions() exige un module actif, une configuration activée, un client connecté, au moins une condition de paiement active assignée aux groupes du client et assez de crédit pour le total du panier courant.

Il détecte le pays du visiteur dans un ordre de fallback fixe. Le module lit d’abord l’en-tête Cloudflare HTTP_CF_IPCOUNTRY lorsqu’il existe et n’est pas XX. Si ce n’est pas disponible, il tente le GeoIP PrestaShop via GeoIp::getCountryByAddr($ip) et reconvertit le nom de pays renvoyé en code ISO. Si GeoIP est indisponible, il vérifie enfin le cookie de contexte PrestaShop iso_code_country.

1. Cloudflare reverse proxy sends HTTP_CF_IPCOUNTRY=US -> module stores country code US and resolves the country name.
2. No Cloudflare header -> PrestaShop GeoIP returns United States -> module looks up ISO code US.
3. GeoIP unavailable -> PrestaShop cookie iso_code_country=US is used.
4. No signal -> empty country code and empty country name.

Cela signifie que les bans pays dépendent du signal disponible pour cette requête. Si vous vous appuyez sur la détection pays Cloudflare, assurez-vous que le trafic boutique passe réellement par Cloudflare afin que l’en-tête soit présent.

L’IP visiteur utilisée pour GeoIP vient de Tools::getRemoteAddr() lorsque PrestaShop la fournit. Le module possède une chaîne de fallback pour HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP, la première valeur de HTTP_X_FORWARDED_FOR, puis REMOTE_ADDR. C’est important, car la qualité GeoIP dépend de la vraie IP client, pas de l’IP d’un proxy intermédiaire.

Un ban pays ne correspond que lorsque la requête courante a un code pays non vide. Si Cloudflare envoie XX, que GeoIP manque, que le lookup de nom de pays ne peut pas mapper le résultat GeoIP vers un code ISO, et que le cookie est absent, alors les règles uniquement pays ne se déclencheront pas pour cette requête. VPN, proxies et configuration CDN peuvent aussi faire différer le pays détecté de la localisation physique de l’acheteur.

Le contrôleur checkout personnalisé redirige les acheteurs vers la page de commande native PrestaShop lorsque le one page checkout est désactivé. Le module n'impose donc pas son flux si le paramètre one_page_checkout_enabled est coupé. Cela garde le réglage lié aux paramètres du module et au comportement réel de PrestaShop.

Oui, le module inclut des outils d'import et d'export pour le contenu blog. Le contrôleur admin PrestaShop peut importer du XML WordPress WXR, avec commentaires optionnels, et exporter les données blog en XML ou JSON via le service BlogExporter.

La bannière réapparaît lorsque le cookie de consentement est absent ou expire. Sur le front PrestaShop, le JavaScript lit mprcookie_consent et masque la bannière pour les visiteurs connus; l'expiration configurée contrôle la duree de conservation, avec 365 jours par défaut.

Oui, le module dispose d'un interrupteur d'affichage mobile. Avant de rendre le widget Crisp, le guard PrestaShop vérifie le réglage SHOW_MOBILE et le contexte appareil; si l'affichage mobile est désactivé et que le contexte est mobile, aucun script Crisp n'est sorti.

Non. S2S_ENABLED vaut false par défaut. Le panneau de readiness indique explicitement que le S2S est optionnel, et le tracking Pixel navigateur peut fonctionner avec un Marketer ID valide et le tracking navigateur activé.

Oui, les marchands peuvent definir des règles de declenchement pour les evenements Criteo pris en charge. La configuration PrestaShop accepte des règles JSON validées avec declencheurs clic, URL, contrôleur ou evenement DOM, puis normalise les noms vers le vocabulaire OneTag autorisé.

Le Front Controller accepte un nom d'événement et des paramètres JSON, refuse les payloads de plus de 8192 caractères, conserve au maximum 50 clés normalisées par niveau, limite la profondeur d'imbrication et tronque les chaînes à 512 caractères.

Non, la désinstallation ne supprime pas les tables cron partagées. Le chemin de désinstallation PrestaShop retire le menu admin du module et desinscrit ses propres tâches, mais conserve volontairement les tables car d'autres modules MPR peuvent dépendre de la même infrastructure.

Non, les catégories racines sont refusées par la logique d'enregistrement des overrides. Le contrôleur admin PrestaShop vérifie que les catégories sélectionnées sont des catégories storefront, car les racines ne rendent pas de pages catégorie normales ou un H1 visible s'appliquerait.

Oui, le module inclut un scanner de cookies du front. Il peut explorer une URL PrestaShop, inspecter les en-têtes Set-Cookie et les affectations document.cookie inline, stocker les nouveaux cookies non catégorisés et suggérer des catégories pour les motifs connus.

Oui, il peut utiliser des motifs user-agent comme cibles de bannissement. Dans l'admin PrestaShop, une règle peut utiliser du texte simple pour une recherche contient insensible à la casse ou une regex entre slashs, et être combinee avec IP, CIDR ou pays.

Non, les fichiers joints ne sont pas traités par le code actuel de soumission. La liste des champs admin contient un type fichier, mais le processeur lit les valeurs avec Tools::getValue et ne gère pas le tableau PHP files, les chemins de stockage ni les pièces jointes.

Oui. Le validateur accepte des chiffres séparés par des virgules ou des espaces, dans la limite des règles de longueur configurées, ce qui permet de stocker plusieurs IDs numériques dans le champ Marketer ID.

Le panneau de diagnostics inclut une action Retry failed events. Elle appelle le reset de queue partagé pour ce module et le provider outbrain, puis remet les événements échoués au statut pending.

Le module stocke les IDs produits dans le cookie navigateur du visiteur mprrecent_ids. Le cookie est écrit avec le chemin /, une durée de vie de 30 jours et SameSite=Lax.

Non. Le contrôleur AJAX crée un objet Product pour chaque ID demandé et ignore les entrées non chargées ou inactives avant de renvoyer les données de carte produit.

La réponse AJAX inclut le nom de chaque produit, l'URL produit, l'URL de l'image de couverture avec home_default et un prix formaté. Le script front rend ces valeurs sous forme de cartes produit compactes.

Aucun compte n’est requis, et la description source indique que cela fonctionne pour les invités, clients connectés et visiteurs récurrents. Le module mémorise les pages produit récentes dans un cookie navigateur plutôt que de remplir une table d’historique utilisateur PrestaShop. Vous devez quand même décrire l’usage des cookies dans vos informations de confidentialité ou cookies lorsque les exigences légales de votre boutique l’imposent.

Le script front-office utilise un cookie nommé mprrecent_ids. Sur les pages produit, il place l’ID produit courant au début de la liste, supprime les doublons, limite la liste au maximum configuré et écrit le cookie pour 30 jours avec SameSite=Lax. La valeur d’installation par défaut est MAX_PRODUCTS=8, et le hook d’affichage par défaut est displayFooterProduct.

Lorsque le widget est rendu, le navigateur lit le cookie et poste la liste d’IDs produit au contrôleur AJAX du module. Le contrôleur nettoie les IDs avec intval, retire les valeurs vides, limite la requête à 20 IDs et ne renvoie que des produits actifs. La réponse contient l’ID produit, le nom, l’URL, l’image de couverture et le prix formaté afin que le widget puisse dessiner la liste de produits récents.

Le module ne construit donc pas un profil de navigation côté serveur lié à un compte client. Le serveur reçoit tout de même les IDs de produits récents pendant la recherche AJAX, et les IDs sont stockés dans le cookie navigateur du visiteur, donc la fonctionnalité reste du tracking basé sur cookie du point de vue de l’avis de confidentialité.

Saisissez l’AdRoll Advertiser ID depuis adroll_adv_id, saisissez le Pixel ID depuis adroll_pix_id, activez le tracking navigateur, et choisissez les événements à envoyer. Les deux IDs doivent contenir uniquement lettres, chiffres, underscores ou tirets, et le tracking reste inactif tant que les IDs ne sont pas valides et que le module n’est pas activé.

• Configuration requise : Advertiser ID, Pixel ID et tracking navigateur activé.
• Événements de parcours page : page view, product view, checkout start et search.
• Événements d’interaction : add to cart, add to wishlist, signup et événements navigateur personnalisés configurés.
• Événement purchase : envoyé sur la confirmation de commande lorsque le tracking purchase est activé.

Le module est une intégration Pixel navigateur. Ses propres métadonnées de démo marquent l’achat côté serveur AdRoll comme indisponible, car l’accès public AdRoll S2S n’est pas exposé comme un flux stable token/endpoint dans ce module.

À l’installation, le tracking navigateur lui-même est désactivé par défaut, tandis que les interrupteurs d’événements standard sont activés par défaut. Cela permet à un marchand de configurer les IDs d’abord, puis d’activer le tracking quand il est prêt. L’exclusion employés et le respect du consentement marketing sont tous deux activés par défaut, donc les employés back-office naviguant le front-office et les visiteurs sans consentement marketing pris en charge peuvent être supprimés avant l’envoi d’événements.

Le hook header prépare la file AdRoll, définit window.adroll_adv_id, window.adroll_pix_id et window.adroll_version='2.0', puis charge https://s.adroll.com/j/roundtrip.js. Les événements header sont construits côté serveur pour page view, product view, checkout start, search et signup, tandis que add-to-cart et wishlist sont attachés en JavaScript aux événements PrestaShop ou sélecteurs de boutons courants.

Les événements navigateur personnalisés sont optionnels et désactivés par défaut. S’ils sont activés, le JSON doit être un tableau ou un objet avec un tableau events. Les noms d’événements sont limités aux lettres, chiffres, underscores et tirets, avec une limite de 64 caractères, et ce module limite les événements personnalisés à 15 noms d’événements distincts. Les déclencheurs pris en charge sont click, url, controller et event.

[{"event":"GalleryBrowse","trigger":"click","selector":".product-images img","params":{"segment_name":"gallery_browse"}}]

Oui, le tracking purchase envoie la valeur de commande et la devise depuis la page de confirmation de commande PrestaShop. Le module construit aussi le nombre d’articles, la référence de commande, les IDs produit, noms, catégories, prix et quantités, puis envoie l’événement purchase via le pixel navigateur quand le tracking purchase est activé.

Le hook de confirmation de commande vérifie d’abord la porte normale de tracking : le module doit être actif, les IDs doivent être valides, l’exclusion employé ne doit pas bloquer la requête, le consentement marketing doit passer quand il est activé, et TRACK_PURCHASE doit être actif. Il accepte ensuite order ou objOrder depuis les paramètres du hook PrestaShop et construit le payload purchase depuis cette commande chargée.

Le mapping de valeur est explicite. Les données de conversion communes sont converties en paramètres de style AdRoll : value devient conversion_value, currency devient adroll_currency, num_items reste le nombre d’articles, order_id est défini sur la référence de commande PrestaShop, et les données produit deviennent product_id, content_ids et un tableau products avec item ID, nom, prix et quantité lorsque disponible.

L’événement reste côté navigateur. Le template appelle window.mpradrollTrack('purchase', params, 'Order confirmation') lorsque le script header est présent, ou se rabat sur window.__adroll.track/window.adroll.track. Si la fonction legacy record_user d’AdRoll existe, le template l’appelle aussi, mais le module n’envoie pas de requête purchase server-to-server.

Oui. Lorsque MPRADROLLPIXEL_RESPECT_CONSENT est activé, le module vérifie les modules de consentement cookies pris en charge avant de rendre ou déclencher le tracking AdRoll. Avec mprcookiesrevolution, le consentement marketing est accordé seulement quand le cookie mprcr_consent contient marketing:1. Avec mprcookiebanner, le consentement est accordé quand mprcookie_consent=granted. Si le cookie pertinent manque, le module se rabat sur la valeur DEFAULT_CONSENT de ce module de consentement.

mprcookiesrevolution allowed: mprcr_consent=essential:1|marketing:1|statistics:1
mprcookiesrevolution blocked: mprcr_consent=essential:1|marketing:0|statistics:1
mprcookiebanner allowed: mprcookie_consent=granted

Si aucun module de consentement pris en charge n’est actif, le contrôle de consentement ne bloque pas le tracking. L’exclusion employés peut toujours supprimer le tracking séparément lorsque MPRADROLLPIXEL_EXCLUDE_EMPLOYEES est activé.

Les valeurs par défaut d’installation sont orientées confidentialité : RESPECT_CONSENT=1 et EXCLUDE_EMPLOYEES=1. La méthode côté serveur canTrack() renvoie false si le module est inactif, si un contexte employé valide navigue le front-office, ou si le consentement marketing n’est pas accordé selon les contrôles des modules de consentement pris en charge.

Le template navigateur effectue aussi un contrôle de consentement avant de charger AdRoll. Lorsqu’un module de consentement pris en charge est actif, il vérifie window.MPRCR.isGranted('marketing') si disponible, puis les deux mêmes cookies. Si ce contrôle côté client échoue, le script retourne avant de charger roundtrip.js ou de déclencher les événements en file. Piège pratique : le contrôle côté client ne connaît pas la valeur DEFAULT_CONSENT côté serveur, donc une configuration qui dépend d’un consentement granted par défaut sans cookie de consentement doit être testée dans le navigateur.

Non, ce module envoie les événements AdRoll via le pixel navigateur, pas via une API serveur publique. Le code PrestaShop contient une note de démo indiquant qu'AdRoll S2S est une beta sous support; en production il charge roundtrip.js et envoie seulement des événements navigateur.

Utilisez ce module pour définir des noms d’affichage séparés pour les pages CMS PrestaShop. Il stocke un nom d’affichage par id_cms, langue et boutique dans sa propre table mprcmsnames, donc l’enregistrement CMS natif et son meta_title SEO ne sont pas réécrits dans la table CMS.

• Exemple : gardez le meta title de la page CMS comme Terms and Conditions | My Shop pour le SEO.
• Ouvrez l’écran CMS Display Names du module et trouvez cette ligne de page CMS par ID et meta title existant.
• Saisissez un nom d’affichage plus court comme Terms dans le champ Display Name et enregistrez.
• Sur le front-office, le titre visible de la page CMS reçoit le nom d’affichage via filterCmsContent, et les liens CMS correspondant au motif cms-page-link de PrestaShop sont remplacés dans le HTML final.
• Si vous videz le champ de nom d’affichage, le module supprime sa ligne personnalisée pour cette page CMS et la boutique retombe sur le meta_title CMS original.

La séparation pratique est donc : utilisez le titre CMS natif pour les extraits de recherche et le comportement du titre navigateur, et utilisez ce module pour des titres de page, liens footer et libellés de menu plus courts que les acheteurs scannent réellement.

Le module possède deux chemins front-office. D’abord, filterCmsContent modifie l’objet CMS passé au template de page en remplaçant meta_title par le nom d’affichage stocké pour la langue et la boutique courantes. Ensuite, actionOutputHTMLBefore édite le HTML final pour les liens CMS correspondants avant l’envoi de la réponse.

Le commentaire source est explicite : la vraie balise HTML <title> n’est pas affectée, car PrestaShop la construit via Meta::getMetaTags() en utilisant son propre chemin SQL. C’est pourquoi ce module peut raccourcir les noms visibles sans écraser le titre SEO CMS stocké par PrestaShop.

Le markup du thème compte toujours. Le relabeling des liens ne s’exécute que sur les ancres qui correspondent au motif CMS link attendu par le module, avec l’ID de page CMS dans link-cms-page-{id}-... et l’attribut de classe exact cms-page-link dans l’ordre attendu par la regex. Si un thème construit les menus CMS avec un markup différent ou du HTML imbriqué dans le texte d’ancre, le titre peut encore être changé mais le texte du lien peut ne pas être remplacé.

Non, il ne réécrit pas la balise HTML title. Le module est volontairement limité au contenu CMS visible et au texte de liens CMS rendu, afin que PrestaShop continue d’utiliser le meta title CMS original pour le head de page et les extraits de recherche.

Le commentaire source indique que la balise <title> est construite par le chemin Meta::getMetaTags() de PrestaShop et n’est pas affectée. Le module ne met pas à jour la table CMS native, ne se branche pas dans la génération des meta tags et n’écrit pas de nouveau titre SEO dans PrestaShop.

Ce qu’il peut changer est l’objet CMS passé via filterCmsContent. Si le template de page utilise le meta_title de cet objet CMS filtré comme titre visible, les acheteurs voient le nom d’affichage plus court sur la page. Séparément, actionOutputHTMLBefore peut remplacer le texte des liens CMS correspondants dans le HTML final. Ce sont des changements de contenu visible, pas des changements de balises head.

Pour le travail SEO, continuez à modifier le vrai meta title CMS dans la page CMS native de PrestaShop. Utilisez ce module quand le titre SEO est trop long pour les menus, footers, breadcrumbs ou titres visibles sur page.

Il renomme les liens CMS qui correspondent au markup CMS link attendu par PrestaShop. Le hook de sortie cherche une ancre dont id commence par link-cms-page-{id}- et dont la classe est cms-page-link, puis remplace le texte de lien simple par le nom d’affichage stocké pour la langue et la boutique courantes.

<a id="link-cms-page-3-1" class="cms-page-link" href="/content/3-terms-and-conditions">Terms and conditions</a>

Ce motif compte pour les thèmes personnalisés : si le lien CMS a une autre classe, pas d’id link-cms-page-..., si la classe apparaît avant l’id dans le markup ciblé par le module, ou si le libellé est construit avec du HTML imbriqué plutôt qu’un texte simple, le remplacement de sortie peut ne pas matcher.

La regex est volontairement étroite. Elle attend l’attribut id avant class="cms-page-link", et capture du texte simple entre les balises ouvrante et fermante de l’ancre. Un lien avec plusieurs classes comme class="footer-link cms-page-link", un span dans l’ancre, ou un composant de menu entièrement personnalisé peut sortir de ce motif.

Le remplacement ne fait rien non plus dans le back-office et retourne tôt s’il n’y a pas de noms d’affichage pour la langue et la boutique courantes. Si le footer ou menu CMS de votre thème n’est pas renommé, inspectez d’abord le markup d’ancre généré ; souvent, la correction consiste à faire sortir au template le motif natif PrestaShop d’ID et de classe CMS link.

Oui, les noms d’affichage sont stockés par page CMS, langue et boutique. La table du module utilise id_cms, id_lang et id_shop comme clé, et enregistrer une valeur vide supprime ce libellé stocké afin que PrestaShop retombe sur le titre CMS natif.

La recherche front-office est aussi spécifique à la langue et à la boutique. Elle charge les lignes de mprcmsnames où id_lang égale la langue du contexte courant et id_shop égale la boutique du contexte courant. Il n’y a pas de fallback large id_shop=0 dans cette recherche, donc un nom d’affichage enregistré pour une boutique n’est pas automatiquement réutilisé par une autre.

À l’enregistrement, le module boucle sur les pages CMS et les langues, remplaçant les lignes lorsqu’une valeur est postée et supprimant les lignes lorsque la valeur soumise est vide. C’est pourquoi vider un champ est une vraie réinitialisation, pas seulement un libellé personnalisé vide.

Détail d’implémentation à vérifier dans cette version source : la table de configuration rendue affiche l’input de langue par défaut pour chaque page CMS. La base de données et la logique de sauvegarde prennent en charge id_lang, mais le formulaire visible dans ce checkout ne rend pas de colonnes d’input séparées pour chaque langue. Si vous avez besoin de noms d’affichage non langue par défaut, confirmez que la build installée expose ces inputs ou ajoutez-les avant de vous fier à l’édition multilingue via le formulaire standard.

Oui, le module génère automatiquement un mot de passe pour les formulaires d’inscription et de checkout pris en charge. Dans PrestaShop, il cible les champs de mot de passe courants client, authentication et checkout, puis remplit les inputs password, passwd, confirmation et password_confirmation lorsque le périmètre de page configuré correspond.

Les valeurs par défaut d’installation activent le module, l’appliquent à l’inscription et au checkout, masquent les champs de mot de passe, génèrent un mot de passe de 12 caractères, et incluent majuscules, chiffres et caractères spéciaux. Les contrôleurs applicables sont authentication, registration et identity pour l’inscription, plus order, orderopc et order-opc pour le checkout.

Sur PrestaShop 1.7+, le module enregistre ses CSS et JavaScript front via actionFrontControllerSetMedia. Sur PrestaShop 1.6, il charge les assets depuis displayHeader. Le même hook header injecte les réglages de mot de passe dans window.mprcustomerpassword_config pour que le JavaScript les utilise.

Le script front trouve les champs nommés comme password, passwd, confirmation et password_confirmation, et scanne aussi les formulaires courants registration/authentication pour tout input type=password. Il génère un mot de passe par page, remplit tous les champs correspondants avec la même valeur, définit autocomplete=new-password, et ajoute un marqueur caché mprcustpass_auto=1 au formulaire.

• Mode caché : le wrapper du champ mot de passe est masqué et marqué aria-hidden.
• Mode optionnel dans le code : le champ est affiché avec la valeur générée et un message d’information, mais le script met le champ en readonly.
• Formulaires checkout dynamiques : un MutationObserver retraite les champs de mot de passe nouvellement insérés, et le script protège les valeurs générées à la soumission ainsi qu’avec un contrôle périodique.

Oui, il peut envoyer le mot de passe généré lorsque le mode email est défini sur send password. Le hook d’ajout de compte PrestaShop n’envoie cet email que lorsque le formulaire soumis inclut le marqueur d’auto-génération du module, donc les comptes clients normaux ne sont pas traités par erreur.

La valeur par défaut EMAIL_MODE est send_password. Lorsque actionCustomerAccountAdd s’exécute, le module vérifie d’abord qu’il est activé, puis cherche mprcustpass_auto dans le formulaire soumis. Ce marqueur est ajouté par le JavaScript seulement après qu’il a rempli les champs de mot de passe, donc le chemin email est lié aux mots de passe générés par le module.

Pour l’email de mot de passe, le module lit le mot de passe soumis depuis password d’abord et se rabat sur passwd pour les anciens formulaires PrestaShop. Si aucune valeur n’est présente au moment du hook, il retourne sans envoyer. Quand il envoie, il utilise le template mail mprcustomerpassword_account et transmet le prénom, le nom, l’email, le mot de passe généré, le nom de boutique et l’URL de boutique du client.

Il existe deux alternatives importantes. Avec EMAIL_MODE=silent, le hook sort sans envoyer d’email de mot de passe. Avec EMAIL_MODE=setup_link, il envoie un lien de réinitialisation/configuration au lieu du mot de passe généré. Les marchands qui ne veulent pas envoyer de mots de passe par email doivent utiliser setup-link ou silent mode plutôt que le mode par défaut send-password.

Oui, le module peut envoyer un lien de configuration au lieu du mot de passe généré. Dans PrestaShop, le mode setup-link crée un token de reset, stocke une validité de 24 heures sur l’enregistrement client ou les champs legacy, et envoie au client un lien vers la page de mot de passe.

Ce chemin est sélectionné avec EMAIL_MODE=setup_link. Le même hook account-add et le marqueur mprcustpass_auto s’appliquent encore, donc l’email de configuration est seulement envoyé pour les comptes où le script front du module a généré et soumis les champs de mot de passe.

Sur les objets client PrestaShop récents qui exposent reset_password_token, le module crée un token depuis random_bytes(32), le rend compatible URL en remplaçant les caractères base64 dangereux, le stocke dans reset_password_token, définit reset_password_validity à 24 heures dans le futur, met à jour le client, et construit une URL de page mot de passe avec token, id_customer et reset_token.

Pour le chemin legacy, le module crée un token MD5, met à jour directement les champs reset_password_token et reset_password_validity de la table customer avec une fenêtre de validité de 24 heures, et construit l’URL de page mot de passe avec token et id_customer. L’email utilise le template mprcustomerpassword_setup avec {setup_link}, les valeurs d’identité client, le nom de boutique et l’URL de boutique.

Le mot de passe généré est toujours utilisé pour permettre à PrestaShop de créer le compte pendant le checkout ou l’inscription. La différence est ce que le client reçoit ensuite : setup-link mode envoie un lien pour choisir un mot de passe, tandis que send-password mode envoie le mot de passe généré lui-même.

Non, le mode optionnel affiche le mot de passe généré mais le script actuel rend le champ en lecture seule. Dans PrestaShop, le mode caché masque le bloc complet, tandis que le mode optionnel affiche la valeur avec une note.

Ajoutez un Facebook Page Access Token et un Page ID, puis activez le feed. Dans PrestaShop, le module récupère les posts depuis la Facebook Graph API et peut les rendre dans les hooks home, footer, left column ou right column.

Le formulaire de connexion attend un Page Access Token et un Page ID. L’aide admin oriente les marchands vers une app Facebook Developer avec accès Pages API et les permissions pages_read_engagement et pages_read_user_content. Page Name est optionnel et sert à l’en-tête du feed lorsqu’il est fourni.

• Le hook d’affichage par défaut est displayHome, mais le module prend aussi en charge displayFooterBefore, displayFooter, displayLeftColumn et displayRightColumn.
• Le nombre de posts par défaut est 6, la mise en page par défaut est une grille 3 colonnes, et le cache feed partagé vaut par défaut 3600 secondes.
• Si l’access token ou le Page ID manque, la récupération via Facebook API ne renvoie aucun post, donc le bloc front-office n’a rien à rendre.

MPRFB_ACCESS_TOKEN=your-page-token
MPRFB_PAGE_ID=your-page-id
MPRFB_DISPLAY_HOOK=displayHome
MPRFB_POST_COUNT=6

Une fois configuré, le module appelle Facebook Graph API v21.0 pour les posts de la page, stocke le feed normalisé en cache, et ne rend que dans le hook sélectionné dans les réglages du module.

Oui, il peut afficher le texte du post, les médias, la date, les réactions, partages, commentaires et informations d’auteur. Dans PrestaShop, ces options d’affichage sont configurées séparément, et les posts partagés peuvent être exclus lorsque le réglage EXCLUDE_SHARED est activé.

Les interrupteurs concernés sont des réglages séparés comme SHOW_TEXT, SHOW_MEDIA, SHOW_DATE, SHOW_REACTIONS, SHOW_SHARES, SHOW_COMMENTS et SHOW_AUTHOR. Le texte est activé par défaut et tronqué avec des points de suspension lorsqu’il dépasse TEXT_LENGTH, qui vaut par défaut 200 caractères.

• Les médias sont tirés d’abord des attachments et subattachments Facebook, avec full_picture comme fallback.
• Les compteurs de réactions, commentaires et partages viennent des champs summary renvoyés par Facebook, donc les compteurs affichés dépendent de ce que la réponse API inclut.
• Lorsque EXCLUDE_SHARED est activé, les posts avec status_type égal à shared_story sont ignorés.
• Les posts sans texte de message ni image sont ignorés avant rendu.

C’est important, car un marchand peut construire un bloc social proof compact avec seulement images et compteurs d’engagement, ou un feed éditorial plus complet avec légendes, dates et attribution de page.

Les projets approuvés prennent en charge le vote communautaire et les commentaires imbriqués. Le nombre de votes et de vues est enregistré par projet, ce qui indique simplement quels travaux de clients suscitent le plus d'intérêt.

Oui. Le module met en cache le feed Facebook dans un fichier JSON nommé mprfb_feed_cache.json. Le cache stocke un timestamp cached_at et les posts récupérés, puis réutilise ces posts jusqu’à expiration de la durée configurée.

Cache file: mprfb_feed_cache.json
Duration setting: MPRFB_CACHE_DURATION=3600
Admin refresh: submitMprfbSync clears the file; the next front-office feed load fetches fresh posts and writes cached_at + posts

La durée de cache par défaut dans le trait de feed partagé est 3600 secondes. Le formulaire de configuration du module expose des durées courantes comme 30 minutes, 1 heure, 2 heures, 6 heures, 12 heures et 24 heures. Les actions admin refresh et clear-cache suppriment toutes deux le fichier de cache, donc la prochaine requête feed est forcée vers la source Facebook au lieu de servir des posts en cache obsolètes.

Le cache est indépendant des requêtes, donc les acheteurs normaux ne déclenchent pas un appel Facebook API à chaque page vue. Si le fichier cache est absent, vide, JSON invalide ou plus ancien que la durée configurée, le trait de feed partagé le considère expiré et récupère à nouveau. L’enregistrement de la configuration liée au feed vide aussi le cache du feed, ce qui évite de mélanger des changements de layout ou de nombre avec d’anciennes données de posts.

Pour les boutiques actives, c’est la principale protection contre les chargements de page lents et la pression API évitable. Pour les lancements de campagne, utilisez l’action admin refresh après publication sur Facebook si vous voulez que le bloc front-office récupère immédiatement le nouveau contenu au lieu d’attendre la prochaine expiration de cache.

Oui, il peut publier des articles de blog sur Facebook, mais le workflow d’autopublish est construit autour des articles MPR Blog Revolution, pas de tous les modules blog tiers possibles. Le module Facebook utilise le trait social publisher partagé, écoute les hooks PrestaShop object add et update, vérifie que l’auto-publish est activé, vérifie la présence d’un objet de style Blog Revolution ou Post, et continue seulement lorsque l’objet a status = 1.

La prévention des doublons est stockée dans la table mpr_social_publish. Avant l’envoi, le module vérifie si mprfacebookpostsintegration a déjà publié l’objet de type blog_post avec cet ID de post vers la plateforme facebook. Les envois réussis sont enregistrés avec l’ID de post plateforme, l’URL plateforme, la légende, les URL médias et le statut published, donc les hooks add ou update ultérieurs ignorent le même post au lieu de l’envoyer à nouveau.

Les légendes viennent du template auto-publish du module Facebook. Les placeholders pris en charge sont {title}, {excerpt}, {url} et {shop_name}. Si l’article de blog a une image mise en avant, le publisher construit son URL média depuis img/mprblogrevolution/posts/. Si les identifiants Facebook manquent, si le publisher n’est pas configuré, ou si une condition plateforme requise n’est pas remplie, le chemin auto-publish retourne sans publier.

Le publisher spécifique Facebook est configuré uniquement lorsque PAGE_ID et ACCESS_TOKEN existent. Il utilise Facebook Graph API v21.0, prend en charge les posts texte, posts lien et posts photo/image dans le chemin publish() implémenté, permet un élément média par envoi, et a une limite de caractères de 63206. Un post image media-only est envoyé via l’endpoint photos de la page, tandis que les posts lien ou texte utilisent l’endpoint feed de la page.

Bien que getSupportedMediaTypes() liste actuellement video, le publisher implémenté n’upload pas de vidéo et n’appelle pas d’endpoint videos. Traitez la publication vidéo comme non prise en charge sauf si un vrai chemin de publication vidéo est ajouté.

MPRFB_AUTOPUBLISH=1
MPRFB_AUTOPUBLISH_CAPTION={title}
{excerpt}
Read more: {url}

Le module ignore aussi son propre chemin publisher lorsque la prise de contrôle plus large mprsocialrevolution est active pour Facebook, afin que deux modules sociaux n’essaient pas de publier le même article de blog en même temps.

Le module ajoute des pages dédiées de galerie, catégorie, projet, soumission et un espace client « mes projets », chacune avec sa propre URL optimisée pour le SEO. Les projets approuvés mis en avant peuvent aussi s'afficher dans des zones choisies de la boutique.

Tous les textes de la galerie, catégories, projets et commentaires, sont stockés par langue, la galerie est donc entièrement multilingue. Le module fonctionne sur PrestaShop 1.6.1 à 9.x.

Oui, chaque profil de flux peut porter sa propre langue, devise, pays cibles et labels. C’est utile lorsqu’une boutique vend sur plusieurs marchés avec des wording catalogue ou structures publicitaires différents. Une séparation claire des feeds aide aussi les responsables à comprendre quel marché génère du revenu et lequel nécessite de l’attention.

Dans le modèle de feed, chaque profil stocke id_lang, id_currency, id_shop, target_country, feed_label, content_language et sync_mode. Un nouveau feed utilise par défaut des réglages français dans la source actuelle : target_country=FR, feed_label=FR et content_language=fr.

target_country=AE,AU,GB,US
feed_label=GB
content_language=en
sync_mode=file_only or api

• target_country est normalisé en majuscules et peut être un code pays à deux lettres ou une liste séparée par virgules.
• feed_label est normalisé en majuscules et doit respecter la forme de label de Google Merchant API : lettres majuscules, chiffres et tirets, jusqu’à 20 caractères.
• content_language est normalisé en minuscules et doit être un code langue à deux lettres pour l’entrée produit API.
• Pour la sync API, des profils de feed séparés sont généralement plus propres lorsque chaque marché a besoin d’un label, d’une devise ou d’une langue distincts.

Le contrôleur front de feed sert un feed précis par ID ou nom de fichier avec un token, utilise un cache TTL par défaut de 3600 secondes, et peut régénérer avec generate=1. Cela permet à une boutique PrestaShop de maintenir des feeds Merchant séparés sans mélanger pays, langues ou labels de campagne.

Non, la description source indique que les valeurs numériques internes de PrestaShop restent intactes dessous. Le module personnalise les numéros affichés sur les factures, bons de livraison et avoirs. Si vous avez besoin de personnaliser les références de commande elles-mêmes, la source recommande d’utiliser le produit séparé Custom Order Numbering.

Le module de facture confirme cette séparation dans le code : hookActionSetInvoice génère et logue la référence de facture formatée, mais laisse volontairement le numéro de facture stocké par PrestaShop numérique/natif. La chaîne formatée affichée est fournie plus tard via actionInvoiceNumberFormatted, et la génération de bon de livraison stocke la valeur numérique du compteur dans order_invoice.delivery_number.

Default invoice format: {DOC_TYPE}/{YYYY}/{NNNNNN}
Default delivery format: {DOC_TYPE}/{YYYY}/{NNNN}
Default credit slip format: {DOC_TYPE}/{YYYY}/{NNNN}

Les valeurs générées sont enregistrées dans mprinvoicenumber_number avec type de document, IDs de commande, facture ou slip, valeur de compteur, motif et numéro formaté. Cela vous donne des documents visibles par le client personnalisés sans changer les IDs de commande ou références de commande aléatoires ; ceux-ci sont gérés par mprordernumber.

Le module génère un indicateur via displayProductListReviews. Son JavaScript trouve la miniature produit englobante et injecte un badge Bundle dans la zone image.

L'onglet liste les produits inclus configurés dans une grille. Chaque carte peut afficher l'image produit, le nom du produit, le prix formaté ou FREE pour un prix à zéro, ainsi qu'un lien vers le produit inclus.

Il inclut un helper dispatcher pour les routes rewrite-only. Lorsqu'une route n'a pas d'ID, il peut résoudre les slugs de catégorie, produit, CMS ou fabricant correspondants et mettre à jour les paramètres de requête en conséquence.

Oui. Le formulaire admin stocke le flag d'activation, et chaque hook front s'arrête immédiatement lorsque isFeatureEnabled() vaut false.

Le chemin côté serveur exige que CAPI soit active et qu'un access token Reddit soit configuré. L'Events Testing ID est optionnel et utilisé seulement lorsqu'il est présent.

Non, la source décrit des événements navigateur et des événements côté serveur fonctionnant en parallèle avec des ID de conversion partagés. Le chemin côté serveur peut aider à réduire les pertes lorsque le suivi navigateur est bloqué, tandis que le pixel navigateur continue de capturer le comportement côté client. Utiliser les deux avec soin donne à Reddit des signaux plus complets qu’un simple pixel collé.

Le suivi navigateur est préparé dans les hooks d’en-tête et de confirmation de commande. Le module peut émettre des événements comme PageVisit, ViewContent, Search, SignUp, InitiateCheckout, des événements de pont de type ajout au panier et Purchase. Quand l’API Conversions est activée, les événements correspondants sont mis en file côté serveur avec la même identité : les paramètres navigateur utilisent conversionId, tandis que la charge utile API stocke conversion_id dans les métadonnées de l’événement.

• Un Reddit Pixel ID est requis pour le suivi navigateur.
• L’API Conversions exige aussi un jeton d’accès, et le module envoie les données vers l’endpoint de conversions Reddit pour le pixel configuré.
• Les vérifications d’exclusion des employés et de consentement marketing passent par canTrack() avant la préparation du suivi front-office.
• La limite par défaut des lots de la file CAPI est 20, tandis que les chemins de pont front et d’achat traitent immédiatement de petits lots.

La configuration pratique consiste à garder le pixel navigateur actif pour les événements client habituels et à utiliser l’API Conversions comme signal côté serveur complémentaire, pas comme remplacement.

Le module mappe directement la plupart des actions standards, tandis qu'InitiateCheckout est envoyé comme événement personnalisé Reddit nommé InitiateCheckout dans le mapping côté serveur.

Oui. La configuration inclut l'exclusion des employés, et la barrière de suivi la vérifie avant de construire la sortie du pixel front ou d'autoriser les événements via le chemin de suivi du module.

La liste des hooks disponibles couvre displayHome, displayFooterCategory, displayLeftColumn, displayRightColumn, displayFooterBefore, displayFooterProduct, displayProductAdditionalInfo, displayOrderConfirmation2 et displayCrossSellingShoppingCart.

Oui, la description source inclut des collections de produits sélectionnées ainsi que des widgets dynamiques. Les collections choisies à la main sont utiles pour les campagnes, le merchandising éditorial et les promotions axées sur la marge. Les sources dynamiques sont utiles lorsque vous voulez que les meilleures ventes, les nouveautés ou les produits de retour en stock restent à jour avec moins de travail manuel.

Les collections sélectionnées sont stockées séparément des widgets. La table collection-produit stocke id_collection, id_product et position, et setProducts() réécrit cette liste dans l’ordre enregistré par l’admin. Un widget peut ensuite utiliser le type de widget collection et pointer vers la collection choisie.

• Les types de collection incluent curated, staff_picks, seasonal et spotlight.
• Les requêtes publiques de collection retournent les produits actifs de la boutique et conservent l’ordre collection-produit enregistré.
• Si le widget exige des images, le fournisseur filtre les produits sans image exploitable.
• Les types de widgets automatiques avec fournisseurs de produits implémentés incluent bestsellers, new, sale, featured, trending, back_in_stock et cart_recommendations.
• recently_viewed est listé comme type/libellé de widget dans le modèle, mais getProducts() n’a pas encore de cas fournisseur pour lui ; il ne doit donc pas être présenté comme une liste automatique fonctionnelle tant que cette implémentation n’est pas ajoutée.

Vous pouvez donc créer une collection de campagne choisie à la main pour un bloc de page d’accueil ou de page produit, tout en utilisant des blocs dynamiques implémentés ailleurs dans la même boutique PrestaShop.

Oui. Le modèle de widget stocke hide_products_without_images, et les requêtes produit/l'assemblage du provider utilisent ce drapeau pour exiger une image de couverture boutique pour de nombreuses sources de widgets.

Le module écoute actionUpdateQuantity. Lorsqu'une quantité produit passe de zéro ou moins à une valeur positive, il insère une ligne dans mprshowcaserevolution_stock_change, que la source de produits de retour en stock peut utiliser.

Installez et activez le module pour ajouter un bouton Ask a question sur les pages produit PrestaShop. Il s’affiche via le hook displayProductAdditionalInfo, ouvre un formulaire modal à côté des informations produit, et transmet le nom du produit, la référence et l’ID produit dans la demande.

À l’installation, le module stocke ENABLED=1, définit RECIPIENT_EMAIL depuis PS_SHOP_EMAIL, et utilise [Product Question] comme préfixe d’objet par défaut. Le hook assigne le nom du produit, la référence produit, l’ID produit, l’URL AJAX et une valeur de token cachée au template Smarty.

• Hook front : displayProductAdditionalInfo.
• Endpoint AJAX : module/mpraskaboutproduct/ask.
• Réglages admin : interrupteur d’activation, email destinataire et préfixe d’objet.

Le résultat est un formulaire de demande spécifique au produit sur la page produit, afin que le marchand reçoive le message avec le contexte produit plutôt qu’une demande de contact générique.

Oui, les clients envoient la demande produit directement depuis la modale du front-office. Le contrôleur front PrestaShop reçoit le nom de l’expéditeur, son email, le message, le nom du produit et l’ID produit via AJAX, puis retourne un message JSON de succès ou d’erreur sans obliger le client à ouvrir un client email.

Le template envoie une requête FormData au contrôleur front du module et met à jour la modale avec la réponse JSON. En cas de succès, le formulaire est réinitialisé et le client voit le message de réussite ; en cas d’échec de validation ou d’envoi mail, la même modale affiche l’erreur retournée.

• La requête est considérée invalide si le marqueur d’envoi attendu sender_email est absent.
• Le contrôleur envoie au destinataire configuré du module, ou se rabat sur l’email de la boutique.
• Si le template mail question du module existe, il est utilisé ; sinon le code revient au template cœur PrestaShop contact.

La demande reste ainsi dans le parcours front-office PrestaShop et conserve le nom du produit ainsi que l’ID produit dans le corps de l’email.

Il valide la demande dans le contrôleur front AJAX avant d’envoyer l’email. Une requête doit soumettre sender_email, et les champs requis sont sender_name, sender_email et message. L’email est vérifié avec Validate::isEmail() de PrestaShop, et le message avec Validate::isCleanHtml().

POST /module/mpraskaboutproduct/ask sender_name=Alice&sender_email=alice@example.com&message=Can you confirm availability?&id_product=42&product_name=Demo product

• L’absence du marqueur d’envoi sender_email retourne {"success":false,"message":"Invalid request."}.
• Un nom, email ou message vide retourne {"success":false,"message":"All fields are required."}.
• Un email invalide retourne {"success":false,"message":"Invalid email address."}.
• Un HTML de message non sûr retourne {"success":false,"message":"Invalid message content."}.

Si la validation réussit, le module envoie la demande à l’email destinataire configuré, avec repli vers l’email de la boutique lorsqu’aucun destinataire de module n’est défini.

Après validation, le contrôleur construit l’objet de l’email à partir du préfixe d’objet configuré plus le nom du produit soumis. Le message est échappé et converti avec nl2br() pour le template email. Le nom du produit et l’ID produit sont inclus dans les variables mail, afin que l’équipe puisse identifier l’article sans demander au client de renvoyer les détails.

La modale inclut un champ token caché, mais le chemin actuel du contrôleur valide les champs de requête et le contenu du message plutôt que ce token. Si une protection anti-spam plus forte est nécessaire, ajoutez-la autour du formulaire front plutôt que de supposer que ce contrôleur effectue une vérification de token CSRF.

Oui, le module vous permet de définir l’email destinataire et le préfixe d’objet pour les questions produit. Si aucun destinataire n’est configuré, le contrôleur front PrestaShop se rabat sur l’adresse email de la boutique, puis envoie le message avec le contexte produit inclus.

La classe de configuration expose RECIPIENT_EMAIL et SUBJECT_PREFIX. À l’installation, RECIPIENT_EMAIL est initialisé depuis PS_SHOP_EMAIL, et SUBJECT_PREFIX vaut par défaut [Product Question]. Dans le contrôleur front, un destinataire vide est remplacé par Configuration::get('PS_SHOP_EMAIL').

Recipient: mpraskaboutproduct.RECIPIENT_EMAIL or PS_SHOP_EMAIL
Subject: SUBJECT_PREFIX + product name

C’est utile lorsque les questions produit doivent aller vers une boîte commerciale, une équipe technique ou un bureau fournisseur plutôt que vers l’adresse de contact principale de PrestaShop.

Oui. Les avis sont contrôlés avant d’être enregistrés, et les contrôles échoués retournent une erreur de validation au lieu d’accepter l’avis silencieusement. La source inclut ces protections :

• Limite par même IP : lorsque MIN_TIME_BETWEEN est supérieur à zéro, le module vérifie si la même IP a publié un autre avis dans cette boutique dans le nombre de secondes configuré.
• reCAPTCHA : lorsqu’il est activé, le module vérifie le token soumis auprès de Google. Il prend en charge v2 et v3 ; v3 utilise un seuil de score de 0.5. Un token manquant fait échouer le contrôle, tandis qu’une clé secrète manquante ou un problème de vérification réseau est traité comme non bloquant.
• Contrôles des liens et balises : le contenu avec plus de deux URL est rejeté, et le HTML embarqué évident comme <script>, <iframe>, <object>, <embed> et <form> est bloqué.

La protection par temps minimum est un contrôle du délai entre deux avis pour la même IP, pas un minuteur de chargement de formulaire. Pour utiliser reCAPTCHA comme protection active, activez-le et configurez la clé de site et la clé secrète dans les réglages du module.

Le flux de soumission plus large ajoute d’autres garde-fous pratiques. Les avis exigent un type d’entité valide, un ID d’entité, un contenu d’au moins 10 caractères et une note de 1 à 5. Les avis invités sont désactivés par défaut, et les clients connectés sont empêchés d’évaluer deux fois la même entité sauf si l’avis précédent a été marqué comme spam.

• MODERATION vaut par défaut 1, donc les nouveaux avis sont stockés comme pending sauf si la modération est désactivée.
• MIN_TIME_BETWEEN vaut par défaut 30 secondes.
• Pour les avis produit de clients connectés, le module peut marquer un avis comme achat vérifié lorsqu’il trouve une commande valide contenant ce produit.
• Les uploads de photos, lorsqu’ils sont activés, sont limités aux formats JPEG, PNG et WebP, avec des limites par défaut de 3 images et 2 MB par image.

Ce n’est pas pour autant un système de détection de fraude. Le code fournit limitation de fréquence, reCAPTCHA, contrôles de contenu, prévention des doublons, marquage d’achat vérifié et modération ; les marchands doivent donc garder la modération activée lorsque la qualité des avis compte.

Oui, les avis ne sont pas limités aux pages produit. Le module inclut une gestion d’entités pour les avis produit, catégorie, CMS et boutique, ainsi qu’une route publique d’avis, avec chaque zone d’affichage contrôlée par configuration et rendue via des hooks ou contrôleurs front-office PrestaShop.

Le modèle de données stocke les avis avec entity_type et entity_id, et le service de soumission accepte product, category, cms et store comme types d’entité valides. La page de réglages dispose d’interrupteurs séparés pour PRODUCT_REVIEWS, CATEGORY_REVIEWS, CMS_REVIEWS et STORE_REVIEWS ; seuls les avis produit sont activés par défaut dans les valeurs actuelles.

L’intégration automatique de page produit est le chemin le plus complet dans le code inspecté : les avis produit s’affichent via displayProductExtraContent, les étoiles de listing via displayProductListReviews, et le badge de note produit via les hooks de page produit. La page publique d’avis est exposée sous /reviews et peut filtrer les avis approuvés par type=product, category, cms ou store.

Allowed entity types: product, category, cms, store
Public route: /reviews
Filtered examples: /reviews?type=category or /reviews?type=store

Pour le placement sur catégorie, CMS et boutique, planifiez soigneusement l’emplacement front-office. La source prend en charge ces enregistrements d’avis et le hub d’avis, mais les pages produit disposent de la couverture de hooks intégrée la plus forte dans les fichiers inspectés.

Oui, des rappels peuvent être créés après qu’une commande atteint le statut livré configuré. Le hook de statut de commande PrestaShop planifie les rappels uniquement lorsque la fonctionnalité de rappel est activée, et le module stocke des lignes de rappel avec les données de commande, client, délai et statut d’avis.

Plus précisément, le hook inspecté écoute actionOrderStatusPostUpdate et vérifie si le nouveau statut de commande PrestaShop a son indicateur delivery défini. Lorsque REMINDERS_ENABLED est activé, il charge les produits de la commande et crée une ligne de rappel par produit via ReviewReminder::createForOrder().

• REMINDERS_ENABLED vaut par défaut 0.
• REMINDER_DELAY_DAYS vaut par défaut 7.
• Les lignes en double pour la même commande et le même produit sont ignorées.
• Les produits déjà évalués par ce client sont ignorés.
• Chaque ligne de rappel stocke un token de 64 caractères et un statut comme pending, sent ou reviewed.

Le modèle inclut aussi des helpers pour trouver les rappels en attente après le délai configuré, les marquer comme envoyés, les marquer comme évalués et charger un rappel par token. Dans les fichiers inspectés, j’ai trouvé la planification et le modèle de données, mais pas un flux cron complet d’envoi d’emails qui appelle ces méthodes helper.

Oui, le module inclut des gestionnaires d’avis externes pour Google Business Profile et Trustpilot. Lorsque les identifiants API requis sont configurés, les avis externes peuvent être synchronisés dans des tables locales d’avis externes, puis affichés ou agrégés selon les réglages du module PrestaShop.

La table d’avis externes stocke la source, l’ID d’avis source, l’auteur, le titre, le contenu, la note, l’URL source, la date de publication, la langue, l’ID produit optionnel, l’ID boutique, les données API brutes et les horodatages de synchronisation. Une clé unique sur source plus source_review_id empêche les imports en double lorsque le même avis est récupéré de nouveau.

• La synchronisation Trustpilot exige EXT_TRUSTPILOT_ENABLED, une clé API et un Business Unit ID. Le fournisseur dispose aussi d’un repli d’import CSV pour les exports Trustpilot.
• La synchronisation Google Business Profile exige EXT_GOOGLE_ENABLED, un JSON de compte de service contenant client_email et private_key, plus Account ID et Location ID.
• Le contrôleur cron s’exécute sur /module/mprcomments/cron?token=EXT_CRON_TOKEN&action=sync et retourne les résultats de synchronisation par source en JSON.
• Les avis externes d’entreprise peuvent être affichés sur les pages produit, chargés paresseusement par défaut, et éventuellement comptés dans les badges de note produit lorsque l’agrégation externe est activée.

Pour la sécurité SEO, le moteur de schema utilise les avis produit natifs pour les données structurées Product. Les avis d’entreprise importés peuvent être affichés aux acheteurs, mais les commentaires source les excluent explicitement du balisage d’avis produit sauf si le marchand dispose d’avis produit natifs.

Non, les projets soumis ne sont pas publiés automatiquement par défaut. Dans PrestaShop, le réglage auto_approve vaut par défaut 0, donc les nouveaux projets sont stockés comme en attente et les requêtes de galerie publique utilisent le statut de projet approuvé avant de les afficher.

Le contrôleur de soumission exige une authentification client et un token de sécurité valide avant de créer un projet. Il valide le titre du projet, exige au moins une image uploadée et applique la limite configurée du nombre d’images avant l’enregistrement. Les réglages d’image par défaut sont max_images=20 et max_image_size_mb=5.

Default: auto_approve=0
Submitted project status: pending
Public gallery status filter: approved

• Si auto_approve reste désactivé, le client est redirigé vers My Projects après soumission et le projet attend la modération.
• Si auto_approve est activé, le même flux de soumission enregistre le nouveau projet avec le statut approved.
• La liste admin des projets prend en charge les actions groupées d’approbation, rejet, mise en avant et suppression.
• Le contrôleur public de projet retourne une 404 pour les projets non approuvés sauf si une session de prévisualisation admin est valide.

Pour la plupart des boutiques, laisser l’approbation automatique désactivée est le choix par défaut le plus sûr, car les titres, descriptions et photos soumis par les clients sont vérifiés avant d’apparaître dans la vitrine publique.

Oui, les admins peuvent ajouter des épingles produit aux images de vitrine. Dans PrestaShop, chaque épingle stocke les coordonnées x et y de l’image, un libellé et des ID produit de repli ordonnés, puis résout un produit actif en stock pour l’affichage public du projet.

Le contrôleur admin des épingles ajoute, met à jour, supprime et charge les épingles via AJAX JSON. Les coordonnées doivent être comprises entre 0 et 100 et sont arrondies à deux décimales. Les ID produit de repli sont normalisés, dédupliqués et stockés en JSON, avec le premier ID aussi écrit dans le champ hérité id_product.

Pin fields: id_showcase_image, id_product, product_fallback_ids, x_percent, y_percent, label, position
Resolution order: first active in-stock product, then first active product

• La recherche produit admin retourne des produits actifs par nom, référence ou ID produit, limitée à 20 résultats.
• Sur la page publique du projet, les épingles sont enrichies avec l’URL produit, l’image de couverture et le prix formaté.
• L’endpoint AJAX front des épingles peut aussi rendre le template de miniature produit du thème lorsqu’il est disponible.
• Si tous les produits de repli sont inactifs, l’épingle reste positionnée mais ne se résout vers aucun produit.

Cela permet à un marchand de transformer une image de galerie client en lookbook achetable tout en gardant une liste de repli pour les produits en rupture ou désactivés.

Oui, les votes en double du même client sur un projet sont évités. Dans PrestaShop, la table des votes possède une clé unique projet-client, et le modèle met à jour le vote existant au lieu d'insérer une nouvelle ligne.

Oui. Une page projet Customer Showcase hors prévisualisation peut produire du JSON-LD lorsque le contrôleur projet dispose de suffisamment de données pour le construire. Le contrôleur collecte le titre du projet, une méta-description de page résolue, l’URL canonique du projet, de grandes URL d’images de vitrine et le nom de la catégorie, puis le template front imprime le JSON dans un script application/ld+json lorsque project_schema_json n’est pas vide.

{"@context":"https://schema.org","@type":"ImageGallery","name":"Bathroom renovation","description":"Short project summary","url":"https://shop.example/showcase/bathroom-renovation","mainEntityOfPage":"https://shop.example/showcase/bathroom-renovation","image":["https://shop.example/img/showcase/large/photo.jpg"],"about":"Bathrooms"}

Le type de schema utilisé par le module est ImageGallery, il décrit donc la galerie du projet client plutôt que de revendiquer un schema séparé de produit, service ou avis.

Le contrôleur ignore volontairement le schema en mode prévisualisation : les pages de prévisualisation reçoivent une valeur project_schema_json vide et le helper de prévisualisation applique une gestion noindex. Sur les pages projet normales, les grandes URL d’image sont construites depuis img/showcase/large/ en utilisant le domaine SSL de la boutique et l’URI de base, afin que les données structurées pointent vers des URL d’image absolues plutôt que vers les fichiers miniatures ou moyens utilisés ailleurs sur la page.

• Source de la description : le JSON-LD utilise la méta-description de page résolue. Il s’agit de la méta-description de projet enregistrée lorsqu’elle existe ; sinon le contrôleur génère une description de vitrine client basée sur le titre. La description de projet nettoyée et tronquée n’est qu’un repli final dans buildProjectSchema() si la méta-description résolue est encore vide.
• Champs optionnels : image est inclus uniquement lorsque le projet a des images, et about uniquement lorsque le projet a un nom de catégorie.
• Sécurité de sortie : le JSON est généré avec json_encode(..., JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) et se rabat sur Tools::jsonEncode() si nécessaire, puis Smarty imprime ce JSON préparé sans filtrage dans le script JSON-LD.

Non. Le module implémente uniquement le code Google Customer Reviews côté PrestaShop ; il ne contient aucun code pouvant inscrire, approuver ou rendre une boutique éligible dans Google Merchant Center. Vous devez disposer du programme Google Customer Reviews disponible pour la boutique dans Merchant Center, d’un Merchant ID numérique, et de données de commande acceptées par Google pour l’opt-in de l’enquête.

Ce que le module peut contrôler, c’est l’implémentation front-office une fois ces prérequis remplis : il stocke le Merchant ID, charge l’opt-in d’enquête Google sur la page de confirmation de commande, envoie l’ID commande, l’email client, le pays de livraison, la date de livraison estimée et les valeurs GTIN des produits de la commande, et affiche le badge d’évaluation à la position configurée.

L’envoi des enquêtes, l’approbation du programme, le calcul de la note vendeur et la manière dont les notes apparaissent dans les propriétés Google restent sous le contrôle de Google. Le module peut faire apparaître le code d’opt-in et de badge, mais il ne peut pas approuver la boutique ni forcer Google à afficher des notes.

À l’installation, le module démarre désactivé avec un MERCHANT_ID vide, une position de badge par défaut BOTTOM_RIGHT et une langue de badge en. Le garde front-office exige à la fois ENABLED et un Merchant ID non vide, donc un module installé mais non configuré ne sortira pas le code d’opt-in ou de badge.

• Opt-in de confirmation de commande : le hook ne s’exécute que pour une commande chargée, utilise l’email du client de la commande, lit le pays de livraison depuis l’adresse de livraison, utilise une date de livraison estimée simple de sept jours après aujourd’hui, et passe le ean13 de chaque produit commandé comme valeur GTIN.
• Badge : le hook de fermeture du body affiche le badge d’évaluation Google avec l’ID marchand configuré et l’une des positions prises en charge, comme BOTTOM_RIGHT, BOTTOM_LEFT ou INLINE.
• Limite : si les produits n’ont pas de valeur EAN13, le module envoie quand même l’entrée produit avec un GTIN vide ; c’est hors de PrestaShop que Google décide s’il accepte ou utilise ces données produit.

Pas automatiquement. Le module fournit un aperçu et un historique, mais la source ne contient pas de rollback en un clic restaurant chaque produit à son prix précédent. Avant d’appliquer une mise à jour de masse, utilisez l’aperçu pour inspecter les ID produit affectés, le prix actuel, le nouveau prix calculé et la différence.

• Avant l’application : exportez ou sauvegardez les ID produit affectés et le champ de prix que vous modifiez, surtout si vous mettez à jour un périmètre large comme tous les produits, une catégorie ou un fabricant.
• Après l’application : le module écrit une entrée de log avec la formule, le périmètre, le champ de prix, le nombre affecté, l’employé et la date.
• Si vous devez annuler : utilisez le log pour identifier l’exécution, puis restaurez depuis votre sauvegarde/export. Appliquer la formule inverse peut être risqué, car l’arrondi, les modifications de prix ultérieures et les changements de périmètre produit peuvent rendre le calcul inverse différent des valeurs d’origine.

Pour les changements à haut risque, lancez l’aperçu, exportez le même ensemble de produits, et appliquez la mise à jour pendant une période calme afin que toute correction puisse être faite à partir de valeurs source connues.

L’aperçu et la vraie mise à jour utilisent le même helper de calcul, donc les nombres prévisualisés reposent sur les mêmes actions de formule qui seront ensuite appliquées : increase_percent, decrease_percent, increase_fixed et decrease_fixed. Les diminutions en pourcentage et fixes sont bornées à zéro, et les prix calculés sont arrondis à six décimales avant écriture.

increase_percent:10 => current price * 1.10; decrease_fixed:5 => max(0, current price - 5)

Lors de l’application, le module met à jour à la fois product et product_shop pour le champ sélectionné, et ne prend en charge que price ou wholesale_price. Le sélecteur de périmètre peut cibler tous les produits actifs ou les produits actifs d’une catégorie, d’un fabricant ou d’un fournisseur sélectionné ; les produits inactifs ne sont pas sélectionnés par les requêtes de périmètre.

Le hook autorise les URLs contenant module/mprpasswordprotect ou module-mprpasswordprotect, et il s'arrête aussi lorsque le paramètre module de la requête correspond au nom du module.

La classe de configuration expose l'activation de la protection par mot de passe, le mot de passe, le message, le bypass employé/maintenance et les interrupteurs noindex via le formulaire OptionsManager.

Oui. L'installation crée une page meta non configurable pour module-mprpasswordprotect-gate avec le titre Password Required et l'URL rewrite password.

Le contrôleur gate définit un flag d'erreur et réaffiche le même template de mot de passe, qui montre le message traduit Incorrect password. Please try again..

Non. Le contrôleur de renvoi envoie l'email de confirmation de commande reconstruit et enregistre un message privé, mais il n'appelle aucune logique de changement de statut de commande.

Avant l’envoi, le contrôleur AJAX exige un ID commande et un token de module, valide les deux, charge la commande et le client, puis appelle le Mail::Send() standard de PrestaShop avec le template order_conf depuis _PS_MAIL_DIR_ et l’ID boutique original de la commande.

• Produits : il reconstruit les lignes produit HTML et texte brut depuis $order->getProducts(), avec le nom produit, la référence optionnelle, la quantité, le prix unitaire TTC et le prix total TTC.
• Adresses : les blocs livraison et facturation sont générés avec AddressFormat::generateAddress(), avec un repli assemblé depuis la société, le nom, la rue, le code postal et la ville si le formatage d’adresse échoue.
• Piste d’audit : après un renvoi réussi, il ajoute un message privé à la commande et écrit une entrée de log PrestaShop ; si l’envoi mail échoue, il retourne une erreur JSON plutôt que de changer le statut de la commande.

Le module envoie le template standard PrestaShop order_conf via Mail::Send, après reconstruction des lignes produit, adresses, totaux, transporteur et valeurs de paiement depuis la commande.

Après un envoi réussi, le module crée un message privé de commande indiquant que la confirmation a été renvoyée, avec l'email destinataire et l'horodatage.

Le module doit être activé et PHONE_NUMBER doit être renseigné. Son validateur de configuration obligatoire attend uniquement des chiffres et un signe plus initial optionnel, par exemple +1234567890.

Oui. Le trait de chat partagé prend en charge les filtres de page all, product, category et checkout via le réglage PAGES.

Non. Le template rendu crée un lien normal vers Signal et utilise le CSS local du module ainsi qu'un SVG inline pour le bouton. Aucun chargeur JavaScript Signal externe n'est présent dans le template du hook.

Si DELAY est supérieur à zéro, le template masque d'abord le widget et utilise un timeout pour l'afficher après le nombre de secondes configuré.

Le module stocke le choix d’affichage du visiteur dans le cookie léger mpr_tax_display et, tôt dans le contrôleur front, prépare le cache d’affichage des prix par groupe de PrestaShop afin que les calculs de prix produit rendent les prix TTC ou HT pour cette requête. Il ne met pas à jour les paniers, commandes, règles fiscales, factures ou groupes clients en base de données.

Sur les pages produit/listing, il injecte aussi des données cachées .mpr-tax-prices avec les prix TTC et HT préformatés, afin que JavaScript puisse remplacer immédiatement les prix visibles. Si une page ne contient pas de données de prix produit injectées, comme certaines pages panier ou checkout, le script enregistre la préférence et recharge afin que PrestaShop rende la page avec le mode d’affichage choisi.

Le total checkout et le montant de taxe restent calculés par PrestaShop à partir du panier, de l’adresse, des règles fiscales et du flux checkout normal. Ce module affecte la préférence d’affichage et les libellés de prix, pas le calcul fiscal.

Activez le module pour afficher un bouton fixe de retour en haut sur le front-office PrestaShop. Le code sort le bouton depuis les hooks de footer/fermeture du body, évite le rendu en double lorsque les deux hooks sont disponibles, et inclut le CSS et le JavaScript nécessaires au bouton.

Après installation, les valeurs par défaut sont activé, afficher après 300 pixels, style circle et position right. Le module enregistre displayFooter, displayFooterAfter et displayBeforeBodyClosingTag ; le premier hook pris en charge que votre thème rendra affichera le bouton, et les appels de hooks suivants retourneront une chaîne vide car buttonRendered est déjà défini.

Le template crée un seul bouton fixe avec l’ID mprb2t-btn, un label/titre accessible, un SVG inline de flèche vers le haut, et du CSS/JavaScript inline. Il n’y a pas de règle par produit, catégorie ou page dans ce module ; l’activer rend donc le bouton disponible partout où le thème exécute l’un de ces hooks de footer/fermeture du body.

Oui, vous pouvez définir la distance de défilement avant l’apparition du bouton. La configuration PrestaShop stocke une valeur Show After en pixels, et le JavaScript front-office compare ce seuil avec window.pageYOffset avant d’ajouter ou retirer la classe visible du bouton.

Le seuil par défaut est 300 pixels, et le champ admin est enregistré sous SHOW_AFTER. La valeur est assignée à Smarty sous mprb2t_show_after et devient la variable JavaScript threshold dans le template.

if (window.pageYOffset > threshold) { btn.classList.add('mprb2t-visible'); } else { btn.classList.remove('mprb2t-visible'); }

L’écouteur de scroll est enregistré comme passif et toggleBtn() s’exécute aussi une fois immédiatement après le chargement du script, afin que l’état du bouton soit correct même lorsqu’un acheteur arrive sur une page avec une ancre ou revient à une position déjà défilée.

Oui, le module prend en charge les options de style présentes dans sa configuration : forme ronde ou carrée et position à gauche ou à droite de l’écran. Le template PrestaShop applique ces valeurs au CSS inline ; le code n’inclut pas de sélecteur de couleur ni de règles de ciblage par page.

Les valeurs installées par défaut sont STYLE=circle et POSITION=right. Dans le template, POSITION=left écrit left: 30px ; toute autre valeur configurée suit la branche droite et écrit right: 30px. Pour la forme, STYLE=circle écrit border-radius: 50%, tandis que l’option carrée utilise un petit rayon de 6px.

• Dimensions fixes : le bouton fait 48 par 48 pixels, est fixé en bas du viewport et utilise z-index: 9999.
• Couleurs intégrées : le template utilise un fond sombre, une icône blanche et un état hover plus sombre. Ces valeurs sont codées en dur dans le template actuel.
• Limite pratique : il n’y a pas de réglage pour le choix de l’icône, la position par appareil, la durée d’animation ou les couleurs personnalisées dans la classe de configuration.

Oui, cliquer sur le bouton fait remonter la page en douceur jusqu’en haut. Le script front-office PrestaShop écoute le clic sur le bouton, empêche l’action par défaut, et appelle window.scrollTo avec top défini à 0 et behavior défini à smooth.

Le gestionnaire de clic est court et direct : il est lié au bouton généré mprb2t-btn, appelle e.preventDefault(), puis demande au navigateur de défiler vers le haut avec le défilement fluide natif.

window.scrollTo({ top: 0, behavior: 'smooth' });

Comme le module utilise le comportement natif scrollTo du navigateur plutôt qu’une boucle d’animation personnalisée, il reste léger et ne stocke aucun état de scroll. Le bouton ne devient visible qu’après le seuil configuré ; cliquer dessus ne recharge pas la page et ne change pas l’URL.

Utilisez MPR Compare pour ajouter une liste de comparaison côté client à PrestaShop. Les ID produit sélectionnés sont stockés dans le localStorage du navigateur sous la clé mprcompare, tandis que le module interroge les détails produit par AJAX uniquement lorsque la page de comparaison ou les miniatures flottantes ont besoin de données.

Le commentaire d’en-tête du module décrit la conception comme zéro stockage en base de données et zéro cookie pour l’interaction sur les pages de listing. Les hooks de liste produit et de page produit sortent des boutons statiques avec un attribut data-id-product ; le script navigateur ajoute ou retire ces ID de localStorage et met à jour localement l’état des boutons, compteurs et barre flottante.

Le serveur n’intervient que lorsque de vraies données produit sont nécessaires. La page de comparaison lit les ID depuis localStorage et les poste au contrôleur front actions avec action=getProducts, tandis que les miniatures flottantes appellent action=getProductImage. Vider la liste de comparaison enregistre simplement un tableau vide dans localStorage.

Le tableau de comparaison peut afficher le nom du produit, l’URL, l’image de couverture, le prix actuel, l’ancien prix, la description courte, la référence, le fabricant, le poids, l’état du stock, les caractéristiques, l’état et l’EAN13 lorsque ces valeurs existent. Le contrôleur AJAX ignore les produits PrestaShop inactifs.

Les données viennent d’objets Product chargés dans la langue et la boutique courantes. Les prix sont formatés depuis Product::getPriceStatic() avec taxe activée ; l’ancien prix n’est retourné que lorsque le prix sans réduction est supérieur au prix actuel. Les images de couverture utilisent medium_default pour le tableau de comparaison et cart_default pour l’endpoint de miniature flottante.

• Caractéristiques : le contrôleur appelle getFrontFeatures() et retourne chaque paire nom/valeur de caractéristique, tandis que le script front regroupe les noms de caractéristiques uniques en lignes de comparaison.
• Disponibilité : l’état du stock est retourné depuis Product::getQuantity($idProduct) > 0, donc c’est un indicateur simple en stock/hors stock.
• Données manquantes : les champs optionnels comme fabricant, référence, poids, EAN13 et ancien prix sont vides ou omis dans le tableau lorsque PrestaShop n’a aucune valeur pour eux.

Oui, la taille maximale de comparaison est configurable. Le réglage MAX_ITEMS vaut quatre par défaut à l’installation, le script front refuse d’ajouter plus d’articles une fois la limite atteinte, et l’endpoint produit AJAX découpe les ID entrants selon le même maximum configuré.

À l’installation, MAX_ITEMS est créé avec la valeur 4 ; le contrôleur admin l’enregistre avec un minimum de 1. Cette valeur est envoyée au navigateur dans mprCompareConfig.maxItems et également assignée au template de page de comparaison sous maxItems.

var max = config.maxItems || 4;

L’application des doublons est également côté client : si le produit est déjà dans localStorage, la fonction d’ajout retourne sans l’ajouter de nouveau. L’endpoint AJAX découpe quand même la liste d’ID demandée au maximum configuré, donc une requête modifiée manuellement ne peut pas faire charger plus de produits que la limite configurée sur la page de comparaison.

Oui, il ajoute des contrôles de comparaison via des hooks PrestaShop. Le module affiche des boutons sur les listes de produits et les pages produit, un compteur de navigation, et une barre flottante de comparaison optionnelle avec miniatures produit, contrôles de suppression et lien vers la page de comparaison.

Pour PrestaShop 1.7 et plus récent, le module enregistre les hooks media, page produit, navigation et fermeture du body ; pour les anciens thèmes 1.6, il utilise les hooks hérités header, bouton produit, nav et footer. Les boutons de listing produit sont des liens statiques avec js-mprcompare-toggle, les contrôles de page produit sont des boutons, et les deux utilisent la même valeur data-id-product pour le gestionnaire de liste JavaScript.

La barre flottante est contrôlée par le réglage SHOW_FLOATING, activé par défaut. Quand des produits sont sélectionnés, le script affiche la barre, charge les données de miniature par AJAX si elles ne sont pas déjà en cache, rend les boutons de suppression pour chaque produit, et garde le compteur d’en-tête et le compteur flottant synchronisés avec le nombre d’ID dans localStorage.

Les clients peuvent soumettre des demandes de fonctionnalités depuis l’onglet de page produit lorsque le module et l’affichage produit sont activés. Dans PrestaShop, le contrôleur AJAX valide le token, le produit, le titre, la description et les champs d’identité invité, puis limite les soumissions par produit et par IP.

L’onglet produit est ajouté uniquement lorsque ENABLED et SHOW_ON_PRODUCT sont activés et que le module peut résoudre l’ID produit. L’onglet commence comme une liste résumé/lazy, puis le script front demande la première page d’éléments lorsque l’onglet devient visible, en utilisant la valeur configurée REQUESTS_PER_PAGE, qui vaut 10 par défaut.

• Sécurité : les actions d’écriture exigent un token CSRF depuis Tools::getToken(false). Le JavaScript récupère un token avec action=getToken si le balisage initial de l’onglet n’en contient pas déjà un.
• Validation : le titre doit faire au moins 5 caractères, la description au moins 10 caractères, les invités doivent fournir un nom et un email valide, et les clients connectés utilisent automatiquement le nom et l’email de leur compte.
• Limite de fréquence : le contrôleur autorise au plus 3 soumissions pour le même produit et la même adresse IP pendant la journée précédente.
• Données stockées : la demande enregistre le produit, l’identité client ou invité, le texte de description nettoyé, la boutique, la langue, l’adresse IP, le statut, les horodatages et un nombre initial de votes de 1.

Oui, les demandes peuvent exiger une connexion client et une approbation admin. Dans PrestaShop, REQUIRE_LOGIN bloque les soumissions invitées, REQUIRE_APPROVAL stocke les nouvelles demandes comme submitted, et les listes publiques masquent les éléments submitted aux non-soumissionnaires jusqu’à ce qu’ils passent à un statut public.

Les valeurs par défaut sont adaptées aux marchands : REQUIRE_LOGIN est désactivé, mais REQUIRE_APPROVAL est activé. Avec l’approbation activée, le contrôleur enregistre les nouveaux éléments en submitted ; sans elle, les nouveaux éléments démarrent en under_review.

La visibilité est gérée dans le modèle, pas seulement dans le template. Les listes produit normales excluent les éléments declined et submitted, puis rajoutent les éléments submitted uniquement lorsque le visiteur actuel correspond au soumissionnaire par ID client ou adresse IP. La requête de roadmap publique indexable exclut aussi submitted et declined, donc les idées en attente ne deviennent pas du contenu SEO public.

Pour le soumissionnaire, le JavaScript peut afficher un avis d’attente : Your request is pending review and only visible to you. Cela rend le workflow d’approbation clair sans exposer les demandes non vérifiées aux autres acheteurs.

Oui, le vote peut être activé et le vote invité peut être autorisé ou bloqué. Dans PrestaShop, l’endpoint de vote bascule un vote par demande, utilise l’ID client ou un suivi basé sur l’IP, et retourne une exigence de connexion lorsque le vote invité est désactivé.

Le vote est activé par défaut, tandis que le vote invité est désactivé par défaut. Lorsque le vote invité est désactivé et que le visiteur n’est pas connecté, la réponse AJAX inclut require_login, et le script front redirige vers le lien de connexion lorsqu’il existe.

Le stockage des votes est une table séparée mprfeaturerequest_vote. Les votants connectés sont associés par id_customer ; les invités, lorsqu’ils sont autorisés, sont associés par adresse IP. Appeler l’endpoint à nouveau retire le vote en supprimant la ligne existante, tandis qu’un nouveau vote insère une ligne et marque l’état voted retourné comme true.

Après chaque bascule, le module recalcule le compteur de la demande en incrémentant ou décrémentant vote_count avec une mise à jour base de données qui utilise GREATEST(0, ...), afin que le nombre affiché ne puisse pas passer sous zéro. Les demandes nouvellement soumises reçoivent aussi un vote automatique de leur auteur, ce qui explique le compteur initial à 1.

Oui, le hub principal de la roadmap peut être indexable lorsque le module Feature Requests est activé, que la page roadmap est activée et que le réglage INDEX_ROADMAP_PAGE autorise l’indexation. Les pages de détail, les pages roadmap propres à un produit et les endpoints AJAX sont volontairement exclus de l’index.

• URL propre du hub roadmap, par exemple /feature-requests : le type de page roadmap utilise la politique SEO du module. Lorsque l’indexation est activée, robots se résout en index, follow.
• Hub roadmap avec paramètres de filtre/tri pris en charge, par exemple /feature-requests?status=planned : le contrôleur redirige ceux-ci en 301 (status, sort, view, search, page) vers le hub canonique /feature-requests, afin que les doublons ne soient jamais indexés. Toute autre chaîne de requête non redirigée est rendue en noindex, follow.
• Page propre à un produit, par exemple /feature-requests/module/my-product : le type de page module est configuré comme non indexable, donc robots se résout en noindex, follow.
• Page de détail d’une demande, par exemple /feature-requests/some-request : le type de page detail est configuré comme non indexable, donc robots se résout en noindex, follow. Les réponses 404 des pages de détail envoient aussi X-Robots-Tag: noindex, nofollow, noarchive.
• Endpoint AJAX, par exemple module/mprfeaturerequest/ajax : le contrôleur envoie X-Robots-Tag: noindex, nofollow, noarchive.

Le hook de sitemap suit la même logique : il n’ajoute l’URL du hub roadmap que lorsque le module, l’affichage de la roadmap, l’inclusion dans le sitemap et la politique SEO l’autorisent tous.

Le chemin de code se limite au rendu du widget JivoChat depuis displayBeforeBodyClosingTag. Il vérifie que le module est activé, qu’un WIDGET_ID existe, que la page actuelle correspond au filtre de page configuré, et que l’affichage mobile est autorisé lorsque le visiteur est sur mobile.

Lorsqu’il s’affiche, le template injecte le script externe JivoChat depuis //code.jivosite.com/widget/{widget_id}, éventuellement après le délai configuré. Si PASS_USER_DATA est activé et que le client est connecté, il définit jivo_onLoadCallback() et appelle jivo_api.setContactInfo() avec le nom et l’email du client.

Il n’y a aucune table, aucun modèle ni contrôleur de module pour les messages ou transcriptions de chat dans cette source. Supprimer ou désactiver le module PrestaShop arrête l’intégration du widget, mais n’exporte, ne supprime ni ne gère l’historique des conversations détenu par JivoChat.

hookPaymentOptions() affiche Pay by Invoice uniquement lorsque tous les contrôles d’éligibilité réussissent. Le module doit être actif, le réglage du module doit être activé, le panier doit appartenir à un client connecté, et l’objet client doit se charger correctement.

• Contrôle client : les paniers invités et les enregistrements client invalides ne retournent aucune option de paiement.
• Contrôle groupe : le client doit appartenir à au moins un groupe assigné à une condition de paiement active.
• Contrôle condition : seules les conditions actives liées via mpr_payment_term_group sont retournées, triées par position et jours.
• Contrôle crédit : le module prend la limite de crédit la plus élevée parmi les groupes du client ; 0 signifie illimité. Sinon, les commandes différées impayées plus le total du panier courant doivent rester dans la limite.
• Contrôle validation : le contrôleur de validation front répète le contrôle de condition et de crédit avant de créer la commande, donc une option de checkout périmée ne peut pas contourner les règles.

Si un contrôle échoue, le module retourne une liste vide d’options de paiement et PrestaShop ne propose tout simplement pas Pay by Invoice pour ce panier.

Les conditions disponibles sont calculées depuis les groupes client du panier courant. Le service interroge les conditions actives jointes via mpr_payment_term_group, utilise la langue courante pour le nom et la description de la condition, et trie le résultat par position puis days. Les conditions par défaut créées à l’installation incluent Due on Receipt plus Net 15, Net 30, Net 60 et Net 90.

Le template de checkout affiche ensuite chaque condition disponible comme option radio, avec la première sélectionnée, son badge couleur, le texte des jours d’échéance et la description optionnelle. Si la limite de crédit n’est pas illimitée, il affiche aussi le crédit disponible et le montant différé restant dû avant la liste des conditions.

Lorsque le client soumet l’option de paiement, le contrôleur de validation lit le mpr_pt_term_id sélectionné, recalcule le total du panier, appelle à nouveau canPlaceDeferredOrder(), crée la commande PrestaShop dans l’état configuré OS_AWAITING, avec repli vers bankwire s’il manque, puis crée un enregistrement mpr_deferred_order avec le montant, le client, la boutique et la date d’échéance basée sur les jours de la condition sélectionnée.

La date d’échéance est calculée en ajoutant le nombre de jours de la condition sélectionnée à la date de création de la commande différée. Les conditions installées par défaut incluent Due on Receipt / Net 0, Net 15, Net 30, Net 60 et Net 90.

• Si la commande est créée le 2026-06-17 avec Net 0, la date d’échéance est 2026-06-17.
• Si la commande est créée le 2026-06-17 avec Net 15, la date d’échéance est 2026-07-02.
• Si la commande est créée le 2026-06-17 avec Net 30, la date d’échéance est 2026-07-17.

Le module stocke le résultat comme une date au format Y-m-d, pas comme un horodatage avec heure de la journée. Le calcul utilise la date d’exécution actuelle du serveur/de la boutique PHP lorsque la commande différée est créée, donc les commandes passées près de minuit suivent la limite de date côté serveur plutôt que l’horloge locale du client. Les changements d’heure d’été n’ajoutent pas une heure à la date d’échéance stockée, mais ils peuvent compter indirectement si la commande est créée autour d’une limite de date.

Au checkout, le client sélectionne une condition de paiement via mpr_pt_term_id. Le module valide que la condition est active, appartient à l’un des groupes du client et respecte la limite de crédit effective du client avant de créer la commande PrestaShop. Ce n’est qu’après la validation de la commande qu’il crée l’enregistrement de paiement différé avec la condition sélectionnée, le total TTC de la commande et la date d’échéance calculée.

$dueDate = date('Y-m-d', strtotime('+' . (int) $term->days . ' days'));

La valeur stockée est copiée dans mpr_deferred_order.due_date au moment de la commande. Modifier plus tard le nombre de jours d’une condition de paiement ne recalcule pas les dates d’échéance des commandes déjà existantes. Les contrôles d’impayé comparent la date d’échéance stockée avec la date serveur courante ; une facture impayée due aujourd’hui est donc encore due aujourd’hui, et ne devient en retard qu’après cette date.

La valeur de limite de crédit est par groupe client, pas par client individuel. Le module stocke les limites dans mpr_pt_credit_limit, où id_group est la clé primaire, et les conditions de paiement elles-mêmes sont aussi assignées aux groupes via mpr_payment_term_group.

Pour un client appartenant à plusieurs groupes, le service récupère tous ses groupes et utilise MAX(credit_limit) parmi eux. Exemple : si Ana appartient à Retail sans limite configurée, B2B Silver avec 1000.00, et B2B Gold avec 2500.00, sa limite de crédit effective est 2500.00.

Une limite configurée à 0 est traitée comme illimitée par le service de checkout. Lorsqu’une vraie limite existe, le module soustrait les commandes différées impayées de ce client dans la boutique courante et n’affiche les conditions Pay by Invoice que lorsque outstanding + cart total reste dans la limite effective du groupe.

Les limites de crédit et la disponibilité des conditions sont liées mais séparées. Assigner une limite à un groupe ne rend pas toutes les conditions de paiement disponibles à elle seule ; la condition doit aussi être active et assignée à au moins l’un des groupes du client. De même, assigner une condition à un groupe sans vraie limite de crédit signifie que le groupe peut utiliser la condition tant que la limite effective se résout comme illimitée ou qu’un autre groupe fournit une limite suffisante.

Le montant restant dû est calculé depuis les lignes impayées dans mpr_deferred_order pour le même client et la boutique courante. Les lignes déjà marquées payées sont exclues, et le total du panier utilisé pour la nouvelle commande est le total TTC de la commande. Si le client dépasse la limite effective, le service de checkout retire toutes les conditions différées des options de paiement disponibles et le contrôleur de validation rejette un paiement différé soumis même si quelqu’un poste la condition manuellement.

L’installation crée un état de commande nommé Awaiting Deferred Payment, stocke son ID dans OS_AWAITING, et le contrôleur de validation utilise cet état lorsqu’il appelle validateOrder() pour les commandes Pay by Invoice. Si l’état stocké manque, le contrôleur se rabat sur l’état bank-wire de PrestaShop.

• logable = true signifie que PrestaShop traite la commande comme une commande valide passée pour les flux d’historique de commande et de statistiques, même si le paiement est encore en attente.
• invoice = true et pdf_invoice = true signifient que la génération de facture est activée pour l’état de commande différée.
• paid = false signifie que l’état de commande ne marque pas la commande comme payée ; le module suit le règlement séparément dans mpr_deferred_order.is_paid.

Lorsque l’enregistrement différé est créé, is_paid commence à 0. La méthode markAsPaid() du modèle de commande différée définit plus tard is_paid à 1 et enregistre paid_date, sans changer la signification de l’état initial de la commande.

L’état installé appartient au module, utilise le libellé Awaiting Deferred Payment dans toutes les langues, et est créé avec send_email = false, unremovable = false, et une valeur de couleur bleue. La page de retour paiement peut ensuite afficher la condition de paiement sélectionnée, le montant dû et la date d’échéance pendant que la commande reste impayée du point de vue de l’état de paiement PrestaShop.

Il y a un suivi back-office important : lorsqu’un admin marque une commande différée comme payée via le contrôleur des commandes différées du module, le module met d’abord à jour mpr_deferred_order. Si la commande PrestaShop liée est encore dans l’état d’attente du module et que l’état payé standard PS_OS_PAYMENT existe, il déplace aussi la commande PrestaShop vers cet état payé. Si la commande a déjà été déplacée vers un autre état, le module ne l’écrase pas aveuglément.

Une notification réelle est construite à partir de commandes PrestaShop valides dans la boutique courante, limitée par l'âge maximal de commande configuré et les règles d'inclusion ou d'exclusion produit. Elle utilise le produit commandé, la ville de livraison et le prénom masqué.

Non. Les notifications de vente générées ne sont pas de vraies commandes PrestaShop et ne sont pas écrites dans la table des commandes. Le module a trois modes de notification :

• Commandes réelles uniquement : affiche les commandes valides récentes de PrestaShop, avec noms de clients masqués, ville, données produit, image produit, prix et temps relatif.
• Générées uniquement : construit des notifications d’apparence réaliste à partir de produits actifs du catalogue plus des listes de noms et villes configurées ou intégrées. Ce sont des messages d’affichage, pas des commandes.
• Mixte : utilise d’abord les notifications de commandes réelles et complète les emplacements restants avec des notifications générées lorsqu’il n’y a pas assez de commandes réelles récentes.

Le mode d’installation par défaut est mixed. En mode mixte, si les notifications réelles sont moins nombreuses que le nombre demandé, le code génère automatiquement des compléments ; il n’y a pas d’interrupteur séparé de remplissage généré dans le mode mixte. Si chaque notification doit correspondre à un achat réel, passez le module en mode Real orders only et assurez-vous que l’âge maximal des commandes et les filtres produit sont assez larges pour retourner des commandes récentes.

Les notifications réelles sont chargées depuis les commandes PrestaShop valides de la boutique courante, limitées par l’âge maximal configuré des commandes. L’âge maximal par défaut est de 72 heures. Les listes d’inclusion et d’exclusion de produits sont appliquées avant le retour de la notification, et le nom client affiché est masqué au lieu de montrer le prénom complet.

Les notifications générées sont construites depuis des produits actifs du catalogue. Le module sélectionne les données produit, calcule un prix d’affichage, essaie d’utiliser l’image de couverture du produit, choisit un nom et une ville depuis ses listes, et crée un temps relatif comme un nombre récent de minutes. Cela se produit au moment de l’affichage via l’endpoint de notifications front-office ; cela ne crée pas de paniers, commandes, clients, détails de commande, paiements ou lignes d’historique de commande.

Le toast front-end étiquette les notifications comme Verified Purchase dans le template d’affichage, y compris les notifications générées. Ce libellé fait partie de la présentation du pop-up, pas une preuve qu’une notification générée provient d’une vraie commande. Pour les boutiques à conformité stricte ou sensibles à l’audit, utilisez le mode Real orders only.

Oui. La configuration accepte des listes d'IDs produit à inclure et à exclure, séparées par des virgules. Ces filtres s'appliquent à la sélection des lignes de commandes réelles comme à la sélection des produits pour les notifications générées.

Le front controller notifications renvoie du JSON avec un header de réponse noindex lorsque le module est activé. Le script navigateur récupère ce flux et rend les notifications toast selon les réglages de timing.

Non, le module crée le point d’entrée front-office vers Telegram. Après le clic de l’acheteur, Telegram gère la conversation dans l’application Telegram ou l’expérience web. Cela garde le module simple et évite de créer une deuxième boîte de réception de messages dans PrestaShop.

Le widget affiche un lien Telegram fixe en utilisant le nom d’utilisateur configuré. Si un message prérempli optionnel est configuré, le module l’ajoute à l’URL https://t.me/... et remplace {url} par l’URL de la page courante avant d’envoyer l’acheteur vers Telegram. Le navigateur ouvre Telegram dans un nouvel onglet ou dans le contexte de l’application ; le chat lui-même n’est pas intégré dans la page PrestaShop.

Le module ne stocke pas les messages Telegram entrants, ne crée pas de fils de service client PrestaShop, et n’exécute pas de webhook Telegram ni de boîte bot dans le back-office. L’historique des conversations, les réponses, les pièces jointes et les notifications restent dans Telegram.

L’affichage est contrôlé par les réglages du module. Le widget ne s’affiche que lorsque le module est activé et qu’un nom d’utilisateur Telegram valide est présent. Vous pouvez aussi contrôler la position front-office, le style icône ou barre, le texte d’appel à l’action, la couleur, la taille, la marge, l’infobulle, l’animation, le délai d’affichage, la visibilité mobile et le périmètre de pages comme toutes les pages, les pages produit, les pages catégorie ou les pages checkout.

Oui, Weekly Flash Sale peut publier automatiquement, mais uniquement via des modules de publication compatibles. La tâche cherche mprinstagramintegration avec publishToInstagram(), mprfacebookpostsintegration avec publishToFacebook(), et mprxintegration avec publishToX(). Elle construit chaque légende à partir des templates Instagram, Facebook et X en utilisant des placeholders comme {product_name}, {original_price}, {sale_price}, {discount}, {code} et {product_url}.

• ok:... signifie que le publisher a retourné un résultat de plateforme, donc l’envoi a été traité comme réussi.
• skipped signifie que le module de plateforme est manquant ou inactif, que la méthode de publication requise manque, ou que la légende de cette plateforme est vide.
• FAIL signifie que la méthode de publication a retourné false.
• FAIL:message signifie que le publisher a lancé une exception, et le message après le préfixe est enregistré pour diagnostic.
• dry-run est un statut global d’exécution de test. La tâche retourne avant de créer la règle panier, de publier ou d’écrire l’historique de vente.
• disabled est retourné lorsque la vente hebdomadaire est désactivée et que l’exécution n’est pas un dry run.

Pour les exécutions réelles, les résultats par plateforme sont stockés dans mprweeklysale_history sous ig_result, fb_result et x_result, avec le produit, la remise, le code généré et les dates de vente.

La publication automatique fait partie de la tâche de flash sale. Une vraie exécution choisit d’abord un produit actif qui n’a pas été utilisé récemment selon la fenêtre d’historique configurée, crée une règle panier pour la remise, puis appelle les modules de publication sociale disponibles. La configuration par défaut utilise une remise de 50 %, une durée de 24 heures, le préfixe de code FLASH, une fenêtre d’historique de 12 semaines, et un planning hebdomadaire le mercredi à 08:00.

La règle panier générée est spécifique au produit, active, mise en avant, limitée à une quantité 1000 et à une quantité par utilisateur 1. Les légendes sont construites après la préparation du prix soldé, du code de remise, de l’URL produit et de l’image produit. La légende X est raccourcie pour respecter la limite de la plateforme, et la légende Instagram est aussi plafonnée avant publication.

La publication automatique exige donc plus que l’activation de Weekly Flash Sale. Le module d’intégration correspondant doit être installé, actif et exposer la méthode de publication attendue, et la tâche cron planifiée doit s’exécuter avec le bon token. Si un module de plateforme manque, la vente peut quand même être créée et la plateforme manquante est enregistrée comme skipped.

Utilisez le slider de page d’accueil du module pour afficher un carrousel hero sur le hook displayHome de PrestaShop. Le code résout le slider par défaut via l’identifiant homepage, charge ses bannières actives, joint les champs texte de la langue/boutique courante lorsqu’ils existent, et sort le carrousel uniquement lorsque des images exploitables existent.

À l’installation, le module initialise un slider actif avec l’identifiant homepage. Pour afficher un hero sur la page d’accueil, créez ou modifiez des bannières pour ce slider, uploadez au moins une image valide, gardez la bannière active, et assurez-vous que le module reste accroché à displayHome. Le hook appelle le même renderer de widget avec slider = homepage, donc la sortie de page d’accueil suit les mêmes règles que les widgets intégrés.

La requête du carrousel charge les bannières actives assignées au slider sélectionné et les trie par position puis par ID bannière. La ligne langue/boutique est jointe avec un LEFT JOIN, donc le titre, le sous-titre et le texte CTA sont pris depuis la langue et la boutique courantes lorsque cette ligne existe, mais une bannière n’est pas rejetée simplement parce que la ligne texte langue/boutique manque. Une bannière image seule non traduite peut donc quand même s’afficher.

Si aucune bannière active n’a de fichier image desktop ou mobile existant, le module retourne une chaîne vide au lieu d’afficher une zone hero cassée.

Le comportement d’affichage vient de la configuration du module. La vitesse par défaut est 5000 millisecondes, l’autoplay est activé, les contrôles et indicateurs sont activés, la transition est slide, le style Ken Burns est activé, et la hauteur par défaut est 500. Le template donne aussi au premier slide un chargement eager et une priorité de récupération, tandis que les slides suivants sont chargés en lazy pour réduire le poids initial de la page.

Oui, chaque bannière peut stocker une image desktop et une image mobile optionnelle pour PrestaShop. Le template du carrousel sort des sources picture responsives, utilise l’image mobile sur les petits écrans, et ajoute des sources AVIF ou WebP lorsque des fichiers correspondants existent à côté des images configurées.

L’image mobile est destinée aux écrans étroits et est émise avec une condition media max-width: 767px. L’image desktop reste l’image de repli normale du slide, il est donc préférable d’uploader une image desktop pour chaque bannière et d’ajouter une image mobile lorsque le recadrage doit changer sur téléphone.

Le module ne convertit pas les images pendant le rendu. Il vérifie si des fichiers voisins avec le même nom de base et des extensions .avif ou .webp existent déjà, puis ajoute ces sources lorsqu’elles sont présentes. Si ces fichiers optimisés ne sont pas sur disque, le carrousel se rabat sur les chemins d’image originaux uploadés.

Une bannière sans fichier image desktop ni mobile est ignorée avant rendu. Cela empêche les slides vides. Si seule une image mobile existe, la bannière peut quand même passer le contrôle de fichier, mais les visiteurs desktop peuvent ne pas avoir de vraie image desktop de repli ; la configuration marchand doit donc considérer l’image desktop comme base et l’image mobile comme remplacement responsive optionnel.

Oui, le module implémente le rendu de widget PrestaShop pour les sliders en dehors de la page d’accueil. Un template peut appeler le widget avec un slider_id numérique ou avec un identifiant de slider stocké dans la table de sliders du module.

{widget name='mprbannerrevolution' slider_id=2} {widget name='mprbannerrevolution' slider='homepage'} {widget name='mprbannerrevolution' slider='landing-sale'}

Si aucun paramètre n’est passé, le module résout le slider par défaut homepage. Le code n’assigne pas automatiquement les sliders aux pages CMS ; il résout le slider depuis les paramètres du widget, puis affiche uniquement les bannières actives de ce slider qui disposent d’une image desktop ou mobile disponible.

La version par identifiant ne fonctionne que pour les sliders actifs, car la recherche utilise le contrôle actif de la table de sliders. Le chemin numérique slider_id charge cet ID exact de slider. Une fois le slider résolu, le même pipeline de rendu que la page d’accueil est utilisé : langue courante, boutique courante, bannières actives, contrôles d’existence de fichiers, sources responsives, réglages de carrousel et template de carrousel partagé.

Un commentaire de code mentionne slider_cms, mais le résolveur implémenté gère slider_id, slider, et le slider homepage par défaut. Pour les pages CMS ou landing pages, utilisez un appel widget explicite dans le contenu de page ou le template du thème au lieu d’attendre que le module associe automatiquement des pages CMS à des sliders.

Vous pouvez configurer le contenu réel de bannière utilisé par le carrousel PrestaShop : titre traduit, sous-titre, texte CTA et URL CTA. Chaque bannière stocke aussi la couleur d’overlay, l’opacité d’overlay, l’alignement du texte, l’état actif, la position, l’image desktop et l’image mobile optionnelle.

Les champs de contenu sont multilingues, donc le titre de bannière, le sous-titre, le texte du bouton et l’URL du bouton peuvent varier selon la langue. Le titre est utilisé comme titre principal du slide, le sous-titre apparaît dessous, et le bouton CTA n’apparaît que lorsque le texte CTA et l’URL CTA sont tous les deux présents pour cette langue.

Les contrôles visuels sont stockés avec la bannière elle-même. La couleur d’overlay est noire par défaut, l’opacité d’overlay est une valeur en pourcentage, et l’alignement du texte prend en charge left, center et right. Le drapeau actif contrôle si la bannière peut apparaître, et la valeur de position contrôle l’ordre dans le slider sélectionné.

Les champs image sont les médias réellement utilisés par le carrousel. L’image desktop est l’image principale du slide, et l’image mobile optionnelle donne un recadrage différent aux téléphones. Le flux d’upload admin accepte les formats web courants comme JPG, PNG, WebP et GIF, tandis que le renderer front-office peut aussi ajouter des sources AVIF ou WebP si des fichiers optimisés correspondants existent sur disque.

Les champs texte vides sont autorisés. Une bannière peut donc servir de slide purement visuel, de hero avec texte sur image, ou de slide promotionnel avec bouton, selon les champs traduits remplis.

Oui, les messages soumis sont stockés dans PrestaShop. Le processeur crée un enregistrement de soumission avec statut, indicateur de spam, adresse IP, user agent, contexte client ou invité, puis stocke chaque valeur de champ soumise dans la table de données de soumission du module.

La ligne principale de soumission est enregistrée dans mprcontactform_submission. Elle inclut l’ID formulaire, l’ID boutique, l’ID client lorsque le visiteur est connecté, le nom client, l’email client, l’adresse IP, le user agent, le statut, l’indicateur spam, la raison spam et la date de création. Les soumissions invitées sont enregistrées avec l’ID client 0.

Les réponses individuelles sont enregistrées séparément dans mprcontactform_submission_data. Chaque ligne stocke l’ID soumission, l’ID champ, le nom du champ et la valeur de champ soumise. Cela permet au module de séparer l’en-tête de soumission des champs dynamiques du formulaire, ce qui compte parce que chaque formulaire peut avoir un ensemble de champs différent.

Le processeur valide le formulaire actif et ses champs actifs avant l’enregistrement. Les champs requis, le format email, le format téléphone, le format URL, les champs numériques, les options select, les validateurs personnalisés et la case GDPR peuvent tous rejeter la soumission avant qu’elle soit enregistrée. Les contrôles anti-spam s’exécutent ensuite ; les soumissions spam sont quand même enregistrées avec is_spam = 1 et une raison, mais les emails admin et client normaux ne sont envoyés que pour les soumissions non spam.

L’adresse IP est prise depuis les en-têtes forwarded lorsqu’ils sont présents, puis depuis l’adresse remote en repli, et le user agent est stocké avec une limite de longueur. Cela crée une piste d’audit pour les demandes sans transformer le module en CRM complet ; le suivi se fait toujours via les destinataires email configurés ou le workflow back-office utilisé par le marchand pour examiner les soumissions.

Oui, les demandes peuvent être routées vers des destinataires admin configurés. Chaque formulaire peut définir des adresses email admin et une ligne d’objet ; le mailer accepte les destinataires séparés par des virgules et se rabat sur l’email global du module ou l’email de la boutique lorsque le destinataire d’un formulaire est vide.

Ce routage est par formulaire, donc un formulaire de contact peut envoyer les demandes commerciales vers une boîte mail, tandis qu’un autre formulaire envoie les demandes support vers une autre boîte. Le formulaire dispose aussi d’un réglage send_admin_email ; si les emails admin sont désactivés pour ce formulaire, la soumission peut quand même être stockée sans envoyer de notification admin.

Le repli du destinataire se fait dans l’ordre. Le mailer utilise d’abord la liste d’emails admin du formulaire, puis le réglage email admin de niveau module, puis PS_SHOP_EMAIL. Plusieurs destinataires peuvent être saisis sous forme de liste séparée par des virgules. Les adresses email invalides sont ignorées plutôt qu’utilisées pour l’envoi.

L’objet admin vient de l’objet email traduit du formulaire lorsqu’il est défini, sinon il se rabat sur un objet générique de nouvelle soumission. Le nom de la boutique est ajouté, et l’email client soumis est utilisé comme adresse reply-to lorsqu’il est disponible, afin que répondre depuis la boîte mail puisse revenir au client.

La confirmation client est séparée. Si send_customer_email est activé et que la soumission inclut une adresse email client, le module peut aussi envoyer un message de confirmation au visiteur. Les soumissions spam sont enregistrées pour examen, mais le mailer n’est pas appelé pour elles ; le spam n’est donc normalement pas transféré aux destinataires admin ou aux clients.

Oui. Le module vérifie les soumissions avant d’envoyer les emails, marque le spam détecté dans l’enregistrement de soumission et stocke une raison de spam. La source inclut ces déclencheurs anti-spam :

• Honeypot : le champ caché website_url_confirm doit rester vide.
• Timing de soumission : l’horodatage caché _mpr_ft doit être présent, valide et plus ancien que le min_submit_time configuré du formulaire.
• Limite de fréquence : l’IP de l’expéditeur est bloquée lorsqu’elle a déjà atteint le maximum de soumissions par heure du formulaire.
• IP bloquées : l’IP de l’expéditeur est comparée à la liste d’IP bloquées du formulaire, séparée par retours à la ligne.
• Mots bloqués : chaque champ soumis est vérifié par rapport aux mots bloqués configurés avec une recherche de sous-chaîne insensible à la casse.

Par défaut, les formulaires fraîchement installés activent le honeypot et le contrôle de timing avec un temps minimum de soumission de 3 secondes. Les soumissions spam sont enregistrées pour examen, mais le flux normal d’emails admin/client ne s’exécute que pour les soumissions non spam.

La limite de fréquence par défaut au niveau du module est de 10 soumissions par IP par heure. Définir le maximum de soumissions par IP par heure à 0 désactive ce contrôle de limite. La requête de limite compte les soumissions enregistrées depuis la même adresse IP dans l’heure précédente, donc les tentatives répétées peuvent être bloquées même si le visiteur renvoie le même formulaire.

Le contrôle de timing est conçu pour détecter les posts automatisés qui soumettent immédiatement ou omettent l’horodatage caché. Un vrai visiteur reçoit le champ caché _mpr_ft avec le formulaire, tandis qu’un bot qui poste directement sans charger la page échouera généralement à l’exigence d’horodatage.

Les raisons de spam sont stockées comme libellés lisibles par machine tels que honeypot, timing, rate_limit, blocked_ip et blocked_words. Plusieurs raisons peuvent être enregistrées sur la même soumission, ce qui aide à distinguer un simple envoi trop rapide d’un message qui contient aussi des mots bloqués.

Oui, il peut remplacer la page de contact PrestaShop par défaut lorsque ce réglage est activé. Le module ajoute des routes de contact et utilise le hook dispatcher pour rediriger le contrôleur contact cœur vers son propre rendu de page contact, tout en gardant les liens d’affichage normaux du module disponibles.

Le réglage est désactivé par défaut. Lorsque replace_core_contact est activé, le module expose des routes de contact via hookModuleRoutes, en utilisant la réécriture de page contact de la boutique lorsque possible, et il gère aussi le contrôleur cœur contact via le hook dispatcher.

En termes d’implémentation, le hook dispatcher n’envoie pas de redirection navigateur 301 ou 302. Il réécrit sur place les paramètres de la requête courante en changeant le contrôleur vers le contrôleur display du module et en définissant le nom du module à mprcontactform. L’acheteur reste dans le flux de contact, mais PrestaShop rend la page contact du module au lieu du contrôleur contact cœur.

Le module peut aussi rendre les formulaires via sa propre route d’affichage de module et via des hooks comme displayMprContactForm et displayContactContent. Cela signifie que les marchands peuvent remplacer la page de contact principale, intégrer un formulaire spécifique ailleurs, ou garder la page de contact cœur inchangée et utiliser uniquement les liens du module.

Si le remplacement n’est pas activé, le hook de route ne retourne aucune route de remplacement de contact et la page de contact cœur reste sous le contrôle normal de PrestaShop. La fonctionnalité est ainsi réversible depuis la configuration sans désinstaller le module.

Le module ajoute une action de suppression sur la page de détail de commande admin PrestaShop. Elle s’affiche via les hooks displayAdminOrderMain et displayAdminOrder lorsque le module est activé et qu’un ID commande est disponible, puis envoie la commande vers le flux de corbeille du module.

Sur une installation standard, le module est activé et la confirmation est requise. La page commande affiche un bloc Delete Order avec un bouton qui pointe vers le contrôleur admin du module en utilisant un paramètre trash_order. Si la confirmation est activée, le template ajoute une invite de confirmation navigateur avant la soumission de l’action.

Lorsque l’admin confirme, le contrôleur transmet l’ID commande et l’ID employé courant au service de corbeille. Le service charge l’Order PrestaShop, crée le snapshot de corbeille, stocke qui l’a supprimée, puis appelle la méthode native de suppression de commande de PrestaShop. Si la commande ne peut pas être chargée comme objet valide, l’action de corbeille retourne false au lieu de supprimer quoi que ce soit.

L’action est destinée aux commandes de test, doublons ou indésirables qu’un marchand choisit volontairement de retirer du back-office. Ce n’est pas un indicateur de masquage doux sur la ligne de commande originale ; après la fin du flux de corbeille, la méthode native de suppression de commande PrestaShop a été appelée et l’enregistrement restant du module n’est que le snapshot de corbeille.

Avant la suppression, le module charge l’Order PrestaShop, crée un résumé JSON compact, insère une ligne dans mprdeleteorders_trash, puis appelle la méthode native de suppression de commande. La table de corbeille est volontairement conservée à la désinstallation par sécurité.

{"id_order":1234,"reference":"ABCDEF123","id_customer":42,"total_paid":149.90,"date_add":"2026-06-17 10:15:00","current_state":2}

• id_order : l’ID de commande PrestaShop original, également enregistré comme colonne de premier niveau dans la table de corbeille pour le filtrage.
• reference : la référence de commande, également enregistrée sous order_reference.
• id_customer : l’ID client lié à la commande supprimée.
• total_paid : le total de commande depuis total_paid_tax_incl.
• date_add : la date de création originale de la commande.
• current_state : l’ID d’état de commande au moment de la suppression.
• deleted_by : l’ID de l’employé back-office qui a cliqué sur l’action de corbeille.
• date_deleted : le moment où l’enregistrement de corbeille a été créé.

C’est un snapshot d’audit, pas une sauvegarde réversible complète de toutes les tables liées à la commande, facture, message et lignes de commande. Utilisez-le pour identifier ce qui a été supprimé et par qui avant une purge définitive.

La table de corbeille elle-même stocke id_trash, id_order, order_reference, order_data, deleted_by et date_deleted. Le contrôleur de liste peut afficher ces lignes de corbeille afin qu’un admin puisse consulter l’ID de commande original, la référence, l’employé supprimant et la date de suppression.

Le JSON contient volontairement seulement un petit ensemble de valeurs d’en-tête de commande. Il ne stocke pas les produits, détails de commande, adresses, paiements, factures, messages, lignes transporteur, contenu du panier, bons de réduction ou historique des mouvements de stock. Pour cette raison, il doit être traité comme une traçabilité des suppressions, pas comme un package de restauration.

Non, le module ne reconstruit pas une commande PrestaShop supprimée depuis la corbeille. Lorsqu’une commande est déplacée vers la corbeille, il stocke un petit snapshot JSON avec des valeurs comme l’ID commande, la référence, l’ID client, le total payé, la date de création et l’état courant, puis appelle la méthode de suppression de commande de PrestaShop.

La méthode de restauration lit uniquement la ligne de corbeille, confirme qu’elle existe, supprime cette ligne de corbeille et retourne un succès pour cette action de nettoyage. Elle ne recrée pas la ligne de commande originale, les détails de commande, paiements, factures, historique de commande, données panier ou enregistrements liés.

Cette limitation est importante parce que le module ne stocke pas assez de données relationnelles pour effectuer une reconstruction complète et sûre d’une commande. Traitez la corbeille comme un tampon d’audit et de nettoyage, pas comme une sauvegarde complète. Pour une vraie récupération, utilisez une sauvegarde de base de données ou un processus de restauration manuel en dehors de ce module.

L’action de nettoyage définitif de la corbeille est également séparée de la restauration de commande. Retirer une ligne de corbeille retire seulement le snapshot d’audit du module ; cela n’affecte pas une commande PrestaShop déjà supprimée, car les données de commande originales ont déjà été retirées par l’appel de suppression natif.

Pour les boutiques en production, le workflow pratique est d’utiliser le module pour nettoyer les commandes connues de test ou indésirables, de garder des sauvegardes de base de données pour la récupération, et de vérifier la commande avant de la supprimer. Si une commande peut devoir être récupérée avec produits, paiements, factures et historique intacts, ne vous fiez pas à la ligne de corbeille du module comme source de récupération.

Non, le chemin de désinstallation conserve la table de corbeille par sécurité. Dans PrestaShop, le module supprime ses onglets et sa configuration, mais le commentaire du code indique que mprdeleteorders_trash est gardée.

Oui. Lorsque le suivi des achats est activé et que le module est autorisé à suivre le visiteur, il déclenche un événement Hotjar purchase depuis le hook de confirmation de commande PrestaShop. Le template front-office appelle hj('event', 'purchase') sur la page de confirmation de commande.

C’est utile pour l’analyse Hotjar, car vous pouvez filtrer les enregistrements, heatmaps, enquêtes ou funnels autour des sessions ayant atteint un achat, puis inspecter le comportement avant la commande. Cela aide à répondre à des questions comme où les acheteurs ont hésité, quelles étapes checkout ils ont rejouées, ou quels motifs de page apparaissent dans les sessions réussies.

Ce n’est pas un remplacement des analyses de revenus ou du reporting de commandes côté serveur. Hotjar reçoit l’événement nommé pour la segmentation comportementale ; les détails de commande du module servent surtout à construire le contexte local d’événement et ne constituent pas un flux transactionnel complet.

La fonctionnalité dépend des gardes normaux du module Hotjar. Le module doit être activé, le Hotjar Site ID doit être configuré en chiffres, le suivi des achats doit être activé, et le visiteur doit passer les contrôles de suivi du module, comme la gestion du consentement lorsque le respect du consentement est activé. Si le suivi n’est pas autorisé, le hook de confirmation de commande ne retourne rien.

Lorsque le hook s’exécute, le module construit un contexte d’achat local depuis la commande PrestaShop, avec des valeurs comme l’ID commande, la devise, la valeur totale, le nombre d’articles et les identifiants produit. Ce contexte est assigné au template de confirmation de commande et peut être utilisé par les outils locaux d’enregistrement/démo d’événements du module, mais l’appel Hotjar Events API effectué par le template reste le simple événement nommé purchase.

Dans Hotjar, utilisez l’événement purchase comme marqueur comportemental. Pour les totaux, taxes, marges, attribution, remboursements ou reporting de conversion faisant autorité, continuez à utiliser les données de commande PrestaShop ou une plateforme analytics conçue pour le reporting transactionnel.

Non. Le module envoie des événements PrestaShop et du contexte client à Klaviyo, mais la logique de campagne, les segments, le contenu email et les flows SMS sont gérés dans Klaviyo. Cette séparation est utile parce que les données boutique viennent de PrestaShop tandis que la stratégie marketing reste dans la plateforme marketing.

En termes de source, le côté PrestaShop est limité à la livraison de données onsite. Lorsque ENABLED est défini et que PUBLIC_API_KEY est présent, le hook d’en-tête charge le script onsite de Klaviyo avec le company id. Les valeurs par défaut d’installation laissent le module désactivé, gardent la clé publique vide, et fournissent des interrupteurs de suivi comme TRACK_VIEWED, TRACK_CART et TRACK_PURCHASE.

Le template front peut identifier les clients connectés avec email et prénom, suivre une page produit comme Viewed Product, et suivre la page panier comme Added to Cart. Il ne contient pas de constructeur de flow Klaviyo, éditeur de segment, éditeur de template email, écran de workflow SMS ou couche API de campagne. La source expose un interrupteur d’achat, mais le template de suivi navigateur inspecté ne sort pas d’appel de suivi d’achat ; l’automatisation d’achat doit donc toujours être vérifiée dans Klaviyo plutôt que supposée depuis le seul réglage PrestaShop.

PUBLIC_API_KEY=YOUR_KLAVIYO_PUBLIC_KEY ENABLED=1 TRACK_VIEWED=1 TRACK_CART=1

Partiellement. Le module a des templates de cartes produit et un chargement de données produit, mais le chemin front-office implémenté n’est pas une colonne dropdown autonome product_list. MenuBuilder peut charger des éléments de colonne product_list depuis un ID catégorie et une limite, mais extractChildrenFromColumns() n’expose pas les éléments product_list comme enfants de menu, donc les marchands ne doivent pas compter sur ce type de colonne pour afficher des cartes produit tant que le support template/enfants n’est pas ajouté.

Le chemin implémenté aujourd’hui correspond aux aperçus produit sous les enfants d’arborescence de catégories. Ajoutez une colonne dropdown de type category_tree, activez PRODUCTS_NB avec une valeur supérieure à zéro, et le builder peut attacher des produits depuis chaque enfant de catégorie. Le template front-office rend ensuite le premier produit attaché comme carte mise en avant et les produits attachés restants comme petites cartes dans le panneau.

SHOW_PRICES et SHOW_DISCOUNTS contrôlent si les prix et badges de remise apparaissent ; les deux sont activés par défaut. PRODUCTS_NB contrôle combien d’aperçus produit d’enfants de catégorie sont attachés. Le TTL du cache menu contrôle la vitesse à laquelle les changements structurels apparaissent, et des hooks de mise à jour produit, catégorie et CMS sont enregistrés pour vider les données de menu en cache lorsque le contenu de la boutique change.

Implemented storefront path:
category_tree child + PRODUCTS_NB > 0 = product previews under that category child.
Not currently implemented as rendered storefront cards:
standalone product_list column.

Le module rend le menu mobile depuis la même configuration de menu de premier niveau, avec un parseur mobile dédié. Cela réduit la maintenance en double et aide à garder la navigation desktop et mobile alignée. Vous devez quand même vérifier la mise en page mobile, car les libellés longs et les arborescences de catégories profondes peuvent affecter l’utilisabilité.

Les sorties desktop et mobile reçoivent toutes deux les mêmes données $menu.children pour l’arborescence off-canvas. Sur mobile, le template rend cette arborescence, tandis que HtmlMobileTreeParser et le builder de menu peuvent convertir plusieurs mises en page de colonnes desktop en structure mobile plus simple, incluant arborescences de catégories, arborescences de catégories CMS, catégories de blog, groupes de liens, liens CMS, listes de liens, arbres mobiles dérivés du HTML et onglets visuels.

Cela signifie que vous maintenez normalement les libellés, liens, arborescences de catégories, liens CMS, onglets visuels et contenu d’arbre mobile personnalisé compatible une seule fois dans le module. L’exception pratique concerne le contenu qui n’est pas extrait dans menu.children. En particulier, les colonnes desktop product_list ne sont pas extraites dans l’arbre mobile actuel, et le template mobile ne rend que $menu.children ; le contenu product-list nécessiterait un support de template front/mobile avant d’apparaître dans le menu off-canvas.

Le HTML personnalisé est un autre point à tester. Si une colonne contient un balisage inhabituel et aucun arbre mobile exploitable, le parseur mobile peut se rabattre sur une structure simple ou vide ; testez donc les libellés longs, les arbres imbriqués et le HTML promotionnel à une vraie largeur mobile avant de vous appuyer dessus pour la navigation.

Non. Le module connecte PrestaShop à Tidio et contrôle le comportement de chargement front-office. Les flows chatbot, la gestion de la boîte de réception et les workflows d’opérateur sont gérés dans Tidio, là où ces outils doivent se trouver.

Les réglages PrestaShop sont des réglages de connexion et de rendu : PUBLIC_KEY est requis et validé, ENABLED vaut 1 par défaut, et le widget peut être retardé, masqué sur mobile, limité par type de page, et recevoir optionnellement l’email/nom du client connecté via PASS_USER_DATA.

PUBLIC_KEY=your_tidio_public_key ENABLED=1 PAGES=all DELAY=0 PASS_USER_DATA=1

Sur le front office, le template définit seulement des données optionnelles document.tidioIdentify et ajoute le script hébergé de Tidio depuis code.tidio.co. Il n’y a pas de constructeur de bot côté PrestaShop, vue de boîte de réception, écran d’assignation d’opérateur, table d’historique de messages ou API de flow dans ce module ; l’automatisation commerciale/support doit donc toujours être configurée dans le tableau de bord Tidio.

La configuration enregistre l'état d'activation, le titre, le message HTML, la visibilité du champ newsletter, le délai en secondes, la durée du cookie en jours et l'affichage sur toutes les pages ou uniquement sur la page d'accueil.

Après sa fermeture par le visiteur, le script définit le cookie mprwpop_seen avec le nombre de jours configuré. Le script de la popup vérifie ce cookie avant de l'afficher à nouveau.

Non. Le champ email est seulement affiché dans ce module. Lorsque SHOW_NEWSLETTER est activé, le template front affiche un formulaire newsletter avec un champ email et un bouton Subscribe, mais le module lui-même ne contient aucun contrôleur front, gestionnaire AJAX, insertion dans une table abonnés ou intégration de module newsletter qui stocke les adresses soumises.

Le script de popup gère uniquement le timing d’affichage, la fermeture de la modale, la fermeture avec la touche Escape, et le cookie mprwpop_seen. Il n’intercepte pas la soumission du formulaire et n’envoie l’adresse nulle part.

Si vous voulez capturer des leads, connectez ce formulaire à votre propre gestionnaire, à un module newsletter, à un endpoint Brevo ou Mailchimp, ou à une action de formulaire niveau thème que votre boutique traite. Tant que cette intégration n’existe pas, activer le champ affiche seulement une boîte email ; cela ne crée pas d’abonnés newsletter.

Les réglages liés du module décident seulement si le champ est affiché et à quelle fréquence le popup apparaît. Les valeurs par défaut d’installation définissent SHOW_NEWSLETTER à 0, DELAY à 3 secondes, COOKIE_DAYS à 7, et SHOW_ON à all ; SHOW_ON=homepage le limite au contrôleur index.

Le cookie de visibilité est défini lorsque l’acheteur ferme le popup, clique sur l’overlay ou appuie sur Escape. Soumettre le formulaire newsletter ne crée pas d’enregistrement abonné dans ce module, et le formulaire template n’a pas d’URL d’action ; un marchand doit donc le traiter comme un placeholder front-end jusqu’à ce qu’il soit connecté à un vrai endpoint newsletter.

<form class='mprwpop-newsletter' id='mprwpop-nl-form' method='post'>

Oui. Lorsque le réglage d'affichage est limité à la page d'accueil, le hook renvoie du contenu uniquement si la page courante du front controller est la page index.

Ajoutez votre Microsoft UET Tag ID numérique et activez le suivi navigateur dans le module. Le hook d’en-tête PrestaShop charge le script UET, pousse l’événement de chargement de page, puis envoie les événements navigateur configurés lorsque le suivi est actif et que les règles de consentement l’autorisent.

Sur une nouvelle installation, le suivi n’est pas actif tant que ces réglages ne sont pas complets : ENABLED vaut 0 par défaut, TAG_ID est vide, et le module ne se considère actif que lorsque le tag ID est numérique. Dans le formulaire admin, enregistrez l’ID de balise Microsoft Ads UET sans lettres ni espaces, gardez RESPECT_CONSENT activé si vous utilisez un module cookie pris en charge, et décidez quels interrupteurs d’événements doivent rester activés.

TAG_ID=123456789 ENABLED=1 RESPECT_CONSENT=1 TRACK_PAGE_VIEW=1 TRACK_PRODUCT_VIEW=1 TRACK_PURCHASE=1

Lorsque le hook d’en-tête s’exécute, il peut aussi capturer msclkid depuis l’URL d’arrivée pour le matching de conversion ultérieur. L’exclusion des employés est activée par défaut via EXCLUDE_EMPLOYEES, donc les tests effectués en étant connecté au back-office peuvent ne pas déclencher d’événements sauf si vous tenez compte de ce réglage.

Oui, il prend en charge Microsoft Conversions API pour les événements d’achat côté serveur, mais seulement lorsque les réglages requis sont complets. Le module a besoin du suivi activé, d’un TAG_ID numérique, de CAPI_ENABLED activé, d’un CAPI_ACCESS_TOKEN enregistré, et du suivi des achats activé.

• Validation admin : le UET Tag ID doit contenir uniquement des chiffres, CAPI ne peut pas être activé sans tag ID numérique, le bearer token est requis lorsque CAPI est activé, et la limite de lot de file doit être entre 1 et 100.
• Flux commande : sur actionValidateOrder, le module vérifie canTrack(), TRACK_PURCHASE et la disponibilité CAPI avant de mettre quoi que ce soit en file.
• Flux de file : une conversion d’achat est mise en file pour le fournisseur microsoft_uet, liée à l’ID commande, puis le module traite immédiatement un petit lot de 3 événements. La tâche cron traite plus tard le lot normal configuré.

La balise navigateur UET peut toujours gérer les événements de page, panier, recherche et remarketing ; le chemin CAPI dans ce module est spécifiquement le chemin d’achat côté serveur.

Pour la configuration, les champs CAPI importants sont :

CAPI_ENABLED=1 CAPI_ACCESS_TOKEN=your_microsoft_token CAPI_BATCH_LIMIT=20 TRACK_PURCHASE=1

Le client API envoie les événements à Microsoft UET CAPI en utilisant le tag ID numérique dans l’endpoint et un bearer token. La charge utile normalise le nom/ID/heure/source URL de l’événement, le consentement ad-storage, les données utilisateur et les données d’achat personnalisées. Le matching utilisateur peut inclure l’adresse IP, le user agent, le msclkid stocké, les détails client hachés et les identifiants anonymes de panier/invité lorsqu’ils sont disponibles.

Ce n’est pas un remplacement côté serveur de chaque événement navigateur du module. Les événements page view, product view, search, add-to-cart, wishlist et click/URL/controller personnalisés restent côté navigateur dans la source inspectée ; CAPI est le complément serveur pour les achats.

Le module regroupe les événements Microsoft Ads UET autour des activités de commerce front-office, compte, recherche et déclencheurs personnalisés. Les principaux événements sont configurables individuellement dans les réglages du module.

• Commerce/front-office : pageView, productView, addToCart, addToWishlist, initiateCheckout et purchase. Les événements produit, panier et achat incluent des paramètres commerce comme les ID produit, valeurs de commande, devise et quantités lorsque disponibles.
• Recherche : search se déclenche sur les pages de résultats de recherche avec le contexte de requête.
• Compte : signUp est déclenché après inscription client via le flux de hook d’inscription du module.
• Personnalisé : les événements personnalisés peuvent être configurés avec des déclencheurs de clic, URL, contrôleur ou événement DOM, avec des noms d’événements limités aux règles de nommage UET autorisées par le module.

L’événement d’achat est envoyé sur la page de confirmation de commande, tandis que les événements add-to-cart et wishlist sont capturés par des écouteurs JavaScript front-office.

La plupart de ces interrupteurs sont activés par défaut à l’installation, notamment TRACK_PAGE_VIEW, TRACK_PRODUCT_VIEW, TRACK_ADD_CART, TRACK_ADD_WISHLIST, TRACK_INITIATE_CHECKOUT, TRACK_SEARCH, TRACK_PURCHASE et TRACK_SIGNUP. TRACK_CUSTOM_EVENTS est désactivé par défaut jusqu’à ce que vous définissiez des règles d’événement personnalisées.

Les règles personnalisées sont volontairement bornées : le normaliseur de config accepte jusqu’à 15 noms d’événements distincts, retire les paramètres réservés event_id, et prend en charge les sélecteurs de clic, correspondances URL contains, noms de contrôleurs ou événements DOM personnalisés. Le JavaScript front-office déduplique les événements de boutons add-to-cart et wishlist pendant environ une seconde, afin que la même action ait moins de chances d’être comptée deux fois.

Oui. Avec RESPECT_CONSENT activé, le module vérifie le consentement marketing avant de considérer le suivi Microsoft UET comme actif. Il vérifie d’abord mprcookiesrevolution en lisant le cookie mprcr_consent et en cherchant marketing:1. Si ce cookie est absent, il se rabat sur la valeur DEFAULT_CONSENT de ce module. Si Cookies Revolution n’est pas actif, il vérifie mprcookiebanner via mprcookie_consent=granted, en se rabattant là aussi sur le réglage de consentement par défaut de ce module lorsque le cookie est absent.

Si aucun module de consentement MPR pris en charge n’est actif, la fonction de consentement retourne autorisé, donc le suivi n’est pas bloqué par le consentement seul. Pour un blocage GDPR strict, gardez RESPECT_CONSENT activé et installez/configurez l’un des modules de consentement pris en charge.

Le flux msclkid s’exécute dans le hook d’en-tête. Le module lit msclkid depuis l’URL d’arrivée, accepte uniquement les caractères A-Za-z0-9._:- jusqu’à 500 caractères, le reflète dans $_COOKIE['mprbuet_msclkid'], puis écrit un cookie HTTP-only nommé mprbuet_msclkid pour 7776000 secondes. Les données utilisateur de conversion côté serveur ultérieures peuvent inclure cet ID de clic Microsoft stocké lorsqu’il est présent.

• https://shop.example/?msclkid=abc123 stocke abc123 dans le cookie du module.
• Un achat ultérieur peut attacher cette valeur aux données de conversion Microsoft UET si les conversions côté serveur sont configurées.

Le contrôle de consentement côté serveur et le garde JavaScript front-office travaillent ensemble mais ne sont pas identiques. Le garde PHP canTrack() bloque la construction d’événements pour les employés, les modules désactivés et le consentement marketing échoué ; le template d’en-tête vérifie aussi les cookies navigateur avant de charger bat.js lorsqu’un module de consentement client pris en charge est présent.

Si RESPECT_CONSENT est défini à 0, le contrôle de consentement est contourné. Si aucun module de consentement MPR pris en charge n’est installé, la fonction PHP autorise le suivi du seul point de vue du consentement, donc les boutiques strictes ne doivent pas s’appuyer sur le module UET seul comme unique couche de consentement.

Le cookie msclkid est écrit avant l’achat ultérieur, ce qui compte car un acheteur peut arriver depuis Microsoft Ads, naviguer, puis commander lors d’une requête ultérieure. La valeur n’est acceptée que si elle correspond à la liste blanche de caractères du module ; les valeurs invalides ou trop longues sont ignorées au lieu d’être envoyées à Microsoft.

Non. Le tag navigateur n'est injecté par le hook d'en-tête PrestaShop que lorsque le suivi est actif, c'est-à-dire quand un TAG_ID numérique est enregistré et que ENABLED vaut 1. La bibliothèque Microsoft est alors ajoutée avec script.async = true depuis https://bat.bing.com/bat.js, elle se charge donc sans bloquer le rendu de la page.

Au chargement, le module envoie un seul pageLoad vers window.uetq, puis uniquement les événements que vous avez activés, comme la vue produit, l'ajout au panier ou l'achat, via uetq.push('event', ...). Si un module de consentement compatible est présent, le pixel n'est chargé qu'après confirmation du consentement marketing dans le navigateur, donc les visiteurs qui refusent ne déclenchent aucune requête vers Microsoft.

L'envoi côté serveur via la Conversions API s'exécute dans une tâche cron planifiée, pas dans la requête du client, et les employés connectés sont exclus par défaut via EXCLUDE_EMPLOYEES.

Lorsque la Conversions API est activée et qu'un jeton bearer Microsoft est enregistré, les événements d'achat sont mis en file d'attente à la validation de la commande et envoyés côté serveur par une tâche cron planifiée, send_bing_uet_conversions, qui s'exécute toutes les 300 secondes. Chaque exécution traite la file jusqu'à la limite de lot configurée (CAPI_BATCH_LIMIT, défaut 20, autorise 1–100 et plafonne à 100 lignes par exécution), de sorte que les événements en échec ou en attente sont réessayés au cycle suivant au lieu d'être perdus.

Les données utilisateur côté serveur peuvent inclure l'identifiant de clic Microsoft stocké (msclkid), l'e-mail et le téléphone hachés, l'IP client et le user-agent. Les entrées traitées et obsolètes sont nettoyées automatiquement, l'historique récent est conservé et les anciennes lignes sont supprimées avec le temps.

Si le jeton bearer est manquant ou vide, le bloc d'état de l'admin affiche un avertissement et aucun événement côté serveur n'est envoyé tant que vous ne l'avez pas ajouté. L'UET navigateur peut rester activé indépendamment pour les vues de page et le remarketing pendant que vous configurez la Conversions API.

Non, pas pour le bouton de contact Messenger de base. Le réglage requis est le Facebook Page ID numérique ; sans App ID configuré, le template front-office affiche un lien direct https://m.me/{page_id} afin que les acheteurs ouvrent Messenger depuis le bouton flottant.

• Mode lien m.me : exige que le module soit activé et qu’un Page ID valide soit présent. Il est rapide à configurer et fonctionne comme un simple lien de contact Messenger externe.
• Mode SDK : le module traite un champ App ID rempli comme le déclencheur pour rendre le balisage du plugin customer chat Facebook et charger le SDK customer chat Facebook. Le texte de salutation est utilisé dans ce balisage en mode SDK.

Les marchands qui veulent seulement un bouton Messenger fiable peuvent donc laisser l’App ID vide. Ajoutez l’App ID uniquement lorsque vous voulez volontairement le chemin de chat intégré basé sur le SDK et que la configuration côté Facebook est prête.

L’exigence de Page ID est stricte : le validateur de configuration requise accepte uniquement des chiffres, 5 à 32 caractères, et le widget ne s’affiche pas tant que le module est activé mais que ce champ est vide. Les valeurs par défaut activent le widget, l’affichent sur toutes les pages y compris mobile, utilisent le style icône en bas à droite, et un délai d’affichage de 0 seconde.

Les réglages d’apparence comme POSITION, STYLE, CTA_TEXT, COLOR, SIZE, MARGIN, infobulle et animation sont utilisés par le chemin de bouton lien flottant. Le filtrage par page et la visibilité mobile viennent du garde de chat partagé, donc vous pouvez afficher le point d’entrée Messenger uniquement sur les pages produit, catégorie ou checkout si cela correspond à votre flux support.

La méthode de fetch vérifie d'abord RSS_URL. Si elle est vide, elle construit une URL RSS depuis BOARD_URL. Les URLs de pins ne sont utilisées que lorsque le chemin RSS ne produit aucun post.

Non. mprpinterestintegration est un module de contenu/feed Pinterest, pas le module de suivi publicitaire Pinterest. Il affiche des pins, tableaux ou contenus alimentés par RSS Pinterest sur la boutique et inclut une gestion de cache pour le feed affiché. La source contient aussi des réglages optionnels de publication via l’API Pinterest pour la publication de produits/contenus.

• Pinterest Feed Integration : utilisez-le pour afficher du contenu Pinterest sur le front-office, configurer des noms d’utilisateur, URL de pin, URL de tableau ou sources RSS, et éventuellement publier du contenu de boutique sur Pinterest.
• Pinterest Tag : utilisez le module Pinterest Tag séparé pour la mesure publicitaire, les événements de tag navigateur et le suivi optionnel via l’API Conversions comme visites de page, vues produit, ajout au panier, checkout, recherche et inscription.

Si l’objectif est une meilleure mise en scène visuelle ou l’intégration de contenu Pinterest, utilisez cette intégration de feed. Si l’objectif est l’attribution Pinterest Ads ou l’optimisation de conversion, utilisez plutôt le module Pinterest Tag.

Pour le chemin feed, la source requise peut être aussi simple qu’une ou plusieurs URL de pins enregistrées, ou une URL de tableau/source RSS selon la façon dont vous voulez sélectionner le contenu. Les réglages de feed partagés contrôlent le hook d’affichage, le nombre de posts, les colonnes, la mise en page grille/slider, le bouton follow, la visibilité mobile et la durée de cache ; le cache vaut par défaut 3600 secondes et peut être rafraîchi depuis l’admin du module.

Le chemin optionnel de publication est également séparé du tracking publicitaire. La publication Pinterest exige des identifiants API Pinterest comme un access token et un board ID, et le publisher envoie des données de pin basées sur l’image à Pinterest. Cela n’installe toujours pas le tag publicitaire Pinterest et ne reporte pas les conversions publicitaires ; pour cela, la boutique a besoin du module séparé mprpinteresttag.

La config map inclut ACCESS_TOKEN, BOARD_ID, AUTOPUBLISH et AUTOPUBLISH_CAPTION. La publication est gérée via le PinterestPublisher partagé.

Chaque item de feed pointe vers l'URL du pin, affiche l'image thumbnail, un badge vidéo optionnel, un texte overlay, le nom d'auteur optionnel et une caption optionnelle selon les réglages du module et les données source.

Le module exige la Website Key Smartsupp. Son panneau de configuration indique au marchand de la copier depuis les réglages Smartsupp, et le validateur de configuration obligatoire considère une clé vide comme invalide.

Si PASS_USER_DATA est activé et que le client est connecté, le trait chat partagé renvoie customer_email et customer_name. Le template les assigne à _smartsupp.email et _smartsupp.name.

Non. Le template charge le script de widget externe de Smartsupp. L'interface de chat visible est fournie par Smartsupp après l'exécution du chargeur.

Oui. Si le réglage DELAY est supérieur à zéro, le template encapsule l'initialisation Smartsupp et l'injection du script dans setTimeout.

Non, vous n’avez pas besoin d’un compte développeur TikTok uniquement pour afficher des vidéos. Le feed d’affichage repose sur des URL de vidéos TikTok collées et sur l’endpoint public oEmbed de TikTok. Dans les réglages du module, saisissez le nom d’utilisateur TikTok pour le lien follow, collez une URL de vidéo TikTok par ligne dans le champ Video URLs, puis enregistrez.

Lorsque le feed est construit, le module découpe la liste d’URL enregistrée par ligne, ignore les entrées qui ne contiennent pas tiktok.com, appelle https://www.tiktok.com/oembed?url=..., et stocke le titre, la légende, l’auteur, la miniature et le HTML d’intégration retournés pour l’affichage. Ce chemin d’affichage n’utilise pas de token API, de revue d’app ou d’identifiants développeur.

Les identifiants ne sont pertinents que pour le workflow optionnel de publication. La source a des réglages de publication comme ACCESS_TOKEN, CLIENT_KEY, AUTOPUBLISH et AUTOPUBLISH_CAPTION, et utilise une instance de publisher TikTok pour ce chemin. Si votre objectif est seulement d’intégrer des vidéos TikTok sélectionnées sur la boutique, vous pouvez laisser ces identifiants de publication vides.

Le module d’affichage est activé par défaut, avec les interrupteurs de légende, icône de vues et icône de likes activés, tandis que les valeurs de feed partagées utilisent displayHome, 6 posts, 3 colonnes desktop, une mise en page grille, lazy loading et une durée de cache de 3600 secondes. Le feed ne s’affiche que dans le hook social-feed configuré ; si le hook configuré ne correspond pas au hook courant, rien n’est sorti.

Il y a deux cas pratiques : les URL sans tiktok.com sont ignorées, et toute requête oEmbed qui échoue est ignorée au lieu de rendre une carte cassée. La carte front-office pointe vers l’URL TikTok originale et affiche la miniature, l’auteur et la légende retournés ; les vidéos supprimées/privées ou les réponses oEmbed bloquées réduiront donc simplement le feed.

VIDEO_URLS=https://www.tiktok.com/@brand/video/1234567890 USERNAME=brand SHOW_CAPTION=1 POST_COUNT=6

Oui. Le trait chat commun vérifie le réglage mobile avant le rendu et ne renvoie aucun bouton lorsque l'affichage mobile est désactivé pour un visiteur mobile.

Non, le module ne gère pas les agents, l’historique des conversations ou les workflows support. WhatsApp lui-même gère la conversation, tandis que le module gère le bouton front-office et l’URL click-to-chat. Cela garde l’intégration légère et claire.

Le seul champ de connexion requis est PHONE. Il doit contenir uniquement des chiffres, 7 à 20 caractères, avec indicatif pays et sans signe plus ni espaces. Le template front construit https://wa.me/{phone}, et si un message est configuré, il ajoute ?text=... afin que WhatsApp le préremplisse.

• Ce que PrestaShop contrôle : activation/désactivation, numéro de téléphone, message prérempli optionnel, position, style icône/barre, texte CTA, couleur, taille, marge, infobulle, animation, visibilité mobile, délai d’affichage et filtre de page.
• Ce que WhatsApp contrôle : le fil de discussion réel, les réponses, l’assignation du personnel, l’historique des messages, les notifications et toutes les fonctionnalités de boîte de réception ou CRM.

Le message optionnel prend en charge {product} sur les pages produit et {url} pour la page courante, ce qui est utile pour les questions produit. Cela reste seulement un message WhatsApp prérempli, pas un ticket ou un enregistrement support PrestaShop stocké.

Le module remplace {url} par l'URL de la page courante. Sur les pages produit, il peut aussi remplacer {product} par le nom du produit courant.

Le module peut être rendu depuis le hook footer ou before-body, mais un indicateur statique interne évite la double sortie. Le périmètre peut couvrir toutes les pages, les pages produit, les pages catégorie ou les pages liées au checkout.

Ajoutez le code d’invitation Discord dans la configuration du module et activez le widget. Dans PrestaShop, le module affiche un bouton front-office lié à discord.gg avec le code d’invitation stocké, et une position, un style, un texte CTA, une couleur, une taille, une infobulle, une animation et une marge configurables.

Utilisez uniquement le code d’invitation, pas l’URL complète. Le validateur de configuration requise attend des lettres, chiffres, tirets et underscores, 2 à 64 caractères. Un code d’invitation manquant empêche le rendu ; un code enregistré invalide est signalé par l’avis de configuration et peut produire un mauvais lien Discord.

INVITE_CODE=AbCdEfG123 ENABLED=1 STYLE=icon POSITION=bottom-right CTA_TEXT=Join our Discord

À l’installation, les valeurs par défaut définissent déjà le widget comme activé, en bas à droite, style icône, bleu Discord #5865F2, taille 60px, marge 20px, infobulle activée, animation pulse, mobile activé, toutes les pages, et aucun délai. Le panneau de configuration admin recommande de créer une invitation permanente et un canal support dédié, car le module envoie les acheteurs vers le flux d’entrée sur le serveur au lieu de gérer les conversations Discord dans PrestaShop.

Oui, le widget peut être limité par type de page. Dans PrestaShop, le garde de chat partagé prend en charge toutes les pages, les pages produit, les pages catégorie ou les contrôleurs liés au checkout, et vérifie aussi le réglage séparé de visibilité mobile avant le rendu.

Le filtre de page est stocké dans le réglage partagé PAGES. Le garde retourne true pour all, vérifie php_self=product pour les pages produit, php_self=category pour les pages catégorie, et traite cart, order, order-opc, orderopc et checkout comme contrôleurs liés au checkout.

Le même garde exige aussi ENABLED et un INVITE_CODE non vide, et masque le widget sur mobile lorsque SHOW_MOBILE est désactivé. Le ciblage par page n’est donc pas un snippet séparé à coller dans le thème ; il fait partie de la décision de rendu du module avant la sortie du CSS et du bouton.

PAGES=product SHOW_MOBILE=1 DELAY=0

Oui, le module possède un réglage de délai pour le bouton front-office. Dans PrestaShop, le template de hook écrit une valeur data-delay et un petit script masque le widget puis l'affiche après le nombre de secondes configuré.

Non, le module n’envoie pas de texte prérempli dans Discord. Le réglage de connexion requis est un code d’invitation, pas un token API utilisateur/message, et le template front-office affiche un lien vers https://discord.gg/{invite_code}.

Le champ admin Pre-filled Message est stocké pour référence et le module peut remplacer {url} en interne avant d’assigner les données template, mais le template front-office actuel ne sort pas ce message et ne l’ajoute pas à l’URL d’invitation Discord.

C’est différent des plateformes de chat qui prennent en charge des paramètres d’URL pour une conversation préremplie. Les liens d’invitation Discord envoient l’acheteur vers un flux d’invitation/rejoindre un serveur, donc la configuration pratique consiste à créer un lien d’invitation permanent et à orienter les clients vers un canal support après leur arrivée.

La source confirme cette séparation. Le formulaire de connexion admin étiquette le champ comme Pre-filled Message, mais sa description indique qu’il n’est pas utilisé pour les invitations Discord et qu’il est stocké pour référence. Dans le hook, le module remplace {url} dans le message enregistré avant d’assigner les données Smarty, mais le template utilise seulement invite_code, position/style/CTA/apparence, infobulle, animation et délai.

Pour les marchands, la configuration fiable est l’invitation elle-même : créez un code d’invitation stable, empêchez son expiration, et utilisez les règles de serveur/canal Discord pour guider les clients après leur arrivée. Ne comptez pas sur ce module pour ouvrir un DM Discord direct, publier dans un canal ou transmettre un message checkout/produit à Discord.

Non, c’est un module de navigation linguistique. Il aide les acheteurs à passer entre les langues que vous exploitez déjà, et les dirige vers les URL localisées lorsque PrestaShop dispose des données. La qualité de traduction, le ciblage pays et la logique de localisation du visiteur restent en dehors de ce module.

Le module lit les langues PrestaShop actives pour la boutique courante avec Language::getLanguages(true, shop_id). Si la boutique n’a qu’une seule langue active, il ne retourne aucun sélecteur. Pour chaque langue, il associe l’ISO de langue à un SVG de drapeau lorsqu’il existe, construit une URL de langue depuis les URL de langues alternatives du contrôleur front lorsqu’elles sont disponibles, et se rabat sur getLanguageLink() de PrestaShop.

• Navigation : la sortie desktop masque le sélecteur de langue desktop natif et affiche un dropdown de drapeaux dans displayNav2 ; la sortie mobile peut afficher un select simple dans displayMobileLanguageSelector.
• Libellés : SHOW_LABEL contrôle si le code ISO courant est affiché à côté du drapeau, et SHOW_NAMES contrôle si les noms complets de langues sont affichés dans le dropdown. Les valeurs par défaut sont label désactivé et noms activés.
• Limites : il ne traduit pas les noms/descriptions de produits, ne choisit pas les langues par géolocalisation, ne redirige pas les visiteurs par pays, et ne crée pas d’URL localisées manquantes.

Il existe un nettoyage supplémentaire des URL pour les alias de pages cœur et un hook d’intégration pour les chemins de filtres traduits de MPR Filter Revolution, mais cela dépend toujours de routes/données traduites existantes. C’est un sélecteur, pas un moteur de traduction.

Il enregistre displayHeader, displayOrderConfirmation, actionCustomerAccountAdd et actionValidateOrder.

Non. Le template de confirmation de commande et le builder de conversion serveur utilisent l'événement Pinterest checkout pour les commandes terminées, avec valeur de commande, quantité, devise, ID de commande et event ID.

CAPI_ENABLED doit être activé, le Pinterest ad account ID doit contenir uniquement des chiffres et l'access token ne doit pas être vide. Le batch limit doit être compris entre 1 et 100.

Oui, lorsqu'une règle personnalisée a capi activé. Le front conversion bridge mappe les noms d'événements navigateur connus et accepte aussi les noms d'événements CAPI personnalisés configurés.

Les valeurs par défaut d'installation mettent ENABLED à 0 et USERNAME à une chaîne vide. Le hook de rendu s'arrête tôt sauf si le module est activé et qu'un nom d'utilisateur existe.

Non, il ouvre votre profil Snapchat via le nom d’utilisateur configuré. Le contenu du profil et les conversations restent dans Snapchat lui-même. Cela garde le module concentré sur un chemin clair permettant aux acheteurs de vous suivre ou de vous contacter sans ajouter un lourd feed social à la page.

La sortie front-office est un bouton flottant rendu depuis le hook displayBeforeBodyClosingTag. Le hook s’arrête avant le rendu si le bouton Snapchat n’est pas activé, si la valeur USERNAME est vide, si l’affichage mobile est désactivé pour un visiteur mobile, ou si le contrôleur courant est listé dans EXCLUDE_PAGES. Lorsqu’il s’affiche, la destination est construite comme https://www.snapchat.com/add/ plus le nom d’utilisateur encodé dans l’URL.

Le template confirme qu’il s’agit d’un lien normal, pas d’une intégration Snapchat. Il sort une balise <a> avec l’URL configurée, target=_blank optionnel, texte d’infobulle, style de bouton, animation et message grabber optionnel. Il n’y a pas d’iframe, pas d’appel API Snapchat, pas de renderer de feed et aucun code qui lit les conversations ou le contenu de profil depuis Snapchat.

Required for output: ENABLED=1
Required account value: USERNAME=yourbrand
Rendered link: https://www.snapchat.com/add/yourbrand

Pour les marchands, cela signifie que le module a un impact faible : il donne aux visiteurs un chemin visible vers votre présence Snapchat tout en laissant tout le contenu Snapchat, les follows, messages et la confidentialité du compte sous le contrôle de l’application et du site Snapchat.

La définition de configuration liste small, medium et large, libellés 48px, 60px et 72px. La taille choisie est transmise à la classe du widget sous forme mprchat-size-....

Non. Ce module affiche un lien flottant vers un profil Snapchat. Snapchat Pixel et le suivi des événements publicitaires sont gérés par un autre module de ce lot.

Lorsque les wishlists invité sont activées, le script front stocke les ID produit dans le localStorage du navigateur et renvoie des réponses en mode invité pour les actions d'ajout et de retrait. Le stockage connecté utilise les tables de base de données du module.

La configuration JavaScript marque le client comme connecté, et l'action de synchronisation peut envoyer les articles localStorage au serveur afin de les ajouter à la wishlist par défaut du client.

Les wishlists en base disposent d'un token de 32 caractères. La vue front peut charger les produits par token, et le template traite le propriétaire connecté différemment d'un visiteur consultant une wishlist partagée.

Lorsqu'un client connecté enregistre un produit, le module stocke le prix au moment de l'ajout. La liste de produits compare ce prix stocké avec le prix actuel du produit et signale une baisse lorsque le prix actuel est inférieur.

Non. Ce module est surtout un tracker d’automatisation Brevo et une synchronisation d’inscription client, pas une intégration complète d’événements panier/commande/produit.

• Gère : displayBeforeBodyClosingTag charge le script d’automatisation Brevo, appelle la fonction de suivi de page, et identifie le visiteur par email lorsqu’un client est connecté. actionCustomerAccountAdd peut créer ou mettre à jour le nouveau client comme contact Brevo lorsque l’auto-subscription est activée.
• Ne gère pas : les mises à jour de panier, les payloads de vue produit, les événements d’achat de confirmation de commande, les événements de panier abandonné ou les événements de statut de commande. Le module n’enregistre pas de hooks panier, commande ou produit pour ces actions.

Si vous avez besoin de panier abandonné, de revenus d’achat ou d’automatisation de comportement produit dans Brevo, ce module nécessiterait des hooks d’événements supplémentaires ou une intégration séparée qui envoie ces événements Brevo spécifiques.

La liste de hooks est la limite importante : le module enregistre seulement displayBeforeBodyClosingTag et actionCustomerAccountAdd. Le template front-office crée window.sib, charge https://sibautomation.com/sa.js?key=..., met en file les fonctions Brevo standard et appelle window.sendinblue.page(). Si un client est connecté, il appelle aussi window.sendinblue.identify() avec l’adresse email. Aucun ID produit, ligne de panier, référence de commande, total ou statut de commande n’est ajouté à ce payload navigateur.

À la création de compte, le module poste vers l’endpoint contacts Brevo avec l’email du client, FIRSTNAME, LASTNAME, updateEnabled=true, et le LIST_ID configuré lorsqu’il est enregistré. C’est utile pour la croissance de liste et l’entrée dans des automatisations de base, mais c’est séparé du tracking d’événements ecommerce.

Registered hooks: displayBeforeBodyClosingTag, actionCustomerAccountAdd
Contact API: POST https://api.brevo.com/v3/contacts
Tracked browser event here: page view, plus logged-in email identify
Not present here: cart payload, purchase payload, abandoned cart event

Activez le module, ajoutez une clé API Brevo, et gardez la synchronisation automatique des inscriptions activée. Lorsque PrestaShop crée un compte client, le hook actionCustomerAccountAdd envoie l’email plus les attributs FIRSTNAME et LASTNAME à Brevo, et inclut l’ID de liste configuré lorsqu’il est enregistré.

Les réglages pertinents sont ENABLED, API_KEY, LIST_ID et AUTO_SUBSCRIBE. À l’installation, le module démarre avec ENABLED=0, une clé API vide, un ID de liste vide, une clé client tracker vide et AUTO_SUBSCRIBE=1. La configuration habituelle est donc : activer Brevo, coller la clé API depuis Brevo, saisir éventuellement l’ID numérique de liste pour les nouveaux contacts, et laisser Auto-subscribe New Customers activé.

La synchronisation ne s’exécute que pour les créations de nouveaux comptes client, car le module écoute actionCustomerAccountAdd. Il vérifie d’abord que le module est actif, que la clé API existe, que l’auto-subscribe est activé, et que PrestaShop a fourni un objet newCustomer chargé. Si l’un de ces contrôles échoue, il retourne sans rien envoyer à Brevo.

Lorsqu’il envoie, le module poste du JSON vers https://api.brevo.com/v3/contacts avec un timeout cURL de 10 secondes et la vérification SSL peer activée. Il définit updateEnabled à true, donc un contact Brevo existant peut être mis à jour au lieu de provoquer un échec de contact en double. Cette version source ne fait pas d’import en masse des clients existants et ne synchronise pas les modifications de profil ultérieures sauf si PrestaShop crée un nouveau compte via ce hook.

Required: ENABLED=1, API_KEY set, AUTO_SUBSCRIBE=1
Optional: LIST_ID=123
Sent fields: email, FIRSTNAME, LASTNAME, listIds when configured

Oui. Le hook front-office charge le tracker d’automatisation Brevo uniquement lorsque le module est activé, que la Brevo API Key est configurée et que la Client Key est configurée. Le champ Client Key dans les réglages du module est libellé Client Key (Tracker), et l’indication source dirige les marchands vers Brevo > Automation > Settings > Tracking Code.

Pour confirmer que le tracker est chargé, ouvrez la source du front-office ou les outils développeur du navigateur et cherchez https://sibautomation.com/sa.js?key=... avec l’ID de script sendinblue-js. Le template initialise window.sib.client_key, met en file sendinblue.track, sendinblue.identify, sendinblue.trackLink et sendinblue.page, identifie les clients connectés par email, puis appelle window.sendinblue.page().

Si vous ne voyez pas ce script, vérifiez d’abord l’interrupteur d’activation du module, l’API Key et la Client Key. Le hook retourne une chaîne vide lorsque l’un de ces prérequis manque.

L’exigence d’API key compte même si le tracker navigateur utilise la Client Key. Dans ce module, isActive() est partagé par le hook tracker et vérifie à la fois ENABLED et API_KEY ; ensuite le hook vérifie séparément CLIENT_KEY. Une boutique avec seulement la Client Key enregistrée ne sortira donc toujours rien tant que la clé API n’est pas configurée aussi.

Required for tracker output:
ENABLED=1
API_KEY=xkeysib-...
CLIENT_KEY=Brevo automation tracker key

La sortie du tracker se limite au script d’automatisation Brevo, au suivi de page et à l’identification email des clients connectés. Elle n’ajoute pas de contenu de panier, totaux de commande, métadonnées produit ou événements d’achat dans cette version source.

Oui, la synchronisation automatique des inscriptions peut être désactivée depuis la configuration du module. Le hook PrestaShop actionCustomerAccountAdd vérifie l’interrupteur AUTO_SUBSCRIBE avant d’envoyer un nouveau client à Brevo, donc le module peut rester installé pendant que la synchronisation d’inscription est désactivée.

Le réglage est libellé Auto-subscribe New Customers dans les options du module. Sa valeur par défaut est activée sur une installation fraîche, mais le hook la vérifie chaque fois que PrestaShop crée un compte client. Lorsque AUTO_SUBSCRIBE est désactivé, le hook sort avant de valider le nouvel objet client ou d’appeler l’API contacts Brevo.

Désactiver cet interrupteur arrête seulement la synchronisation inscription-vers-contact. Cela ne désinstalle pas le module, ne retire pas les identifiants API enregistrés, et ne désactive pas automatiquement le tracker d’automatisation front-office. Si ENABLED, API_KEY et CLIENT_KEY restent configurés, le hook tracker peut toujours charger le script Brevo et appeler la fonction de suivi de page.

Cela ne désabonne pas et ne supprime pas non plus les contacts déjà créés dans Brevo. Cela empêche simplement ce module d’envoyer les futures créations de nouveaux comptes contact tant que l’interrupteur reste désactivé.

AUTO_SUBSCRIBE=1: new customer can be posted to Brevo contacts
AUTO_SUBSCRIBE=0: actionCustomerAccountAdd returns before syncContactToBrevo()

Vous pouvez ajouter Crisp chat à PrestaShop en saisissant votre Crisp Website ID et en activant le module. L’avis de configuration du module attend le Website ID au format UUID, mais il exige seulement que le champ soit non vide ; il n’impose pas le motif UUID exact lors de l’enregistrement ou de l’affichage du widget. En pratique, vous devez quand même coller le vrai Website ID au format UUID depuis Crisp, car une valeur arbitraire non vide peut être enregistrée et rendue mais peut ne pas charger un widget fonctionnel.

À l’installation, le module Crisp crée des valeurs de chat par défaut avec ENABLED=1, un WEBSITE_ID vide, SHOW_MOBILE=1, PAGES=all, DELAY=0 et PASS_USER_DATA=1. Comme le Website ID commence vide, le module peut être installé et activé, mais le widget reste inactif tant que cet ID n’est pas enregistré.

L’avis de configuration requise attend un format UUID, par exemple xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. L’aide de configuration pointe vers Crisp sous Settings > Website Settings > Setup instructions. Une fois une valeur non vide enregistrée, le front-office applique toujours les mêmes règles d’affichage, donc le widget respecte l’interrupteur d’activation, un Website ID non vide, le réglage mobile et le ciblage par page.

Lorsque ces règles sont respectées, le template définit window.CRISP_WEBSITE_ID, pousse optionnellement les données email/nom du client connecté, et ajoute https://client.crisp.chat/l.js de façon asynchrone dans le head de la page.

Minimum setup:
Enable Crisp Chat = Yes
Website ID = UUID from Crisp
Show on Pages = All Pages, Product Pages, Category Pages or Checkout Pages

Oui, Crisp chat peut être limité par type de page PrestaShop. Le garde de chat partagé prend en charge toutes les pages, les pages produit, les pages catégorie ou les contrôleurs checkout, notamment cart, order, order-opc, orderopc et checkout, avant de sortir le script Crisp.

Le réglage est le champ select partagé Show on Pages. Ses valeurs stockées prises en charge sont all, product, category et checkout. La valeur par défaut du module est all, donc une installation fraîche avec un Website ID valide sera éligible à l’affichage sur chaque page front-office sauf si le marchand modifie ce réglage.

La correspondance de page utilise le contrôleur courant PrestaShop php_self. Le mode produit uniquement correspond exactement à product, le mode catégorie uniquement à category, et le mode checkout correspond à cart, order, order-opc, orderopc ou checkout. L’interrupteur mobile est vérifié séparément, donc une page peut correspondre à la règle de page et rester masquée sur mobile si SHOW_MOBILE est désactivé.

Show on Pages = all       -> every page
Show on Pages = product   -> product controller only
Show on Pages = category  -> category controller only
Show on Pages = checkout  -> cart/order checkout controllers

Si une valeur inattendue est stockée dans PAGES, la branche par défaut du garde partagé autorise la page plutôt que de la bloquer. Pour un ciblage prévisible, utilisez l’une des quatre valeurs exposées par le formulaire.

Oui, mais seulement lorsque la transmission des données client est activée et que l’acheteur est connecté. Le réglage est l’interrupteur Pass Customer Data dans la configuration du module Crisp ; définissez-le sur No pour empêcher le module d’envoyer les données d’identité du client connecté à Crisp.

• Lorsque PASS_USER_DATA est désactivé, le helper de chat partagé retourne des champs client vides.
• Lorsqu’il est activé et que le client est connecté, le helper retourne l’email du client et son prénom plus son nom.
• Le template Crisp les envoie comme user:email et user:nickname avant de charger https://client.crisp.chat/l.js.

Les visiteurs anonymes reçoivent quand même le widget Crisp lorsque le Website ID et les règles d’affichage l’autorisent, mais aucun email ou nom de client PrestaShop n’est transmis car il n’y a pas d’objet client connecté.

Sur une installation fraîche, PASS_USER_DATA vaut par défaut 1, donc les marchands qui ne veulent pas cette transmission doivent désactiver l’interrupteur volontairement. Le helper n’expose que deux valeurs au template : customer_email et customer_name. Il n’inclut pas les données d’adresse, numéros de téléphone, contenu de panier, historique de commandes ou ID client PrestaShop.

Le hook Crisp doit aussi respecter les règles d’affichage normales du module. Si le module est désactivé, le Website ID manque, l’affichage mobile est bloqué, ou la règle de page ne correspond pas, le template n’est pas rendu et aucune donnée client n’est poussée vers Crisp.

PASS_USER_DATA=1 + logged-in customer: email and first name + last name can be pushed
PASS_USER_DATA=0 or anonymous visitor: customer_email and customer_name stay empty

Oui, le script Crisp peut être retardé d’un nombre de secondes configuré. Le template hook PrestaShop actuel enveloppe le chargeur Crisp dans setTimeout lorsque le délai est supérieur à zéro ; il n’attend pas le scroll, le clic, le toucher ou une autre interaction utilisateur.

Le réglage enregistré est DELAY, affiché dans le formulaire partagé comme Fallback Delay (seconds). Dans le module Crisp actuel, le hook transmet cette valeur au template comme entier. Si la valeur est supérieure à zéro, le template enveloppe tout le bloc de configuration Crisp et d’ajout de script dans setTimeout(..., DELAY * 1000).

Une valeur de 0 signifie que le template n’ajoute pas de wrapper timeout, donc la configuration Crisp s’exécute immédiatement lorsque la sortie du hook est analysée. Bien que la description du champ partagé mentionne la première interaction utilisateur et un repli, ce template Crisp implémente uniquement le comportement de timer décrit ci-dessus.

DELAY=0  -> no setTimeout wrapper; load immediately
DELAY=5  -> run Crisp setup after 5 seconds
DELAY=15 -> run Crisp setup after 15 seconds

Le délai ne contourne pas la chaîne normale de gardes. Le module doit toujours être activé, le Website ID doit être présent, l’affichage mobile doit être autorisé pour les visiteurs mobiles, et la règle de ciblage par page doit correspondre avant qu’un script retardé soit imprimé.

Configurez les ID produit exclus dans le réglage de liste de produits du module, par exemple sous forme de liste séparée par des virgules. L’override retire les produits exclus du package transmis au calcul de règle panier de PrestaShop, donc les remises monétaires sont calculées uniquement sur les produits éligibles.

Excluded product IDs: 42,108,315
Cart: #42 $100 excluded + #77 $50 eligible
Voucher: 20% off products
Before exclusion: 20% of $150 = $30 discount
After exclusion: 20% of $50 = $10 discount; #42 stays at full price

La même liste d’exclusion peut être combinée avec des exclusions de catégories et de fabricants, car le module fusionne les trois sources en un seul ensemble de produits exclus. Les remises en pourcentage s’appliquent uniquement aux produits éligibles. Les réductions à montant fixe sont proratisées via le package filtré, tandis que la livraison gratuite et le comportement de cadeau sont laissés à la gestion normale des règles panier de PrestaShop.

Le réglage de liste de produits est stocké sous PRODUCTS. Le résolveur lit la valeur séparée par des virgules, convertit chaque entrée avec intval, retire les zéros vides, puis fusionne ces ID avec les ID dérivés des catégories et fabricants. La liste finale est mise en cache pour la requête PHP courante, ce qui évite de répéter les requêtes de catégorie et fabricant pendant le même calcul de panier.

L’override CartRule modifie uniquement les règles avec une réduction monétaire : reduction_percent supérieur à zéro ou reduction_amount supérieur à zéro. Si le module n’est pas activé, si la liste d’exclusion configurée se résout vide, ou si le package de règle panier courant ne contient aucun produit exclu, il délègue au calcul parent de PrestaShop sans changement.

Comme le filtre vérifie id_product, l’exclusion s’applique au produit entier. Si un produit a des déclinaisons, la source ne distingue pas une combinaison d’attributs d’une autre dans cette étape d’exclusion.

Stored setting: PRODUCTS=42,108,315
Resolver output: [42,108,315,...category matches,...manufacturer matches]
Override input: package products
Override output: package products without excluded id_product values

Oui. Les exclusions peuvent être saisies comme ID produit directs, ID catégorie et ID fabricant. Les champs de config admin sont des listes séparées par des virgules, et le résolveur les convertit en une liste finale d’ID produit avant le calcul de remise.

PRODUCTS=12,15
CATEGORIES=3,7
MANUFACTURERS=1,4

Avec cette configuration, les produits 12 et 15 sont exclus directement. Le module interroge aussi category_product pour chaque produit assigné aux catégories 3 ou 7, et interroge product pour chaque produit dont id_manufacturer est 1 ou 4. Il fusionne ces ID, supprime les doublons avec array_unique, et met le résultat en cache pour la requête courante.

L’override CartRule demande ensuite au module cette liste de produits résolue et filtre les produits exclus hors du package avant que la remise de règle panier parent soit calculée. En termes marchands : les produits correspondants restent au prix plein, tandis que le reste du panier peut quand même recevoir la remise du bon.

La règle catégorie est basée sur les ID catégorie exacts enregistrés dans CATEGORIES. La requête source lit les lignes depuis category_product où id_category est dans cette liste ; elle ne parcourt pas l’arbre de catégories en PHP. Si une boutique doit exclure aussi toutes les catégories enfants, ces ID de catégories enfants doivent être inclus sauf si les produits sont également assignés directement à la catégorie parente listée.

La règle fabricant est basée sur product.id_manufacturer. Comme pour les produits directs, l’exclusion finale se fait par id_product, donc toutes les déclinaisons d’un produit correspondant sont traitées comme exclues. Les entrées texte invalides sont effectivement réduites par conversion entière ; les valeurs vides et zéro ne contribuent pas d’ID produit utiles.

Category source: ps_category_product.id_category IN saved category IDs
Manufacturer source: ps_product.id_manufacturer IN saved manufacturer IDs
Final discount filter: id_product not in resolved exclusion list

Non, l’override cible les réductions monétaires des règles panier, pas l’avantage de livraison gratuite lui-même. Si le module est désactivé, si aucun produit exclu n’est configuré, ou si la règle panier n’a pas de réduction en pourcentage ou à montant fixe, l’override délègue au calcul normal CartRule de PrestaShop.

Exemple : un bon donne 10% de remise plus la livraison gratuite, et le panier ne contient que des produits exclus par ce module. La remise produit devient 0 parce que chaque produit est exclu de la réduction monétaire, mais si la règle a free_shipping et que PrestaShop calcule l’action de livraison, l’override délègue au calcul parent de livraison, donc la partie livraison gratuite peut toujours s’appliquer.

Pour les paniers mixtes, le module filtre les produits exclus avant le calcul parent. Les remises en pourcentage s’appliquent uniquement aux produits éligibles, et les remises à montant fixe sont calculées par PrestaShop sur le package filtré.

Le chemin rapide est important pour les bons de livraison gratuite uniquement. Lorsqu’une règle panier n’a pas de reduction_percent et pas de reduction_amount, l’override retourne le résultat parent PrestaShop sans filtrer le package. Cela signifie qu’un bon de livraison gratuite pur suit les conditions normales de bon PrestaShop et n’est pas réduit simplement parce que des produits sont dans la liste d’exclusion.

Lorsque tous les produits sont exclus et qu’une règle combine une remise monétaire avec la livraison gratuite, l’override retourne 0 pour la partie monétaire sauf si le filtre courant est l’un des filtres d’action shipping/all de PrestaShop. Pour ces filtres shipping/all, il appelle le calcul parent avec FILTER_ACTION_SHIPPING, ce qui est la raison au niveau source pour laquelle l’avantage de livraison peut rester disponible.

Un piège pratique : l’avis panier optionnel est séparé des maths de remise. Le renderer d’avis vérifie si le module et l’avis sont activés, si le panier a des règles panier, et si des produits exclus sont présents. Il n’inspecte pas si la règle panier est monétaire ou uniquement livraison gratuite ; le message peut donc rester informatif pendant que PrestaShop gère la livraison normalement.

Oui, le module peut afficher un avis panier lorsque des produits exclus sont présents. Dans PrestaShop, l’avis apparaît uniquement lorsque le module et le réglage d’avis sont activés, que le panier a des règles panier, et qu’au moins un produit du panier correspond à la liste d’exclusion.

La fonctionnalité d’avis est activée par défaut à l’installation avec SHOW_NOTICE=1. Le texte d’avis multilingue par défaut est The following products are excluded from the applied discount:, et les marchands peuvent modifier NOTICE_TEXT depuis les réglages du module. Le module enregistre à la fois displayShoppingCart et displayShoppingCartFooter ; le hook footer est conservé comme alias de compatibilité pour les boutiques qui utilisent encore l’ancien placement de hook.

Le renderer dispose aussi d’un garde anti-doublon. Une fois qu’un avis a été rendu pendant la requête, $cartNoticeRendered empêche le même message d’apparaître deux fois si les deux hooks panier s’exécutent dans le thème.

Le module construit la liste de noms produits depuis les produits du panier courant dont id_product apparaît dans la liste d’exclusion résolue. Si product_name est indisponible, il se rabat sur name, puis sur un libellé générique de numéro produit. Le template échappe le texte d’avis et les noms de produits avant la sortie.

Notice shown only if:
ENABLED=1
SHOW_NOTICE=1
cart has at least one cart rule
cart contains at least one resolved excluded product

Si aucun bon/règle panier n’est appliqué, l’avis est volontairement masqué même si des produits exclus sont dans le panier. Cela lie le message au moment où le client attend une remise et peut se demander pourquoi certains articles sont restés au prix plein.

Le champ obligatoire est le HubSpot Portal ID. L'alerte de configuration requise du module reste active tant que ce champ est vide.

Le template HubSpot examiné identifie les clients connectés par e-mail lorsque pass-user-data est activé. Il n'envoie pas de données de visiteurs anonymes depuis PHP.

Le trait de chat partagé prend en charge toutes les pages, les pages produit, les pages catégorie ou les pages liées au checkout comme cart, order, order-opc, orderopc et checkout.

Non. Le code utilise un timeout configuré en millisecondes avant de rendre le widget. Il s'agit d'un délai temporel, pas d'un chargement déclenché par une interaction.