Basta ricostruire ogni sito WordPress

Riepilogo

La maggior parte delle agenzie costruisce ogni sito WordPress partendo da un tema vuoto, anche quando una base condivisa permetterebbe di risparmiare settimane di lavoro. Questo articolo sostiene che theme.json, i block pattern e i blocchi dinamici consentono di standardizzare il livello strutturale preservando il design distintivo di ogni cliente. Affronta direttamente le cinque obiezioni che impediscono ai team di cambiare: «abbiamo clienti diversi», «i blocchi personalizzati sono costosi», «l'editor è confuso», «perderemo i nostri hook e filtri» e «FSE non è pronto per la produzione». Ogni obiezione riceve una controargomentazione pratica e un pattern concreto da adottare in modo incrementale. Il risultato è un processo di build ripetibile che continua a valorizzare il lavoro su misura dove serve. Avvertenza: non sono promessi pulsanti di reset con un clic.

Quanti dei siti dei tuoi clienti condividono anche una sola riga di codice? Non la riga del copyright—il codice vero. Se la risposta è «quasi nessuno», hai già sentito il dolore: la stessa sezione hero ricostruita per la nona volta, lo stesso markup della griglia del team copiato da un progetto all'altro, le stesse modifiche di preprocess incrociate tra mezza dozzina di temi. Hai anche sentito la difesa: «Ogni cliente ha esigenze diverse». Vero. Ma la conclusione che tutti traggono, cioè che ogni sito necessiti di una base su misura, è falsa. L'ecosistema di WordPress ora ti offre un modo per standardizzare gli elementi strutturali senza standardizzare il design: theme.json per i design token, i block pattern per i layout ricorrenti e i blocchi dinamici per quelle poche funzionalità che richiedono vera logica lato server. Questo articolo parla delle obiezioni che impediscono alle agenzie di fare questo passo e di ciò che funziona davvero quando si cerca di superarle.

L'obiezione «ma ogni cliente è diverso»

Il principio di base: standardizzare le fondamenta, non la superficie. Il motivo per mantenere la struttura in una libreria condivisa è proprio quello di lasciare libero il livello visivo. Un file theme.json non è un design—è un insieme di design token. Colori, spaziatura e tipografia sono valori, non markup. Questo è il cambiamento cruciale: puoi condividere il markup mentre un theme.json specifico per sito fa sembrare il sito completamente diverso per un altro marchio.

Prendi due clienti: uno studio legale e un rivenditore di articoli per l'outdoor. I loro linguaggi di design sono molto distanti. Ma entrambi hanno bisogno di una sezione hero, di una griglia per le testimonianze e di una banda call-to-action. Invece di ricostruire il markup per ciascuno, mantieni tre block pattern e lascia che il theme.json di ogni cliente definisca colori, font e spaziatura. La struttura rimane identica; i design token la trasformano da un marchio all'altro. Quando il rivenditore cambierà la sua palette di colori la prossima primavera, modificherai un file sul suo sito—non il markup in sei template.

In pratica, significa che il tuo team crea i pattern come codice, li registra in un plugin condiviso e lascia che il theme.json di ogni sito cliente gestisca la verniciatura. I nomi delle classi del pattern diventano la tua architettura; i valori diventano le variabili. Puoi anche spingerti oltre ed estendere theme.json per includere impostazioni personalizzate per i tipi di post o l'output dei plugin, anche se a un certo punto stai costruendo un'interfaccia di configurazione invece di un sito—una trappola discussa in il nostro approfondimento sull'estensione di theme.json. Mantieni lo strato condiviso snello: dovrebbe contenere solo ciò che si ripete tra i clienti. Nel momento in cui ti ritrovi ad aggiungere un'impostazione «nel caso qualcuno un giorno la voglia», hai creato un'astrazione che costerà più da mantenere di quanto risparmi.

Quando configuri un nuovo cliente, i primi trenta minuti dovrebbero essere: clona il plugin dei pattern condivisi, crea un nuovo theme.json con la palette e la scala tipografica del cliente e registra il loro logo e footer. Non è una build personalizzata; è un'attività di configurazione. Il rimanente lavoro specifico del cliente va nel contenuto, nella struttura e in eventuali funzionalità davvero su misura. Questa è la differenza tra costruire ogni casa da zero e avere una serie di piante prefabbricate che puoi riverniciare e ritappezzare. L'analogia è approssimativa, ma il principio regge: più spingi tutto verso i valori di theme.json, meno devi toccare il markup.

Uno dei vantaggi più semplici è guardare davvero a come funzionano i block pattern. Un pattern è solo una collezione di blocchi con contenuto e stile predefiniti. Puoi salvare qualsiasi configurazione di blocchi come pattern, e poi un cliente può inserirla senza dover sapere come è costruita. Questo significa che il pattern diventa un 'punto di ingresso' per utenti non tecnici. Quando il tuo team mantiene il pattern sottostante nel codice, il cliente ottiene una libreria coerente senza toccare un singolo tag PHP.

Ora, la precisazione a cui continuo a tornare: non centralizzare eccessivamente. Un theme.json con un'impostazione per ogni sfumatura concepibile è una palude da manutenzione. I pattern condivisi dovrebbero avere una propria opinione, non essere onnipotenti. Se un cliente ha bisogno di un layout radicalmente diverso—ad esempio, una homepage da rivista con una grande griglia in evidenza—potrebbe non adattarsi alla tua libreria standard di pattern. Va bene. La standardizzazione significa che vinci sull'80% dei progetti simili, non che costringi ogni sito nello stesso stampo.

L'obiezione «i blocchi personalizzati fanno saltare il budget»

Ecco un contro-principio che sembra noioso ma fa risparmiare denaro: la maggior parte delle cose che pensi abbiano bisogno di un blocco personalizzato non lo richiede. I blocchi core più un pattern possono coprire la stragrande maggioranza dei layout. Il blocco personalizzato è l'ultima risorsa, non la prima intenzione.

L'esempio classico è la griglia del team. Se è un caso isolato, usa i blocchi core «colonne» e «gruppo» e lascia che il cliente inserisca un avatar a mano. Se tre clienti chiedono la stessa griglia con la stessa struttura «link social sotto il nome», ora hai un candidato per un block pattern. Quando quel pattern inizia a raccogliere nuove opzioni—effetti hover, ordinamento, stelle di valutazione—il pattern diventa un sacco a pelo ingestibile, e allora è il momento di scrivere un blocco personalizzato. L'errore che danneggia il budget è saltare direttamente al blocco personalizzato alla prima richiesta.

Uno scenario più insidioso: il cliente chiede un «carousel di case study». Il primo istinto è pensare: «Mi serve un blocco carousel». Ma gli serve davvero un carousel? Forse hanno bisogno di un gruppo di post scorrevole orizzontalmente, che i blocchi core possono gestire con un blocco «gruppo» e un po' di CSS. O forse hanno bisogno di un elenco dinamico di case study recenti, che è un blocco dinamico che interroga il CPT. La domanda non è «quale funzionalità vuole il cliente?» ma «da quali dati dipende?» Se i dati sono statici e modificabili dal cliente, un pattern basta. Se i dati provengono da una query al database, un blocco dinamico è giustificato. Se i dati devono aggiornarsi in tempo reale da un'API, potresti avere a che fare con un'integrazione REST API—che rientra in un tipo diverso di build.

Quando costruisci un blocco, block.json è il tuo amico. È la fonte unica di verità per attributi, script e stili, il che rende il blocco portabile tra progetti. Ti permette anche di dichiarare dipendenze e traduzioni in modo pulito, il che è essenziale quando distribuisci una libreria su molti siti clienti. Per i contenuti che dipendono da dati live, un blocco dinamico renderizza sul server, quindi non devi inviare un bundle JavaScript a ogni visualizzazione di pagina. E se il tuo blocco evolve, puoi gestire le deprecazioni con eleganza per non rompere i contenuti esistenti—la nostra guida alla deprecazione dei blocchi illustra esattamente il pattern.

Prima di costruire qualsiasi cosa, esamina la decisione con questa griglia:

Approccio	Ideale per	Evitare quando
Blocco core	Contenuti una tantum, pagine semplici	Il layout si ripete su molti clienti e richiede opzioni ricche
Block pattern	Layout ripetibili senza logica	Il layout richiede condizionali, dati dinamici o interazioni complesse
Blocco personalizzato	Comportamento ripetuto, basato sui dati o altamente specifico	L'unico motivo è una sezione una tantum che può essere gestita con una classe

Dovrai anche pensare alla denominazione dei blocchi fin dal primo giorno. Il nome di un blocco è essenzialmente un contratto con i tuoi contenuti. Se lo chiami wagent/team-grid e in seguito lo rinomini in wagent/team-carousel, romperai i contenuti esistenti a meno che non fornisca un percorso di deprecazione. Scegli nomi generici basati sullo scopo che non diventino falsa pubblicità man mano che il blocco evolve. Questo è un aspetto della disciplina di denominazione che tutti abbiamo imparato dai prefissi dei plugin, e si applica anche ai nomi dei blocchi.

La visione contrarian qui è la cosa più utile che posso dire: il blocco personalizzato che costruisci perché un cliente ha chiesto «solo un pezzo» è quasi sempre un errore. Di' no con educazione, consegna un blocco core con una classe e metti da parte le ore. Il cliente ti rispetterà di più—e tu avrai una voce più piccola nel budget di manutenzione.

L'obiezione «i clienti romperanno l'editor»

Questa obiezione è giusta a metà. L'editor a blocchi in sé non è il problema; il problema è dare ai clienti troppa corda. theme.json può limitare ciò che è modificabile: disattivare l'editor dei template, limitare i blocchi consentiti e impostare stili predefiniti per ridurre i danni di una colonna fuori posto. Alcuni clienti riusciranno comunque a rompere qualcosa, ma puoi ripristinare una pagina a un pattern salvato con un clic—qualcosa che l'editor classico non poteva offrire.

Ti faccio uno scenario. Un cliente chiama e dice: «Ho spostato una sezione e ora l'intera pagina sembra sbagliata». Con un tema classico, dovresti accedere, ispezionare il CSS e probabilmente passare un'ora a sistemare il layout. Con un setup a blocchi, puoi aprire la pagina, selezionare l'area di contenuto e reimpostarla al pattern salvato. Il pattern è la linea di base; le modifiche del cliente sono il livello sovrapposto. Quando la sovrapposizione sbaglia, la rimuovi. Non è solo un flusso di lavoro più gradevole; è un editor fondamentalmente più indulgente.

Ora, la sfumatura: la maggior parte dei clienti non vuole modificare molto. Vogliono cambiare testo, sostituire foto e magari riordinare una sezione. Il block pattern ti dà esattamente questo senza esporre l'intera struttura del sito. In questo senso, l'editor non è un giocattolo; è un mirino. Il tuo compito è calibrare ciò che i clienti possono vedere. Ciò significa che potresti disattivare le impostazioni «Templates», limitare l'inseritore di blocchi a un elenco curato e persino precompilare pattern vuoti con lavoro segnaposto. L'editor diventa un modulo di inserimento contenuti piuttosto che una tela di web design.

Sul fronte dell'accessibilità, la gestione del focus e il supporto da tastiera dell'editor a blocchi sono generalmente migliori dei campi di template degli editor classici. Ma devi comunque assicurarti che i pattern abbiano una corretta gerarchia dei titoli e nomi accessibili. Poiché il pattern è condiviso tra i clienti, risolvi quei problemi una sola volta, un altro vantaggio nascosto della standardizzazione.

La parte davvero difficile è interna. Per il tuo team, imparare a prototipare con i blocchi richiede di disimparare l'abitudine «farlo in PHP». È un costo reale, ma è un costo una tantum per persona. Non è un motivo per evitare l'approccio; è un motivo per iniziare con una libreria di pattern e un cliente indulgente prima di implementarla ovunque. Non lasciare che il ritornello «i miei clienti non sanno usare i blocchi» nasconda il fatto che non hai ancora configurato un setup a blocchi che li venga incontro.

L'obiezione «abbiamo già hook e filtri»

Il principio qui è: non stai buttando via gli hook; stai aggiungendo un livello sopra. I blocchi sono il confine di presentazione; gli hook sono ancora il modo in cui inietti la logica. Il callback di render di un blocco dinamico viene eseguito in PHP, il che significa che puoi chiamare le stesse funzioni e applicare gli stessi filtri di cui già ti fidi.

Immagina un plugin che ti permette di aggiungere un campo «prodotto in evidenza» a qualsiasi post usando un filtro. Con un blocco dinamico, puoi includere un blocco renderizzato lato server che esegue quel filtro e stampa l'output all'interno del wrapper del blocco. Il cliente inserisce il blocco; la logica PHP esistente fa il lavoro pesante. Niente viene buttato. Per un esempio ancora più concreto, considera un blocco personalizzato che elenca i post recenti di un progetto. Nel suo callback di render, chiami get_posts(), poi fai un ciclo e applichi the_title() e the_permalink()—gli stessi template tag che usi da anni.

Questo è anche il posto per essere onesti su ciò che non si traduce. Alcuni temi vecchi e furbi usano template-parts con condizionali intricati che prendono argomenti in base al contesto della pagina. Ricrearlo come blocco può essere complicato. Ma non devi ricreare tutto in una volta. Il percorso incrementale è mantenere la logica PHP, avvolgerla in un blocco dinamico e spostare il markup nel template del blocco. Spesso scoprirai che i tuoi pattern di filtro esistenti possono gestire il nuovo output. E se la logica è strettamente accoppiata a una gerarchia di template (ad esempio, «nei risultati di ricerca, mostra questo in modo diverso»), puoi ancora usare il template classico per quelle viste specifiche mentre usi i blocchi per le pagine normali.

La REST API apre anche una porta diversa: puoi costruire blocchi che recuperano dati da altri siti WordPress o servizi di terze parti. Un blocco dinamico può chiamare wp_remote_get() per recuperare JSON e renderizzarlo nel front-end. È un pattern potente per le build delle agenzie in cui i clienti vogliono mostrare feed sociali, elenchi di prodotti o dati interni senza gestire un'integrazione separata. Il compromesso è la memorizzazione nella cache e la gestione degli errori—se l'API remota è lenta, la tua pagina è lenta. Tieni i blocchi basati su API fuori dai contenuti critici above-the-fold, oppure usa il rendering lato client con un corretto stato di caricamento.

Le action e i filtri continuano a girare durante il salvataggio e il rendering; l'architettura degli hook non sparisce quando adotti i blocchi, si sposta semplicemente in un nuovo contesto. Se hai bisogno di rinfrescare la tua comprensione di dove le action e i filtri incontrano questo nuovo mondo di blocchi, il nostro approfondimento sugli hook è un utile ripasso.

L'obiezione «FSE non è pronto per la produzione»

Giusto, ma chiediti cosa significa davvero «rischioso». Full Site Editing ha attraversato diverse release, e theme.json ha raggiunto uno schema stabile. Il rischio non è che l'editor «si rompa all'improvviso»—il rischio è che il codice personalizzato del tuo team possa fare affidamento su vecchi template PHP che coesistono male con i template a blocchi. Inoltre, alcuni plugin di terze parti assumono ancora l'editor classico o il personalizzatore. Questa è una decisione di compatibilità, non un motivo per buttare via tutto il modello.

Un modo utile di pensarci: i siti semplici e ripetibili con contenuti scritti a blocchi sono i meno rischiosi. I clienti ad alto rischio sono quelli con temi classici profondamente personalizzati o plugin proprietari che renderizzano il loro front-end. Questa è una ragione legittima per restare con i temi classici per quella piccola nicchia. L'errore è fingere che «pronto per la produzione» sia un singolo interruttore acceso o spento.

Prima di proporre un tema a blocchi a un cliente, esegui una rapida lista di controllo:

• Il cliente ha un tema fortemente personalizzato che richiederebbe una migrazione?
• I plugin indispensabili supportano il Site Editor e la REST API?
• L'ambiente di hosting consente l'accesso ai file che il tema a blocchi si aspetta?
• Hai previsto tempo per la progettazione dei pattern, non solo per la registrazione dei blocchi?
• Il team del cliente tollererà le modifiche all'editor, o ha bisogno di un template bloccato?

Se una risposta è no, regola l'ambito o usa un approccio ibrido. Non è un compromesso; è giudizio ingegneristico. E se stai costruendo un ibrido, ricorda la storia di hook e filtri di cui sopra—puoi ancora avvolgere la vecchia logica in blocchi dinamici mentre il theme.json gestisce l'aspetto globale.

Versionare il tuo theme.json non è solo una preoccupazione teorica. Ho visto la libreria di blocchi personalizzati di un'agenzia rompersi quando il cliente ha aggiornato WordPress e il file style del blocco registrato con wp_register_style() cambiava handle. Il fix è stato facile, ma il panico era reale. Un semplice processo di test—esegui l'aggiornamento su una copia di staging del sito, clicca sulle pagine chiave, poi rilascia—risolve la maggior parte di queste sorprese.

L'obiezione che non hai fatto a te stesso

Ecco la meta-obiezione che impedisce alle agenzie di standardizzare: «È un grande cambiamento, e non c'è tempo per farlo durante il lavoro con i clienti». Vero—quindi non farlo durante il lavoro con i clienti. Scegli un progetto interno o un piccolo cliente e costruisci una libreria di pattern. Usa theme.json come sistema di design token. Aggiungi un blocco personalizzato solo quando è giustificato. Avvolgi i vecchi hook dove servono. Iterate.

Ecco una bozza dei primi 30 giorni:

1. Analizza le ultime cinque build dei clienti e elenca i dieci elementi di layout più ripetuti.
2. Trasforma quei dieci elementi in block pattern, con un piccolo set di classi CSS.
3. Crea un plugin condiviso (o mu-plugin) che registri quei pattern. Se non hai ancora pensato all'organizzazione dei plugin per questo, dai un'occhiata a questa guida su come creare plugin robusti.
4. Crea un theme.json che rispecchi il tuo design di base; aggiungi valori specifici per il cliente man mano che avvii i progetti.
5. Scegli un piccolo progetto interno o un cliente amichevole e migralo allo stack.
6. Documenta una storia eroica di un cliente che ha modificato la sua homepage senza chiamarti.

Alla fine di questo esperimento, non avrai un badge «block-first» da appendere al muro. Avrai un team in grado di avviare un nuovo sito cliente da una base condivisa senza scusarsi per i tempi. Sarai anche in una posizione migliore per dire di no alla richiesta del cliente per un 42° blocco personalizzato—perché sai esattamente cosa possono fare i blocchi core, o perché puoi mostrare perché un blocco dinamico sarebbe davvero più veloce.

Costruirai ancora alcuni siti su misura? Sì. Alcuni clienti avranno sempre bisogno di un template personalizzato, di una pagina bespoke o di un'integrazione proprietaria che non vale la pena forzare nel modello condiviso. L'obiettivo non è eliminare il lavoro su misura—è renderlo l'eccezione piuttosto che la regola.

La ripetibilità viene dalle parti noiose: uno schema theme.json solido, una libreria di pattern chiara e la disciplina di mantenere lo strato condiviso snello. Non è la versione patinata che senti nei webinar. È quella che batte la tristezza del lunedì mattina di fronte a un tema vuoto.