Módulo de atributos com imagens gerais ou específicas

12/11/2026
v4.4.2

Menos trabalho de estilização para o navegador em páginas com miniaturas. O PROBLEMA: Para exibir os sabores acima do nome, a folha de estilo usava `:has()` para buscar o bloco de texto de cada cartão. Esse seletor não tinha sujeito: o navegador o verificava em cada elemento de cada miniatura (cerca de 60 por cartão) e repetia esse processo com quaisquer alterações dentro delas, o que em uma página com imagens e carrosséis com atraso é constante.

A SOLUÇÃO: O JavaScript do módulo marca esse bloco com uma classe ao carregar, reservando também a altura da faixa, e a folha usa essa classe. Os cartões subsequentes (filtros, abas, carregar mais, carrosséis) são marcados antes de serem renderizados.

VERIFICADO: Mesma posição e tamanho da tira, nome e cartão nas 26 miniaturas de uma capa em 390 e 1440 px, mesmo deslocamento cumulativo (CLS) e sem erros de JavaScript; um cartão inserido posteriormente é marcado antes do próximo quadro.

12/11/2026
v4.4.1

O "+N" nas miniaturas não causa mais lentidão no carregamento da página. O PROBLEMA: Para determinar quantos sabores cabem na linha, o módulo os exibia novamente e media cada linha individualmente, tanto no carregamento inicial quanto em mais três carregamentos subsequentes. Cada medição forçava o navegador a redimensionar a página inteira: cerca de 30 ms por carregamento para uma categoria de 20 miniaturas em um computador rápido e de três a quatro vezes mais em um dispositivo móvel. Isso acontecia mesmo com temas que ocultavam os sabores na lista, onde não havia nada para contar.

A SOLUÇÃO O cálculo é realizado após o navegador já ter posicionado a página (ResizeObserver), imediatamente antes de renderizá-la, e é repetido apenas se a largura de uma seção mudar: fotos que chegam com atraso, o telefone sendo girado, uma aba sendo aberta ou um carrossel sendo montado. Primeiro, todas as medidas são lidas e, em seguida, são escritas, incluindo apenas as alterações. Abas criadas ao abrir a página (evento rkrPestanaAbierta) também são contabilizadas.

VERIFICADO: As mesmas imagens ocultas e o mesmo "+N" em cada miniatura, como na versão 4.4.0 , em 390 e 1440 px, ao ultrapassar o limite de 767 px, em uma categoria e em todas as 18 abas de uma página inicial; nenhum erro de JavaScript. Em navegadores sem ResizeObserver, o cálculo é feito como antes, com as leituras agrupadas.

12/11/2026
v4.4.0

As miniaturas em um carrossel ou página de categoria exibem seus sabores em uma única consulta. O PROBLEMA: Desde a versão 4.3.9 , cada produto exigia suas combinações em uma única consulta: em uma página inicial com 98 produtos diferentes, isso resultava em 98 consultas.

A SOLUÇÃO: O PrestaShop calcula os dados de todos os produtos em uma lista (categoria, busca, novidades, mais vendidos, ofertas e carrosséis que usam essas mesmas listas) antes de exibir o primeiro. O módulo referencia esses produtos ao passar o cursor sobre eles e, ao exibir o primeiro, lê as combinações de todos eles de uma só vez. Se um tema exibir os produtos um por um, sem realizar esse cálculo previamente, tudo permanece como na versão 4.3.9.

VERIFICADO. Página inicial de uma loja real (PrestaShop 8.2, Creative Elements, 127 miniaturas): de 98 para 24 combinações de consultas; os mesmos sabores, imagens e links em cada miniatura. Banco de 60 miniaturas, apresentação completa: de 120 para 70 consultas nas versões 8.2.8 e 1.7.8.11 , de 191 para 141 na 9.1.5 , e em todas as três versões os mesmos 381 sabores com os mesmos dados.

PARA DESENVOLVEDORES Nova ação de gancho `actionGetProductPropertiesBefore` (registrada pela atualização): salva apenas o ID do produto, sem consultar nada.

12/11/2026
v4.3.9

Miniaturas com imagens combinadas param de carregar o banco de dados. O PROBLEMA: Medido na página inicial de uma loja real (PrestaShop 8.2.4 , 132 miniaturas em carrosséis): para cada miniatura, o módulo verificava suas configurações, solicitava todas as combinações com seus respectivos níveis de estoque do PrestaShop e, para cada link de sabor, relia os atributos daquela combinação. Aproximadamente 1.000 consultas foram feitas apenas para exibir os sabores, entre 8 e 47 ms por produto. O cache da página ocultava isso de visitantes anônimos, mas não daqueles que já tinham um carrinho ou sessão.

A SOLUÇÃO

• Uma única consulta de combinações com seus atributos e nomes, sem estoque ou preços, que a miniatura não utiliza.
• O link para cada sabor é criado usando estes dados: o PrestaShop fornece a URL para a combinação e o módulo fornece a âncora (#/valor-do-grupo). O formato da âncora (nome do grupo e ordem dos atributos) varia entre as versões 1.7, 8 e 9; o módulo verifica se ela corresponde à âncora do PrestaShop na primeira vez que é necessária e, em seguida, a reutiliza.
• As imagens globais e a lista de produtos com configurações personalizadas são lidas uma vez por página, e não uma vez por miniatura.
• Se o mesmo produto aparecer em vários carrosséis, o cálculo será feito apenas uma vez.
• Se o produto não tiver um grupo de cores, o PrestaShop não será mais solicitado a calcular suas variações de cor, que estavam sempre vazias. VERIFICADO: Um banco de dados de 48 produtos com 6 a 10 sabores (12 deles com sabor e tamanho), 60 miniaturas com 12 duplicadas. Consultas ao módulo: de 653 para 126 na 8.2.8 , de 632 para 126 na 9.1.5 e de 661 para 135 na 1.7.8.11; agora há 2 consultas por novo produto e 0 por duplicado. As imagens, nomes, ordem e links nas miniaturas são os mesmos, e as capturas de tela de antes e depois são idênticas. Os links abrem a combinação correta na página do produto. UMA MUDANÇA NOTÁVEL: Quando o produto combina dois grupos (sabor e tamanho), cada sabor aparece em várias combinações. Anteriormente, seu link levava a qualquer combinação e podia mudar de um carregamento para outro; Agora, se for esse o sabor, usa a combinação padrão; caso contrário, usa sempre a mesma (a que tiver o ID mais baixo). PARA DESENVOLVEDORES: As miniaturas não chamam mais `Product::getAttributesGroups()`, portanto, os hooks `actionProductGetAttributesGroupsBefore` e `actionProductGetAttributesGroupsAfter` não são mais acionados por elas. Em um produto sem um grupo de cores, o módulo não lê mais `main_variants` antes de gravá-lo: o PrestaShop sempre o deixa vazio nesse caso. Se outro módulo o preencheu anteriormente no mesmo hook, ele agora é substituído pelas variantes do módulo em vez de ser decorado. [sin destacar] Licença AFL-3.0 em todos os cabeçalhos e em `LICENSE.txt`; CustomizationPolicy.txt.

v4.3.82026/09/09

A faixa de combinações não desalinha mais a grade. O PROBLEMA: A faixa só ocupava altura quando o produto tinha imagens combinadas. Medindo em uma categoria real com cartões de 374px: um cartão sem combinações media 466px e um com combinações, 532px. E ao diminuir o tamanho da janela, um segundo salto aparecia porque seis combinações abrangiam duas ou três linhas. A grade ficava desalinhada e parecia um modelo quebrado.

A SOLUÇÃO, em três partes

• A faixa é reservada em todos os cartões, independentemente de terem ou não combinações, mas apenas em anúncios onde pelo menos um cartão as possui. Essa marca é definida pelo JavaScript do módulo (classe rkr-listing-with-swatches no contêiner do anúncio). Um catálogo sem imagens de combinações não perde um único pixel; onde há combinações, todos os cartões têm o mesmo tamanho.
• A faixa é SEMPRE uma única linha e de altura fixa: ela nunca aumenta. Qualquer coisa que não caiba não se repete; é contada como "+N". Assim, a altura é independente do número de combinações (0, 1, 2, 6 ou 20) e da largura da tela.
• As miniaturas agora aparecem ACIMA do nome do produto: o bloco de texto do cartão se torna uma coluna flexível e o banner assume a posição order:-1. Ele é posicionado usando `:has()`, portanto, não depende de como cada tema nomeia esse bloco; se o navegador não o suportar, o banner permanece onde o tema o coloca e o restante continua funcionando. Uma altura fixa grande para todos os produtos foi descartada intencionalmente: isso deixaria um espaço morto para produtos sem combinações, que são a maioria em um catálogo típico. O "+N" É CALCULADO PELO MÓDULO. O contador do tema é calculado usando SEUS tamanhos, não os do módulo, e estava fornecendo um número diferente do exibido; agora está oculto. O contador do módulo é calculado aritmeticamente (largura da banda versus largura da imagem), não medindo onde cada imagem terminou: uma medição feita antes que o navegador terminasse de renderizar deixaria uma imagem cortada ao meio na borda. Ele recalcula ao redimensionar e redesenhar a lista devido a filtros ou paginação. VERIFICADO: Em uma categoria de 20 produtos com 0, 1, 2 e 6 combinações: em 1600px, 19 dos 20 cartões medem exatamente o mesmo (322,78px), e a única diferença se deve à linha de desconto temática, não à faixa. Em 1024px, 5 combinações e "+1" são visíveis; em 375px, 3 combinações e "+3" são visíveis, sem imagens cortadas.