Modulo a blocchi HTML o JavaScript in qualsiasi punto del negozio

v4.3.02026/11/03

Aggiunto

• Segmentazione dei blocchi per app mobile o web :
• Selettore diretto nell'intestazione del blocco ( Mostra in: Tutti gli ambienti, Solo app mobile o Solo Web al di fuori dell'app).
• Regola condizionale avanzata in Regole di visualizzazione ( App mobile : uguale a Sì/No), che consente di combinare la condizione con pagine, categorie, prodotti, clienti o carrelli.
• Colonna e badge di stato nell'elenco del Back-Office ( Tutti , App , Web ).
• Rilevamento compatibile e disaccoppiato con l'ecosistema rkrapp ( RkrAppMode , User-Agent RkrApp/... , cookie rkrapp_mode e parametro ?rkrapp=1|0 ).

14/10/2026
v4.2.1

Organizzato

• Un hook personalizzato risultava inutile se il tema lo richiamava con {hook h='…'} . Creandolo, veniva salvato solo il suo nome: il modulo non vi si agganciava (solo ` install() lo faceva, e con gli hook predefiniti), quindi PrestaShop non lo richiamava e i blocchi di quell'hook non venivano visualizzati, senza alcun errore. Solo {widget name='rkrhtmlblocks' hook='…'} funzionava. Ora, quando si salva un hook personalizzato, il modulo vi si aggancia (e PrestaShop crea l'hook se non esiste); rinominandolo o eliminandolo, viene scollegato dal vecchio nome, a meno che non si tratti di uno degli hook predefiniti o che sia utilizzato da un altro hook personalizzato. L'aggiornamento aggancia tutti gli hook personalizzati esistenti.
• Errori di inglese nelle stringhe sorgente , che sono ciò che vede un negozio inglese: gli operatori delle regole erano "minore di", "maggiore di", "uguale a" e "diverso da" (ora "minore di", "maggiore di", "uguale a", "diverso da"), e l'hook displayProductAdditionalInfo era chiamato "Product addition info" (ora "Additional product info"). Il resto del catalogo è stato rivisto: la descrizione del modulo ("block" → "blocks", anche in config.xml ), i messaggi "Please provide valid name!" senza articolo, "css" e "cms" in minuscolo, la guida Smarty ("every smarty functions", "We do not support on help using smarty"), la variabile client name e sette descrizioni di hook ("thumbnails..", "on the top of", "page not found page", "top navigation left side", punto mancante). La modifica del codice sorgente modifica la chiave: en.php ed es.php vengono rigenerati, con lo stesso spagnolo di prima. La guida alle regole ( help_filter_rules.tpl , in inglese, non tradotto) ora utilizza i nuovi nomi degli operatori.

10/10/2026
v4.2.0

I blocchi RKR Extra Data si inseriscono all'interno di un blocco HTML. Con RKR Extra Data 1.2.0 o versioni successive installate, il relativo pulsante appare sopra il contenuto del blocco (e i modelli): apre il generatore di schede, le FAQ, gli avvisi, i calcolatori, ecc., e li inserisce nella posizione del cursore, utilizzando uno qualsiasi dei quattro editor (testo, visuale base, visuale avanzato o codice). Nello store, il blocco appare già convertito all'hook scelto.

I due moduli rimangono indipendenti: senza RKR Extra Data non compare alcun pulsante e tutto funziona come nella 4.1.3; senza di esso, RKR Extra Data rimane invariato in prodotti, categorie e pagine.

Corretto

• Con "Attiva Smarty", un blocco RKR Extra Data causava il crash della pagina. Il costruttore scrive i blocchi tra parentesi graffe e senza spazi ( {rkred-faq} … {/rkred-faq} ), che è la sintassi di Smarty: la compilazione del contenuto falliva e, di conseguenza, l'intera pagina. Ora, questi blocchi vengono racchiusi in {literal} prima di passare attraverso Smarty e arrivano intatti nell'HTML; le variabili ( {$…} , {shop_name} ) vengono comunque sostituite. Se il contenuto ha già un {literal} aggiunto manualmente, questo rimane invariato.
• Il tentativo di salvare un blocco generava un errore "Permesso negato" quando la cartella del modulo non era scrivibile (hosting protetto o modulo montato in modalità di sviluppo). I messaggi tra le schermate e i dati di importazione venivano precedentemente salvati come file .json all'interno del modulo; ora vengono memorizzati nella cache di PrestaShop.
• Si sono verificati errori JavaScript durante il passaggio da un editor all'altro. Il passaggio da un editor visuale all'altro ha comportato la visualizzazione nella console del messaggio "Impossibile leggere le proprietà di null (lettura di 'body')" entro i primi 7 secondi, un errore per ogni linguaggio: il plugin AutoSize di TinyMCE ha continuato a misurare un editor che era già stato rimosso. Il contenuto non è andato perso, ma la console si è riempita a ogni modifica.

Validatore di componenti aggiuntivi

Ecco cosa ha indicato il validatore, prima di questa versione:

• "Uso della classe Context" (44 volte): il modulo fornisce il suo contesto a RkrhtmlblocksHelper quando viene compilato e le altre classi lo richiedono lì.
• Codice HTML scritto in PHP : il riepilogo delle regole di visualizzazione è contenuto in tooltip.tpl , i messaggi si trovano in lineas.tpl e il pulsante "Indietro" utilizza l'icona di HelperForm.
• file_get_contents() → Tools::file_get_contents() durante l'importazione.
• Module::isEnabled() , deprecato nella versione 9.0: vedi module_shop .
• .htaccess nella directory principale del modulo, che risultava mancante.
• PHPStan (livello 5, PrestaShop 9.1.5 ): smartyRegisterFunction() → registerPlugin() da Smarty (è esattamente quello che ho fatto con $lazy = false ), tipi di proprietà e array_slice() con numeri interi.
• Formattazione (PHP CS Fixer) in sei file. Testato su ps91: visualizzazione delle regole utilizzando il contesto (pagina, categoria), elenco con riepilogo delle regole, salvataggio di un blocco, chiamate di filtro AJAX, tutti e quattro gli editor funzionanti senza errori e il negozio con Smarty abilitato. Nessuna modifica al database: nessuno script di aggiornamento.

v4.1.32026/10/07

Meno query sul front-end: da 40 a 2 sulla homepage. Il modulo non effettuava query pesanti, ma molte : una per ogni hook o posizione renderizzata (26 sulla homepage) e, in aggiunta, una per ogni blocco per leggere i suoi filtri (14). Ognuna impiegava decimi di millisecondo, ma sommate arrivavano a circa 18 ms per pagina.

Ora i blocchi di memoria e lingua attivi vengono letti contemporaneamente e serviti dalla memoria tramite hook, e tutti i filtri vengono letti con una singola query ( IN ). L'allocazione di memoria dura solo per la durata della richiesta: non c'è cache persistente da invalidare. Le regole HTML e di visualizzazione (pagina, categoria, gruppo, dispositivo, ecc.) sono esattamente le stesse.

• Pagina iniziale: da 40 query a 2. Categoria: da 19 a 2. Prodotto: da 25 a 2.
• L'amministrazione continua a leggere i filtri per ogni blocco in tempo reale.

29/09/2026
v4.1.2

L'altra metà di ciò che è successo in 4.1.1. Quella ha chiuso i 102 avvisi "Traduzione non trovata" lasciati da PHP; c'erano 54 stringhe rimaste nei modelli di amministrazione , che seguono un altro percorso e sovrascrivere l() non è sufficiente.

smartyTranslate() ` — ciò che si cela dietro ` {ls='...' mod='rkrhtmlblocks'} ` — chiama ` getModuleTranslation() con cinque argomenti, quindi il backup di Symfony è abilitato e non c'è modo di disabilitarlo dal modulo. Ognuno di questi 54 ha lasciato una notifica in uno store inglese; due ne hanno lasciata una anche in spagnolo , Variable e -- , che si scrivono allo stesso modo in entrambe le lingue — prova che il problema non è mai stato "traduzione mancante".

Ora sono tradotti in PHP, in classes/RkrhtmlblocksTextos.php , e il template visualizza la variabile con escape. Misurato: 54 → 0 con shared/scripts/medir-avisos-traduccion.py , e in ps1788 con lo store in inglese, un caricamento della schermata di configurazione passa da 37 dei nostri avvisi a 0. Lo stesso strumento sul file ZIP 4.1.1 dà ancora 54, ed è questo che rende significativo quello zero.

E a proposito, un pannello che non è mai stato tradotto

I quattro testi "Come usare i Custom Hooks" erano codificati in inglese direttamente nel template, senza alcuna funzione di traduzione: quel pannello appariva in inglese anche in un negozio spagnolo. Ora sono presenti nel catalogo, in entrambe le lingue.