Tema a blocchi vs tema classico in WordPress: il confronto onesto

Apri la cartella del tuo tema. Se contiene una cartella templates con dentro un index.html, più un theme.json nella radice, hai un tema a blocchi. Se contiene index.php insieme a file come header.php e footer.php, e la barra laterale della bacheca mostra Aspetto e poi Personalizza, hai un tema classico.

Quell’unica differenza strutturale decide chi può cambiare cosa sul tuo sito, dove finiscono quelle modifiche e quale metà dell’ecosistema di plugin di WordPress si comporta normalmente.

Il riconoscimento in 30 secondi

Indizio	Tema classico	Tema a blocchi
File di template principale	index.php	templates/index.html
Intestazione e piè di pagina	header.php, footer.php	parts/header.html, parts/footer.html
Configurazione globale	functions.php	theme.json (più un functions.php facoltativo)
Voce di menu in bacheca	Aspetto > Personalizza	Aspetto > Editor
Dove vengono salvate le modifiche	File su disco	Database, come post wp_template
Schermata Widget	Presente	Assente

WordPress decide cercando templates/index.html. Un tema che distribuisce un theme.json ma tiene i suoi template PHP è ancora trattato come classico — quello stato intermedio è comune e ha un nome, ne parliamo più sotto.

Se hai accesso alla shell, un comando chiude la questione:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI è la verifica più rapida su un sito che non hai costruito tu, soprattutto quando un page builder ha nascosto le solite voci di menu.

Cosa cambia per chi modifica il sito

In un tema classico, intestazione, piè di pagina, barra laterale, colori e logo stanno dietro al Personalizza, e hai solo i controlli che l’autore del tema ha deciso di costruire. Se il tema non ha registrato un controllo per il testo del copyright nel piè di pagina, quel controllo non esiste. O modifichi un file PHP o te lo tieni così.

In un tema a blocchi, l’Editor del sito espone l’intera pagina. Intestazione, piè di pagina, il loop, la pagina 404, il layout dei risultati di ricerca: è tutto fatto di blocchi, tutto modificabile da qualcuno che non ha mai visto una riga di PHP. Questa è la vera funzione di punta, ed è davvero grossa.

Il prezzo è che tutto è modificabile da qualcuno che non ha mai visto una riga di PHP. Un cliente può cancellare il titolo del sito dall’intestazione alle due di notte e su disco non c’è nessuno storico versioni da cui recuperare — solo le revisioni interne dell’Editor del sito. Blindare le cose è possibile con il blocco dei blocchi e limitando chi arriva all’editor, ma è lavoro opzionale che devi ricordarti di fare.

Due perdite minori che nella pratica si fanno sentire: i temi a blocchi non hanno la schermata Widget (le aree widget sono sostituite da parti di template e blocchi), e i menu classici sono sostituiti dal blocco Navigazione, che memorizza le sue voci come un tipo di contenuto separato invece che nella familiare schermata Menu.

Cosa cambia per lo sviluppatore

I temi classici usano la gerarchia di template PHP. WordPress risolve una richiesta lungo una catena nota — single-{post-type}.php, poi single.php, poi singular.php, poi index.php — e il tuo file viene eseguito, chiama get_header(), esegue il Loop e stampa markup che controlli carattere per carattere.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

I temi a blocchi usano gli stessi nomi della gerarchia con estensione .html, ma il file contiene markup a blocchi — HTML con i delimitatori dei blocchi dentro i commenti — e non ci sono template tag:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Tre conseguenze che gli sviluppatori incontrano subito:

get_header() e get_footer() non vengono mai eseguite. Tutto ciò che è agganciato a quelle action, in un plugin o in un vecchio tema child, non fa niente in silenzio. wp_head e wp_footer scattano ancora, quindi la maggior parte degli enqueue sopravvive, ma gli hook specifici dell’intestazione no.

Il database batte i tuoi file. Nell’istante in cui qualcuno salva un template nell’Editor del sito, WordPress memorizza quella versione come post wp_template e la serve al posto del tuo file. Puoi modificare il file HTML tutto il pomeriggio e vedere zero cambiamenti sul front end. Azzerare la personalizzazione di quel template restituisce il controllo alla versione su file. È la segnalazione “il mio tema a blocchi è rotto” più frequente in assoluto, e non è un bug.

Lo stile si sposta dentro theme.json. Colori, scala delle spaziature, tipografia e default per singolo blocco sono dichiarati come dati invece che come CSS, e il CSS lo genera WordPress. È più pulito e molto più coerente — finché non ti serve qualcosa che lo schema non esprime, e a quel punto stai comunque scrivendo CSS e combattendo con la specificità contro le regole generate.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Controlla il valore di version rispetto alla release di WordPress che stai usando: lo schema è stato rivisto più di una volta e copiare un numero di versione da un vecchio tutorial produce impostazioni che vengono ignorate in silenzio.

Nota che functions.php non sparisce. I temi a blocchi lo usano ancora per gli enqueue, per registrare voci con add_image_size, per i custom post type e per qualsiasi altra cosa in PHP. Semplicemente ci fai molto meno lavoro di templating.

Cosa guadagni davvero e cosa perdi davvero

Passare ai blocchi ti fa guadagnare: controllo editoriale sull’intera pagina, coerenza di design imposta da theme.json, meno file da mantenere e stili che coincidono tra editor e front end molto più spesso di quanto i temi classici siano mai riusciti a fare.

Passare ai blocchi ti fa perdere: il controllo diretto sul markup in uscita, la personalizzazione lineare basata sugli hook, la compatibilità con tutto ciò che dà per scontati i template PHP, e la tranquillità di sapere che l’aspetto del sito vive nel controllo di versione.

Quest’ultimo punto merita enfasi. In un tema classico, git log ti dice cosa è cambiato. In un tema a blocchi, una fetta significativa dell’aspetto del sito vive nel database, dove la tua pipeline di deploy non guarda.

Quando un tema classico è ancora la risposta giusta

• Il sito gira su un page builder. Elementor, Divi, Beaver Builder e strumenti simili si prendono loro il templating. Mettere un tema a blocchi sotto aggiunge un secondo sistema di templating che non fa niente.
• Il markup deve essere esatto. Librerie di componenti su misura, markup rigoroso per l’accessibilità, requisiti di schema fuori dall’ordinario — l’output a blocchi è limitato da ciò che i blocchi emettono, e combatterlo costa più che scrivere PHP.
• Templating pesante lato plugin. Plugin di membership, LMS, directory e vecchie estensioni per l’e-commerce distribuiscono spesso override di template PHP. Molti hanno ormai un equivalente a blocchi; molti no.
• Il sito è finito e funziona. Un tema con cinque anni di personalizzazioni accumulate non ha un percorso di aggiornamento verso i blocchi, ha solo una ricostruzione. “È l’approccio più recente” non è una ragione di business.
• Nessuno tranne te ci metterà mano. Il beneficio principale dell’Editor del sito è consegnare il controllo a chi non sviluppa. Se persone così non ce ne sono, stai pagando i costi di un vantaggio che nessuno usa.

La via di mezzo ibrida

Un tema classico può aggiungere un theme.json e ottenere il sistema degli stili globali, i preset di colore e spaziatura e uno stile coerente nell’editor — continuando a usare i suoi template PHP e il Personalizza. WordPress non lo chiama tema a blocchi, e l’Editor del sito resta non disponibile, ma ottieni gran parte del beneficio del design system con una frazione del lavoro.

Per un sito esistente che tutto sommato funziona, di solito è la prima mossa giusta. Aggiungi theme.json, definisci palette e spaziature, cancella il CSS che sostituisce, e poi valuta se vuoi ancora il resto.