Attributes module with general or specific images

v4.4.22026/11/12

Less styling work for the browser on pages with thumbnails. THE PROBLEM: To display the flavors above the name, the stylesheet used `:has()` to search for the text block of each card. This selector had no subject: the browser checked it on every element of each thumbnail (about 60 per card) and repeated this process with any changes within them, which on a page with delayed images and carousels is constant.

THE SOLUTION: The module's JavaScript marks that block with a class upon loading, while also reserving the strip's height, and the sheet uses that class. Subsequent cards (filters, tabs, load more, carousels) are marked before being rendered.

VERIFIED Same position and size of the strip, name and card in the 26 thumbnails of a cover at 390 and 1440 px, same cumulative offset (CLS) and no JavaScript errors; a card inserted later is marked before the next frame.

v4.4.12026/11/12

The "+N" in the thumbnails no longer slows down page loading. THE PROBLEM: To determine how many flavors fit in the row, the module would redisplay them all and measure each row individually, both on initial load and three more times afterward. Each measurement forced the browser to resize the entire page: about 30 ms per load for a category of 20 thumbnails on a fast computer, and three to four times longer on a mobile device. This even happened with themes that hid the flavors in the list, where there was nothing to count.

THE SOLUTION The calculation is performed after the browser has already positioned the page (ResizeObserver), just before rendering it, and is repeated only if the width of a section changes: photos arriving late, the phone being rotated, a tab opening, or a carousel being assembled. First, all measurements are read, and then they are written, only including the changes. Tabs created upon opening (rkrPestanaAbierta event) are also counted.

VERIFIED: Same hidden images and the same "+N" in each thumbnail as in version 4.4.0 , at 390 and 1440 px, when crossing the 767 px threshold, in one category and across all 18 tabs of a homepage; no JavaScript errors. In browsers without ResizeObserver, it is calculated as before, with the readings grouped.

v4.4.02026/11/12

The thumbnails on a carousel or category page read their flavors in a single query. THE PROBLEM: Since version 4.3.9 , each product required its combinations in one query: on a homepage with 98 different products, 98 queries.

THE SOLUTION: PrestaShop calculates the data for all products in a list (category, search, new arrivals, best sellers, offers, and carousels that use those same lists) before displaying the first one. The module references these products as it hovers over them, and when displaying the first one, it reads the combinations from all of them at once. If a theme displays the products one by one, without first performing this calculation, everything remains as in version 4.3.9.

VERIFIED. Homepage of a real store (PrestaShop 8.2, Creative Elements, 127 thumbnails): from 98 to 24 combination queries; the same flavors, images, and links in each thumbnail. Bank of 60 thumbnails, full presentation: from 120 to 70 queries in 8.2.8 and 1.7.8.11 , from 191 to 141 in 9.1.5 , and in all three the same 381 flavors with the same data.

FOR DEVELOPERS New hook actionGetProductPropertiesBefore (registered by the upgrade): only saves the product id, does not query anything.

v4.3.92026/11/12

Thumbnails with combination images stop loading the database. THE PROBLEM Measured on the homepage of a real store (PrestaShop 8.2.4 , 132 thumbnails in carousels): for each thumbnail, the module checked its settings, requested all combinations with their stock levels from PrestaShop, and, for each flavor link, reread the attributes of that combination. Approximately 1,000 queries were made just to display the flavors, between 8 and 47 ms per product. The page cache hid this from anonymous visitors, but not from those who already had a cart or session.

THE SOLUTION

• A single query of combinations with their attributes and names, without stock or prices, which the thumbnail does not use.
• The link for each flavor is created using this data: PrestaShop provides the URL for the combination, and the module provides the anchor (#/group-value). The anchor format (group name and attribute order) varies between versions 1.7, 8, and 9; the module checks it against the PrestaShop anchor the first time it's needed and then reuses it.
• Global images and the list of products with custom settings are read once per page, not once per thumbnail.
• If the same product appears in multiple carousels, it is calculated only once.
• If the product doesn't have a color group, PrestaShop is no longer asked to calculate its color variations, which were always empty. VERIFIED: A database of 48 products with 6 to 10 flavors (12 of them with both flavor and size), 60 thumbnails with 12 duplicates. Module queries: from 653 to 126 in 8.2.8 , from 632 to 126 in 9.1.5 , and from 661 to 135 in 1.7.8.11; now there are 2 queries per new product and 0 per duplicate. The images, names, order, and links in the thumbnails are the same, and the before and after screenshots are identical. The links open the correct combination on the product page. A NOTICEABLE CHANGE: When the product combines two groups (flavor and size), each flavor appears in several combinations. Previously, its link led to any combination, and it could change from one load to another; Now it uses the default combination if it's that flavor, and if not, always the same one (the one with the lowest ID). FOR DEVELOPERS: Thumbnails no longer call Product::getAttributesGroups(), so the actionProductGetAttributesGroupsBefore and actionProductGetAttributesGroupsAfter hooks are no longer triggered from them. In a product without a color group, the module no longer reads main_variants before writing it: PrestaShop always leaves it empty in that case. If another module populated it beforehand in that same hook, it is now replaced by the module's variants instead of being decorated. [sin destacar] AFL-3.0 license in all headers and in LICENSE.txt; CustomizationPolicy.txt.

v4.3.82026/09/09

The combination strip no longer throws off the grid. THE PROBLEM: The strip only occupied height when the product had combination images. Measured in a real category with 374px cards: a card without combinations measured 466px and one with them 532px. And when narrowing the window, a second jump appeared because six combinations spanned two or three rows. The grid became misaligned and looked like a broken template.

THE SOLUTION, in three pieces

• The strip is reserved on all cards, regardless of whether they have combinations, but only in listings where at least one card has them. This mark is set by the module's JavaScript (class rkr-listing-with-swatches in the listing container). A catalog without combination images doesn't lose a single pixel; where combinations are present, all cards are the same size.
• The strip is ALWAYS a single row and of a fixed height: it never grows. Anything that doesn't fit doesn't wrap around; it's counted as "+N". Thus, the height is independent of the number of combinations (0, 1, 2, 6, or 20) and the screen width.
• The thumbnails now appear ABOVE the product name: the card's text block becomes a flex column, and the banner takes order:-1. It's located using `:has()` so it doesn't depend on how each theme names that block; if the browser doesn't support it, the banner stays where the theme places it, and the rest continues to function. A large fixed height for all products was intentionally discarded: it would leave a dead space for products without combinations, which are the majority in a typical catalog. THE "+N" IS CALCULATED BY THE MODULE. The theme's counter is calculated using ITS sizes, not the module's, and it was giving a different number than the one displayed; now it's hidden. The module's counter is calculated arithmetically (band width versus image width), not by measuring where each image ended up: a measurement taken before the browser finished rendering would leave an image cut in half against the edge. It recalculates when resizing and repainting the list due to filters or pagination. VERIFIED: In a category of 20 products with 0, 1, 2, and 6 combinations: at 1600px, 19 of the 20 cards measure exactly the same (322.78px), and the only difference is due to the theme discount row, not the strip. At 1024px, 5 combinations and "+1" are visible; at 375px, 3 and "+3" are visible, with no cropped images.