Aggiornato a giugno 2026, copre i temi figli sia con Hummingbird (PrestaShop 9, pipeline SCSS) sia con Classic (PrestaShop 8). Il meccanismo di override è identico con entrambi i temi padre.
Ecco il momento in cui un buon proprietario di un negozio PrestaShop diventa un proprietario frustrato: hai acquistato un tema premium, volevi modificare tre piccole cose, un font diverso per i titoli, il colore del tuo brand sui pulsanti, un ritocco al layout della pagina prodotto, quindi hai aperto /themes/your-theme/templates/catalog/product.tpl e lo hai modificato. Sembrava perfetto. Poi, sei settimane dopo, l’autore del tema ha rilasciato la versione 2.1 con una correzione di sicurezza e una galleria prodotto più veloce. Hai cliccato su aggiorna. Ogni modifica che avevi fatto è sparita, sovrascritta, irrecuperabile a meno che tu non abbia per caso un backup da confrontare.
È la ferita autoinflitta più comune nelle personalizzazioni PrestaShop, e da anni ha una soluzione corretta: il tema figlio. Questa guida parla proprio di questo, che cos’è davvero un tema figlio PrestaShop a livello di file system, come l’ordine di risoluzione degli override decide quale file prevale, come crearne uno basato su Hummingbird o Classic, e dove passa esattamente il confine tra "usa un tema figlio" e "qui serve invece un modulo". Se in realtà vuoi solo aggiungere uno snippet CSS o uno script di tracciamento senza creare un fork di nulla, quello è un intervento più circoscritto con una risposta dedicata, vedi CSS e JavaScript personalizzati senza rompere gli aggiornamenti, e più avanti ti rimanderemo a quella guida nel punto giusto.
Che cos’è davvero un tema figlio (a livello di file)
Un tema figlio è una directory di tema separata che dichiara un parent nel proprio config/theme.yml ed eredita tutto da lì, ogni template, ogni asset, ogni valore di configurazione, permettendoti però di sovrascrivere singoli file. Non è una copia del tema padre. È uno strato sottile appoggiato sopra di esso. Qualsiasi file che non inserisci nel figlio viene servito dal padre; qualsiasi file che inserisci nel figlio prevale.
Il "Quindi?" è l’intero senso della tecnica: poiché il figlio vive nella propria directory, un aggiornamento del padre tocca il padre e lascia intatto il tuo lavoro. Il padre passa alla v2.1, i tuoi override continuano a funzionare sopra la v2.1, e tu passi la serata a fare altro invece di ricostruire personalizzazioni a memoria. Ottieni le correzioni di bug e i miglioramenti di velocità dell’autore del tema e il tuo branding, invece di dover scegliere tra le due cose.
L’ordine di risoluzione degli override. Il meccanismo che lo fa funzionare
Per fidarti dei temi figli devi sapere con precisione come PrestaShop decide quale template renderizzare. Quando un controller richiede un template, il livello di rendering del tema cerca in un ordine fisso e si ferma al primo risultato trovato:
| Priorità | Posizione controllata | Prevale quando… |
|---|---|---|
| 1 (massima) | Tema figlio: /themes/child/templates/... | Hai inserito qui un override |
| 2 | Tema padre: /themes/parent/templates/... | Il figlio non ha una copia |
| 3 | Template front propri del modulo (per gli hook del modulo) | Nessuno dei due temi sovrascrive quel template del modulo |
Per questo "copia il solo file che ti serve, modifica la copia" funziona senza rompere nient’altro: PrestaShop risolve ogni template in modo indipendente. Sovrascrivi product.tpl e il resto del negozio continua a essere renderizzato dal tema padre. Non esiste un interruttore tutto-o-niente, il figlio intercetta solo i percorsi esatti che popoli, lasciando passare tutto il resto al padre. Questo passaggio al padre è una funzionalità, non un limite: meno file intercetti, più aggiornamenti del padre arrivano direttamente al tuo negozio.
config/theme.yml, il file che dichiara la relazione
Tutta l’ereditarietà dipende da un solo file dentro la directory config/ del tema figlio, config/theme.yml. La chiave parent è quella che dice a PrestaShop "servi tutto da questo tema, a meno che io non lo sovrascriva". Un tema figlio minimale basato su Hummingbird si presenta così:
parent: hummingbird
name: my-store-child
display_name: My Store Child
version: 1.0.0
assets:
use_parent_assets: trueIl valore di parent deve corrispondere al nome della directory del tema padre (e il padre deve essere effettivamente installato. Un tema figlio non può ereditare da un tema che non è presente sul server). Il valore di name deve essere unico e deve corrispondere al nome della directory del tema figlio. Se sbagli uno dei due, PrestaShop torna silenziosamente al padre oppure rifiuta di abilitare il tema. Entrambi i casi sono più facili da diagnosticare quando sai che quasi sempre si tratta di una mancata corrispondenza dei nomi in questo file.
Creare un tema figlio passo dopo passo
Un tema figlio non fa nulla finché non viene selezionato come tema attivo.
- Crea la directory, per esempio /themes/my-store-child/, con una directory config/ al suo interno. Non copiarci dentro i file del padre. Un tema figlio minimale può essere molto piccolo, ma deve includere un config/theme.yml valido che dichiari parent, name, display_name e version. Con quel file al posto giusto, il rendering sarà identico a quello del padre.
- Aggiungi config/theme.yml in /themes/my-store-child/config/theme.yml con il riferimento al padre mostrato sopra.
- Copia solo i file che stai davvero modificando, conservando il percorso relativo. Per personalizzare la pagina prodotto, copia /themes/hummingbird/templates/catalog/product.tpl in /themes/my-store-child/templates/catalog/product.tpl e modifica solo la copia nel tema figlio.
- Attivalo nel back office sotto Aspetto → Tema & logo. Creare la directory non basta, finché non selezioni e usi qui il tema figlio, il negozio continua a servire il padre. È la domanda di supporto numero uno del tipo "perché la mia modifica non si vede?", e la risposta è quasi sempre: il figlio non è mai stato attivato.
La struttura delle directory del figlio rispecchia esattamente quella del padre. Il compito di un template è trovarsi nello stesso percorso relativo nel figlio in cui si trova nel padre. È questa corrispondenza di percorso che permette al resolver di abbinarli.
Cosa va in un tema figlio, e cosa no
Template (.tpl), sì, lo strumento giusto
Le modifiche strutturali al markup, riordinare i blocchi della pagina prodotto, aggiungere una sezione informativa personalizzata, cambiare il modo in cui viene renderizzato l’header. Sono esattamente il tipo di lavoro per cui esistono gli override dei template. Copia il template del padre nel percorso corrispondente del figlio e modificalo. Anche sovrascrivere il template front di un modulo (un file sotto /themes/[theme]/modules/[module]/views/templates/front/[template].tpl) è una tecnica documentata, ma tieni presente che è un punto debole noto proprio con i temi figli: la documentazione PrestaShop sui temi figli non copre gli override dei template dei moduli, e ci sono segnalazioni aperte di risoluzione incoerente da un tema figlio (la cache dei template può servire la copia del padre). Se devi rifare lo stile dell’output di un modulo e stai usando un tema figlio, testalo con attenzione sulla tua versione, oppure metti l’override direttamente sul tema attivo invece di affidarti al passaggio padre/figlio.
CSS e JavaScript, di solito il livello sbagliato
Se la modifica è puramente visiva, colori, font, spaziature, nascondere un elemento, sovrascrivere un intero template è un approccio pesante, e ti costringe a rifondere quel template a ogni aggiornamento del padre. La scelta più leggera e più sicura per gli aggiornamenti è un foglio di stile o uno script caricato dopo gli asset del padre, senza duplicare alcuna logica di template. È un lavoro abbastanza diverso da meritare una guida propria: CSS e JavaScript personalizzati in PrestaShop senza rompere gli aggiornamenti. La regola pratica: usa un override di template solo quando devi davvero cambiare il markup; per tutto ciò che può fare il CSS, usa il CSS.
Logica di business. Nessuno dei due; serve un modulo
Il confine netto è questo: se la modifica riguarda il comportamento, come vengono calcolati i prezzi, come viene scelta la spedizione, cosa succede durante la finalizzazione dell’ordine. Un tema figlio è il posto completamente sbagliato. I template mostrano dati; non devono elaborarli. Nel momento in cui ti ritrovi a scrivere vera logica PHP dentro un file .tpl, hai messo codice di business nel livello di presentazione, dove non può essere testato, riutilizzato o aggiornato in modo pulito. Quel lavoro appartiene a un modulo (o a una classe di override), non al tema. Un tema decide come appare il carrello; un modulo decide come il carrello si comporta.
Perché "snello" è una regola ferrea, non una finezza
Ogni file che sovrascrivi è un file che smette di ricevere le correzioni dell’autore del tema padre. Se il padre rilascia un product.tpl corretto e più accessibile nella v2.1 e tu hai la tua copia, non riceverai quella correzione. La tua copia resta congelata al markup della v2.0 finché non fondi manualmente le differenze. Quindi ogni override porta con sé una tassa di manutenzione continua, e il conto arriva a ogni aggiornamento del padre.
La disciplina che mantiene bassa questa tassa: sovrascrivere l’unità più piccola che risolve il problema. Devi aggiungere una classe a un solo elemento? Sovrascrivi quel singolo template, non il suo layout padre, non tutta la cartella catalogo. Devi cambiare un colore? È CSS, non un template. Un tema figlio con quattro file di override richiede cinque minuti per essere aggiornato; un tema figlio con quaranta file diventa un progetto ogni volta che il padre cambia.
Sopravvivere a un aggiornamento del tema padre
Quando l’autore del padre rilascia una nuova versione, la routine è breve perché l’architettura fa il lavoro pesante:
- Aggiorna il padre. Il tuo figlio è una directory separata, quindi nulla di ciò che hai scritto viene sovrascritto.
- Confronta i tuoi override con le nuove versioni del padre. Per ogni file che hai copiato, confronta la copia congelata nel figlio con la nuova copia del padre usando qualsiasi strumento di diff. Questo è l’unico punto in cui paghi la tassa di manutenzione, ed è grande solo quanto il numero dei tuoi override.
- Integra ciò che vale la pena mantenere, una correzione di bug, un nuovo campo, un miglioramento di accessibilità aggiunto dall’autore a un template che sovrascrivi, nella copia del figlio.
- Testa le pagine interessate, in particolare quelle di cui sovrascrivi i template, prima e dopo.
I file che non hai sovrascritto non richiedono nulla di tutto questo. Si sono aggiornati automaticamente nell’istante in cui hai aggiornato il padre. Questa asimmetria è tutto il ritorno della tecnica: fai lavoro di confronto e merge solo in proporzione a ciò che hai personalizzato, e ottieni tutto il resto senza interventi.
Hummingbird vs Classic, quale tema padre nel 2026
Hummingbird è la direzione moderna del tema ufficiale PrestaShop per l’era PS 9, mentre Classic resta diffuso e disponibile, soprattutto su PS 8 e sui negozi legacy. Il meccanismo dei temi figli è identico a prescindere dal padre, stesso config/theme.yml, stesso ordine di risoluzione, ma il padre che scegli cambia il modo in cui costruisci gli asset:
| Padre | Strumenti front-end | Sceglilo quando… |
|---|---|---|
| Hummingbird (direzione era PS 9) | Build moderna (Webpack, SCSS), markup più leggero | Stai creando un nuovo negozio, oppure vuoi una base moderna con markup più leggero e veloce. |
| Classic (ancora scaricabile) | Pipeline degli asset più vecchia e più semplice | Stai aggiornando un tema figlio esistente basato su Classic e una migrazione non vale ancora lo sforzo. |
Se stai aggiornando da PrestaShop 8 con un tema figlio basato su Classic, non devi migrare a Hummingbird dal primo giorno. Classic resta disponibile come download separato, ma un nuovo progetto dovrebbe partire da Hummingbird. Poiché la pipeline dei fogli di stile di Hummingbird è basata su SCSS, il modo in cui compili il CSS personalizzato è diverso rispetto a Classic; quindi la scelta del padre incide soprattutto sul flusso di lavoro dello stile, non sulla logica degli override. Scegliere fin dall’inizio il tema di base giusto è una decisione da prendere con attenzione, ne parliamo in come scegliere il tema PrestaShop giusto per la tua attività.
Gli errori più comuni che si fanno ancora
- Il tema figlio non è mai stato attivato. La directory e config/theme.yml esistono, ma il negozio serve ancora il padre perché nessuno ha selezionato il figlio sotto Aspetto → Tema & logo. È sempre la prima cosa da controllare.
- Mancata corrispondenza dei nomi in config/theme.yml. Il valore di name non corrisponde alla directory, oppure parent punta a un tema non installato. Il figlio torna silenziosamente al padre o non si abilita.
- Override fuori controllo. Quaranta template copiati perché "era più facile copiare tutta la cartella". Ora ognuno di quei file richiede un merge manuale a ogni aggiornamento del padre. Mantieni il tema snello per scelta progettuale.
- Nessun controllo versione. Un tema figlio è codice personalizzato. Deve stare in Git con messaggi di commit reali, così un merge sbagliato dopo un aggiornamento del padre si risolve con un revert, non con un gioco di ipotesi.
- "Solo questa volta" sul padre. Non esiste solo questa volta. Una modifica diretta al padre diventa venti, e poi l’aggiornamento che non puoi applicare è proprio quello di sicurezza di cui avevi più bisogno. Ogni modifica, per quanto piccola, va nel figlio.
In sintesi
Un tema figlio richiede circa dieci minuti per essere messo in piedi, una directory, un config/theme.yml, il nome del padre scritto correttamente, l’attivazione nel back office, e trasforma ogni futuro aggiornamento del padre da una cancellazione delle personalizzazioni a un non-evento. Non è una tecnica avanzata né una best practice opzionale; in PrestaShop è semplicemente il modo corretto di personalizzare qualunque tema che non hai scritto tu. Se in questo momento stai modificando direttamente i file del tema padre, la mossa è la stessa anche se le modifiche ti sembrano minime: crea oggi un tema figlio e sposta lì i tuoi override prima che il prossimo aggiornamento li sovrascriva. Poi mantienilo snello, sposta lo stile puro in CSS e JS che sopravvivono agli aggiornamenti, sposta il comportamento nei moduli, e riserva gli override dei template alle modifiche di markup che ne hanno davvero bisogno.
Domande frequenti
Devo copiare tutto il tema padre nel tema figlio?
No, e non dovresti farlo. Un tema figlio eredita tutto dal padre per impostazione predefinita; copi solo i file specifici che stai modificando, conservando il loro percorso relativo. Un figlio minimale può essere semplicemente una directory con un config/theme.yml valido, e renderizzerà in modo identico al padre. Meno file copi, più aggiornamenti del padre arrivano direttamente al tuo negozio.
Il mio tema figlio sembra identico al padre e non compare nulla di ciò che ho modificato. Perché?
Quasi sempre per una di due ragioni: il figlio non è mai stato attivato sotto Aspetto → Tema & logo (creare la directory non basta), oppure c’è una mancata corrispondenza dei nomi in config/theme.yml, il valore di name non corrisponde alla directory del figlio, oppure parent punta a un tema non installato. Controlla prima l’attivazione, poi lo YAML.
Posso mettere CSS e JavaScript personalizzati nel tema figlio?
Puoi farlo, ma per modifiche puramente visive, colori, font, spaziature, nascondere un elemento, sovrascrivere un intero template è pesante e impone un nuovo merge a ogni aggiornamento del padre. Un foglio di stile o uno script caricato dopo gli asset del padre è più leggero e non duplica alcuna logica di template. Riserva gli override dei template alle vere modifiche di markup; per tutto ciò che può fare il CSS, usa il CSS. Vedi CSS e JavaScript personalizzati senza rompere gli aggiornamenti.
I miei override sopravviveranno quando il tema padre viene aggiornato?
Sì, il figlio vive nella propria directory, quindi un aggiornamento del padre non lo tocca mai. L’unico compito che ti spetta è confrontare ogni file sovrascritto con la nuova versione del padre e integrare qualsiasi modifica utile (una correzione di bug, un miglioramento di accessibilità). Quel lavoro è proporzionale solo al numero di file copiati, ed è esattamente il motivo per cui mantenere basso il numero di override ripaga.
Un tema figlio può sovrascrivere il template front-end di un modulo?
È una tecnica documentata, ma è un punto debole noto proprio con i temi figli. Ci sono segnalazioni aperte di override dei template dei moduli risolti in modo incoerente da un tema figlio, perché la cache dei template può servire invece la copia del padre. Se devi rifare lo stile dell’output di un modulo e stai usando un tema figlio, testalo con attenzione sulla tua versione esatta, oppure posiziona l’override direttamente sul tema attivo invece di affidarti al passaggio padre/figlio.
La modifica che voglio fare riguarda il comportamento, non l’aspetto. Va nel tema figlio?
No. Se stai cambiando il modo in cui vengono calcolati i prezzi, come viene scelta la spedizione o cosa succede durante la finalizzazione dell’ordine, quella è logica di business e appartiene a un modulo o a una classe di override, mai a un file .tpl. I template mostrano dati; non devono elaborarli. Un tema decide come appare il carrello; un modulo decide come si comporta il carrello.
Un tema figlio dovrebbe stare sotto controllo versione?
Sì. Un tema figlio è codice personalizzato, e deve stare in Git con messaggi di commit reali. Il vantaggio si vede dopo un aggiornamento del padre: se un merge va storto, sei a un revert da uno stato noto e funzionante invece di dover indovinare cosa avevi cambiato. Inoltre diventa immediato vedere quali file del padre hai effettivamente creato come fork e quindi quali dovrai confrontare al prossimo aggiornamento.
Hummingbird e Classic richiedono configurazioni diverse per i temi figli?
Il meccanismo di override è identico, stesso config/theme.yml, stesso ordine di risoluzione, quindi la scelta del padre non cambia la logica. Ciò che cambia è il flusso di lavoro per lo stile: la pipeline dei fogli di stile di Hummingbird è basata su SCSS, mentre quella di Classic è più semplice, quindi cambia il modo in cui compili il CSS personalizzato. Scegli Hummingbird per i nuovi progetti e Classic quando mantieni un tema figlio esistente basato su Classic.
Guide correlate
Commenti
Lascia un commento
Condividi una domanda, un dettaglio di installazione o un feedback utile per un altro lettore.