RKR Alert News : Informez vos clients lorsque vous publiez un produit qu’ils recherchaient.

05/11/2026
v1.3.0

Révision du package 1.2.0 : dans sa version originale, aucune alerte n’a jamais été envoyée à un client.

Fixé

• L'enregistrement d'une alerte depuis la boutique (page de compte ou page produit) a entraîné une erreur fatale.
• Les alertes sans limite de prix étaient stockées avec un maximum de 0 et ne correspondaient jamais à un produit.
• Les e-mails affichaient le code Smarty du modèle ( {$shop_name|escape...} , {foreach} ) et le message « Array » : les modèles d'e-mails du module ne sont pas gérés par Smarty dans PrestaShop. La liste des produits est désormais générée par le module et les modèles utilisent uniquement des {placeholders} . Les e-mails existent en anglais, espagnol, français, italien, allemand et portugais (une copie est disponible pour les autres langues). Le nom et l'adresse de l'expéditeur ont été inversés.
• Les textes enregistrés dans l'interface d'administration (objets des e-mails, introduction, mentions légales, titre et texte des widgets) étaient stockés sous un nom de configuration et lus sous un autre, et n'ont donc jamais été utilisés. Désormais, chaque clé utilise RKR_ALERTNEWS_ ; la mise à jour renomme les anciennes clés.
• L'enregistrement de l'onglet Général a désactivé l'ensemble du module.
• Les alertes de catégorie n'ont jamais correspondu ( category_product n'a pas id_shop ), elles n'ont examiné que les sous-catégories directes et ont planté sur PHP 8 ( Category::getChildren() renvoie des lignes) : l'arbre de catégorie complet est maintenant utilisé.
• Un produit a été marqué comme traité avant d'être finalisé (PrestaShop 8/9 le crée vide, les importations ajoutent les catégories et le stock ultérieurement) et a ensuite été définitivement perdu. Les produits sont vérifiés une fois la requête enregistrée (et lors des enregistrements ultérieurs) et uniquement s'ils sont actifs, visibles, nommés et non en brouillon ; un produit publié plusieurs jours après sa création est donc toujours détecté. Si seul le filtre « en stock » échoue, le produit est vérifié à nouveau pendant une semaine.
• Recherches enregistrées : la casse et les accents sont ignorés, les mots peuvent apparaître dans n’importe quel ordre, et « red » ne correspond plus à « redondo » au milieu d’un mot uniquement à cause de la sous-chaîne.
• La vérification des alertes de doublons n'a jamais fonctionné (erreur SQL : LIMIT 1 deux fois) ; la correspondance des clients à l'importation présentait la même erreur.
• Les requêtes de la boutique utilisaient un paramètre rkr_token qu'un autre module Rekire intercepte également (redirection vers la page d'accueil pour les clients connectés) ; les paramètres sont maintenant rkran_token et rkran_action .
• Les prix figurant dans les courriels envoyés par la tâche cron ou par importation n'étaient pas formatés.
• Un même produit peut faire l'objet de plusieurs notifications (recherche + marque + catégorie, hook + cron) : les notifications sont uniques par alerte, produit et canal, et un seul e-mail affiche chaque produit une seule fois.
• Les produits qui ne tenaient pas dans un e-mail (nombre maximum par e-mail) ont été marqués comme envoyés ; ils attendent désormais le prochain envoi.
• Après la désinscription ou la suspension d'une alerte, les e-mails récapitulatifs mis en file d'attente étaient toujours envoyés.
• Modifier la fréquence ou le canal d'une alerte dans « Mes alertes » la met en pause (ou la reprend).
• La page « Mes alertes » et la page de désabonnement ont été affichées sans le thème (ni en-tête, ni styles, ni scripts).
• Le lien de désabonnement fonctionnait lors de la première requête GET : les scanners de liens de messagerie désabonnaient les clients. Le lien demande désormais une confirmation.
• Les résumés dépendent de l'heure précise d'exécution de la tâche cron ; ils sont envoyés une fois par intervalle programmé, quelle que soit la fréquence de cette dernière. Lorsque les e-mails instantanés sont désactivés, les alertes « instantanées » sont incluses dans le résumé quotidien.
• Les données de démonstration utilisaient de vrais clients : leurs alertes pouvaient envoyer de vrais e-mails et s’afficher dans la cloche de la boutique. Désormais, les lignes de démonstration ne sont plus envoyées aux clients, et leur suppression entraîne également la suppression de leurs notifications.
• L'exportation et l'effacement psgdpr n'ont rien donné (clé client incorrecte, type de retour incorrect).
• Le menu partagé « MODULES REKIRE » appartenait à ce module : chaque visite du panneau le supprimait et le recréait, et la désinstallation le supprimait en même temps que les menus des autres modules Rekire .
• Les employés disposant d'un accès en lecture seule pouvaient modifier les paramètres, supprimer des abonnements, importer et exporter des données clients : chaque action est désormais soumise à une vérification des autorisations de consultation, de modification et de suppression. En mode multi-boutiques, les employés ne voient que leurs propres boutiques.
• La modification de la fréquence ou du canal dans la liste des abonnements du back-office n'a pas été enregistrée.
• L'importation « remplacer » supprimait tous les abonnements (de chaque boutique) avant la vérification du fichier ; elle ne remplace désormais que les boutiques présentes dans les lignes valides. Les clients sont associés à la boutique cible, le fichier CSV contient l'identifiant de id_shop , l'historique des notifications n'est plus importé avec des identifiants externes et les paramètres importés subissent les mêmes vérifications que les formulaires (le point de terminaison AI et les groupes autorisés ne sont pas importés).
• Multiboutique : les paramètres par défaut sont globaux, les étiquettes et les noms de produits proviennent de la boutique appropriée, les liens des e-mails pointent vers la boutique du client.
• Le bouton de la page produit proposait le nom complet du produit comme recherche enregistrée et affichait l'identifiant de la catégorie au lieu de son nom ; il continuait de fonctionner après avoir changé la combinaison (Classique) et ouvrait la page de connexion pour les invités.
• Le lien « Mon compte » utilise le balisage du thème (Classic, Hummingbird 1.x et 2.x).
• L'éditeur de texte enrichi des courriels n'a pas pu être chargé.
• Le filtre CSS personnalisé peut être contourné ; les variables de thème et le CSS personnalisé sont servis sous forme de feuille de style.
• Requêtes sortantes de l'IA : l'adresse IP vérifiée est celle utilisée (pas de redirection DNS), uniquement HTTPS ; un point de terminaison invalide ne sauvegarde plus la moitié des paramètres de l'IA.
• Les animations de la cloche et du bouton produit ne se répètent plus indéfiniment.
• Les noms de classes génériques partagés avec d'autres modules ( .rkr-check , .rkr-bell-wrap ) ont réduit la fenêtre modale de la page produit à un seul mot par ligne et ont déplacé la cloche hors de son panneau ; le module utilise désormais ses propres noms.
• La liste des fréquences et des canaux sélectionnés dans le système de gestion interne était trop étroite pour être lisible.

Modifié

• Validateur d'extensions PrestaShop : pas nofilter , pas d'appels Context:: , pas de HTML dans PHP, version littérale, .htaccess racine.
• Traductions : es, fr, it, de et pt (XLIFF).