Come creare un child theme WordPress: tre metodi e quando non serve

Hai un tema che ti va bene quasi del tutto e devi cambiargli qualcosa: due colori, l’ordine di una sezione, un pezzo di codice nel footer. La tentazione è aprire i file del tema e modificarli. Funziona, per qualche settimana: al primo aggiornamento le modifiche spariscono tutte insieme, senza avviso e senza modo di recuperarle.

Il child theme è la risposta che WordPress dà a questo problema da quindici anni: una cartella separata che eredita tutto dal tema che stai usando e sovrascrive solo i pezzi che decidi tu. Il tema originale continua ad aggiornarsi, le tue modifiche restano dove le hai messe.

Questa guida copre tre modi di crearne uno — a mano, con un comando WP-CLI, con un plugin — più il caso a parte dei temi a blocchi, dove le regole cambiano. Ma la parte che serve davvero non è quella: è capire come il tuo tema padre carica il CSS, perché è lì che si rompono quasi tutti i child theme, ed è l’unica domanda a cui nessuna guida può rispondere al posto tuo.

Una nota sulle fonti. Il funzionamento descritto qui l’ho verificato il 2 settembre 2026 sulla documentazione ufficiale di WordPress, su quella di WP-CLI, sulle schede dei plugin nel repository e — dove la documentazione non basta — sul codice sorgente del core. I nomi dei file, le funzioni e i comandi hanno accanto il link alla fonte.

Cosa fa un child theme, e cosa non fa

Un child theme è una cartella dentro wp-content/themes/ che dichiara di essere figlia di un’altra. Da quel momento WordPress tratta i due temi come un tema solo, con una regola di precedenza: dove il figlio ha qualcosa, vince il figlio; dove non ce l’ha, si usa quella del padre. Il tema attivo è il figlio, ma il padre resta installato e continua a ricevere aggiornamenti.

Quello che il child theme eredita è tutto: template, funzioni, stili, pattern, impostazioni. La documentazione ufficiale sui child theme lo dice così: «A child theme includes everything from its parent theme by default». Non devi copiare niente per farlo partire.

Tre cose che invece non fa, e che vale la pena sapere prima di cominciare.

• Non protegge dagli aggiornamenti del padre in senso assoluto. Protegge i tuoi file. Se il tema padre cambia il nome di una funzione o la struttura di un template che tu hai sovrascritto, la tua copia continua a girare — e a girare vecchia. È il rovescio della medaglia di cui si parla poco.
• Non funziona senza il padre. Il tema padre deve restare installato. Se lo cancelli, in Aspetto → Temi compare l’errore «The parent theme is missing. Please install the “…” parent theme» e il child theme smette di essere utilizzabile.
• Non si annida. Il child theme di un child theme non esiste: la gerarchia ha esattamente due livelli, padre e figlio, e l’handbook lo dichiara esplicitamente. Se ti serve un terzo livello, quello che ti serve davvero è un tema tuo.

Nei temi a blocchi c’è un livello in più sopra questi due, ma non è un tema: sono le personalizzazioni dell’utente fatte dall’editor, che stanno nel database e vincono su tutto il resto. Ci torno più avanti, perché cambia parecchie cose.

Quando serve davvero, e quando basta il CSS aggiuntivo

Il consiglio «fai sempre un child theme» è pigro. Per molte delle modifiche per cui viene invocato esiste una strada più corta, e a volte il child theme è addirittura la scelta sbagliata. La domanda che decide è una sola: quello che devi cambiare è CSS, o è comportamento?

La stessa domanda vale per le modifiche che sembrano richiedere per forza un file: aggiungere una alert bar in cima al sito è il caso tipico, e in tre casi su quattro la risposta è che il child theme non serve. Per mandare a capo il titolo del sito la risposta è ancora più netta: non serve, e non basterebbe.

Il CSS aggiuntivo è la strada corta ed è ufficiale. Nei temi classici sta in Aspetto → Personalizza → CSS aggiuntivo. Nei temi a blocchi il Customizer è nascosto — la documentazione lo scrive apertamente: con un tema a blocchi «non avrai bisogno di usare il Customizer», e WordPress lo toglie dal menu se non c’è un plugin che lo richiede. Lì il CSS personalizzato si aggiunge da Aspetto → Editor → Stili, nel menu con i tre puntini, alla voce CSS aggiuntivo.

C’è però un limite che va conosciuto prima di scegliere, ed è documentato: il CSS aggiuntivo non viene toccato dagli aggiornamenti del tema, ma viene azzerato quando cambi tema. Sta nel database, legato al tema attivo. Se prevedi di cambiare tema e portarti dietro il lavoro, quel lavoro deve stare in file, cioè in un child theme.

E se la modifica riguarda una funzione — un endpoint, uno shortcode che genera la mappa del sito, un custom post type, un’integrazione — la domanda giusta non è «child theme sì o no», è «questa cosa deve sopravvivere al cambio di tema?». Se la risposta è sì, il posto è un plugin, non un tema. Un tipo di contenuto registrato nel functions.php di un child theme sparisce dal sito il giorno in cui qualcuno attiva un altro tema, e i contenuti restano nel database senza più un modo per vederli.

Se sei arrivato qui perché il tema non ti convince e stai valutando di sostituirlo, prima del child theme conviene chiedersi se il tema sia quello giusto: ho raccolto i criteri in come scegliere un tema WordPress professionale. E se invece l’idea è costruirne uno tuo, le due strade alternative sono costruire un tema da zero o partire da uno starter theme — due percorsi diversi da questo, che qui non serve percorrere. E se il tema non ti convince perché il vincolo non è il tema ma l’intero frontend, esiste una strada ulteriore — per pochi progetti, e con un costo che va messo per iscritto prima: collegare WordPress a un frontend separato.

Metodo 1: a mano, in due file

È il metodo che consiglio di fare almeno una volta, anche se poi userai un plugin: sono due file e dieci minuti, e alla fine sai esattamente cosa c’è dentro il tuo tema. Prima però una raccomandazione che vale per tutti e tre i metodi: fallo su una copia del sito, non in produzione. Attivare un child theme scritto male può lasciarti fuori dal frontend, e se non hai un ambiente di prova la guida su come si prepara un ambiente di staging spiega come farne uno in mezz’ora.

Serve sapere una cosa sola prima di cominciare: il nome esatto della cartella del tema padre, non il suo nome visualizzato. Lo trovi in wp-content/themes/. Per Twenty Twenty-Five la cartella è twentytwentyfive, tutto attaccato e minuscolo. È la fonte di errore numero uno.

style.css: l’unico file davvero obbligatorio

Crea una cartella nuova dentro wp-content/themes/ — chiamala come vuoi, purché non sia il nome di un tema esistente — e dentro un file style.css che comincia così:

/*
Theme Name:  Mio Tema Child
Template:    twentytwentyfive
Description: Personalizzazioni del tema Twenty Twenty-Five.
Author:      Nome Cognome
Version:     1.0.0
Text Domain: mio-tema-child
*/

Di questi campi due contano davvero. Theme Name è l’unico obbligatorio perché WordPress riconosca una cartella come tema. Template è quello che lo rende un child: deve corrispondere al nome della cartella del padre, esattamente, maiuscole comprese. Se sbagli quel valore il tema compare in Aspetto → Temi con l’errore «The parent theme is missing» e non si attiva.

Gli altri campi sono opzionali per WordPress ma diventano obbligatori se un giorno vuoi pubblicare il tema nella directory ufficiale: l’elenco completo, con quali sono richiesti, sta nella documentazione del foglio di stile principale. Un dettaglio che spiega alcuni comportamenti misteriosi: WordPress legge solo i primi 8 KB del file cercando questa intestazione. Se un giorno il tuo style.css diventa lungo e ti viene l’idea di spostare il commento più in basso, il tema smette di esistere per WordPress.

A questo punto il tema c’è già: puoi caricarlo e attivarlo, e il sito sarà identico a prima. Quello che ancora non funziona è il CSS che scriverai sotto quel commento — ed è il punto della sezione successiva.

functions.php: il file che quasi tutti scrivono sbagliato

Nella stessa cartella crea un functions.php. Il codice che trovi in giro, copiato di guida in guida, accoda il foglio di stile del padre e poi quello del figlio. Nella maggior parte dei casi è la cosa sbagliata da fare, e la ragione è nella sezione che segue. Il codice che serve quasi sempre è invece questo:

<?php
/**
 * Funzioni del child theme.
 */

add_action( 'wp_enqueue_scripts', 'mio_tema_child_styles' );

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

Tre cose da notare, perché sono le differenze fra questo codice e quello che si trova copiato ovunque.

• get_stylesheet_uri() restituisce lo style.css del tema attivo, che in un child theme è il figlio. È la funzione giusta per caricare il proprio foglio di stile. Quella che punta sempre al padre è un’altra, get_parent_theme_file_uri(), e serve in un caso preciso che vediamo fra poco.
• Il prefisso sul nome della funzione (mio_tema_child_) non è pignoleria. Il functions.php del figlio e quello del padre finiscono nello stesso spazio dei nomi: due funzioni con lo stesso nome producono un errore fatale, e il sito va giù.
• Il quarto argomento, wp_get_theme()->get( 'Version' ), mette il numero di versione del tuo child theme in coda all’URL del CSS. Serve a invalidare la cache del browser quando modifichi il file: cambi la Version nell’intestazione e i visitatori ricevono il foglio nuovo, invece di quello vecchio salvato tre settimane fa. Senza, ogni modifica al CSS diventa un’assistenza clienti.

Un terzo file, screenshot.png, non serve a funzionare ma serve a te: è l’anteprima che vedi in Aspetto → Temi. Senza, i child theme di un sito con quattro temi installati diventano quattro rettangoli grigi identici.

Il foglio di stile del padre: perché non esiste una ricetta unica

Questa è la sezione che vale l’articolo, ed è quella che le guide saltano perché costringe a dare una risposta scomoda: non c’è un codice da copiare che vada bene sempre. La documentazione ufficiale lo dice in modo netto — «This is different for every theme, and there are no hard rules» — e aggiunge l’istruzione operativa: devi guardare il codice del tema padre e vedere quali fogli di stile accoda.

I casi sono tre, e il codice da scrivere cambia in ognuno.

1. Il padre carica sia il proprio foglio sia quello del tema attivo. Non devi fare niente: il tuo style.css viene caricato da solo. Sono i temi scritti pensando ai child theme, ed è la minoranza.
2. Il padre carica solo il proprio foglio. Il tuo non viene caricato: devi accodarlo tu, con il codice della sezione precedente. È il caso più frequente.
3. Il padre carica solo il foglio del tema attivo (cioè usa get_stylesheet_uri()). Il tuo viene caricato, ma al posto di quello del padre: il sito perde tutti gli stili originali. Qui devi accodare tu quello del padre.

Nel terzo caso il codice è questo, e la funzione è diversa da prima perché deve puntare al padre a prescindere da quale tema sia attivo:

add_action( 'wp_enqueue_scripts', 'mio_tema_child_parent_style' );

function mio_tema_child_parent_style() {
	wp_enqueue_style(
		'mio-tema-parent-style',
		get_parent_theme_file_uri( 'style.css' )
	);
}

Come si guarda il functions.php del padre in trenta secondi

Non serve leggere tutto il tema. Serve cercare una funzione sola, e il modo più rapido è da riga di comando nella cartella del sito:

# Sostituisci twentytwentyfive con la cartella del tuo tema padre
grep -rn "wp_enqueue_style" wp-content/themes/twentytwentyfive/

Se non hai accesso SSH, apri il functions.php del padre da FTP o dal file manager dell’hosting e cerca la stessa stringa. Quello che devi guardare è l’argomento passato a wp_enqueue_style(): se è get_stylesheet_uri() sei nel caso 3, se è get_parent_theme_file_uri() o get_template_directory_uri() sei nel caso 2, se ce ne sono due sei nel caso 1.

Due esempi concreti, entrambi temi ufficiali, che mostrano quanto la risposta cambi. Twenty Twenty-Four non accoda nessun foglio di stile: il comando qui sopra sul suo functions.php non restituisce niente, e infatti la documentazione lo usa proprio come esempio del caso 2. Twenty Twenty-Five — il tema predefinito di WordPress dalla versione 6.7 del novembre 2024 — invece ne accoda uno, e lo fa con get_parent_theme_file_uri( 'style.css' ): carica sempre e solo il proprio. Sei ancora nel caso 2, e il tuo style.css resta a terra finché non lo accodi.

Due temi ufficiali, due comportamenti diversi, stesso codice necessario ma per ragioni opposte. È il motivo per cui la domanda «qual è il codice giusto per il functions.php di un child theme» non ha una risposta valida in generale — e chi te la dà senza chiederti quale sia il tema padre sta indovinando.

Il modo più rapido per capire in che caso sei, senza leggere codice: attiva il child theme vuoto e guarda il sito. Se è identico a prima, il padre carica il proprio foglio e ti manca solo il tuo. Se il sito appare senza stili, il padre stava caricando il foglio del tema attivo e adesso quello sei tu.

Metodo 2: un comando, con WP-CLI

Se hai accesso SSH al server, WP-CLI ha un comando dedicato che crea la cartella e i due file al posto tuo. È il modo più rapido dei tre e non richiede installare niente sul sito:

wp scaffold child-theme mio-tema-child \
  --parent_theme=twentytwentyfive \
  --theme_name="Mio Tema Child" \
  --author="Nome Cognome" \
  --activate

Il primo argomento è lo slug, cioè il nome della cartella che verrà creata; --parent_theme è la cartella del padre e va scritto con la stessa attenzione di prima. Gli altri parametri disponibili — --theme_uri, --author_uri, --enable-network per il multisito, --force per sovrascrivere — sono elencati nella pagina ufficiale del comando.

--activate attiva subito il tema. Su un sito in produzione è meglio ometterlo, creare il tema, guardarlo e attivarlo dopo: attivare un tema è la prima cosa che i visitatori vedono, e se il caso 3 della sezione precedente è il tuo, lo vedono senza stili.

Una cosa che il comando non fa, e che nessun generatore automatico può fare: non guarda come il padre carica il CSS. Il functions.php che genera è una base ragionevole, non una risposta al tuo caso specifico. La verifica della sezione precedente resta da fare comunque.

Metodo 3: con un plugin, e cosa guardare prima di sceglierlo

Se non hai né SSH né FTP — succede su parecchi hosting condivisi, e succede a chi gestisce il sito senza essere uno sviluppatore — restano i plugin che creano il child theme dal pannello. Fanno esattamente le stesse due cose: creano la cartella e scrivono i due file.

Qui però c’è un problema che va detto, perché riguarda proprio il plugin più consigliato. Child Theme Configurator è di gran lunga il più installato della categoria — oltre 300.000 installazioni attive — e al 2 settembre 2026 il suo ultimo aggiornamento risale al 10 giugno 2025. Nella sua pagina sul repository WordPress.org mostra l’avviso automatico che compare quando un plugin non è stato testato con le ultime tre versioni maggiori di WordPress. Non significa che non funzioni: significa che nessuno garantisce che continui a funzionare, e per un plugin che scrive file dentro wp-content/themes/ non è un dettaglio.

Il criterio, più utile di un elenco che invecchierà: prima di installarne uno, apri la sua pagina su WordPress.org e guarda tre righe — «Ultimo aggiornamento», «Testato fino alla versione» e la presenza dell’avviso in cima. Sono le stesse tre righe che si guardano per qualsiasi plugin, e qui contano di più perché il lavoro che fa è irreversibile a metà: i file restano anche dopo che lo disinstalli.

E soprattutto: una volta creato il child theme, il plugin non serve più. Ha finito il suo lavoro. Tenerlo attivo aggiunge codice a ogni caricamento della bacheca senza dare niente in cambio — e i plugin che restano installati «per sicurezza» sono la prima voce da cui si parte quando si va a ripulire un sito.

Se il tema padre è un tema a blocchi

Qui cambia parecchio, e le guide scritte prima del 2022 non lo dicono perché all’epoca non esisteva il problema. Un tema a blocchi si riconosce da due cartelle, templates/ e parts/, e da un file theme.json che centralizza colori, caratteri e spaziature. Twenty Twenty-Four e Twenty Twenty-Five sono entrambi temi a blocchi.

Il child theme funziona esattamente allo stesso modo — stessa cartella, stesso campo Template, stessa precedenza — ma tre cose sono diverse.

• Lo style.css spesso non serve. La documentazione lo dice: caricarlo «è un passaggio opzionale e spesso non necessario per i temi a blocchi», perché il loro aspetto passa da theme.json. Il file deve comunque esistere, con la sua intestazione: è quello che rende il tema un tema.
• Il theme.json del figlio si fonde con quello del padre. Non lo sostituisce. Nel codice sorgente di WordPress la riga che lo fa ha il commento esplicito: «Merge the child theme.json into the parent theme.json. The child theme takes precedence». Significa che nel tuo theme.json devi scrivere solo quello che cambi — se ci copi dentro quello del padre e ne modifichi tre valori, hai appena congelato tutto il resto alla versione di oggi.
• C’è un livello sopra il tuo. Le modifiche fatte dagli Stili nell’editor stanno nel database e vincono sul theme.json del child theme. Se cambi un colore nel file e sul sito non succede niente, il primo posto da guardare non è il file: è se qualcuno ha già toccato quel colore dall’editor.

Per creare un child theme di un tema a blocchi esiste uno strumento ufficiale, ed è la strada che consiglio: Create Block Theme, mantenuto da WordPress.org. Ha una voce dedicata, Create Child Theme, che genera il figlio del tema attivo conservando le modifiche già fatte dall’editor — cioè risolve anche il terzo punto dell’elenco qui sopra, portando fuori dal database quello che ci era finito dentro. È anche l’unico dei plugin di questa guida che fa qualcosa che a mano è scomodo.

Una precisazione che evita un equivoco: theme.json non è una cosa dei soli temi a blocchi. Un tema classico può adottarlo e ottenere gli stili globali — l’ho spiegato nella guida sulla preparazione di un tema alla consegna — e in quel caso valgono le stesse regole di fusione descritte qui.

Cosa si sovrascrive, e con quale regola

«Il figlio vince sul padre» è vero, ma vince in due modi diversi a seconda di cosa stai sovrascrivendo. È la distinzione che separa un child theme che si mantiene da uno che si rompe al primo aggiornamento del padre.

I template: il file del figlio sostituisce quello del padre, per intero

Copi header.php dal padre nella cartella del figlio, lo modifichi, e da quel momento WordPress usa il tuo. Non una fusione: una sostituzione. Vale per i template PHP dei temi classici, per i file .html di templates/ e parts/ nei temi a blocchi, e per i pattern — questi ultimi con una condizione in più, cioè che abbiano anche lo stesso Slug registrato.

Il meccanismo è la gerarchia dei template: WordPress cerca una lista ordinata di nomi di file e prende il primo che trova, guardando prima nella cartella del figlio e poi in quella del padre. È lo stesso ordine che segue get_template_part(), ed è ciò che rende un tema estendibile. Se la gerarchia non ti è familiare, l’ho spiegata in dettaglio nella guida su header, footer, sidebar e gerarchia dei template, e i file specifici — single.php, page.php, archive.php, 404.php — nella parte dedicata ai template personalizzati.

Il rovescio della sostituzione è il debito che ti stai prendendo: ogni template che copi è un file che dovrai mantenere tu. Se il padre corregge un bug o migliora il markup dentro single.php, la tua copia non riceve niente. Per questo il criterio è copiare il meno possibile, e mai «per sicurezza». Vale anche per la parte SEO: i controlli on-page dipendono da cosa c’è nei template, e una copia vecchia se li porta dietro — la lista di cosa verificare è nella checklist SEO on-page per WordPress.

Se ti servono file tuoi che nel padre non esistono, le funzioni da usare per riferirli sono get_theme_file_uri() per gli URL e get_theme_file_path() per i percorsi: cercano prima nel figlio e poi nel padre, quindi funzionano in entrambi i contesti.

// Includere un file PHP che sta nel child theme
require_once get_theme_file_path( 'inc/funzioni-extra.php' );

// Riferire un'immagine del child theme in un template
$logo = get_theme_file_uri( 'assets/img/logo.svg' );

functions.php: non sostituisce, si somma — e gira per primo

È l’eccezione, ed è la fonte di metà dei problemi. Il functions.php del figlio non sostituisce quello del padre: vengono caricati tutti e due. E l’ordine è controintuitivo — prima il figlio, poi il padre. Non è un dettaglio di implementazione nascosto: nel core la funzione che costruisce l’elenco dei temi da caricare mette la cartella del figlio davanti a quella del padre, e i due file vengono inclusi in quell’ordine.

Da questo discendono due conseguenze pratiche, opposte fra loro.

• Puoi rimpiazzare una funzione del padre, se il padre te lo permette. I temi scritti bene avvolgono le proprie funzioni in if ( ! function_exists( '…' ) ). Dato che il figlio gira prima, se definisci tu una funzione con quel nome il padre trova il posto occupato e salta la sua. Twenty Twenty-Five è scritto così, e per questo è estendibile in profondità.
• Non puoi rimuovere un hook del padre scrivendo remove_action() in cima al file. Quando il tuo functions.php viene eseguito, il padre non ha ancora agganciato niente: stai togliendo qualcosa che non c’è. È l’errore che manda in tilt più persone, perché il codice è giusto ed è solo nel posto sbagliato.

La rimozione va rimandata a dopo il caricamento del padre, agganciandola a sua volta a un hook:

// Sbagliato: qui il tema padre non ha ancora aggiunto nulla.
// remove_action( 'wp_footer', 'temapadre_credits' );

// Giusto: si aspetta che il padre abbia fatto il suo lavoro.
add_action( 'after_setup_theme', 'mio_tema_child_rimozioni', 20 );

function mio_tema_child_rimozioni() {
	remove_action( 'wp_footer', 'temapadre_credits' );
}

Due avvertenze su questo codice. remove_action() funziona solo se i tre valori — nome dell’hook, nome della funzione e priorità — coincidono esattamente con quelli usati dal padre nell’add_action(): se il padre ha agganciato con priorità 5, devi rimuovere con priorità 5. E se il padre a sua volta aggancia dentro un hook, after_setup_theme può non bastare: si sposta la rimozione più avanti, su init, o su wp_enqueue_scripts quando si tratta di stili e script.

Per lo stesso motivo, togliere un foglio di stile del padre richiede una priorità più alta di quella con cui il padre lo accoda:

// Il padre accoda con la priorità di default (10): qui serve un numero più alto.
add_action( 'wp_enqueue_scripts', 'mio_tema_child_dequeue', 20 );

function mio_tema_child_dequeue() {
	wp_dequeue_style( 'twentytwentyfive-style' );
}

L’ultimo argomento è l’handle, cioè il primo parametro passato a wp_enqueue_style() dal padre. Lo trovi con lo stesso grep di prima: nel caso di Twenty Twenty-Five è twentytwentyfive-style.

Un’ultima regola, breve e categorica, che sta anche nella documentazione ufficiale: non copiare codice dal functions.php del padre dentro quello del figlio. Due funzioni con lo stesso nome nello stesso processo PHP sono un errore fatale, e il sito smette di rispondere.

I cinque errori che rompono un child theme

Sono sempre gli stessi cinque, e quattro si riconoscono dal sintomo prima ancora di aprire un file.

1. Il campo Template non coincide con la cartella del padre. Sintomo: il tema compare in Aspetto → Temi ma non si attiva, con l’avviso che manca il tema padre. Cause tipiche: hai scritto il nome visualizzato («Twenty Twenty-Five») invece del nome della cartella (twentytwentyfive), oppure il padre è installato con un nome cartella diverso da quello che ti aspettavi — succede con i temi comprati e rinominati.
2. Il CSS del figlio non si vede. È il caso 2 della sezione sui fogli di stile: non l’hai accodato. Verifica veloce: guarda il sorgente della pagina e cerca il tuo style.css fra i <link>. Se non c’è, non è un problema di specificità CSS ed è inutile aggiungere !important: il file non sta proprio arrivando al browser.
3. Il sito perde tutti gli stili appena attivi il figlio. È il caso 3: il padre caricava il foglio del tema attivo, che adesso sei tu. Si risolve accodando quello del padre con get_parent_theme_file_uri().
4. Il CSS del padre viene caricato due volte. Sintomo opposto e più insidioso, perché il sito sembra a posto: succede quando accodi il foglio del padre in un tema che già lo carica da sé. Il risultato è una richiesta e un peso in più su ogni pagina, ed è una delle cause che si trovano quando si va a cercare perché un sito WordPress è lento. Si vede in due secondi dagli strumenti per sviluppatori del browser, nella scheda Rete.
5. Errore fatale dopo aver modificato functions.php. Quasi sempre è un nome di funzione duplicato, o codice copiato dal padre. Dalla versione 5.2 WordPress non lascia più il sito bianco: mostra «Il sito sta avendo difficoltà tecniche», manda un’email all’amministratore e apre la modalità recupero, che permette di entrare nella bacheca con il tema messo in pausa e sistemarlo. Se l’email non arriva — indirizzo sbagliato, invio del server non configurato — la via manuale è rinominare la cartella del child theme via FTP. Attenzione a cosa succede dopo, perché è controintuitivo: WordPress non torna al tema padre, torna al tema predefinito. Il controllo che fa a ogni caricamento della bacheca verifica che il tema attivo abbia i file richiesti e, se non li trova, passa al predefinito — oggi Twenty Twenty-Five. Il padre resta installato: lo riattivi da Aspetto → Temi, o rimetti a posto il child theme e riattivi quello.

Ce n’è un sesto che non rompe niente e crea comunque danni: modificare i file del tema dall’editor della bacheca. È il modo più rapido per mandare offline un sito senza avere una copia del file di prima, ed è anche il motivo per cui quell’editor andrebbe disattivato — è il controllo che consiglio nella checklist di sicurezza WordPress, e il child theme è ciò che lo rende superfluo: le modifiche stanno in file tuoi, e si caricano da FTP o da un deploy.

Portare dentro le modifiche che hai già fatto

Il caso più comune non è «sto per personalizzare un tema»: è «ho già personalizzato un tema e ho scoperto che non dovevo». Il recupero si fa in quattro passaggi, e conviene farlo prima del prossimo aggiornamento del padre, non dopo.

1. Trova cosa hai cambiato. Scarica una copia pulita del tema padre — dal repository se è gratuito, dal fornitore se è commerciale — e confrontala con quella installata. Da riga di comando è un diff -r fra le due cartelle; senza SSH, si confrontano i file che sospetti con un qualsiasi strumento di confronto testo. La regola pratica: guarda per prime le date di modifica dei file, i tuoi saltano fuori subito.
2. Crea il child theme con uno dei tre metodi qui sopra e attivalo su una copia del sito.
3. Sposta le modifiche, non i file interi. Copia nel figlio solo i template che hai davvero toccato, e nel functions.php solo le funzioni che hai aggiunto — non il file del padre.
4. Riporta il padre alla versione pulita sovrascrivendolo con la copia scaricata, e solo allora aggiornalo. È il passaggio che chiude il cerchio: da qui in avanti gli aggiornamenti del tema tornano a essere un’operazione di routine, con la sua procedura di verifica prima e dopo.

Se le personalizzazioni sono nel CSS aggiuntivo e non nei file, il passaggio è ancora più semplice: si copia quel CSS dentro lo style.css del child theme e si svuota il campo. Guadagni il versionamento e non perdi più il lavoro il giorno in cui cambi tema.

Quando il child theme non è più la risposta

C’è un punto oltre il quale il child theme smette di essere una soluzione e diventa un costo. La documentazione ufficiale lo dice con una formula che vale la pena tradurre: personalizzare in modo esteso attraverso un child theme «può diventare un grattacapo di gestione», e per quei progetti conviene forkare il tema originale e farne uno proprio.

I tre segnali che il punto è arrivato, in ordine di gravità:

• Hai copiato più della metà dei template del padre. Stai già mantenendo un tema intero, con in più il vincolo di un padre di cui subisci gli aggiornamenti senza riceverne i benefici.
• Ogni aggiornamento del padre rompe qualcosa. Significa che stai sovrascrivendo pezzi che il padre considera interni e cambia liberamente. Non è colpa dell’aggiornamento.
• Non sai più cosa fa cosa. Quando per capire da dove arriva uno stile devi aprire quattro file in due cartelle, il livello di indirezione è diventato più costoso del problema che risolveva.

A quel punto le strade sono tre, e nessuna è il child theme: scegliere un tema diverso, più vicino a quello che ti serve; adottare una base già impostata, che si copia e diventa tua — e su cui, proprio per questo, un child theme non ha senso; oppure scrivere un tema da zero, che costa di più all’inizio e smette di costare dopo. La domanda che aiuta a scegliere è sempre la stessa: chi manterrà questo tema fra due anni?

Qualunque strada prendi, il tema resta una delle voci da guardare periodicamente: se ogni aggiornamento richiede di rimettere le cose a posto a mano, il problema non è l’aggiornamento — è la struttura. È uno dei controlli annuali della checklist di manutenzione WordPress.

Domande frequenti

add_action( 'after_setup_theme', 'mio_tema_child_lingue' );

function mio_tema_child_lingue() {
	load_child_theme_textdomain(
		'mio-tema-child',
		get_stylesheet_directory() . '/languages'
	);
}

Se ti serve una mano

Riassunto in una riga: il child theme non è un file da copiare, è una domanda da farsi sul tema che hai davanti — come carica gli stili, quanto ne devi sovrascrivere, e se a quel punto non convenga altro.

Se il tema su cui devi lavorare è complesso, se le personalizzazioni sono già finite dentro i file del padre e vanno recuperate, o se hai il dubbio che il child theme sia diventato la strada sbagliata, me ne occupo io: puoi vedere come lavoro nella pagina sullo sviluppo di temi e plugin WordPress su misura, oppure scrivermi e guardiamo insieme il caso specifico.