Un tema child WordPress è un tema che eredita struttura, stile e funzionalità da un altro tema, chiamato parent theme, ma ti permette di aggiungere o sostituire personalizzazioni senza modificare direttamente i file originali.
Il vantaggio è semplice: puoi continuare ad aggiornare il tema principale senza perdere il codice che hai aggiunto nel child.
Questo però non significa che un tema child serva per qualsiasi modifica. Con i moderni temi WordPress, soprattutto quelli a blocchi, molte personalizzazioni possono essere gestite dal Site Editor, dagli stili globali o dalle impostazioni del tema senza creare un child theme.
La domanda corretta, quindi, non è soltanto come creare un tema child WordPress, ma prima ancora quando conviene farlo.
In questa guida vediamo entrambe le cose: come funziona realmente il rapporto parent-child, come creare un tema child manualmente, cosa cambia tra temi classici e block theme, come utilizzare functions.php e theme.json e quali errori evitare per non ritrovarti con un sito difficile da mantenere.
Cos’è un tema child WordPress e come funziona
WordPress definisce i child theme come estensioni di un tema parent. Il tema child eredita dal parent tutto ciò che non ridefinisce autonomamente: template, funzionalità, stili e altri componenti restano quindi disponibili senza doverli duplicare.
La documentazione ufficiale sui child theme chiarisce anche il punto che spesso genera confusione: un tema child non è una copia completa del parent.
Contiene soltanto i file necessari alle personalizzazioni che vuoi mantenere separate.
Se, per esempio, devi modificare un template specifico, puoi inserirne una versione nel child theme. Tutti gli altri file continueranno a essere ereditati dal parent.
Tema parent e child theme: cosa viene ereditato
Immagina il tema child WordPress come un livello aggiuntivo sopra il tema principale.
Il parent continua a fornire la base del sito. Il child interviene soltanto dove gli hai dato qualcosa di diverso da usare.
Questo approccio ha due conseguenze importanti.
La prima è che il tema parent deve rimanere installato, perché il child dipende da esso.
La seconda è che non devi copiare tutto il parent nella cartella del child. Farlo renderebbe più difficile capire quali file hai realmente personalizzato e aumenterebbe il lavoro necessario durante gli aggiornamenti.
Un child theme ben mantenuto contiene quindi solo ciò che serve.
Cosa può sovrascrivere il child senza modificare il parent
Il meccanismo cambia leggermente in base al tipo di risorsa.
Per template, template part e pattern, WordPress può usare il file presente nel child al posto di quello corrispondente nel parent. Nei temi a blocchi puoi inoltre definire impostazioni e stili specifici tramite theme.json.
functions.php segue invece una logica diversa: il file del child non sostituisce quello del parent. WordPress carica entrambi, prima quello del child e subito dopo quello del parent.
Questo dettaglio è fondamentale. Copiare indiscriminatamente funzioni dal parent dentro il child può produrre nomi duplicati e causare errori PHP.
Se vuoi approfondire questo meccanismo, nella guida al file functions.php di WordPress trovi il ruolo del file e i modi più sicuri per modificarlo.
Cosa succede quando aggiorni il tema parent
Il motivo storico per cui esistono i child theme è proprio questo.
Quando aggiorni un tema, i file distribuiti dal produttore possono essere sostituiti dalla nuova versione. Se hai modificato direttamente quei file, le tue modifiche rischiano di scomparire.
Il child theme tiene invece il codice personalizzato in una directory separata.
Aggiornando il parent:
il parent riceve i nuovi file → il child rimane separato → le personalizzazioni continuano a essere applicate.
Questo non significa che ogni aggiornamento sia automaticamente privo di conseguenze.
Se hai copiato nel child un template che il produttore modifica profondamente nel parent, WordPress continuerà a utilizzare la tua versione personalizzata. Il risultato può essere un override ormai incompatibile o semplicemente incapace di beneficiare delle modifiche introdotte nel template originale.
Per questo un child theme protegge le personalizzazioni dalla sovrascrittura, ma non elimina la necessità di manutenerle.
Quando serve davvero un tema child e quando puoi evitarlo
Creare sempre un tema child WordPress “per sicurezza” non è una regola tecnica: conviene farlo quando la personalizzazione deve vivere nei file del tema e restare separata dagli aggiornamenti del parent.
Conviene crearlo quando la personalizzazione deve vivere nel filesystem del tema e vuoi conservarla separata dagli aggiornamenti del parent.
Se invece il cambiamento può essere gestito correttamente dagli strumenti nativi senza modificare file del tema, aggiungere un child può essere soltanto complessità in più.
| Cosa devi modificare | Soluzione da valutare |
|---|---|
| Colori, tipografia o layout disponibili nel Site Editor | Site Editor / Styles |
| Piccole modifiche CSS gestibili con gli strumenti disponibili | CSS personalizzato |
| Un template o una template part del tema | Tema child |
| File PHP del tema | Tema child, se la modifica appartiene realmente al tema |
Impostazioni e stili theme.json da mantenere nei file | Tema child |
| Funzionalità che deve sopravvivere anche cambiando tema | Plugin |
| Personalizzazioni profonde che trasformano completamente il parent | Valutare un tema autonomo |
Il criterio più utile è quindi chiederti a quale livello appartiene la modifica.
Tema child vs Site Editor, Styles e modifiche CSS
Con un tema a blocchi puoi modificare molte parti del sito direttamente da Aspetto → Editor.
Colori, font, spaziature, template, header, footer e altre componenti possono essere personalizzate senza toccare manualmente i file PHP tipici dei temi classici.
In questi casi creare un tema child solo per cambiare un colore o una dimensione tipografica può essere eccessivo.
C’è però una distinzione da ricordare: le personalizzazioni effettuate tramite l’Editor possono essere archiviate nel database. Se vuoi trasformare quelle scelte in una personalizzazione versionabile, distribuibile o gestita attraverso file, il child theme torna ad avere senso.
Tema child vs plugin: dove deve vivere la funzionalità
functions.php può eseguire codice PHP e utilizzare gli hook di WordPress, ma questo non significa che ogni funzionalità debba essere inserita nel tema child.
La documentazione WordPress su functions.php propone un criterio molto utile: se una funzione deve continuare a esistere indipendentemente dal tema utilizzato, dovrebbe normalmente vivere in un plugin.
Un custom post type è un esempio classico.
Se registri un tipo di contenuto fondamentale per il sito dentro il child theme e in futuro cambi tema WordPress, quel codice smette di essere caricato insieme al tema.
La domanda da porti è quindi:
questa personalizzazione riguarda la presentazione e il comportamento del tema oppure è una funzionalità del sito?
Nel primo caso il child theme può essere il posto corretto. Nel secondo è spesso più pulito utilizzare un plugin.
Classic theme e block theme: perché il metodo cambia
I child theme funzionano sia con i temi classici sia con i block theme, ma non devi aspettarti la stessa struttura.
Un tema classico utilizza normalmente template PHP e può gestire gran parte dello stile attraverso fogli CSS e functions.php.
Un block theme utilizza invece template basati su blocchi e fa largo uso di theme.json, template HTML, template part e pattern.
Di conseguenza, una guida al child theme che considera solo style.css, header.php, footer.php e Customizer descrive ormai soltanto una parte del sistema.
Prima di creare il child theme: backup, staging e verifica del parent
Creare un tema child WordPress è relativamente semplice; il rischio vero nasce dalle modifiche che farai dopo e da come verranno mantenute quando il parent cambia.
Prima di intervenire sul tema conviene avere un backup recuperabile e, se il sito è già online, eseguire le modifiche in un ambiente di staging WordPress invece che direttamente in produzione.
Un errore di sintassi PHP, un template incompatibile o un caricamento errato degli asset può altrimenti rendere il front-end inutilizzabile.
Se non hai ancora una strategia di ripristino, puoi partire dalla guida ai plugin di backup WordPress.
Controlla se il tema fornisce già un child theme
Prima di creare da zero un tema child WordPress, verifica la documentazione del tema parent: potrebbe già fornire un child ufficiale o indicare una procedura specifica per stylesheet, template e override.
Diversi temi commerciali distribuiscono già un pacchetto child ufficiale. In quel caso partire da quello fornito dallo sviluppatore è generalmente più sensato che ricostruire autonomamente la stessa struttura.
Controlla anche se la documentazione del parent contiene istruzioni specifiche per child theme, caricamento CSS o override.
Queste informazioni prevalgono su qualsiasi snippet generico trovato online.
Verifica come il parent carica CSS e asset
Questo è uno dei punti più importanti della guida.
Non esiste una singola funzione da copiare in functions.php che sia corretta per tutti i temi.
La documentazione ufficiale spiega che alcuni parent:
- caricano già sia il proprio stylesheet sia quello del child;
- caricano solo il proprio stylesheet;
- utilizzano
get_stylesheet_uri(), che con un child attivo punta al foglio di stile del child; - nei block theme possono gestire gran parte dello styling attraverso
theme.jsonsenza dipendere dastyle.css.
Prima di aggiungere un enqueue devi quindi guardare come lavora il tema parent.
Questo evita stylesheet duplicati, ordine di caricamento sbagliato e regole CSS apparentemente ignorate.
Perché non conviene lavorare direttamente sul sito live
Il child theme nasce per rendere le personalizzazioni più manutenibili, non per rendere innocuo il codice.
Un errore resta un errore anche se si trova nel child.
Testare in staging permette di verificare almeno:
- attivazione del child;
- front-end e responsive;
- template personalizzati;
- eventuali warning o errori PHP;
- editor e back-end;
- cache;
- comportamento dopo un aggiornamento del parent.
È un passaggio particolarmente importante se il sito genera vendite, lead o traffico significativo.
Come creare un tema child WordPress manualmente
Per creare manualmente un tema child WordPress minimale servono una cartella dedicata e un file style.css con un header corretto.
functions.php non è obbligatorio.
La stessa documentazione WordPress definisce style.css come l’unico file assolutamente necessario perché il child theme esista.
1. Crea la cartella in wp-content/themes
Accedi ai file del sito tramite il file manager dell’hosting, SSH oppure un protocollo sicuro per il trasferimento dei file.
Se utilizzi un client remoto e vuoi capire meglio differenze e limiti dei vari sistemi, trovi un approfondimento nella guida a FTP, FTPS e SFTP.
Apri:
wp-content/themes/
e crea una nuova directory.
Una convenzione semplice è:
nome-tema-parent-child
Il nome della directory del child non deve necessariamente seguire questa forma, ma usare un nome riconoscibile rende più semplice capire la relazione fra i due temi.
2. Crea style.css e collega correttamente il parent con Template
Dentro la nuova cartella crea:
style.css
Un header minimale può essere questo:
/* Theme Name: Nome Tema Child Template: nome-cartella-parent Version: 1.0.0 Text Domain: nome-tema-child */
La riga decisiva è:
Template: nome-cartella-parent
Non devi inserire il nome commerciale del tema, ma il nome esatto della directory del parent presente in wp-content/themes.
Se la cartella del parent fosse:
wp-content/themes/mio-tema/
dovresti quindi usare:
Template: mio-tema
La corrispondenza deve essere esatta. Se sbagli questo valore, WordPress non riesce a collegare correttamente child e parent.
Non servono invece obbligatoriamente Theme URI, Author URI o altri campi soltanto per rendere operativo il child.
3. Quando serve davvero functions.php
Dopo aver creato correttamente style.css, puoi già installare e attivare un tema child WordPress minimale: functions.php va aggiunto solo quando serve davvero eseguire codice legato al tema.
Aggiungi functions.php soltanto quando hai realmente bisogno di:
- eseguire codice PHP legato al tema;
- registrare action o filter;
- caricare un asset che il parent non gestisce correttamente;
- configurare funzionalità specifiche del tema.
Il file deve iniziare così:
<?php
Non è necessario aggiungere il tag PHP di chiusura ?> alla fine del file.
Evita soprattutto di copiare l’intero functions.php del tema parent. I due file vengono caricati entrambi e funzioni duplicate possono provocare un fatal error.
4. Come gestire gli stylesheet senza copiare uno snippet alla cieca
Prima verifica il comportamento del parent.
Se il parent carica già correttamente il proprio CSS e devi soltanto assicurarti che venga caricato style.css del child, un pattern possibile è:
<?php
add_action( 'wp_enqueue_scripts', 'cm_child_enqueue_styles' );
function cm_child_enqueue_styles() {
wp_enqueue_style(
'cm-child-style',
get_stylesheet_uri(),
array(),
wp_get_theme()->get( 'Version' )
);
}
Questo snippet carica lo stylesheet del tema attivo, quindi con il child attivo get_stylesheet_uri() restituisce il relativo style.css.
Non copiarlo comunque in automatico.
Se il parent carica già anche il child stylesheet, aggiungerlo di nuovo significa duplicarlo. Se invece il parent usa una struttura CSS differente, potrebbe servire un dependency handle specifico o una strategia diversa.
In alcuni casi puoi dover caricare anche il foglio del parent:
<?php
add_action( 'wp_enqueue_scripts', 'cm_child_enqueue_styles' );
function cm_child_enqueue_styles() {
wp_enqueue_style(
'cm-parent-style',
get_parent_theme_file_uri( 'style.css' )
);
wp_enqueue_style(
'cm-child-style',
get_stylesheet_uri(),
array( 'cm-parent-style' ),
wp_get_theme()->get( 'Version' )
);
}
Questo secondo esempio non è una regola universale: usalo soltanto se hai verificato che corrisponde alla struttura del parent.
La guida ufficiale ai child theme documenta proprio scenari differenti perché il caricamento degli asset varia da tema a tema.
5. Attiva il tema child e verifica che ereditarietà e stile funzionino
Quando i file minimi sono pronti puoi installare il tema child nella directory wp-content/themes oppure comprimerlo in ZIP e caricarlo da Aspetto → Temi → Aggiungi nuovo.
Il parent deve essere installato.
Dopo l’attivazione controlla che il sito mantenga l’aspetto atteso prima di iniziare a personalizzare file o template.
Se già in questa fase il layout cambia in modo inatteso, non iniziare a compensare aggiungendo altro codice: individua prima cosa viene caricato diversamente dal parent.
Come personalizzare il tema child senza renderlo difficile da mantenere
Un tema child WordPress funziona bene quando contiene modifiche mirate e leggibili.
Se nel tempo diventa una copia quasi completa del tema originale, perdi gran parte del vantaggio del modello parent-child.
La documentazione WordPress avverte che personalizzazioni molto estese possono diventare difficili da gestire; in progetti che divergono profondamente dal parent può avere più senso realizzare un tema autonomo.
CSS, JavaScript e altri asset
Puoi inserire CSS, JavaScript, immagini e altre risorse nella directory del child.
Per riferirti ai file del tema attivo WordPress mette a disposizione funzioni specifiche per path e URL.
Evita quindi percorsi hardcoded come:
/wp-content/themes/nome-tema-child/assets/js/script.js
perché diventano fragili se cambia la configurazione del sito.
Per un file che può essere sovrascritto dal child puoi utilizzare funzioni come get_theme_file_uri(); se invece vuoi fare riferimento esplicitamente a una risorsa del parent puoi usare le equivalenti funzioni get_parent_theme_file_*().
Override di template, template part e pattern
Quando vuoi modificare un template del parent, copia nel child solo il file che devi realmente personalizzare, mantenendo la struttura prevista dal tema.
WordPress utilizzerà la versione del child al posto di quella del parent quando il sistema di override lo prevede.
Lo stesso principio vale per template, parti e pattern nei block theme; per i pattern l’identificatore deve restare coerente con quello che vuoi sostituire.
Questo sistema è potente, ma introduce una responsabilità: dal momento in cui crei l’override, quel file non segue più automaticamente l’evoluzione della versione equivalente del parent.
Hook e functions.php: cosa aggiungere e cosa non copiare dal parent
Quando il parent offre action e filter ben progettati, modificarne il comportamento tramite hook è spesso più manutenibile che duplicare un template intero.
Per esempio, potresti rimuovere una funzione collegata a un’action e agganciare una tua implementazione, oppure usare un filtro per modificare un dato prima che venga visualizzato.
È uno dei motivi per cui capire come funzionano action e filter hook in WordPress può ridurre drasticamente la quantità di codice che devi mantenere nel child.
Evita invece il pattern:
copio functions.php del parent → modifico ciò che non mi piace → salvo nel child
Non funziona come l’override dei template.
Il functions.php del child viene eseguito insieme a quello del parent.
Perché gli override vanno ricontrollati dopo gli aggiornamenti del parent
Il parent può cambiare.
Una nuova versione potrebbe:
- modificare la struttura HTML di un template;
- aggiungere hook;
- rimuovere funzioni deprecate;
- cambiare classi CSS;
- introdurre nuovi componenti;
- correggere bug che il tuo override continua invece a mantenere.
Dopo un aggiornamento importante del parent, confronta quindi i file che hai sovrascritto nel child con le rispettive versioni aggiornate.
Aggiornare il parent senza perdere il child non significa che il child non debba mai essere aggiornato.
Tema child e block theme: come cambia il lavoro con theme.json
Con i block theme il tema child WordPress rimane valido, ma una parte consistente della personalizzazione passa attraverso theme.json, template HTML, template part e pattern.
Il file theme.json consente di definire impostazioni globali e stili relativi, fra le altre cose, a colori, tipografia, spacing e configurazione dei blocchi.
La documentazione dedicata a Global Settings and Styles è il riferimento da consultare quando lavori seriamente con questo livello.
La gerarchia WordPress → parent → child → personalizzazioni utente
Per capire perché talvolta una regola nel child sembra non avere effetto devi conoscere l’ordine di precedenza.
La gerarchia documentata da WordPress è:
WordPress ↓ theme.json del parent ↓ theme.json del child ↓ personalizzazioni dell'utente
Il livello più in basso nello schema ha priorità più alta.
Questo significa che il theme.json del child può sovrascrivere configurazioni del parent, ma una personalizzazione salvata dall’utente attraverso l’Editor può a sua volta prevalere.
È un dettaglio essenziale durante il troubleshooting: non dare per scontato che il problema sia nel file del child solo perché una proprietà non appare sul front-end.
Template, parti e pattern nei temi a blocchi
Un block theme non utilizza la stessa architettura di un classico tema PHP.
Nel child puoi aggiungere o sostituire componenti come:
/templates/ /parts/ /patterns/ theme.json
Non devi creare automaticamente tutte queste directory.
Aggiungi soltanto ciò che serve alla personalizzazione.
Per esempio, se vuoi modificare esclusivamente il template del singolo articolo, non c’è motivo di duplicare tutti gli altri template del parent.
Quando il Site Editor basta e quando conviene portare le modifiche nei file
Se gestisci un singolo sito e devi effettuare una personalizzazione puramente visuale, lavorare dal Site Editor può essere più rapido.
Un child theme diventa più interessante quando vuoi che la personalizzazione sia:
versionabile, distribuibile, replicabile o gestita insieme al codice del progetto.
Esiste anche il plugin ufficiale Create Block Theme, sviluppato nell’ecosistema WordPress, che consente fra le altre operazioni di creare un child theme del tema attivo e salvare nel tema modifiche realizzate attraverso l’Editor.
È uno strumento da sviluppo: prima di usarlo su un sito importante conviene comunque lavorare in staging e comprendere quali file verranno modificati.
Come creare un child theme con WP-CLI o un plugin
La procedura manuale è utile perché ti costringe a capire la struttura del child.
Quando lavori su più installazioni o vuoi automatizzare il processo esistono però metodi più rapidi.
WP-CLI con wp scaffold child-theme
Se devi creare rapidamente un tema child WordPress da terminale, WP-CLI dispone di un comando dedicato:
wp scaffold child-theme mio-tema-child --parent_theme=mio-tema
Puoi anche chiedere l’attivazione immediata:
wp scaffold child-theme mio-tema-child --parent_theme=mio-tema --activate
Il comando genera la struttura iniziale basandosi sul parent indicato. La sintassi completa e le opzioni disponibili sono riportate nella documentazione di wp scaffold child-theme.
WP-CLI genera anche functions.php, ma questo non cambia la regola vista prima: WordPress non richiede functions.php perché un child theme esista. È semplicemente parte dello scaffold prodotto dal comando.
Create Block Theme per i block theme
Se lavori con un block theme, Create Block Theme è più coerente con il flusso moderno rispetto ai vecchi generatori focalizzati soltanto su CSS e Customizer.
Può creare un child del tema attivo, esportare un tema e salvare nel filesystem modifiche costruite tramite l’Editor.
Lo valuterei soprattutto quando stai trasformando personalizzazioni visuali realizzate nel Site Editor in un artefatto di tema che vuoi conservare o distribuire.
Child Theme Configurator: cosa sapere prima di usarlo
Child Theme Configurator è uno dei generatori storicamente più conosciuti.
Il plugin analizza il parent, crea il child e include strumenti per gestire stylesheet e template. Tuttavia non lo considererei oggi la scelta automatica per qualsiasi progetto.
La sua scheda nella directory ufficiale mostra al momento un avviso secondo cui il plugin non è stato testato con le ultime tre major release di WordPress e potrebbe avere problemi di compatibilità.
Questo non dimostra automaticamente che il plugin non funzioni. Significa però che, prima di utilizzarlo su un sito in produzione, devi verificarne lo stato corrente e testarlo nel tuo ambiente.
Lo stesso criterio vale per i generatori più datati: il fatto che un plugin riesca a creare una cartella, style.css e functions.php non significa che conosca necessariamente tutte le esigenze del tuo parent o dei moderni block theme.
Errori comuni nei child theme e come risolverli
Molti problemi attribuiti genericamente a un tema child WordPress dipendono in realtà da uno dei tre livelli coinvolti: relazione con il parent, caricamento degli asset oppure override troppo estesi.
WordPress non riconosce il parent theme
Il primo valore da controllare è Template in style.css.
Deve contenere esattamente il nome della cartella del parent.
Se hai:
wp-content/themes/mio-tema/
usa:
Template: mio-tema
e non:
Template: Mio Tema
né il nome mostrato graficamente nella schermata Temi.
Controlla inoltre che il parent sia realmente installato.
Il CSS del parent o del child non viene caricato
Non aggiungere subito un nuovo wp_enqueue_style().
Prima verifica cosa viene già caricato nel sorgente della pagina e nel functions.php del parent.
Il problema potrebbe essere:
- child stylesheet non caricato;
- parent stylesheet mancante;
- foglio caricato due volte;
- ordine delle dipendenze errato;
- cache;
- specificità CSS;
- personalizzazione salvata nel database che prevale;
- block theme che utilizza prevalentemente
theme.json.
La soluzione dipende dalla causa.
Fatal error dopo una modifica a functions.php
Se il sito smette di funzionare subito dopo un intervento nel child, controlla per prima cosa il codice aggiunto.
Gli errori più comuni sono sintassi PHP non valida e nomi di funzione già esistenti.
Se hai copiato una funzione dal parent senza verificare come viene dichiarata, potresti aver creato una duplicazione.
In caso di sito non accessibile puoi intervenire tramite file manager, SSH o SFTP per correggere il file oppure rinominare temporaneamente la directory del child e ripristinare un tema funzionante.
Un template copiato nel child non segue più le modifiche del parent
È il comportamento previsto.
Quando il child fornisce il proprio override, WordPress utilizza quella versione invece del file corrispondente del parent.
Se il parent aggiorna quel template, la tua copia non viene automaticamente sincronizzata.
Per questo non dovresti copiare template “nel caso possano servire”: crea un override solo quando devi realmente modificarlo.
Il parent deve restare installato e non esistono grandchild theme standard
Un child theme non diventa autonomo quando lo attivi.
Il parent resta la sua base e deve essere disponibile.
WordPress inoltre non prevede un terzo livello standard di temi installabili: la gerarchia del tema è parent → child, non parent → child → grandchild.
Nei block theme esiste un ulteriore livello di personalizzazioni dell’utente salvate nel database, ma non equivale a un vero grandchild theme installabile.
Se il tuo child è diventato così complesso da richiedere a sua volta un child, probabilmente è il momento di rivalutare l’architettura e considerare un tema autonomo.
Conclusione
Un tema child WordPress resta uno degli strumenti più utili quando devi modificare realmente un tema senza legare quelle modifiche ai file aggiornabili del parent.
Non dovrebbe però essere un passaggio automatico per qualsiasi sito.
Se devi cambiare impostazioni che il tema o il Site Editor gestiscono già bene, usa prima quegli strumenti. Se stai introducendo funzionalità che devono restare disponibili anche dopo un cambio di tema, spostale in un plugin. Se invece devi personalizzare template, codice e configurazioni del tema mantenendoli separati dagli aggiornamenti del parent, il child theme è il livello giusto.
Quando crei un tema child WordPress, mantienilo minimale: una relazione parent-child corretta, pochi override realmente necessari e codice leggibile sono più facili da aggiornare di una copia completa del tema originale.
E soprattutto tratta il child come codice da mantenere. Ti protegge dalla sovrascrittura delle personalizzazioni, non dall’evoluzione del parent né dagli errori introdotti nel tuo codice.