Bloco HTML ou JavaScript em qualquer lugar da loja

14/10/2026
v4.2.1

Organizado

• Um gancho personalizado era inútil se o tema o chamasse com {hook h='…'} . Criá-lo apenas salvava seu nome: o módulo não se conectava a ele (apenas ` install() o fazia, e com os ganchos padrão), então o PrestaShop não o chamava e os blocos desse gancho não apareciam, sem nenhum erro. Somente {widget name='rkrhtmlblocks' hook='…'} funcionava. Agora, ao salvar um gancho personalizado, o módulo se conecta a ele (e o PrestaShop cria o gancho se ele não existir); renomeá-lo ou excluí-lo o desvincula do nome antigo, a menos que seja um dos ganchos padrão ou esteja sendo usado por outro gancho personalizado. A atualização conecta quaisquer ganchos personalizados existentes.
• Foram encontrados erros de inglês nas strings de origem , que são o que uma loja em inglês vê: os operadores de regra eram "menor que", "maior que", "igual a" e "diferente de" (agora "menor que", "maior que", "igual a", "diferente de"), e o gancho displayProductAdditionalInfo era chamado de "Informações adicionais do produto" (agora "Informações adicionais do produto"). O restante do catálogo foi revisado: a descrição do módulo ("bloco" → "blocos", também em config.xml ), as mensagens "Por favor, forneça um nome válido!" sem artigo, "css" e "cms" em minúsculas, a ajuda do Smarty ("todas as funções do Smarty", "Não oferecemos suporte à ajuda usando Smarty"), a variável client name e sete descrições de ganchos ("miniaturas...", "no topo de", "página não encontrada", "navegação superior à esquerda", um ponto final ausente). Alterar a origem altera a chave: en.php e es.php são regenerados, com o mesmo espanhol de antes. A ajuda das regras ( help_filter_rules.tpl , em inglês, sem tradução) agora usa os novos nomes dos operadores.

v4.2.02026/10/10

O RKR Extra Data é inserido em blocos HTML. Com o RKR Extra Data 1.2.0 ou posterior instalado, o botão correspondente aparece acima do conteúdo (e dos modelos) do bloco: ele abre o construtor de abas, FAQ, avisos, calculadoras, etc., e o insere onde o cursor estiver, usando qualquer um dos quatro editores (texto, visual básico, visual avançado ou código). Na loja, o bloco aparece já convertido para o hook escolhido.

Os dois módulos permanecem independentes: sem o RKR Extra Data, nenhum botão aparece e tudo funciona como na 4.1.3; sem ele, o RKR Extra Data permanece o mesmo em produtos, categorias e páginas.

Corrigido

• Com a opção "Ativar Smarty", um bloco de dados extras do RKR estava causando o travamento da página. O construtor escrevia os blocos entre chaves e sem espaços ( {rkred-faq} … {/rkred-faq} ), que é a sintaxe do Smarty: a compilação do conteúdo falhava e, com ela, a página inteira. Agora, esses blocos são envolvidos em {literal} antes de serem processados pelo Smarty e chegam intactos ao HTML; as variáveis ( {$…} , {shop_name} ) ainda são substituídas. Se o conteúdo já tiver um {literal} adicionado manualmente, ele permanece intacto.
• Ao tentar salvar um bloco, ocorria um erro de "Permissão negada" devido à pasta do módulo não ser gravável (hospedagem protegida ou módulo montado em modo de desenvolvimento). As mensagens entre telas e os dados de importação eram anteriormente salvos como arquivos .json dentro do módulo; agora, são armazenados no cache do PrestaShop.
• Ocorreram erros de JavaScript ao alternar entre editores. A troca de um editor visual para outro resultou na exibição do erro "Não é possível ler as propriedades de null (lendo 'body')" no console nos primeiros 7 segundos, um erro por idioma: o plugin AutoSize do TinyMCE continuou a medir um editor que já havia sido removido. O conteúdo não foi perdido, mas o console ficou cheio a cada mudança.

Validador de complementos

O que o validador indicou, tudo anterior a esta versão:

• "Uso da classe Context" (44 vezes): o módulo fornece seu contexto para RkrhtmlblocksHelper quando é construído e as outras classes o solicitam lá.
• HTML escrito em PHP : o resumo das regras de listagem é composto por tooltip.tpl , as mensagens vão em lineas.tpl e o botão "Voltar" usa o ícone HelperForm.
• file_get_contents() → Tools::file_get_contents() ao importar.
• Module::isEnabled() , obsoleto na versão 9.0: veja module_shop .
• O .htaccess na raiz do módulo estava faltando.
• PHPStan (nível 5, PrestaShop 9.1.5 ): smartyRegisterFunction() → registerPlugin() do Smarty (é exatamente o que eu fiz com $lazy = false ), tipos de propriedade e array_slice() com inteiros.
• Formatação (PHP CS Fixer) em seis arquivos. Testado no PS91: exibição de regras usando contexto (página, categoria), listagem com resumo de regras, salvamento de um bloco, chamadas de filtro AJAX, todos os quatro editores funcionando sem erros e o armazenamento com Smarty habilitado. Sem alterações no banco de dados: nenhum script de atualização.

07/10/2026
v4.1.3

Menos consultas no front-end: de 40 para 2 na página inicial. O módulo não fazia consultas pesadas, mas sim muitas : uma para cada gancho ou posição renderizada (26 na página inicial) e, adicionalmente, uma para cada bloco para ler seus filtros (14). Cada uma levava décimos de milissegundo, mas somavam cerca de 18 ms por página.

Agora, o armazenamento ativo e os blocos de idioma são lidos simultaneamente e servidos da memória por meio de um gancho (hook), e todos os filtros são lidos com uma única consulta ( IN ). A alocação de memória dura apenas o tempo da requisição: não há cache persistente para invalidar. O HTML e as regras de exibição (página, categoria, grupo, dispositivo etc.) são exatamente os mesmos.

• Página inicial: 40 consultas para 2. Categoria: 19 para 2. Produto: 25 para 2.
• A administração continua lendo os filtros de cada bloco em tempo real.

29/09/2026
v4.1.2

A outra metade do que aconteceu na 4.1.1. Essa versão corrigiu os 102 avisos de "Tradução não encontrada" deixados pelo PHP; restaram 54 strings nos modelos de administração , que seguem outro caminho e sobrescrever l() não é suficiente.

smartyTranslate() ` — o que está por trás de ` {ls='...' mod='rkrhtmlblocks'} ` — chama ` getModuleTranslation() com cinco argumentos, então o backup do Symfony está habilitado e não há como desabilitá-lo pelo módulo. Cada um desses 54 deixou uma notificação em um repositório em inglês; dois também deixaram uma em espanhol , Variable e -- , que são escritos da mesma forma em ambos os idiomas — prova de que o problema nunca foi "falta de tradução".

Agora, elas estão traduzidas em PHP, em classes/RkrhtmlblocksTextos.php , e o modelo exibe a variável escapada. Medido: 54 → 0 com shared/scripts/medir-avisos-traduccion.py , e em ps1788 com a loja em inglês, o carregamento da tela de configuração passa de 37 dos nossos alertas para 0. A mesma ferramenta contra o ZIP 4.1.1 ainda retorna 54, o que torna esse zero significativo.

Aliás, um painel que nunca foi traduzido.

Os quatro textos "Como usar ganchos personalizados" estavam codificados em inglês no modelo, ignorando qualquer função de tradução: esse painel também aparecia em inglês em uma loja espanhola. Agora eles estão no catálogo, em ambos os idiomas.