Modifica completa del sito WordPress: guida tecnica 2026

Modifica completa del sito WordPress nel 2026: meccanica, non marketing

La modifica completa del sito WordPress ha raggiunto un punto di svolta nel 2026. Con WordPress 6.9, il 68% delle nuove installazioni adotta per impostazione predefinita un'architettura a blocchi. Per i freelance e le agenzie che ancora consegnano theme PHP classici ai clienti, la domanda non è più se adottare il Full Site Editing, ma come farlo senza compromettere i flussi di lavoro in produzione.

Questo folio copre la meccanica, non il marketing. Testato su siti client reali con WordPress 6.8 e 6.9.

Cosa sostituisce il Full Site Editing, e cosa conserva

Il Full Site Editing non ha eliminato i concetti fondamentali di WordPress. Ha spostato il confine tra ciò che è "configurabile" e ciò che richiede codice. Dove prima si scriveva un header.php, ora si gestisce una parte del template dall'editor visivo. Dove si registrava un walker per il menu, ora si posiziona il blocco Navigation.

Quello che FSE non ha cambiato: la gerarchia dei template, le query WP_Query, il loop di visualizzazione. Li ha semplicemente resi accessibili all'editor senza toccare un file. Per un praticante PHP, questo significa che le competenze acquisite restano valide. Cambia il punto di ingresso per le personalizzazioni, non la logica sottostante.

È utile pensare al Full Site Editing come a un livello di astrazione aggiuntivo sopra il sistema di template già esistente. Chi conosce la gerarchia dei template PHP troverà familiare la struttura dell'editor del sito: singolo post, archivio, pagina, homepage. La nomenclatura è la stessa.

L'anatomia minima di un block theme: tre file

Un block theme funzionante richiede soltanto:

1. style.css con l'header del tema (nome, versione, URI del tema)

2. templates/index.html con i blocchi che compongono la pagina

3. theme.json per i token di stile globali

Con WordPress 6.7, theme.json è arrivato alla versione 3, che introduce il supporto alle variabili CSS personalizzate a livello globale. Prima non era possibile definire un colore di sfondo condizionale senza PHP o CSS aggiuntivo. Ora basta un token nel documento JSON.

Questa struttura minimale funziona in produzione. Non è un esperimento di laboratorio: è la base di decine di theme presenti nel repository ufficiale di WordPress.org e utilizzati su milioni di siti.

La semplicità della struttura ha un risvolto pratico immediato: il version control diventa più pulito. Con un theme PHP classico, le personalizzazioni grafiche sono sparse tra PHP, CSS e JavaScript. Con un block theme, la configurazione visiva è concentrata in theme.json e nei file template HTML, che sono testo puro e si gestiscono bene con Git.

L'editor del sito in WordPress 6.9: cinque aree, una gerarchia

L'interfaccia dell'editor del sito è organizzata in cinque sezioni principali:

• Template: le strutture delle pagine (singolo post, archivio, homepage, pagina 404)

• Parti del template: header, footer, barre laterali riutilizzabili tra template

• Pattern: composizioni di blocchi riutilizzabili, potenzialmente sincronizzate

• Stili: controllo visivo globale del tema, con varianti di stile

• Navigazione: gestione e composizione dei menu

La gerarchia tra questi livelli è precisa: un blocco nel template può sovrascrivere lo stile globale definito in theme.json. Una parte del template può essere bloccata per impedire modifiche accidentali. Questa granularità è ciò che rende FSE adatto alla consegna ai clienti, quando viene usata con consapevolezza.

WordPress 6.9 ha introdotto anche le varianti di stile interattive: è possibile definire più varianti cromatiche del tema (chiara, scura, ad alto contrasto) e permettere ai clienti di sceglierla dall'editor senza toccare CSS.

Le parti del template: l'astrazione giusta, usata male

La parte del template (template part) è l'elemento più frainteso del Full Site Editing. In teoria è semplice: un frammento riutilizzabile che appare in più template. In pratica, la prima tentazione è annidarle eccessivamente.

Un errore comune osservato su progetti reali: creare parti del template per ogni sezione della pagina. Il risultato è una struttura DOM con otto o dieci livelli di annidamento, difficile da ispezionare con gli strumenti di sviluppo e lenta da renderizzare su dispositivi con risorse limitate.

La regola pratica, ricavata dall'uso su una dozzina di siti client: usa le parti del template solo per ciò che è effettivamente condiviso tra più template (header, footer, barre globali). Per le sezioni specifiche di un singolo template, usa i pattern bloccati. Questa distinzione mantiene la struttura leggibile e le prestazioni accettabili.

Un altro aspetto spesso trascurato: le parti del template possono avere un'area (area) dichiarata in theme.json. Le aree standard sono header, footer, e general. L'area influisce su come WordPress gestisce la parte nel contesto dell'editor e nella gerarchia del rendering.

Il blocco Query Loop: il tuo loop PHP, senza PHP

Il blocco Query Loop è la risposta a WP_Query all'interno dell'editor a blocchi. Permette di costruire archivi di post, griglie di prodotti, elenchi di eventi o portfolio direttamente nell'interfaccia visiva, senza scrivere una riga di PHP.

I parametri di query configurabili dall'editor includono: tipo di post, categoria, tag, autore, numero di risultati per pagina, e ordinamento. È possibile creare varianti per layout diversi: una griglia a tre colonne per la homepage, una lista lineare per l'archivio categoria, una vista a schede per la sezione portfolio.

Attenzione: il blocco Query Loop non supporta ancora le query complesse con meta_query multipli o le tax_query annidate. Per questi casi avanzati, il PHP rimane necessario tramite un blocco personalizzato o un plugin dedicato. Non è un limite da nascondere: è un confine chiaro da comunicare ai clienti durante la fase di analisi.

theme.json: cosa controlla, cosa delega

theme.json è il documento di configurazione centrale di un block theme. Nella versione 3 (WordPress 6.7+), gestisce in modo nativo:

• Palette colori: definita una volta, disponibile come token nell'intera interfaccia di editing

• Scale tipografiche: font, dimensioni, peso, interlinea, spaziatura tra le lettere

• Spaziatura globale: margin e padding come valori token predefiniti

• Ombre e bordi: per i blocchi che li supportano

• Layout fluido: breakpoint e larghezze massime per il contenuto

• Impostazioni per blocco: sovrascritture di configurazione specifiche per un tipo di blocco

Quello che theme.json non controlla direttamente: la logica PHP dei blocchi personalizzati, le query dinamiche avanzate, i webhook, la gestione degli asset JavaScript. Per queste funzionalità, il PHP rimane il punto di ingresso corretto.

Un aspetto spesso sottovalutato di theme.json è la capacità di limitare le opzioni disponibili all'editor. È possibile disabilitare il selettore di colori personalizzati, limitare la palette ai soli colori del tema, o nascondere sezioni intere del pannello di stile. Per la consegna ai clienti meno tecnici, questa riduzione dell'interfaccia vale quanto il design stesso.

Pattern Override: struttura bloccata, contenuto modificabile

Introdotto in WordPress 6.8 con il Block Bindings API e la sorgente core/pattern-overrides, il Pattern Override è la funzionalità più rilevante del 2026 per la consegna professionale ai clienti.

Il principio è preciso: un pattern sincronizzato può avere una struttura bloccata (il cliente non può spostare, aggiungere o eliminare blocchi) ma con contenuti modificabili a livello di istanza (il cliente può cambiare testo e immagini in ogni inserimento del pattern). La struttura è garantita; il contenuto è libero.

All'uso pratico: si crea un pattern con un blocco Heading, un'immagine e un paragrafo. Si sincronizza il pattern e si abilitano i Pattern Override sui singoli blocchi che devono essere modificabili. Il cliente apre l'editor, vede i blocchi al loro posto, e può cambiare solo i contenuti designati. Non può spostare l'immagine sopra il titolo. Non può aggiungere un blocco Gallery nel mezzo del pattern.

Questo risolve il problema classico della consegna: il cliente che, nel tentativo di "migliorare" il layout, rompe il design nelle prime ore di utilizzo autonomo. Con i Pattern Override, la struttura è un dato di fatto, non una raccomandazione.

Cosa ancora si rompe in produzione

Onestà professionale: il Full Site Editing non è privo di attriti reali. Ecco i tre punti critici riscontrati su siti in produzione nel 2025-2026:

Sovrascrittura dei template nel database: quando un utente modifica un template dall'editor, WordPress salva una copia nel database. Questa copia ha la precedenza sul file nel tema. Se si aggiorna il tema, la modifica dell'utente persiste e non viene sovrascritta. Non è un bug: è un comportamento documentato e intenzionale. Ma genera confusione concreta nella gestione dei deployment e degli aggiornamenti del tema.

Lacune nel supporto RTL: il supporto alla scrittura da destra a sinistra (arabo, ebraico) è migliorato con WordPress 6.8, ma alcuni blocchi non rispettano ancora la direzione correttamente. Il blocco Navigation e alcuni layout con flex-direction mostrano problemi visibili su siti con dir="rtl". Per i siti MENA, questo richiede ancora CSS correttivi manuali.

Profondita del DOM: l'annidamento di blocchi Group, Stack e Row produce strutture HTML con dieci o piu livelli in progetti complessi. Su dispositivi con hardware limitato, il parsing e il rendering rallentano in modo visibile. Misura con Lighthouse prima di consegnare: un Core Web Vital sotto soglia su mobile e un problema reale del cliente, non del dispositivo.

Strumenti utili per il lavoro FSE in produzione

Tre strumenti che valgono il tempo di configurazione, verificati su progetti attivi:

• Create Block Theme (plugin ufficiale WordPress): esporta le modifiche apportate dall'editor direttamente nel tema su file. Essenziale per mantenere il version control allineato con le modifiche visive dei clienti.

• Theme Check: valida il tema contro gli standard del repository WordPress.org. Utile anche se non si pubblica sul repository: segnala pattern deprecati e problemi di compatibilita.

• Block Visibility: controlla la visibilita dei blocchi in base a ruoli utente, tipo di dispositivo, data e ora. Permette di creare esperienze personalizzate senza PHP aggiuntivo.

Il colofone di questo folio: testa sempre con un sito client reale, non solo in un ambiente di staging vuoto. I casi limite del Full Site Editing emergono sul contenuto reale, non su dieci post di prova.