Module de bloc HTML ou JavaScript n'importe où dans la boutique

03/11/2026
v4.3.0

Ajouté

• Segmentation par bloc selon application mobile ou Web :
• Sélecteur direct dans l'en-tête du bloc ( Afficher dans : Tous les environnements, Application mobile uniquement ou Web uniquement en dehors de l'application).
• Règle conditionnelle avancée dans les règles d'affichage ( application mobile : égale à Oui/Non), vous permettant de combiner la condition avec des pages, des catégories, des produits, des clients ou des paniers.
• Badge de colonne et d'état dans la liste du Back-Office ( Tous , Appli , Web ).
• Détection compatible et découplée avec l'écosystème rkrapp ( RkrAppMode , User-Agent RkrApp/... , cookie rkrapp_mode et paramètre ?rkrapp=1|0 ).

14/10/2026
v4.2.1

Arrangé

• Un hook personnalisé était inutile si le thème l'appelait avec {hook h='…'} . Sa création ne faisait que sauvegarder son nom : le module ne s'y connectait pas (seul ` install() le faisait, et avec les hooks par défaut). Par conséquent, PrestaShop ne l'appelait pas et les blocs associés à ce hook n'apparaissaient pas, sans qu'aucune erreur ne soit signalée. Seul {widget name='rkrhtmlblocks' hook='…'} fonctionnait. Désormais, lors de la sauvegarde d'un hook personnalisé, le module s'y connecte (et PrestaShop le crée s'il n'existe pas) ; le renommer ou le supprimer le dissocie de son ancien nom, sauf s'il s'agit d'un hook par défaut ou s'il est utilisé par un autre hook personnalisé. La fonction `update` met à jour tous les hooks personnalisés existants.
• Des erreurs d'anglais dans les chaînes de caractères sources , telles qu'elles apparaissent dans une boutique anglophone, ont été corrigées : les opérateurs de règles étaient « less than », « greater than », « equals to » et « not equals to » (désormais « less than », « greater than », « equal to », « not equal to »), et le hook displayProductAdditionalInfo s'appelait « Product addition info » (désormais « Additional product info »). Le reste du catalogue a été revu : la description du module (« block » → « blocks », également dans config.xml ), les messages « Please provide valid name! » sans article, « css » et « cms » en minuscules, l'aide Smarty (« every smarty functions », « We do not support on help using smarty »), la variable du nom du client et sept descriptions de hooks (« thumbnails.. », « on the top of », « page not found page », « top navigation left side », un point manquant). La modification du code source modifie la clé : en.php et es.php sont régénérés, avec le même espagnol qu'auparavant. L'aide relative aux règles ( help_filter_rules.tpl , en anglais, non traduit) utilise désormais les nouveaux noms d'opérateurs.

10/10/2026
v4.2.0

Les blocs RKR Extra Data s'insèrent dans un bloc HTML. Avec RKR Extra Data 1.2.0 ou une version ultérieure installée, son bouton apparaît au-dessus du contenu (et des modèles) du bloc : il ouvre l'éditeur d'onglets, la FAQ, les notifications, les calculateurs, etc., et l'insère à l'emplacement du curseur, à l'aide de l'un des quatre éditeurs (texte, visuel basique, visuel avancé ou code). Dans la boutique, le bloc apparaît déjà converti selon le hook choisi.

Les deux modules restent indépendants : sans RKR Extra Data, aucun bouton n’apparaît et tout fonctionne comme dans 4.1.3; sans lui, RKR Extra Data reste identique dans les produits, les catégories et les pages.

Corrigé

• Lorsque l'option « Activer Smarty » était activée, un bloc de données supplémentaires RKR provoquait le plantage de la page. Le constructeur insérait les blocs entre accolades et sans espaces ( {rkred-faq} … {/rkred-faq} ), ce qui correspond à la syntaxe Smarty : la compilation du contenu échouait, entraînant le plantage de la page entière. Désormais, ces blocs sont placés dans des balises {literal} avant d'être traités par Smarty et sont intégrés intacts dans le HTML ; les variables ( {$…} , {shop_name} ) sont toujours remplacées. Si le contenu contient déjà une {literal} ajoutée manuellement, celle-ci reste inchangée.
• La tentative d'enregistrement d'un bloc a généré une erreur « Permission refusée » lorsque le dossier du module était inaccessible en écriture (hébergement protégé ou module monté en mode développement). Auparavant, les messages entre les écrans et les données d'importation étaient enregistrés dans des fichiers .json au sein du module ; ils sont désormais stockés dans le cache de PrestaShop.
• Des erreurs JavaScript se produisaient lors du changement d'éditeur. Le passage d'un éditeur visuel à un autre entraînait l'affichage, dans les 7 premières secondes, du message « Impossible de lire les propriétés de null (lecture de 'body') » dans la console, une erreur par langage : le plugin AutoSize de TinyMCE continuait de mesurer un éditeur déjà fermé. Le contenu n'était pas perdu, mais la console se remplissait à chaque modification.

Validateur d'extensions

Voici ce qu'indiquait le validateur, pour toutes les versions antérieures à celle-ci :

• "Utilisation de la classe Context" (44 fois) : le module donne son contexte à RkrhtmlblocksHelper lors de sa construction et les autres classes le demandent à cet endroit.
• HTML écrit en PHP : le résumé des règles de la liste est constitué de tooltip.tpl , les messages vont dans lineas.tpl et le bouton « Retour » utilise l’icône HelperForm.
• file_get_contents() → Tools::file_get_contents() lors de l'importation.
• Module::isEnabled() , obsolète dans la version 9.0 : voir module_shop .
• Le .htaccess à la racine du module était manquant.
• PHPStan (niveau 5, PrestaShop 9.1.5 ) : smartyRegisterFunction() → registerPlugin() de Smarty (c'est exactement ce que j'ai fait avec $lazy = false ), types de propriétés et array_slice() avec des entiers.
• Format (PHP CS Fixer) en six fichiers. Testé sur ps91 : affichage des règles contextuelles (page, catégorie), liste avec résumé des règles, enregistrement d’un bloc, appels de filtres AJAX, fonctionnement sans erreur des quatre éditeurs et boutique avec Smarty activé. Aucune modification de la base de données : aucun script de mise à jour.

07/10/2026
v4.1.3

Moins de requêtes côté client : de 40 à 2 sur la page d’accueil. Le module n’effectuait pas de requêtes lourdes, mais de nombreuses : une pour chaque hook ou position rendu (26 sur la page d’accueil) et, de plus, une pour chaque bloc afin de lire ses filtres (14). Chaque requête prenait quelques dixièmes de milliseconde, mais le temps total s’élevait à environ 18 ms par page.

Désormais, les blocs de langue et de boutique actifs sont lus simultanément et servis depuis la mémoire via un hook, et tous les filtres sont lus en une seule requête ( IN ). L'allocation mémoire est temporaire : il n'y a pas de cache persistant susceptible d'être invalidé. Le HTML et les règles d'affichage (page, catégorie, groupe, appareil, etc.) restent inchangés.

• Page d'accueil : 40 requêtes pour 2. Catégorie : 19 pour 2. Produit : 25 pour 2.
• L'administration continue de lire en direct les filtres de chaque bloc.

29/09/2026
v4.1.2

L'autre moitié de ce qui s'est passé dans la 4.1.1. Celle-ci a fermé les 102 notifications « Traduction introuvable » laissées par PHP ; il restait 54 chaînes dans les modèles d'administration , qui passent par un autre chemin et la réécriture l() ne suffit pas.

smartyTranslate() ` (qui se cache derrière ` {ls='...' mod='rkrhtmlblocks'} `) appelle ` getModuleTranslation() avec cinq arguments. La fonction de traduction automatique de Symfony est donc activée et il est impossible de la désactiver depuis le module. Chacune des 54 erreurs a laissé une notification dans le store anglais ; deux d'entre elles en ont également laissé une en espagnol , Variable et -- , qui s'écrivent de la même manière dans les deux langues : la preuve que le problème n'a jamais été un « manque de traduction ».

Les messages sont désormais traduits en PHP, dans classes/RkrhtmlblocksTextos.php , et le modèle affiche la variable échappée. Mesure effectuée : 54 → 0 avec shared/scripts/medir-avisos-traduccion.py . Sur la version ps1788, avec la boutique en anglais, le nombre d' alertes affichées sur l'écran de configuration passe de 37 à 0. Le même outil, appliqué à la version 4.1.1 (fichier ZIP), affiche toujours 54, ce qui explique la valeur de zéro.

Et au fait, une case qui n'a jamais été traduite

Les quatre textes « Comment utiliser les hooks personnalisés » étaient intégrés en anglais directement dans le modèle, sans passer par une fonction de traduction : ce panneau apparaissait également en anglais dans une boutique espagnole. Ils figurent désormais dans le catalogue, dans les deux langues.