Personalizzare un tema WordPress sembra semplice, almeno finché arriva un aggiornamento e scompare quella modifica che aveva richiesto un pomeriggio intero. Il problema non è l’aggiornamento: è aver modificato direttamente i file del tema originale. Un tema child WordPress, chiamato anche tema figlio, serve proprio a separare le personalizzazioni dal codice del tema principale. Non è però una soluzione magica per qualsiasi intervento e, soprattutto, non è obbligatorio in ogni progetto.

In questa guida vediamo come funziona, quando conviene utilizzarlo, come crearne uno con i file essenziali e quali verifiche fare prima di attivarlo. Vedremo anche cosa cambia tra temi classici e temi a blocchi, perché molti tutorial trattano ancora WordPress come se l’editor del sito non esistesse.

Che cos’è un tema child WordPress

Un tema child è un tema che eredita il comportamento e l’aspetto di un tema principale, detto parent theme, e permette di aggiungere modifiche senza riscrivere l’intero progetto. WordPress carica il tema figlio attivo e utilizza il tema genitore per le parti che il figlio non definisce. Per questo, un child può contenere pochissimi file pur mostrando un sito completo.

Immagina il tema principale come la struttura di una casa e il child come un insieme di interventi documentati: una diversa finitura, un elemento sostituito, qualche dettaglio su misura. Quando il produttore aggiorna la struttura originale, gli interventi separati non vengono sovrascritti automaticamente. Questo non garantisce che ogni personalizzazione rimanga compatibile: una modifica importante nel parent può richiedere di aggiornare anche il codice del child.

Il tema principale deve restare installato. Se elimini la cartella parent, il figlio perde la propria dipendenza e WordPress non può utilizzarlo correttamente. Il child non è quindi una copia indipendente del tema e non sostituisce il backup.

Quando serve davvero un tema child

È particolarmente utile quando devi modificare file di template, aggiungere funzioni legate alla presentazione del sito, includere CSS organizzato in file o mantenere personalizzazioni che devono sopravvivere agli aggiornamenti del tema. Può essere una scelta ragionevole anche quando un progetto cresce e le modifiche non possono più essere gestite con poche impostazioni visuali.

Un esempio concreto: vuoi intervenire sul markup di una sezione del tema, aggiungere un foglio di stile specifico o modificare il comportamento di un componente tramite hook previsti dallo sviluppatore. Inserire questi interventi nei file del parent espone al rischio di perderli al prossimo aggiornamento; separarli nel child è più controllabile.

Al contrario, per cambiare un colore, scegliere un font o regolare uno spazio spesso bastano le opzioni del tema, gli stili globali o gli strumenti dell’editor. Un child introdotto soltanto per una modifica già gestita dall’interfaccia aggiunge manutenzione senza un vantaggio reale. La domanda corretta non è «devo sempre creare un tema child?», ma «dove deve vivere questa personalizzazione per restare gestibile?».

Tema child, CSS aggiuntivo e plugin: cosa scegliere

Le tre soluzioni hanno ruoli differenti. Il CSS aggiuntivo o gli stili dell’editor sono adatti a correzioni visive contenute; il child è utile per modifiche specifiche del tema, template e file collegati al suo funzionamento; un plugin dedicato è spesso la sede migliore per funzionalità che devono restare disponibili anche cambiando tema.

Per esempio, un tipo di contenuto personalizzato o una logica applicativa fondamentale non dovrebbe dipendere da un tema soltanto perché è comodo aggiungere codice nel suo functions.php. Se domani cambi grafica, quella funzione potrebbe sparire. Per questo vale la pena distinguere sempre presentazione e funzionalità.

Prima di procedere, se devi ancora scegliere o installare il tema principale, consulta la nostra guida su come installare un tema WordPress. Attivare un child sopra un parent non verificato significa costruire personalizzazioni su una base incerta.

Prima di creare il tema figlio: quattro controlli

Il primo controllo riguarda i backup: salva database e file e verifica di poterli ripristinare. Un child modifica la gestione dei file del tema ma non protegge ordini, pagine, impostazioni o contenuti. La nostra guida al backup WordPress spiega cosa includere e come valutare una copia affidabile.

Il secondo controllo riguarda l’ambiente: se il sito è online, prepara uno staging e prova lì l’attivazione. Il terzo riguarda la documentazione del tema parent: alcuni produttori forniscono già un child ufficiale, con file e istruzioni specifiche. Il quarto riguarda il metodo di accesso: devi poter recuperare il sito tramite SFTP o file manager anche se un errore PHP blocca la bacheca.

Se stai lavorando su un negozio WooCommerce, verifica almeno carrello, checkout, account e pagine prodotto dopo ogni modifica. Una personalizzazione del template che sembra innocua può interferire con gli aggiornamenti del tema o del plugin e il problema può emergere soltanto durante un acquisto.

Come creare un tema child WordPress manualmente

Per un esempio semplice utilizziamo come parent il tema Twenty Twenty-Four, il cui nome di cartella è twentytwentyfour. Il procedimento di riconoscimento del tema figlio vale anche per altri temi, ma il caricamento degli stili e l’organizzazione dei template possono cambiare. Non copiare quindi alla cieca codice pensato per un tema diverso.

1. Crea la cartella del tema figlio

Apri la directory wp-content/themes/ e crea una nuova cartella, ad esempio mio-tema-child. Deve trovarsi accanto alla cartella del parent, non al suo interno. Scegli un nome leggibile, senza spazi, e non rinominare la cartella del tema genitore.

2. Aggiungi il file style.css

All’interno di mio-tema-child crea un file style.css con questa intestazione minima:

/*
Theme Name: Mio Tema Child
Template: twentytwentyfour
Version: 1.0.0
Text Domain: mio-tema-child
*/

La riga decisiva è Template: deve corrispondere esattamente al nome della cartella del parent, non al titolo commerciale visualizzato nella bacheca. Se il tema principale si trova in wp-content/themes/flatsome, per esempio, il valore sarà flatsome. Un carattere sbagliato basta a impedire il corretto riconoscimento del rapporto tra i temi.

Theme Name identifica il tema figlio nell’elenco dei temi installati. Gli altri campi, come descrizione, autore e versione, aiutano a gestire il progetto. In questa fase il file può contenere soltanto l’intestazione: il child esiste anche senza regole CSS personalizzate.

3. Installa e attiva il child

Puoi trasferire la cartella via SFTP oppure comprimerla in un file ZIP che contenga la cartella del child e caricarlo da Aspetto → Temi → Aggiungi nuovo tema → Carica tema. Prima dell’attivazione verifica che il parent sia già installato. Poi attiva il child e controlla la homepage, una pagina interna, la navigazione e le principali funzionalità.

Se tutto è stato configurato correttamente, il sito dovrebbe mantenere l’aspetto del tema principale. Un cambiamento inatteso non va ignorato: potrebbe indicare un foglio di stile non caricato, una diversa gestione delle impostazioni o una personalizzazione che il tema parent salva in modo particolare.

Come usare functions.php senza creare errori

Il file functions.php del child è facoltativo. A differenza dei template, non sostituisce il functions.php del parent: WordPress carica entrambi, eseguendo quello del figlio prima di quello del genitore. Questa distinzione è fondamentale. Copiare interamente il file del tema principale nel child può provocare dichiarazioni duplicate di funzioni ed errori fatali.

Se ti serve caricare un foglio di stile del child e il parent non lo carica già, puoi aggiungere un functions.php con il seguente esempio. Il codice va adattato dopo aver controllato come il parent gestisce i propri CSS:

<?php
add_action( 'wp_enqueue_scripts', 'mio_tema_child_carica_stili' );

function mio_tema_child_carica_stili() {
    wp_enqueue_style(
        'mio-tema-child-style',
        get_stylesheet_uri(),
        array(),
        wp_get_theme()->get( 'Version' )
    );
}

Non esiste una regola universale secondo cui ogni child debba caricare manualmente anche lo style.css del parent. Alcuni temi lo includono già, altri usano più file compilati o meccanismi propri. Caricare due volte gli stessi stili può introdurre richieste superflue o problemi di ordine. La documentazione ufficiale WordPress raccomanda di verificare prima il comportamento del tema genitore.

Per aggiungere codice PHP usa nomi di funzione univoci, preferibilmente con un prefisso del progetto, e non modificare il sito live senza una via di recupero. Se dopo una modifica compare un errore critico, la nostra guida agli errori critici WordPress aiuta a individuare il file responsabile.

Come funzionano i template nel tema child

Nei temi classici puoi sovrascrivere determinati file di template del parent copiandoli nel child nella posizione corrispondente e modificando soltanto ciò che serve. La struttura relativa delle cartelle conta: non basta salvare un file con lo stesso nome in un percorso casuale. WordPress utilizza le regole della gerarchia dei template e le eventuali convenzioni del tema.

Qui nasce uno dei rischi più sottovalutati. Se copi un template oggi e il produttore lo aggiorna domani per correggere compatibilità o sicurezza, la tua copia potrebbe continuare a usare il vecchio markup. Il child protegge le modifiche dalla sovrascrittura, ma non aggiorna automaticamente i file che hai duplicato. Per questo conviene limitare gli override, annotare cosa è stato cambiato e confrontarli dopo gli aggiornamenti importanti.

Con WooCommerce il discorso richiede ancora più attenzione: alcuni override possono coinvolgere template del plugin o integrazioni specifiche del tema. Prima di copiare file, cerca hook, filtri o impostazioni che permettano di ottenere lo stesso risultato con meno manutenzione.

Cosa cambia con i temi a blocchi e theme.json

WordPress moderno supporta temi a blocchi, con template HTML, parti del sito e configurazioni definite anche in theme.json. Un child rimane possibile, ma non sempre richiede gli stessi passaggi usati nei temi classici. Se vuoi modificare palette, tipografia o impostazioni globali, il file theme.json del child può essere più appropriato di un lungo foglio CSS.

La configurazione segue una gerarchia: impostazioni predefinite di WordPress, configurazione del parent, configurazione del child e personalizzazioni dell’utente salvate tramite l’editor del sito. Queste ultime possono prevalere su ciò che scrivi nei file del tema. Se una modifica nel child sembra non avere effetto, non dare subito la colpa alla cache: controlla anche gli stili e i template personalizzati memorizzati nel database.

Un altro dettaglio importante è che un tema a blocchi completo ha requisiti strutturali propri, mentre un child eredita dal parent. Non occorre duplicare l’intera struttura del tema originale per fare una piccola personalizzazione. Copiare tutto «per sicurezza» produce quasi sempre più lavoro e più punti da controllare.

Tema child Flatsome: un esempio pratico

Flatsome è un esempio utile perché molti siti WooCommerce lo utilizzano per personalizzare header, pagine prodotto e componenti dell’interfaccia. Se devi introdurre modifiche PHP o CSS che non sono gestite dalle impostazioni del tema, un child può aiutare a mantenerle separate dagli aggiornamenti del parent.

Nel file style.css del child di Flatsome, la riga Template: flatsome deve riferirsi alla cartella effettiva del tema principale. Tuttavia, per il resto della configurazione conviene seguire le istruzioni e l’eventuale pacchetto child forniti dal produttore. Un tema commerciale può avere convenzioni specifiche per asset, hook e opzioni: un tutorial generico non sostituisce la documentazione del prodotto.

Se il sito contiene molte personalizzazioni, suddividile per funzione e tieni traccia delle modifiche. Un functions.php con centinaia di righe senza commenti, controllo delle dipendenze o gestione degli errori diventa fragile anche se si trova nel child. La separazione dei file non sostituisce una buona organizzazione del codice.

Cinque errori comuni da evitare

Usare il nome sbagliato nel campo Template. È il problema più banale e frequente: serve il nome della cartella parent. Eliminare il tema genitore. Il child non contiene tutto il necessario per funzionare da solo. Copiare il functions.php del parent. Può causare errori fatali per funzioni dichiarate due volte.

Duplicare molti template senza motivo. Ogni override può richiedere verifiche quando il parent viene aggiornato. Confondere child e backup. Un tema figlio non recupera un database corrotto, non annulla un aggiornamento fallito e non protegge da una modifica errata: servono backup e un piano di ripristino.

C’è poi un errore meno evidente: usare il child come contenitore universale di qualsiasi funzionalità. Prima di aggiungere codice, chiediti se deve continuare a funzionare anche con un altro tema. Se la risposta è sì, valuta un plugin dedicato invece di legare quella funzione alla grafica.

Come verificare che il tema child funzioni

Dopo l’attivazione confronta alcune pagine prima e dopo, su desktop e mobile. Controlla menu, footer, moduli, immagini, pagine articolo e, se presente, l’intero percorso d’acquisto WooCommerce. Apri gli strumenti sviluppatore del browser per individuare errori JavaScript o file CSS mancanti; controlla anche i log PHP quando aggiungi codice personalizzato.

Poi esegui un aggiornamento di prova del parent in staging e verifica che le personalizzazioni rimangano presenti e compatibili. È il test più importante, perché il vero scopo del child è permetterti di aggiornare senza dover ricostruire ogni volta il lavoro fatto. Se vuoi organizzare questi controlli prima del rilascio, WP Staging Pro è una delle soluzioni disponibili nel catalogo The Waffle per lavorare su una copia del sito.

Domande frequenti sul tema child WordPress

Un tema child rallenta WordPress?

Non necessariamente. Il solo fatto di avere un child non implica un rallentamento significativo. Le prestazioni dipendono dalle risorse caricate, dalle personalizzazioni, dalle query e dal codice aggiunto. Un child essenziale può avere un impatto minimo; uno che include script pesanti o carica CSS duplicati può peggiorare la situazione.

Posso creare un child su un sito già online?

Sì, ma l’attivazione può cambiare impostazioni o comportamento di componenti specifici del tema. Prima esegui backup, prova il passaggio in staging e annota le impostazioni da verificare. Non considerare l’attivazione automaticamente priva di rischi soltanto perché il child eredita il parent.

Devo creare un child per usare Elementor o un page builder?

No. Per utilizzare normalmente un page builder non è richiesto un child. Può diventare utile se il progetto richiede personalizzazioni del tema non gestibili dal builder, oppure interventi su template e codice. Il criterio resta la natura della modifica, non il numero di plugin installati.

Posso aggiornare il tema parent dopo aver attivato il child?

Sì, ed è uno dei principali vantaggi. I file propri del child non vengono normalmente sovrascritti dall’aggiornamento del parent. Questo però non esonera dal controllo di compatibilità, soprattutto se hai copiato template o utilizzato funzioni interne del tema originale.

Procedura completa prima di lavorare su un sito online

Il modo più affidabile per iniziare non è aprire subito un editor e modificare i file. Prima occorre capire quali personalizzazioni esistono già e quali componenti le gestiscono. Un sito WordPress può avere impostazioni nel Customizer, stili globali nell’Editor del sito, codice CSS aggiuntivo, snippet in un plugin, template di un page builder e funzioni personalizzate nel tema. Senza questa ricognizione si rischia di ricreare nel child qualcosa che è già configurato altrove, introducendo conflitti difficili da riconoscere.

Prepara un elenco delle pagine più importanti: homepage, pagina dei contatti, archivio del blog, singolo articolo, eventuali schede prodotto, carrello e checkout. Annota gli elementi che non devono cambiare, per esempio menu, intestazione, piè di pagina, larghezza del contenuto e visualizzazione mobile. Questo elenco sarà la base del controllo dopo l’attivazione. È un lavoro poco spettacolare, ma evita di scoprire un problema quando lo segnala un cliente.

Prima di intervenire crea un backup verificabile di file e database, non soltanto una copia della cartella del tema. Se possibile usa un ambiente di staging e verifica che la copia funzioni con la stessa versione di PHP, di WordPress e dei plugin principali. Ricorda che uno staging non è automaticamente un backup: per recuperare dati persi serve una copia ripristinabile. Se il sito gestisce ordini, iscrizioni o prenotazioni, evita di sovrascrivere il database di produzione con quello della copia di test.

Come riconoscere il tema parent corretto

La riga Template nel file style.css del child deve corrispondere esattamente al nome della directory del tema genitore installato, non al suo nome commerciale e nemmeno al titolo mostrato nella bacheca. Per verificarlo puoi consultare la cartella wp-content/themes tramite SFTP o il file manager dell’hosting. Se il tema parent risiede nella cartella flatsome, il valore corretto è flatsome. Una differenza di maiuscole, uno spazio o un trattino errato può impedire a WordPress di riconoscere il rapporto tra i due temi.

Non rinominare la directory del tema genitore per adattarla al child: così rischi di compromettere gli aggiornamenti e i percorsi delle risorse. È il child che deve indicare il parent esistente. Controlla inoltre che il tema principale sia installato e mantenuto aggiornato. Il tema figlio non lo sostituisce: continua a dipendere dai suoi file e dalle sue funzionalità.

Come gestire gli stili senza creare conflitti

Una modifica CSS apparentemente banale può avere effetti diversi a seconda della specificità dei selettori e dell’ordine di caricamento. Se uno stile del tema principale continua a prevalere, non aggiungere automaticamente !important ovunque. Ispeziona l’elemento con gli strumenti di sviluppo del browser, individua la regola vincente e verifica se esiste un’impostazione ufficiale del tema che risolve il problema. Le personalizzazioni più robuste utilizzano selettori precisi, ma non eccessivamente legati alla struttura HTML interna.

Evita selettori che dipendono da classi generate dinamicamente da un builder, perché possono cambiare dopo un aggiornamento. Preferisci, quando possibile, classi personalizzate assegnate ai componenti. Per una modifica limitata a una singola pagina, applica una classe specifica al contenitore anziché intervenire su tutti i titoli o pulsanti del sito. Infine prova la resa con viewport differenti e con utenti autenticati e non autenticati: barre di amministrazione, menu mobili e contenuti dinamici possono modificare l’impaginazione.

Modificare template PHP: quando è necessario e quando evitarlo

Nei temi classici è possibile sovrascrivere alcuni template copiandoli nel child, rispettando la struttura prevista dal tema. Tuttavia non ogni file PHP del parent può essere copiato indiscriminatamente aspettandosi che WordPress lo utilizzi. Occorre conoscere la gerarchia dei template di WordPress e gli eventuali sistemi di override specifici del tema o del plugin. Prima di duplicare un file, verifica se esiste un hook, un filtro o un’impostazione che consenta di ottenere lo stesso risultato con meno codice.

Quando un template viene copiato nel child, il suo contenuto non si aggiorna automaticamente insieme al parent. Questo è un vantaggio per conservare una personalizzazione, ma anche una responsabilità: se il tema principale corregge un problema di accessibilità o compatibilità nel template originale, la copia personalizzata potrebbe non ricevere quella correzione. Mantieni un elenco dei template sovrascritti e confrontali dopo gli aggiornamenti importanti. Nei negozi WooCommerce questa disciplina è particolarmente utile, perché alcuni template del plugin possono cambiare nel tempo.

Personalizzazioni e sicurezza: cosa non inserire nel tema figlio

Un tema child non è il posto giusto per salvare password, chiavi API, token o credenziali. I file del tema sono codice applicativo e possono finire in archivi di backup, repository o pacchetti condivisi. Le informazioni sensibili devono essere gestite attraverso strumenti e configurazioni appropriati, fuori dai file distribuiti. Anche le funzioni che governano dati importanti, integrazioni esterne o logiche commerciali dovrebbero essere valutate come funzionalità autonome, non semplicemente come elementi grafici del tema.

Non copiare intere librerie del tema principale nel child per modificarne una riga. Aumenteresti la superficie di manutenzione e potresti mantenere in uso codice obsoleto. Se devi intervenire su funzioni PHP, controlla la validazione dei dati in ingresso, l’escaping dell’output e le autorizzazioni dell’utente. Quando la modifica riguarda un’azione amministrativa, verifica anche i nonce previsti da WordPress. Il child preserva il codice durante gli aggiornamenti del parent, ma non rende quel codice sicuro per definizione.

Verifiche dopo l’attivazione del child theme

Dopo aver attivato il tema figlio, apri il sito in una finestra privata e controlla che le risorse CSS e JavaScript vengano caricate senza errori. Ispeziona la console del browser e, se necessario, i log PHP dell’hosting. Controlla che il menu principale e quello mobile si aprano correttamente, che il logo non sia scomparso e che immagini e font vengano serviti con i percorsi giusti. Un child apparentemente funzionante sulla homepage può comunque avere problemi nei template di archivio o nelle pagine meno visitate.

Se utilizzi WooCommerce, verifica almeno ricerca prodotti, varianti, aggiunta al carrello, checkout e area cliente, senza eseguire acquisti reali non necessari. Se usi un builder visuale, apri una pagina in modifica e controlla che l’editor carichi correttamente. Confronta inoltre una pagina prima e dopo l’intervento, preferibilmente usando screenshot con la stessa larghezza dello schermo. Le differenze visive non sempre sono errori, ma devono essere intenzionali.

Infine svuota soltanto le cache necessarie e ripeti i controlli. Una cache può mostrare vecchi stili e far sembrare inefficace una modifica corretta; al contrario, una pagina servita dalla cache può nascondere un errore presente nella versione aggiornata. Se qualcosa non funziona, torna alla modifica più recente, non disattivare alla cieca tutti i componenti. Un registro sintetico dei cambiamenti, con data e motivo, semplifica molto la diagnosi.

Come mantenere il child nel tempo

Il lavoro non termina quando il sito appare corretto. Aggiorna il tema parent secondo una procedura controllata, soprattutto quando il produttore modifica template, hook o dipendenze. Dopo ogni aggiornamento significativo ripeti almeno i test delle funzionalità critiche. Il child deve essere versionato o archiviato in modo da poter confrontare le modifiche e recuperare rapidamente una versione precedente.

Se più persone intervengono sul sito, definisci chi può modificare i file e come vengono approvate le modifiche. Evita di lavorare contemporaneamente su copie diverse del child, perché l’ultimo caricamento può sovrascrivere il lavoro precedente. Quando una personalizzazione non serve più, rimuovila in modo consapevole: conservare anni di CSS inutilizzato rende più difficile capire quale regola stia causando un problema. Un tema figlio ben gestito è piccolo, leggibile e documentato.

Conclusione: usa il child quando risolve un problema reale

Un tema child WordPress è uno strumento di manutenzione e sviluppo: rende più chiara la separazione tra codice del produttore e modifiche del progetto, semplifica gli aggiornamenti e aiuta a documentare ciò che è stato personalizzato. Non è un requisito universale e non sostituisce staging, backup o buone pratiche di sviluppo.

Se devi cambiare poche impostazioni visive, parti dagli strumenti del tema. Se devi intervenire sui file e mantenere modifiche aggiornabili, valuta un child ben strutturato. Se stai aggiungendo funzionalità indipendenti dall’aspetto del sito, considera un plugin. La scelta giusta è quella che riduce il lavoro di domani, non quella che aggiunge più file oggi.

Il team di The Waffle