Le classi Tailwind scritte nei contenuti ora arrivano allo storefront

Chi scrive i contenuti di un negozio lo sa: si prova una classe, si salva, si ricarica, e non succede niente. Le classi Tailwind esistono nel foglio di stile solo se qualcuno le ha già usate in un template, quindi il redattore deve chiedere a uno sviluppatore di aggiungerle al tema. La pull request #1611 di fballiano è stata unita il 26 ottobre 2026 e cambia questa regola: le classi scritte nei contenuti entrano nello stile del tema.

Cosa è cambiato

Il perimetro è largo e copre i punti dove il contenuto si scrive davvero: pagine CMS, blocchi statici, post del blog, widget, variabili personalizzate, condizioni del checkout, i campi del footer del tema, le descrizioni di prodotti e categorie. In tutti questi posti si possono usare le classi di Tailwind e di DaisyUI, e il risultato si vede sullo storefront.

Due comodità che cambiano il lavoro quotidiano:

• l’anteprima del page builder a schermo intero mostra la classe nuova subito, prima di salvare;
• su un server con Node.js installato, il salvataggio del contenuto avvia da solo la preparazione dello stile. Non serve aspettare un deploy.

Per chi preferisce comandare a mano, il comando fa lo stesso lavoro all’istante, per esempio in uno script di deploy:

# prepara il foglio di stile del tema con le classi presenti nei contenuti
./maho theme:content:build

L’editor dice se la classe esiste

La barra degli strumenti del tab Contenuto ha un pulsante Source, anche nel page builder a schermo intero: mostra l’HTML al posto del testo formattato, dentro un editor di codice.

Dentro un attributo class l’editor completa le classi Tailwind e DaisyUI del tema e segnala una classe che lo storefront non usa. Una classe di colore ha il suo campione, e il pannello mostra il CSS della voce scelta. Se una classe ha una forma più corta, come h-[100%] invece di h-full, compare la proposta con un pulsante per sostituirla.

Il badge di una colonna o di una cella del page builder ha i pulsanti Impostazioni, Source ed Elimina, e Source apre l’HTML di quel solo elemento. Il pulsante Mostra o Nascondi editor sotto i campi del contenuto non c’è più, perché fa lo stesso il pulsante Source.

Perché conta

Le classi finiscono nello stesso foglio di stile del tema, non in un foglio a parte: è il punto che tiene insieme l’aspetto del negozio. Un secondo foglio lascerebbe che una classe scritta nel contenuto sovrascriva una classe del tema in modo imprevedibile. Il risultato è un negozio in cui chi scrive può comporre una pagina senza toccare il tema, e senza rompere l’ordine delle regole.

Cosa serve

• Node.js e la Tailwind CLI sul server, con npm install, e un worker della coda che li raggiunga. Senza worker l’anteprima mostra la classe nuova ma lo storefront no, e svuotare la cache non basta.
• mahocommerce/maho-composer-plugin 5.2, che questa versione di Maho richiede.
• Un’estensione che clicca #toggle<id del campo> o chiama getToggleButton() va aggiornata, perché quel pulsante non esiste più.

Cosa può non funzionare

• Uno script che scrive contenuti in SQL non avvia la preparazione: dopo va lanciato il comando a mano.
• Il controllo delle classi legge il css/styles.css del pacchetto, quindi una classe DaisyUI che esiste solo nella copia preparata risulta sconosciuta.
• La preparazione tiene la copia attuale e la precedente, quindi una pagina in cache da due build punta a un file eliminato finché la cache non si aggiorna.
• Nell’anteprima una classe DaisyUI che la copia preparata non contiene resta senza stile.
• Ogni copia contiene le classi di tutti gli store, non di uno solo.
• Il completamento non vede i fogli di stile di un’altra origine, come un CDN.

Come averlo

Dopo l’aggiornamento, su un server dove esiste node_modules/.bin/tailwindcss, il cron prepara la copia entro 15 minuti e lo storefront carica media/theme/<package>-<theme>-<hash>.css invece di skin/frontend/<package>/<theme>/css/styles.css. Un server senza Tailwind CLI continua a usare il file del pacchetto.

Nel resto della pull request

• Salva e continua a modificare di un post del blog funziona di nuovo: i nomi di ripiego delle tab non corrispondevano all’id delle tab del post.
• L’intestazione e il piè di pagina XML di un feed prodotti usano lo stesso editor di codice, con i numeri di riga, l’annullamento e la ricerca, al posto della copia colorata disegnata dietro al campo.
• Le immagini SVG nel contenuto non si rompono più con un errore 500, perché l’azione che le serve le legge senza passare da GD e le ripulisce dagli script.
• La tabella dell’editor non lascia più che un’icona in una cella stretta copra il testo accanto.