Blog
Il Site Editor a prova di cliente: un playbook su theme.json
Usa theme.json per stabilire limiti nel Site Editor di WordPress, così i clienti possono modificare i contenuti senza rompere il tuo design.
Riepilogo
Quando un cliente apre per la prima volta il Site Editor di WordPress, la possibilità di modificare ogni blocco, colore e layout può sembrare una funzionalità per lui — e una minaccia per te. Questo articolo spiega come usare theme.json per tracciare una linea chiara tra modifica dei contenuti e controllo del design. Invece di combattere il Site Editor, imposti preset, impostazioni predefinite e limiti che rendono sicuro per i clienti non tecnici aggiornare il proprio sito. Vedremo cosa bloccare, cosa lasciare aperto e perché bloccare troppo è un rischio reale. L'approccio si basa su design token e vincoli a livello di template, quindi funziona in modo coerente su ogni sito cliente che gestisci. Alla fine, avrai un flusso di lavoro ripetibile per consegnare il Site Editor senza consegnare le chiavi del tuo sistema di design.
Qual è la prima cosa che fai quando un cliente ti scrive per dire che "ha appena provato ad aggiornare il titolo" e l'intera spaziatura del sito è crollata?
Se gestisci più di un sito WordPress, probabilmente hai ricevuto quel messaggio in qualche forma. Il Site Editor ha dato al tuo cliente le chiavi di un'auto con cinque marce e senza freni. Pensano di fare una semplice modifica al testo, e improvvisamente la tipografia globale è fuori posto, l'hero della homepage ha un colore neon che non hai scelto tu, e due blocchi sono ora impilati invece che affiancati.
Nel frattempo, stai pensando agli altri sei siti clienti che supporti, e l'ultima cosa di cui hai bisogno è una trappola di manutenzione in cui ogni modifica "utile" del cliente richiede un ripristino da backup.
La risposta non è togliere il Site Editor. È stabilire dei limiti al suo interno usando theme.json. Secondo le risorse per sviluppatori di WordPress, theme.json è la fonte centrale di verità per le impostazioni e gli stili dell'editor a blocchi — definisce le palette di colori, la tipografia e le opzioni di layout che appaiono al cliente. Ciò significa che lo stesso file che controlla il tuo design può anche controllare cosa il tuo cliente può e non può modificare.
Vediamo come pensare a questo aspetto, perché la maggior parte dei tutorial si concentra su cosa theme.json può fare per gli sviluppatori. La domanda per un'agenzia è diversa: come usarlo per rendere i clienti al sicuro senza farli sentire imprigionati?
Perché il Site Editor sembra così pericoloso?
Il tuo cliente non sta cercando di rompere il sito. Sta cercando di fare ciò che gli hai insegnato a fare per anni nel vecchio editor: cambiare un titolo, sostituire un'immagine, magari aggiungere un paragrafo. Il pericolo non è la loro intenzione — è che il Site Editor mostra i controlli globali nello stesso posto dei controlli dei contenuti.
Ecco uno scenario comune. Un cliente apre un template nel Site Editor e vede un blocco di intestazione. Ne cambia il colore per abbinarlo alla nuova tonalità del brand. Ma poiché quell'intestazione è in un template, la modifica si applica ovunque quel template viene usato. Per il cliente, sembrava una singola modifica. Per il sito, era un cambiamento globale.
Il principio generale: quando dai a qualcuno un page builder, alla fine troverà le "impostazioni con protezioni" e le disattiverà. Ma con theme.json puoi nascondere le protezioni stesse. Invece di dire al cliente "non toccare gli stili globali", semplicemente non gli mostri una palette di colori che possa produrre un brutto risultato. Definisci una palette di colori approvati, una scala di dimensioni dei caratteri e una serie di preset di spaziatura — e il cliente sceglie da quelli, non dall'intero spettro del CSS.
Questo è il primo cambiamento: smetti di pensare in termini di regole e inizia a pensare in termini di fabbriche. theme.json è la tua linea di produzione. Configuri le opzioni che il cliente vede, e i vincoli sono applicati dall'interfaccia stessa, non da una serie di istruzioni in un documento di consegna.
Cosa dovresti effettivamente bloccare?
Non tutto. Se blocchi troppo strettamente l'area dei contenuti, il cliente o ti chiamerà ogni volta che deve aggiungere un paragrafo, o troverà un modo per aggirarti — spesso aggiungendo un plugin una tantum o copiando HTML dal suo vecchio sito.
Ecco una tabella pratica su cosa bloccare, cosa lasciare e perché:
| Superficie di modifica | Bloccare? | Perché |
|---|---|---|
| Struttura del template e layout dei blocchi | Blocca | Previene la rimozione o il riordino accidentale dei blocchi di layout principali |
| Stili globali (colori, caratteri, preset di spaziatura) | Blocca con preset | I clienti scelgono da un set approvato, non da valori arbitrari |
| Testo e immagini dei contenuti | Lascia aperto | È il loro lavoro; lasciali fare senza chiedere permesso |
| Spaziatura tra i blocchi | Blocca parzialmente | Fornisci preset di spaziatura così possono regolare il ritmo senza rompere l'allineamento |
| Pattern di blocchi selezionati | Lascia aperto se li hai verificati | Un modo sicuro per i clienti di aggiungere nuove sezioni senza costruire da zero |
La sfumatura importante è "blocca con preset", non "blocca del tutto". Per gli stili globali, non stai nascondendo il pannello delle impostazioni; stai riducendo il numero di scelte a un set curato. Per la struttura del template, puoi bloccare alcuni blocchi in modo che non possano essere rimossi, ma consentire comunque ai clienti di modificarne il testo.
Una parola di cautela: bloccare un blocco in un template è diverso dal bloccarlo in una pagina specifica. I blocchi del template influenzano tutti i contenuti che usano quel template. Se hai bisogno di diversi livelli di blocco su pagine diverse, dovrai lavorare a livello di blocco nell'editor, che è più fragile. Per il lavoro ripetibile dell'agenzia, progetta i tuoi template in modo che le aree bloccate siano coerenti.
Come si stabiliscono i limiti senza far sembrare l'editor una trappola?
La tecnica è definire i tuoi design token in theme.json e poi resistere alla tentazione di fare qualsiasi altra cosa in CSS.
Ad esempio, invece di lasciare che il cliente imposti un colore arbitrario su un pulsante, definisci uno stile del pulsante in theme.json che usa un colore specifico dalla tua palette. Il cliente può comunque selezionare il pulsante e cambiarne il testo, ma il selettore colore mostra solo i tuoi campioni approvati. Lo stesso vale per le dimensioni dei caratteri, l'interlinea e la spaziatura.
Lo stesso principio si applica ai template. Puoi usare la funzione "blocca" su blocchi specifici all'interno di un template — ad esempio, bloccare la struttura a colonne di un blocco testimonianza così il cliente può cambiare il testo della citazione ma non trasformare tre colonne in due. Se non hai ancora usato il blocco dei blocchi, è disponibile nella barra degli strumenti dell'editor; quando blocchi un blocco, puoi scegliere se il cliente può modificarne il contenuto, spostarlo o entrambi. Puoi anche applicarlo in theme.json per le impostazioni predefinite a livello di blocco.
L'obiettivo è un editor in cui il cliente non vede mai un controllo che possa rompere il design. Non significa che non possano fare errori; significa che il peggior errore che possono fare è cambiare la formulazione di un titolo, non l'aspetto dell'intero sito.
Se stai usando tipi di contenuto personalizzati, gli stessi principi si applicano oltre ai template predefiniti — vedi la nostra guida su estendere theme.json a tipi di contenuto personalizzati e output di plugin.
Cosa succede quando blocchi troppo?
Ecco il punto controcorrente: bloccare troppo è dannoso quanto bloccare troppo poco. Un cliente che non può ridimensionare un titolo o aggiungere uno spazio tra le sezioni alla fine ti chiederà di "sistemare le cose" — e poi ti ritrovi a fare piccole modifiche gratis. Peggio, potrebbero decidere che il Site Editor è inutile e tornare a un page builder di terze parti, che dà loro di nuovo troppo controllo.
Il compromesso è reale. Gli editor bloccati producono meno chiamate di emergenza, ma anche più richieste del tipo "puoi spostare questo pulsante su di cinque pixel?". Gli editor aperti producono l'opposto. Il tuo compito è trovare il punto di equilibrio per ogni cliente, non applicare una configurazione universalmente.
Una buona euristica di partenza: blocca tutto ciò che influisce su tutte le istanze di qualcosa (stili globali, struttura del template), e lascia aperto tutto ciò che influisce su una singola istanza (testo e immagini di una singola pagina). Se un cliente rompe una singola pagina, è una soluzione di 5 minuti. Se rompe uno stile globale, è una soluzione di 20 minuti e una preoccupazione per la sicurezza.
Come rendere questo ripetibile tra i clienti?
È qui che entra in gioco il flusso di lavoro dell'agenzia. Dovresti avere un theme.json di base che definisce i tuoi design token — la palette di colori, la scala tipografica e i preset di spaziatura — e poi un file di override per ogni cliente che estende o modifica valori specifici.
Inizia creando un tema a blocchi "starter". Ecco come costruire un tema a blocchi personalizzato con theme.json — una volta sviluppato e documentato, copiarlo per un nuovo cliente è una questione di sostituire colori e caratteri del brand. Non stai reinventando la ruota; stai scambiando token. Questa è esattamente la mentalità di smettere di ricostruire ogni sito WordPress, ma applicata all'editor piuttosto che al backend.
Poiché theme.json è un singolo file, è anche facile da versionare e distribuire in più ambienti. Puoi rivedere le modifiche, vedere cosa ha modificato un cliente negli stili globali e confrontare queste modifiche con il tuo file di base. Questo ti dà una solida traccia di audit per le richieste di supporto.
Se gestisci più siti e non hai ancora impostato un tema di base, questa è la tua occasione. È l'unico lavoro WordPress personalizzato che si ripaga ogni volta che un cliente apre l'editor.
E i clienti che continuano a chiedere "un altro colore"?
La tua palette è una promessa. Se definisci cinque colori del brand e un cliente ne chiede un sesto, la risposta non è "no" — è "sì, ma arriva come aggiunta deliberata alla palette, non come un codice hex una tantum in un titolo." Quando aggiungi un colore a theme.json, diventa disponibile in tutto il sito in modo coerente. Questo è il modo giusto di gestire queste richieste.
È anche qui che devi comunicare con il cliente. Spiega che il Site Editor mostra loro solo i colori e i caratteri che corrispondono ai loro standard di brand. Se vogliono ampliare questi standard, lo gestirai nel sistema di design, e poi ogni nuovo colore sarà disponibile ovunque — incluse le pagine future che non hanno ancora costruito. Questa è una risposta molto migliore di "non lo facciamo".
Allo stesso tempo, non accumulare una palette di quaranta colori. Rivedila trimestralmente e rimuovi tutto ciò che è stato un incidente una tantum. L'obiettivo è un set di opzioni piccolo e intenzionale.
Se blocchi il layout ma lasci i contenuti, e rendi la palette una parte viva della tua relazione con il cliente, il Site Editor smette di essere una minaccia. Diventa un modo per dare ai tuoi clienti una vera autonomia senza sacrificare gli standard di design che sei pagato per proteggere.
Sources (5)
- WordPress Architecture: A Complete Guide - Liquid Web
- Inside WordPress - A Deep Dive into Technical Architecture and Essential Components
- WordPress Tech Stack Explained: Core Components and Uses - WPoptic
- A Guide To Understanding WordPress Architecture - Pressable
- A Detailed Guide About WordPress Architecture - Auxilium Technology