Módulo atributos con imágenes generales o específicas

v4.4.22026/11/12

Menos trabajo de estilos para el navegador en las páginas con miniaturas. EL PROBLEMA Para subir los sabores encima del nombre, la hoja de estilos buscaba con :has() el bloque de texto de cada tarjeta. Ese selector no tenía sujeto: el navegador lo comprobaba en cada elemento de cada miniatura (unos 60 por tarjeta) y lo repetía con cualquier cambio dentro de ellas, que en una página con imágenes en diferido y carruseles es continuamente.

LA SOLUCIÓN El JS del módulo marca ese bloque con una clase al cargar, a la vez que ya reservaba el alto de la franja, y la hoja usa la clase. Las tarjetas que llegan después (filtros, pestañas, cargar más, carruseles) se marcan antes de pintarse.

COMPROBADO Misma posición y tamaño de la franja, del nombre y de la tarjeta en las 26 miniaturas de una portada a 390 y 1440 px, mismo desplazamiento acumulado (CLS) y sin errores de JavaScript; una tarjeta insertada más tarde queda marcada antes del siguiente fotograma.

v4.4.12026/11/12

El «+N» de las miniaturas deja de frenar la carga de la página. EL PROBLEMA Para saber cuántos sabores caben en la fila, el módulo volvía a enseñarlos todos y medía cada franja una por una, al cargar y tres veces más después. Cada medida obligaba al navegador a recolocar la página entera: unos 30 ms por carga en una categoría de 20 miniaturas en un ordenador rápido, de tres a cuatro veces más en un móvil. Pasaba incluso en temas que esconden los sabores del listado, donde no había nada que contar.

LA SOLUCIÓN El cálculo se hace cuando el navegador ya ha colocado la página (ResizeObserver), justo antes de pintarla, y se repite solo si cambia el ancho de una franja: fotos que llegan tarde, giro del móvil, una pestaña que se abre o un carrusel que se monta. Primero se leen todas las medidas y después se escribe, y solo lo que cambia. Las pestañas que se crean al abrirse (evento rkrPestanaAbierta) también se cuentan.

COMPROBADO Mismas imágenes ocultas y el mismo «+N» en cada miniatura que la 4.4.0, a 390 y 1440 px, al cruzar el corte de 767 px, en una categoría y en las 18 pestañas de una portada; sin errores de JavaScript. En navegadores sin ResizeObserver se calcula como antes, con las lecturas agrupadas.

v4.4.02026/11/12

Las miniaturas de un carrusel o de una página de categoría leen sus sabores en una sola consulta. EL PROBLEMA Desde la 4.3.9 cada producto pedía sus combinaciones en una consulta: en una portada con 98 productos distintos, 98 consultas.

LA SOLUCIÓN PrestaShop calcula los datos de todos los productos de un listado (categoría, búsqueda, novedades, más vendidos, ofertas y los carruseles que usan esas mismas listas) antes de pintar el primero. El módulo apunta esos productos al pasar y, al pintar el primero, lee las combinaciones de todos a la vez. Si un tema pinta los productos de uno en uno, sin pasar antes por ese cálculo, todo sigue como en la 4.3.9.

COMPROBADO Portada de una tienda real (PrestaShop 8.2, Creative Elements, 127 miniaturas): de 98 a 24 consultas de combinaciones; los mismos sabores, imágenes y enlaces en cada miniatura. Banco de 60 miniaturas, presentación completa: de 120 a 70 consultas en 8.2.8 y en 1.7.8.11, de 191 a 141 en 9.1.5, y en las tres los mismos 381 sabores con los mismos datos.

PARA DESARROLLADORES Nuevo gancho actionGetProductPropertiesBefore (lo registra el upgrade): solo guarda el id del producto, no consulta nada.

v4.3.92026/11/12

Las miniaturas con imágenes de combinación dejan de cargar la base de datos. EL PROBLEMA Medido en la portada de una tienda real (PrestaShop 8.2.4, 132 miniaturas en carruseles): por cada miniatura el módulo comprobaba sus ajustes, pedía a PrestaShop todas las combinaciones con sus existencias y, para el enlace de cada sabor, volvía a leer los atributos de esa combinación. Unas 1.000 consultas solo para pintar los sabores, entre 8 y 47 ms por producto. La caché de página lo escondía a los visitantes anónimos, pero no a quien ya tenía carrito o sesión.

LA SOLUCIÓN

• Una sola consulta de combinaciones con sus atributos y nombres, sin existencias ni precios, que la miniatura no usa.
• El enlace de cada sabor se monta con esos datos: PrestaShop pone la URL de la combinación y el módulo el ancla (#/grupo-valor). El formato del ancla (nombre de grupo y orden de los atributos) cambia entre 1.7, 8 y 9; el módulo lo comprueba contra el de PrestaShop la primera vez que hace falta y después lo reutiliza.
• Las imágenes globales y la lista de productos con ajustes propios se leen una vez por página, no una vez por miniatura.
• Si el mismo producto sale en varios carruseles, se calcula una sola vez.
• Si el producto no tiene grupo de color, ya no se pide a PrestaShop que calcule sus variantes de color, que salían vacías siempre. COMPROBADO Banco de 48 productos con 6 a 10 sabores (12 de ellos con sabor y tamaño), 60 miniaturas con 12 repetidas. Consultas del módulo: de 653 a 126 en 8.2.8, de 632 a 126 en 9.1.5 y de 661 a 135 en 1.7.8.11; ahora son 2 por producto nuevo y 0 por producto repetido. Las mismas imágenes, nombres, orden y enlaces en las miniaturas, y las capturas antes y después son idénticas. Los enlaces abren la combinación correcta en la ficha. UN CAMBIO QUE SE NOTA Cuando el producto combina dos grupos (sabor y tamaño), cada sabor sale en varias combinaciones. Antes su enlace llevaba a una cualquiera, y podía cambiar de una carga a otra; ahora lleva a la combinación por defecto si es de ese sabor y, si no, siempre a la misma (la de id más bajo). PARA DESARROLLADORES Las miniaturas ya no llaman a Product::getAttributesGroups(), así que los hooks actionProductGetAttributesGroupsBefore y actionProductGetAttributesGroupsAfter no se disparan desde ellas. En un producto sin grupo de color el módulo ya no lee main_variants antes de escribirlo: PrestaShop lo deja vacío siempre en ese caso. Si otro módulo lo rellenara antes en ese mismo hook, ahora se sustituye por las variantes del módulo en vez de decorarse. [sin destacar] Licencia AFL-3.0 en todas las cabeceras y en LICENSE.txt; fuera CustomizationPolicy.txt.

v4.3.82026/09/09

La franja de combinaciones deja de descuadrar el grid. EL PROBLEMA La franja solo ocupaba alto cuando el producto tenia imagenes de combinacion. Medido en una categoria real con tarjetas de 374 px: una tarjeta sin combinaciones median 466 px y una con ellas 532 px. Y al estrechar la ventana aparecia un segundo salto, porque seis combinaciones envolvian a dos y tres filas. El grid quedaba desalineado y con aspecto de plantilla rota.

LA SOLUCION, en tres piezas

• La franja se RESERVA en todas las tarjetas, tengan o no combinaciones, pero SOLO en los listados donde alguna tarjeta las tiene. Esa marca la pone el JS del modulo (clase rkr-listado-con-swatches en el contenedor del listado). Un catalogo sin imagenes de combinacion no pierde ni un pixel; donde las hay, todas las tarjetas miden lo mismo.
• La franja es SIEMPRE de una fila y de altura fija: nunca crece. Lo que no cabe no envuelve, se cuenta en un "+N". Asi el alto es independiente del numero de combinaciones (0, 1, 2, 6 o 20) y de la anchura de la pantalla.
• Las miniaturas pasan a estar ENCIMA del nombre del producto: el bloque de texto de la tarjeta se convierte en columna flex y la franja toma order:-1. Se localiza con :has() para no depender de como llame cada tema a ese bloque; si el navegador no lo soporta, la franja se queda donde la ponga el tema y el resto sigue funcionando. Se descarto a proposito la altura fija grande para todos: dejaria un hueco muerto en los productos sin combinaciones, que en un catalogo normal son la mayoria. EL "+N" LO CALCULA EL MODULO El contador del tema esta calculado con SUS tamanos, no con los del modulo, y daba un numero distinto del que se ve; ahora se oculta. El del modulo se calcula por aritmetica (ancho de la franja contra ancho de una imagen), no midiendo donde ha quedado cada imagen: una medicion hecha antes de que el navegador acabe de maquetar dejaba una imagen cortada por la mitad contra el borde. Se recalcula al redimensionar y al repintar la lista por filtros o paginacion. COMPROBADO En una categoria de 20 productos con 0, 1, 2 y 6 combinaciones: a 1600 px 19 de las 20 tarjetas miden exactamente lo mismo (322,78 px) y la unica distinta lo es por la fila del descuento del tema, no por la franja. A 1024 px se ven 5 combinaciones y "+1"; a 375 px, 3 y "+3", sin ninguna imagen cortada.