Cos’è un tema child WordPress
Un tema child WordPress, chiamato in italiano tema figlio, è un tema che eredita caratteristiche e funzionalità da un altro tema, definito parent theme o tema genitore.
Il tema parent rimane quindi la base del sito. Contiene template, funzioni, fogli di stile e tutte le altre risorse necessarie al funzionamento del tema.
Il child theme aggiunge un livello sopra questa base. Al suo interno si inseriscono soltanto le personalizzazioni che devono essere mantenute separatamente dal tema originale.
È proprio questa separazione a renderlo utile.
Se si modifica direttamente un file del tema parent, infatti, un successivo aggiornamento può sostituire quel file con la versione distribuita dallo sviluppatore. Le modifiche effettuate manualmente rischiano quindi di andare perse.
Con un tema child il codice personalizzato rimane invece nella propria directory.
WordPress definisce infatti il child theme come un’estensione del tema parent: permette di modificare o estendere il tema senza intervenire direttamente sul suo codice.
Un esempio per capire come funziona
Si supponga di avere installato un tema chiamato:
mio-tema
La relativa directory potrebbe trovarsi in:
wp-content/themes/mio-tema/
All’interno sono presenti tutti i file distribuiti dallo sviluppatore.
Si vuole però personalizzare il sito.
Una prima possibilità sarebbe aprire direttamente i file di mio-tema e modificarli. Tecnicamente funziona, ma introduce un problema: quei file appartengono al tema originale e possono essere sostituiti durante un aggiornamento.
Una soluzione più ordinata consiste nel creare:
wp-content/themes/mio-tema-child/
Il tema parent continua a fornire tutto ciò che serve. Nel child vengono conservate soltanto le personalizzazioni.
Il risultato può essere rappresentato così:
WordPress
│
└── wp-content
│
└── themes
│
├── mio-tema
│ ├── style.css
│ ├── functions.php
│ └── ...
│
└── mio-tema-child
├── style.css
└── functions.php
Il parent deve rimanere installato perché il child dipende da esso. Un tema figlio non è quindi un tema completamente indipendente.
Perché conviene usare un tema child
Il motivo principale riguarda la manutenzione.
Gli aggiornamenti di un tema possono contenere correzioni di sicurezza, compatibilità con nuove versioni di WordPress, correzioni di errori e modifiche funzionali.
Rinunciare agli aggiornamenti soltanto perché sono stati modificati alcuni file del tema non è una buona strategia.
Il tema child permette invece di separare il codice dello sviluppatore dalle personalizzazioni realizzate sul sito.
Questa distinzione aiuta anche durante la manutenzione. Aprendo la directory del child si vede immediatamente quale codice è stato aggiunto rispetto al tema originale.
Il tema parent può continuare a evolvere mentre le modifiche personalizzate rimangono separate.
Questo non significa, però, che un child theme renda qualsiasi modifica automaticamente compatibile con tutte le future versioni del parent. Se viene sovrascritto un template e lo sviluppatore modifica profondamente la versione originale, può essere necessario aggiornare anche la copia presente nel child.
Il tema child evita la sovrascrittura delle personalizzazioni. Non elimina la necessità di controllare la compatibilità del codice.
Quando serve davvero un tema child
Non occorre creare un child theme per qualsiasi modifica grafica.
Se il tema permette di cambiare colori, logo, tipografia o altre impostazioni attraverso le proprie opzioni oppure attraverso l’editor di WordPress, si possono utilizzare normalmente quegli strumenti.
Il child theme diventa particolarmente utile quando si interviene sui file o sul codice del tema.
Succede, per esempio, quando si deve modificare un template, aggiungere codice PHP legato al tema, introdurre CSS personalizzato organizzato nel progetto oppure creare nuovi template e parti del tema.
Prima di procedere conviene quindi porsi una domanda: la modifica riguarda realmente il tema?
Se la risposta è sì, il child theme può essere il posto corretto.
Se invece si sta sviluppando una funzionalità che deve continuare a funzionare anche cambiando completamente tema, può essere più appropriato utilizzare un plugin.
La differenza è importante.
Una funzione inserita nel functions.php del child theme rimane legata all’attivazione di quel tema. Cambiando tema, quel codice non viene più eseguito. Anche un approfondimento presente sul blog VHosting evidenzia questa differenza tra codice associato al tema e funzionalità mantenute tramite plugin o sistemi dedicati agli snippet.
Prima di creare il child theme
Dalle guide confrontate emerge un suggerimento pratico che vale la pena rendere esplicito: prima di modificare un sito già online è opportuno disporre di un backup e, quando possibile, effettuare le prove in un ambiente separato.
Un errore PHP può rendere temporaneamente inutilizzabile il sito. Un template modificato male può alterare il frontend. Un errore CSS può invece produrre un risultato molto diverso da quello previsto.
Sul blog VHosting viene consigliato il backup prima di intervenire sui file di WordPress e viene indicato il child theme come buona pratica per preservare le modifiche durante gli aggiornamenti.
Per la procedura manuale serve inoltre poter accedere ai file dell’installazione.
Si può utilizzare il file manager messo a disposizione dall’hosting oppure un collegamento FTP/SFTP. Le guide operative consultate includono normalmente questi strumenti tra i prerequisiti per la creazione manuale del child theme.
Come creare manualmente un tema child WordPress
Si parte dalla directory dei temi:
wp-content/themes/
Qui si trova la cartella del tema parent.
Se, per esempio, il tema principale utilizza:
wp-content/themes/mio-tema/
si può creare:
wp-content/themes/mio-tema-child/
L’aggiunta di -child non costituisce un obbligo tecnico. È una convenzione utile per riconoscere facilmente la directory.
Il passaggio successivo consiste nella creazione del file style.css.
Il file style.css
Il file style.css non contiene necessariamente soltanto regole CSS.
All’inizio presenta un’intestazione sotto forma di commento attraverso la quale WordPress può leggere le informazioni sul tema.
Per un esempio semplice si può utilizzare:
/* Theme Name: Mio Tema Child Description: Tema child di Mio Tema Author: Nome autore Template: mio-tema Version: 1.0 */
Il valore più importante per stabilire la relazione con il parent è:
Template: mio-tema
Qui non va necessariamente inserito il nome commerciale mostrato nell’interfaccia di WordPress.
Deve essere indicato il nome della directory del parent theme.
Se la struttura è:
wp-content/themes/astra/
il valore sarà:
Template: astra
Se invece la cartella fosse:
wp-content/themes/mio-tema/
si utilizzerebbe:
Template: mio-tema
Un errore in questo campo impedisce a WordPress di associare correttamente il tema child al relativo parent.
La relazione tra parent e child theme permette quindi di mantenere una base comune senza duplicare l’intero progetto.
functions.php è obbligatorio?
Qui si trova una delle differenze più interessanti tra le varie guide consultate.
Molti tutorial propongono immediatamente la creazione di due file:
style.css functions.php
È una configurazione molto comune, ma non bisogna confondere “comune” con “sempre obbligatoria”.
Il file functions.php serve quando il child theme deve eseguire codice PHP. Può essere utilizzato, per esempio, per registrare hook, caricare risorse oppure introdurre funzioni specifiche.
Può iniziare semplicemente con:
<?php /** * Funzioni del tema child. */
Un aspetto importante riguarda il rapporto con il functions.php del parent.
A differenza di diversi template, il file functions.php presente nel child non sostituisce quello del tema genitore. WordPress carica entrambi.
Non bisogna quindi copiare il contenuto del functions.php del parent nel child.
Si inserisce soltanto il codice aggiuntivo necessario.
Attenzione ai nomi delle funzioni PHP
Dal confronto con le guide francesi emerge un problema pratico che spesso viene trascurato nei tutorial più brevi.
Poiché vengono eseguiti sia il codice del child sia quello del parent, bisogna evitare di dichiarare accidentalmente una funzione PHP già esistente con lo stesso nome.
Una doppia dichiarazione può produrre un errore del tipo:
Cannot redeclare function...
La guida di Notuxedo segnala esplicitamente questo possibile conflitto e suggerisce di utilizzare nomi differenti oppure, quando appropriato, verificare l’esistenza della funzione.
Una semplice precauzione consiste nell’utilizzare un prefisso specifico per le proprie funzioni:
<?php
function mio_sito_personalizzazione() {
// Codice personalizzato.
}
Il prefisso riduce la possibilità di collisione con funzioni definite da WordPress, dal parent theme o dai plugin.
Come caricare gli stili del tema parent
Questo è probabilmente il punto sul quale le vecchie guide generano più confusione.
Si trovano spesso esempi nei quali viene indicato come obbligatorio inserire nel functions.php un wp_enqueue_style() per caricare il CSS del parent.
La documentazione ufficiale WordPress chiarisce invece che il comportamento dipende da come il parent theme carica i propri fogli di stile.
Se il parent carica soltanto lo stylesheet del tema attivo tramite get_stylesheet_uri(), può essere necessario caricare esplicitamente anche il foglio di stile del parent.
Un esempio è:
<?php
function mio_tema_child_styles() {
wp_enqueue_style(
'mio-tema-parent',
get_parent_theme_file_uri( 'style.css' )
);
}
add_action( 'wp_enqueue_scripts', 'mio_tema_child_styles' );
Non va però copiato automaticamente in qualsiasi child theme.
Prima si verifica come il parent gestisce i propri CSS e si consulta, quando disponibile, la documentazione del tema.
È un dettaglio importante perché rende la guida meno “meccanica”: il codice corretto dipende dalla struttura reale del tema utilizzato.
Perché non usare @import
In vecchi tutorial si può ancora incontrare una soluzione simile:
@import url("../mio-tema/style.css");
Per un child theme moderno non è il metodo da prendere come riferimento.
Quando occorre gestire esplicitamente gli stylesheet, WordPress mette a disposizione il proprio sistema di enqueue attraverso funzioni come wp_enqueue_style().
Questo consente di gestire le risorse attraverso WordPress anziché creare manualmente dipendenze CSS con @import.
Come modificare un template del parent
Qui il tema child mostra uno dei suoi utilizzi principali.
Si supponga che un tema classico utilizzi un determinato template e che sia necessario modificarlo.
Invece di intervenire direttamente nella directory del parent, si copia nel child soltanto il file necessario, mantenendo la posizione prevista dalla struttura del tema.
WordPress può utilizzare il file presente nel child al posto di quello corrispondente del parent.
La documentazione ufficiale prevede inoltre che un child theme possa sovrascrivere template, template part e pattern del parent oppure aggiungerne di nuovi. Per i pattern da sovrascrivere deve corrispondere anche lo Slug registrato.
Il principio da seguire è semplice: si copiano soltanto i file che devono realmente essere modificati.
Copiare l’intero parent dentro il child annullerebbe buona parte del vantaggio della struttura.
Il problema dei template che diventano vecchi
La separazione dei file evita che un aggiornamento cancelli la personalizzazione, ma produce anche una responsabilità.
Si immagini di copiare un template dal parent al child.
Passano alcuni mesi e lo sviluppatore pubblica una nuova versione del tema nella quale quel template viene corretto o modificato.
Il file personalizzato presente nel child non viene automaticamente riscritto con quelle modifiche.
Questo è esattamente ciò che si desiderava per proteggere la personalizzazione, ma significa anche che bisogna verificare periodicamente se il template personalizzato sia ancora compatibile con il parent aggiornato.
Un child theme deve quindi essere considerato codice da mantenere.
Come attivare il tema child
Terminata la configurazione, si accede alla dashboard di WordPress e si apre:
Aspetto > Temi
Il child dovrebbe comparire insieme agli altri temi installati.
Si attiva esattamente come un normale tema.
Il parent deve rimanere installato sul server, ma non deve essere attivato separatamente. È il child a diventare il tema attivo e WordPress utilizza il parent come base.
Dopo l’attivazione conviene controllare immediatamente il frontend.
Se la grafica appare completamente diversa, uno dei primi elementi da verificare è il caricamento dei fogli di stile. Se WordPress segnala invece che manca il tema parent, va controllato il valore Template presente in style.css.
Le guide dedicate alla risoluzione dei problemi indicano proprio il mancato caricamento di style.css tra gli inconvenienti più comuni.
Si può creare un child theme con un plugin?
Sì.
Per chi preferisce non creare manualmente directory e file esistono plugin che automatizzano parte del lavoro.
Per i block theme esiste inoltre Create Block Theme, plugin collegato all’ecosistema WordPress che permette, tra le altre operazioni, di generare un child theme a partire dal tema attivo. La documentazione WordPress.com aggiornata ad agosto 2026 indica esplicitamente questa possibilità.
Per i temi classici esistono altri plugin dedicati alla generazione e configurazione dei child theme.
Il plugin elimina alcuni passaggi manuali, ma non cambia il principio di funzionamento.
Alla fine WordPress deve comunque disporre di un tema child correttamente collegato al proprio parent.
Conoscere la procedura manuale rimane utile perché permette di capire cosa succede realmente nel filesystem e facilita la diagnosi quando qualcosa non funziona.
Child theme e block theme non sono esattamente la stessa cosa
Questo è uno degli aspetti che merita maggiore attenzione nelle guide aggiornate.
WordPress oggi distingue tra temi classici e block theme, cioè temi progettati intorno al sistema a blocchi e al Site Editor.
Nei temi classici si incontrano soprattutto file PHP, CSS e JavaScript.
Nei block theme acquistano invece maggiore importanza theme.json, i template a blocchi, le template part, i pattern e le personalizzazioni effettuate tramite Site Editor.
Anche alcune guide aggiornate al 2026 sottolineano esplicitamente la necessità di distinguere le due famiglie prima di creare il child theme.
Il concetto di ereditarietà rimane, ma cambia il modo nel quale alcune personalizzazioni vengono gestite.
theme.json e l’ereditarietà nei temi a blocchi
Nei block theme il file theme.json permette di definire impostazioni e stili globali del tema.
Anche qui esiste un meccanismo di ereditarietà.
La documentazione WordPress descrive una gerarchia nella quale intervengono le impostazioni predefinite di WordPress, il parent theme, il child theme e infine le personalizzazioni dell’utente.
Un aspetto particolarmente interessante è proprio l’ultimo livello.
Le modifiche effettuate dall’utente attraverso gli strumenti di personalizzazione possono essere memorizzate nel database e avere precedenza su theme.json, template e pattern del tema.
Questo significa che, lavorando con un block theme, modificare un file nel child e non vedere immediatamente il risultato non implica necessariamente che l’ereditarietà non funzioni.
Potrebbe esistere una personalizzazione salvata nel database che prevale sul file.
È un comportamento da conoscere quando si effettua il debug di un tema moderno.
Esistono i grandchild theme?
Una domanda meno comune, ma tecnicamente interessante, riguarda la possibilità di creare un tema figlio di un altro tema child.
WordPress non prevede una gerarchia standard installabile parent → child → grandchild.
La gerarchia dei temi si ferma a due livelli: parent e child.
Nei block theme le personalizzazioni salvate dall’utente possono comportarsi concettualmente come un ulteriore livello, ma non costituiscono un vero “grandchild theme”. Sono infatti memorizzate nel database e non rappresentano un terzo tema installabile.
Gli errori più frequenti
Il primo errore da controllare è quasi sempre il campo Template di style.css.
Deve corrispondere alla directory del parent.
Il secondo riguarda gli stylesheet. Una pagina priva della grafica prevista può indicare che il CSS del parent o del child non viene caricato come previsto.
Un’altra situazione frequente riguarda la cache. Si modifica il CSS ma il browser continua a mostrare la vecchia versione. Prima di cambiare nuovamente il codice conviene verificare la cache del browser, eventuali plugin di caching e gli altri livelli di cache presenti sull’hosting.
Con PHP bisogna invece controllare errori di sintassi e possibili collisioni tra nomi di funzione.
Se dopo una modifica compare un errore PHP, WordPress dispone anche del sistema WP_DEBUG e WP_DEBUG_LOG. Sul blog VHosting è disponibile una guida specifica dedicata a come attivare il debug su WordPress.
Child theme oppure plugin?
La scelta non dipende dalla quantità di codice, ma dalla sua funzione.
Se il codice serve a modificare l’aspetto o un comportamento strettamente collegato al tema, il child theme è una collocazione naturale.
Se invece la funzione appartiene al sito indipendentemente dalla grafica, conviene valutarne l’inserimento in un plugin.
Si pensi, per esempio, alla registrazione di un tipo di contenuto personalizzato che deve rimanere disponibile anche dopo un cambio di tema. Legarlo al child significa perdere quella registrazione quando il tema viene disattivato.
Lo stesso principio vale per integrazioni applicative e altre funzionalità che rappresentano caratteristiche del sito e non del suo aspetto.
Per approfondire la gestione del codice PHP è disponibile anche la guida VHosting su come inserire codice PHP personalizzato su WordPress. La guida tratta proprio il rapporto tra functions.php, child theme e sistemi alternativi per gestire gli snippet.
Una struttura minima da usare come riferimento
Per un tema classico molto semplice si può quindi partire da:
mio-tema-child/ │ ├── style.css └── functions.php
Il primo file potrebbe contenere:
/* Theme Name: Mio Tema Child Description: Personalizzazioni di Mio Tema Template: mio-tema Version: 1.0 */
Il secondo viene aggiunto quando occorre eseguire codice PHP:
<?php /** * Personalizzazioni PHP del tema child. */
Successivamente si aggiungono soltanto i template e le altre risorse effettivamente necessarie.
Prima di aggiungere codice per il caricamento degli stylesheet si controlla come il parent gestisce i propri CSS.
È una procedura leggermente meno automatica rispetto al classico “copia queste righe”, ma evita di trattare tutti i temi WordPress come se fossero costruiti nello stesso modo.
Dove si incontra un tema child nella pratica
Il tema child si incontra soprattutto quando un sito WordPress deve essere personalizzato oltre le opzioni offerte dal tema.
Si può avere la necessità di modificare un template, aggiungere una funzione collegata alla grafica, intervenire sulla struttura di una pagina oppure mantenere CSS specifico del progetto.
In questi casi si lavora nella directory wp-content/themes, tramite il file manager dell’hosting o FTP/SFTP, lasciando intatti i file distribuiti dallo sviluppatore.
Quando arriva un aggiornamento del parent, questo può essere installato senza cancellare direttamente i file conservati nel child. Dopo l’aggiornamento rimane comunque opportuno verificare il sito, soprattutto quando sono stati sovrascritti template o introdotte personalizzazioni PHP importanti.
È questo il punto centrale del tema child: non serve semplicemente a “fare modifiche senza perderle”, ma a separare in modo riconoscibile il codice personalizzato dal codice mantenuto da chi sviluppa il tema. Una separazione che, su un sito WordPress destinato a essere aggiornato e mantenuto nel tempo, rende molto più chiaro capire dove finisce il tema originale e dove iniziano gli interventi specifici del progetto.
