Attributmodul mit allgemeinen oder spezifischen Bildern

12.11.2026
v4.4.2

Weniger Styling-Aufwand für den Browser auf Seiten mit Vorschaubildern. DAS PROBLEM: Um die Geschmacksrichtungen über dem Namen anzuzeigen, verwendete das Stylesheet `:has()`, um den Textblock jeder Karte zu suchen. Dieser Selektor hatte kein Subjekt: Der Browser überprüfte ihn für jedes Element jedes Vorschaubildes (etwa 60 pro Karte) und wiederholte diesen Vorgang bei jeder Änderung innerhalb dieser Elemente, was auf einer Seite mit verzögerten Bildern und Karussells ein ständiger Vorgang ist.

DIE LÖSUNG: Das JavaScript des Moduls kennzeichnet diesen Block beim Laden mit einer Klasse und reserviert gleichzeitig die Höhe der Leiste. Das Sheet verwendet diese Klasse. Nachfolgende Karten (Filter, Tabs, „Mehr laden“, Karussells) werden vor dem Rendern gekennzeichnet.

ÜBERPRÜFT: Gleiche Position und Größe des Streifens, des Namens und der Karte in den 26 Miniaturansichten eines Covers bei 390 und 1440 Pixeln, gleicher kumulativer Offset (CLS) und keine JavaScript-Fehler; eine später eingefügte Karte wird vor dem nächsten Frame markiert.

12.11.2026
v4.4.1

Das „+N“ in den Vorschaubildern verlangsamt das Laden der Seite nicht mehr. DAS PROBLEM: Um die Anzahl der Geschmacksrichtungen pro Zeile zu ermitteln, zeigte das Modul alle Bilder erneut an und maß jede Zeile einzeln – sowohl beim ersten Laden als auch drei weitere Male danach. Jede Messung zwang den Browser, die gesamte Seite neu zu laden: etwa 30 ms pro Ladevorgang für eine Kategorie mit 20 Vorschaubildern auf einem schnellen Computer und drei- bis viermal so lange auf einem Mobilgerät. Dies trat sogar bei Designs auf, die die Geschmacksrichtungen in der Liste ausblendeten, da es dort nichts zu zählen gab.

DIE LÖSUNG: Die Berechnung erfolgt, nachdem der Browser die Seite positioniert hat (ResizeObserver), kurz vor dem Rendern, und wird nur wiederholt, wenn sich die Breite eines Abschnitts ändert: z. B. durch verspätet eintreffende Fotos, Drehung des Smartphones, Öffnen eines Tabs oder Aufbau eines Karussells. Zuerst werden alle Messwerte erfasst und anschließend nur die Änderungen berücksichtigt. Beim Öffnen erstellte Tabs (rkrPestanaAbierta-Ereignis) werden ebenfalls mitgezählt.

VERIFIZIERT: Dieselben ausgeblendeten Bilder und dasselbe „+N“ in jedem Vorschaubild wie in Version 4.4.0 , bei 390 und 1440 Pixeln, beim Überschreiten der 767-Pixel-Schwelle, in einer Kategorie und auf allen 18 Tabs einer Startseite; keine JavaScript-Fehler. In Browsern ohne ResizeObserver erfolgt die Berechnung wie zuvor, wobei die Messwerte gruppiert werden.

12.11.2026
v4.4.0

Die Vorschaubilder auf einer Karussell- oder Kategorieseite lesen ihre Geschmacksrichtungen in einer einzigen Abfrage aus. DAS PROBLEM: Seit Version 4.3.9 benötigt jedes Produkt seine Kombinationen in einer einzigen Abfrage: auf einer Startseite mit 98 verschiedenen Produkten 98 Abfragen.

DIE LÖSUNG: PrestaShop berechnet die Daten für alle Produkte einer Liste (Kategorie, Suche, Neuheiten, Bestseller, Angebote und Karussells, die dieselben Listen verwenden), bevor das erste Produkt angezeigt wird. Das Modul greift beim Überfahren mit der Maus auf diese Produkte zu und liest beim Anzeigen des ersten Produkts die Kombinationen aller Listen gleichzeitig aus. Wenn ein Theme die Produkte nacheinander anzeigt, ohne diese Berechnung vorher durchzuführen, bleibt alles wie in Version 4.3.9.

VERIFIZIERT. Homepage eines realen Shops (PrestaShop 8.2, Creative Elements, 127 Thumbnails): Die Anzahl der Abfragen sank von 98 auf 24; in jedem Thumbnail wurden dieselben Varianten, Bilder und Links verwendet. Datenbank mit 60 Thumbnails, vollständige Darstellung: Die Anzahl der Abfragen sank von 120 auf 70 in 8.2.8 und 1.7.8.11 , von 191 auf 141 in 9.1.5 ; in allen drei Versionen wurden dieselben 381 Varianten mit denselben Daten verwendet.

FÜR ENTWICKLER Neuer Hook actionGetProductPropertiesBefore (registriert durch das Upgrade): speichert nur die Produkt-ID, führt keine Abfragen durch.

12.11.2026
v4.3.9

Vorschaubilder mit Kombinationsbildern laden die Datenbank nicht mehr. DAS PROBLEM: Gemessen auf der Startseite eines realen Shops (PrestaShop 8.2.4 , 132 Vorschaubilder in Karussells): Für jedes Vorschaubild überprüfte das Modul seine Einstellungen, forderte alle Kombinationen mit ihren Lagerbeständen von PrestaShop an und las für jeden Geschmackslink die Attribute dieser Kombination erneut ein. Allein für die Anzeige der Geschmacksrichtungen wurden ca. 1.000 Abfragen durchgeführt, mit Ladezeiten zwischen 8 und 47 ms pro Produkt. Der Seitencache verbarg dies für anonyme Besucher, nicht aber für diejenigen, die bereits einen Warenkorb oder eine Sitzung hatten.

DIE LÖSUNG

• Eine einzelne Abfrage von Kombinationen mit ihren Attributen und Namen, ohne Lagerbestand oder Preise, die im Vorschaubild nicht verwendet werden.
• Der Link für jede Geschmacksrichtung wird anhand folgender Daten erstellt: PrestaShop liefert die URL für die Kombination, und das Modul stellt den Anker (#/Gruppenwert) bereit. Das Ankerformat (Gruppenname und Attributreihenfolge) variiert zwischen den Versionen 1.7, 8 und 9; das Modul prüft es beim ersten Bedarf anhand des PrestaShop-Ankers und verwendet ihn anschließend wieder.
• Globale Bilder und die Liste der Produkte mit benutzerdefinierten Einstellungen werden einmal pro Seite und nicht einmal pro Miniaturansicht eingelesen.
• Wenn dasselbe Produkt in mehreren Karussells erscheint, wird es nur einmal berechnet.
• Wenn ein Produkt keiner Farbgruppe zugeordnet ist, berechnet PrestaShop nicht mehr die Farbvarianten, die zuvor leer waren. VERIFIZIERT: Eine Datenbank mit 48 Produkten und 6 bis 10 Geschmacksrichtungen (davon 12 mit Geschmacksrichtung und Größe), 60 Vorschaubildern mit 12 Duplikaten. Modulabfragen: von 653 auf 126 in 8.2.8 , von 632 auf 126 in 9.1.5 und von 661 auf 135 in 1.7.8.11; jetzt gibt es 2 Abfragen pro neuem Produkt und 0 pro Duplikat. Bilder, Namen, Reihenfolge und Links in den Vorschaubildern sind identisch, ebenso die Screenshots vor und nach der Änderung. Die Links öffnen die korrekte Kombination auf der Produktseite. EINE AUFFÄLLIGE ÄNDERUNG: Wenn ein Produkt zwei Gruppen (Geschmacksrichtung und Größe) kombiniert, wird jede Geschmacksrichtung in mehreren Kombinationen angezeigt. Zuvor führte der Link zu jeder beliebigen Kombination und konnte sich bei jedem Seitenaufruf ändern. Es wird nun die Standardkombination verwendet, falls es sich um die entsprechende Variante handelt, andernfalls immer dieselbe (die mit der niedrigsten ID). FÜR ENTWICKLER: Thumbnails rufen nicht mehr `Product::getAttributesGroups()` auf, daher werden die Hooks `actionProductGetAttributesGroupsBefore` und `actionProductGetAttributesGroupsAfter` nicht mehr durch sie ausgelöst. Bei einem Produkt ohne Farbgruppe liest das Modul `main_variants` nicht mehr vor dem Schreiben: PrestaShop lässt es in diesem Fall immer leer. Falls ein anderes Modul es zuvor im selben Hook befüllt hat, wird es nun durch die Varianten des Moduls ersetzt, anstatt es zu formatieren. [sin destacar] AFL-3.0-Lizenz in allen Headern und in `LICENSE.txt`; CustomizationPolicy.txt.

09.09.2026
v4.3.8

Der Kombinationsstreifen stört das Raster nicht mehr. DAS PROBLEM: Der Streifen belegte nur dann Höhe, wenn das Produkt Kombinationsbilder enthielt. Gemessen in einer realen Kategorie mit 374px großen Karten: Eine Karte ohne Kombinationen maß 466px, eine mit Kombinationen 532px. Beim Verkleinern des Fensters entstand ein zweiter Sprung, da sechs Kombinationen zwei oder drei Zeilen umfassten. Das Raster war dadurch verschoben und wirkte wie eine fehlerhafte Vorlage.

DIE LÖSUNG, in drei Teilen

• Der Streifen ist auf allen Karten reserviert, unabhängig davon, ob sie Farbkombinationen enthalten, jedoch nur in Angeboten, in denen mindestens eine Karte Farbkombinationen aufweist. Diese Markierung wird durch das JavaScript des Moduls (Klasse rkr-listing-with-swatches im Angebotscontainer) gesetzt. Ein Katalog ohne Farbkombinationsbilder verliert kein einziges Pixel; sind Farbkombinationen vorhanden, haben alle Karten die gleiche Größe.
• Der Streifen besteht IMMER aus einer einzigen Zeile und hat eine feste Höhe: Er wächst nicht. Alles, was nicht hineinpasst, wird nicht umgebrochen, sondern als „+N“ gezählt. Die Höhe ist daher unabhängig von der Anzahl der Kombinationen (0, 1, 2, 6 oder 20) und der Bildschirmbreite.
• Die Vorschaubilder erscheinen nun ÜBER dem Produktnamen: Der Textblock der Karte wird zu einer Flexbox-Spalte, und das Banner erhält die Position -1. Es wird mithilfe von `:has()` positioniert, sodass es nicht von der Benennung des Blocks durch das jeweilige Theme abhängt. Falls der Browser dies nicht unterstützt, bleibt das Banner an der vom Theme festgelegten Position, und die übrigen Funktionen bleiben erhalten. Eine große, feste Höhe für alle Produkte wurde bewusst verworfen, da dadurch unnötiger Platz für Produkte ohne Kombinationen entstanden wäre, die in einem typischen Katalog die Mehrheit bilden. Die Zahl „+N“ wird vom Modul berechnet. Der Zähler des Themes wird anhand seiner eigenen Größe berechnet, nicht anhand der des Moduls, und lieferte eine andere Zahl als die angezeigte; er ist nun ausgeblendet. Der Zähler des Moduls wird arithmetisch berechnet (Bandbreite versus Bildbreite), nicht durch Messen der Position jedes Bildes: Eine Messung vor Abschluss des Browser-Renderings würde ein Bild am Rand halbieren. Die Berechnung erfolgt neu, wenn die Liste aufgrund von Filtern oder Paginierung in der Größe angepasst oder neu gezeichnet wird. VERIFIZIERT: In einer Kategorie mit 20 Produkten und 0, 1, 2 und 6 Kombinationsmöglichkeiten: Bei einer Auflösung von 1600 px sind 19 der 20 Karten exakt gleich groß (322,78 px). Der einzige Unterschied ergibt sich aus der Rabattzeile, nicht aus dem Streifen. Bei 1024 px sind 5 Kombinationen und „+1“ sichtbar; bei 375 px sind 3 Kombinationen und „+3“ sichtbar, ohne dass Bilder beschnitten werden.