Module d'attributs avec des images générales ou spécifiques

12/11/2026
v4.4.2

Moins de travail de style pour le navigateur sur les pages avec vignettes. LE PROBLÈME : Pour afficher les saveurs au-dessus du nom, la feuille de style utilisait `:has()` pour rechercher le bloc de texte de chaque carte. Ce sélecteur n'avait pas de sujet : le navigateur le vérifiait sur chaque élément de chaque vignette (environ 60 par carte) et répétait ce processus à chaque modification, ce qui est constant sur une page avec des images différées et des carrousels.

LA SOLUTION : Le JavaScript du module attribue une classe à ce bloc lors de son chargement, tout en réservant la hauteur de la bande. La feuille utilise ensuite cette classe. Les cartes suivantes (filtres, onglets, menu « Charger plus », carrousels) sont marquées avant leur affichage.

VÉRIFIÉ Même position et taille de la bande, du nom et de la carte dans les 26 vignettes d'une couverture à 390 et 1440 px, même décalage cumulatif (CLS) et aucune erreur JavaScript ; une carte insérée plus tard est marquée avant l'image suivante.

12/11/2026
v4.4.1

Le « +N » dans les vignettes ne ralentit plus le chargement de la page. PROBLÈME : Pour déterminer le nombre de saveurs par ligne, le module les réaffichait toutes et mesurait chaque ligne individuellement, au chargement initial puis à trois reprises. Chaque mesure obligeait le navigateur à redimensionner la page entière : environ 30 ms par chargement pour une catégorie de 20 vignettes sur un ordinateur performant, et trois à quatre fois plus longtemps sur un appareil mobile. Ce problème survenait même avec les thèmes qui masquaient les saveurs dans la liste, puisqu’il n’y avait rien à compter.

LA SOLUTION Le calcul est effectué après que le navigateur a déjà positionné la page (ResizeObserver), juste avant son rendu, et n'est répété que si la largeur d'une section change : chargement tardif des photos, rotation du téléphone, ouverture d'un onglet ou assemblage d'un carrousel. Toutes les mesures sont d'abord lues, puis enregistrées, en ne tenant compte que des modifications. Les onglets créés à leur ouverture (événement rkrPestanaAbierta) sont également comptabilisés.

VÉRIFIÉ : Les images cachées et le « +N » dans chaque vignette sont identiques à ceux de la version 4.4.0 , à 390 et 1440 px, lors du franchissement du seuil de 767 px, dans une catégorie et sur l’ensemble des 18 onglets de la page d’accueil ; aucune erreur JavaScript n’a été détectée. Dans les navigateurs ne prenant pas en charge ResizeObserver, le calcul est effectué comme précédemment, les mesures étant regroupées.

12/11/2026
v4.4.0

Les vignettes d'un carrousel ou d'une page de catégorie affichent leurs saveurs en une seule requête. PROBLÈME : Depuis la version 4.3.9 , chaque produit nécessite ses combinaisons en une seule requête : sur une page d'accueil comportant 98 produits différents, cela représente 98 requêtes.

LA SOLUTION : PrestaShop calcule les données de tous les produits d’une liste (catégories, résultats de recherche, nouveautés, meilleures ventes, offres et carrousels utilisant ces mêmes listes) avant d’afficher le premier produit. Le module référence ces produits au survol de la souris et, lors de l’affichage du premier, il lit simultanément les combinaisons de tous les produits. Si un thème affiche les produits un par un, sans effectuer ce calcul préalable, le comportement reste identique à celui de la version 4.3.9.

VÉRIFIÉ. Page d'accueil d'une boutique réelle (PrestaShop 8.2, Creative Elements, 127 vignettes) : de 98 à 24 requêtes combinées ; mêmes thèmes, images et liens dans chaque vignette. Banque de 60 vignettes, présentation complète : de 120 à 70 requêtes dans les versions 8.2.8 et 1.7.8.11 , de 191 à 141 dans la 9.1.5 , et dans les trois versions, les mêmes 381 thèmes avec les mêmes données.

POUR LES DÉVELOPPEURS Nouvelle action de hook GetProductPropertiesBefore (enregistrée par la mise à niveau) : enregistre uniquement l’identifiant du produit, n’effectue aucune requête.

12/11/2026
v4.3.9

L'affichage de vignettes avec des images combinées empêche le chargement de la base de données. PROBLÈME : Mesuré sur la page d'accueil d'une boutique réelle (PrestaShop 8.2.4 , 132 vignettes en carrousel) : pour chaque vignette, le module vérifiait ses paramètres, demandait à PrestaShop toutes les combinaisons disponibles ainsi que leurs niveaux de stock, et, pour chaque lien vers une variante, relisait les attributs de cette combinaison. Environ 1 000 requêtes étaient effectuées rien que pour afficher les variantes, soit entre 8 et 47 ms par produit. Le cache de la page masquait ce processus aux visiteurs anonymes, mais pas à ceux ayant déjà un panier ou une session ouverte.

LA SOLUTION

• Une seule requête de combinaisons avec leurs attributs et leurs noms, sans stock ni prix, que la miniature n'utilise pas.
• Le lien pour chaque saveur est créé à partir des données suivantes : PrestaShop fournit l’URL de la combinaison, et le module fournit l’ancre (#/valeur-du-groupe). Le format de l’ancre (nom du groupe et ordre des attributs) varie entre les versions 1.7, 8 et 9 ; le module la compare à l’ancre PrestaShop lors de sa première utilisation, puis la réutilise.
• Les images globales et la liste des produits avec des paramètres personnalisés sont lues une fois par page, et non une fois par vignette.
• Si un même produit apparaît dans plusieurs carrousels, il n'est calculé qu'une seule fois.
• Si le produit n'a pas de groupe de couleurs, PrestaShop n'est plus sollicité pour calculer ses variations de couleurs, qui étaient auparavant inexistantes. VÉRIFIÉ : Une base de données de 48 produits avec 6 à 10 saveurs (dont 12 avec saveur et taille), 60 vignettes avec 12 doublons. Requêtes du module : de 653 à 126 dans 8.2.8 , de 632 à 126 dans la 9.1.5 et de 661 à 135 dans la 1.7.8.11; il y a désormais 2 requêtes par nouveau produit et 0 par doublon. Les images, les noms, l'ordre et les liens des vignettes sont identiques, et les captures d'écran avant/après sont identiques. Les liens ouvrent la combinaison correcte sur la page produit. UN CHANGEMENT NOTABLE : Lorsqu'un produit combine deux groupes (saveur et taille), chaque saveur apparaît dans plusieurs combinaisons. Auparavant, son lien menait à n'importe quelle combinaison et pouvait changer d'un chargement à l'autre. Désormais, la combinaison par défaut est utilisée si la variante est spécifiée, sinon, toujours la même (celle avec l'ID le plus bas). POUR LES DÉVELOPPEURS : Les miniatures n'appellent plus `Product::getAttributesGroups()`, les hooks `actionProductGetAttributesGroupsBefore` et `actionProductGetAttributesGroupsAfter` ne sont donc plus déclenchés. Pour un produit sans groupe de couleurs, le module ne lit plus `main_variants` avant de l'écrire : PrestaShop le laisse toujours vide dans ce cas. Si un autre module l'avait renseigné au préalable dans ce même hook, il est maintenant remplacé par les variantes du module au lieu d'être décoré. [sin destacar] Licence AFL-3.0 dans tous les en-têtes et dans `LICENSE.txt` ; CustomizationPolicy.txt.

09/09/2026
v4.3.8

La bande de combinaisons ne perturbe plus la grille. PROBLÈME : La bande n’occupait de la hauteur que lorsque le produit comportait des images combinées. Mesuré dans une catégorie réelle avec des cartes de 374 px : une carte sans combinaisons mesurait 466 px et une avec combinaisons 532 px. En réduisant la taille de la fenêtre, un second décalage apparaissait car six combinaisons s’étendaient sur deux ou trois lignes. La grille se désalignait et ressemblait à un modèle cassé.

LA SOLUTION, en trois parties

• La bande est réservée sur toutes les cartes, qu'elles comportent ou non des combinaisons, mais uniquement dans les listes où au moins une carte en contient. Cette marque est définie par le JavaScript du module (classe rkr-listing-with-swatches dans le conteneur de la liste). Un catalogue sans images de combinaisons ne perd aucun pixel ; lorsqu'il y a des combinaisons, toutes les cartes ont la même taille.
• La bande est toujours composée d'une seule ligne et d'une hauteur fixe : elle ne s'allonge jamais. Tout élément qui dépasse ne se prolonge pas est comptabilisé comme « +N ». Ainsi, la hauteur est indépendante du nombre de combinaisons (0, 1, 2, 6 ou 20) et de la largeur de l'écran.
• Les vignettes apparaissent désormais AU-DESSUS du nom du produit : le bloc de texte de la fiche devient une colonne flexible et la bannière est positionnée à l'emplacement -1. Son positionnement est assuré par `:has()`, ce qui la rend indépendante de la façon dont chaque thème nomme ce bloc. Si le navigateur ne la prend pas en charge, la bannière reste à l'emplacement défini par le thème et le reste continue de fonctionner. Une hauteur fixe importante pour tous les produits a été volontairement abandonnée : elle aurait créé un espace vide pour les produits sans combinaisons, qui sont majoritaires dans un catalogue classique. LE « +N » EST CALCULÉ PAR LE MODULE. Le compteur du thème est calculé à partir de SES dimensions, et non de celles du module, et affichait une valeur différente de celle affichée ; cette valeur est désormais masquée. Le compteur du module est calculé arithmétiquement (largeur de la bande par rapport à la largeur de l'image), et non en mesurant la position finale de chaque image : une mesure prise avant la fin du rendu par le navigateur laisserait une image coupée en deux par le bord. Il est recalculé lors du redimensionnement et du rafraîchissement de la liste suite à l'application de filtres ou à la pagination. VÉRIFIÉ : Dans une catégorie de 20 produits avec 0, 1, 2 et 6 combinaisons : à 1 600 px, 19 des 20 cartes ont exactement la même taille (322,78 px), et la seule différence est due à la ligne de réduction thématique, et non à la bande. À 1 024 px, 5 combinaisons et « +1 » sont visibles ; à 375 px, 3 combinaisons et « +3 » sont visibles, sans image recadrée.