WordPress 5.8 introdotto un sistema opt-in per i temi per configurare le impostazioni del blocco, gli stili, i modelli e altro. È fatto attraverso un nuovo theme.json file che gli autori possono inserire nella radice delle cartelle dei temi. Anne McCarthy, responsabile del programma di sensibilizzazione dell’FSE, ha annunciato un sondaggio prima di oggi per ottenere feedback dagli sviluppatori su questa funzione.

“Dal momento che questo nuovo meccanismo è un primo passo verso un sistema di stile completo per il futuro di WordPress, è importante sentire da tutti coloro che stanno attualmente utilizzando theme.json per saperne di più su come le persone utilizzano questo strumento e su cosa potrebbe avere senso includere in Core in futuro”, ha scritto nell’annuncio.

Il sondaggio è aperto a tutti gli autori del tema che hanno utilizzato theme.json, dando loro la possibilità di fornire un primo feedback e aiutare a guidare la nave in avanti.

Poiché ho lavorato a lungo con questo sistema negli ultimi mesi, avevo alcune cose da dire. Inoltre, mi piace partecipare ai sondaggi relativi a WordPress. Ho anche deciso che sarebbe stata un’opportunità per condividere alcuni dei miei pensieri non filtrati da una prospettiva di sviluppo sullo stato attuale di theme.json.

Quelle che seguono sono le mie risposte alle domande del sondaggio – beh, la versione riordinata.

Nota: Questo è un post incentrato sugli sviluppatori che potrebbe non piacere universalmente a tutti i nostri lettori. Ho cercato di spiegare alcune cose con una terminologia intuitiva, ma potrebbe essere necessaria una conoscenza preliminare dello sviluppo del tema.

Esperienza

La prima domanda del sondaggio è piuttosto secca. Ti chiede qual è la tua esperienza con i temi dei blocchi predefiniti o l’utilizzo theme.json. Fornisce quattro scelte (e un’opzione “altro”):

• Ho creato e lanciato temi a blocchi.
• Ho sperimentato con i temi dei blocchi di costruzione.
• ho esplorato usando theme.json con un tema classico.
• Ho usato un tema a blocchi, ma non ne ho ancora creato uno.

Ho scelto la prima opzione perché ho già creato due temi a blocchi per la famiglia e gli amici. Questi erano semplici siti personali che già mantengo gratuitamente — onestamente, devo iniziare a caricare. Sto anche lavorando a un tema che spero di rilasciare pubblicamente.

Come è iniziato e come sta andando

La seconda domanda chiede come si è iniziato con i temi dei blocchi e theme.json. Le scelte sono tra la biforcazione di un tema esistente, utilizzando il Tema vuoto, o partendo da zero.

Di nuovo, questa è una di quelle cose in cui ho sperimentato ogni direzione, ma non riesco a ricordare il punto di partenza esatto. La maggior parte del mio lavoro deriva da un tema su cui ho lavorato l’ultima volta nel 2019.

Ho intenzione di rilasciarlo come nuovo tema gratuitamente ad un certo punto. Sto principalmente aspettando quanto segue:

• Sviluppo del blocco di navigazione per sistemarsi
• Il blocco Post Autore da dividere in blocchi più piccoli
• Un robusto set di blocchi relativi ai commenti
• Pubblica il blocco immagine in primo piano per avere un’opzione di dimensione

Penso che potrei realisticamente rilasciare una versione beta del mio tema da usare a proprio rischio oggi se tali elementi fossero affrontati.

Modelli e parti di modelli

Il sondaggio ha chiesto quali modelli e parti del modello i temi includono sempre nei loro temi basati su blocchi. C’era un campo di commento a mano libera – passi su soapbox…

Al momento ho una relazione di amore/odio con i modelli di blocco. La natura statica dei modelli HTML mi ricorda i tempi più semplici in cui lo sviluppo del tema era meno complicato. Tuttavia, questo presenta anche un problema in un sistema dinamico.

Non riesco a ricordare l’ultima volta che ho creato un tema tradizionale basato su PHP con più di un modello di primo livello: index.php. I pezzi dinamici sono sempre stati il ​​cuore della cosa, che sono parti modello. Con PHP, è facile impostare alcune variabili o utilizzare una chiamata di funzione per caricare contestualmente le parti dei modelli necessarie per qualsiasi pagina che un visitatore sta attualmente visualizzando su un sito.

Il sistema dei modelli di blocco non funziona in questo modo. In sostanza, costringe gli sviluppatori a infrangere il principio Don’t Repeat Yourself (DRY).

Ad esempio, se un designer volesse visualizzare una parte del modello di intestazione diversa per pagine e post, dovrebbe solo creare un header-page.php o header-post.php modello in temi tradizionali. Tuttavia, poiché il sistema dei modelli di blocco è diverso, ora devono creare due modelli di livello superiore, single.html (posta) e page.html, per realizzare la stessa cosa.

Questa è una “cosa negativa” perché gli autori del tema devono duplicare tutto l’altro codice in ciascuno dei modelli di livello superiore. Non è possibile caricare contestualmente parti del modello diverse.

Per rispondere alla domanda: sto usando quasi tutti i possibili modelli di primo livello per necessità.

Ho anche risposto alla seconda parte della domanda e ho elencato le mie parti del modello più comunemente usate (suddivise per gerarchia):

• Intestazione
• Contenuto
  – Ciclo continuo
  – Barra laterale
• piè di pagina

Il content-*.html e loop-*.html le parti del modello sono quelle con il maggior numero di variazioni.

Definizione dei colori

La prossima sezione del sondaggio chiede come gli autori del tema definiscono le loro lumache della tavolozza dei colori in theme.json. Credici o no, nominare i colori potrebbe essere l’argomento più controverso nel mondo dei temi da anni. Le uniche due cose generalmente concordate sono i colori di “sfondo” e di “primo piano”.

Morten Rand-Hendriksen ha aperto un biglietto nel 2018 per standardizzare uno schema di denominazione dei colori del tema. Non era la prima discussione e non è stata l’ultima. Il problema che avrebbe dovuto affrontare erano gli scarti di colori nel sistema, che è il modo in cui i temi definiscono le loro tavolozze. Una volta che un utente fa uso di un colore preimpostato, lo slug viene inserito nel loro contenuto. Passa a un altro tema con slug diversi e i vecchi colori scompaiono e non cambiano automaticamente con i colori del nuovo tema.

Uso nomi semantici che seguono qualcosa che ricorda da vicino il framework CSS di Tailwind sistema di ombreggiatura. Invece di red-medium (descrittivo), userei primary-500 (semantico), per esempio. Un approccio semantico consentirebbe agli autori di temi di definire un insieme di colori che vengono aggiornati ogni volta che un utente cambia tema.

Naturalmente, ci sono altre scuole di pensiero e anche tutti coloro che preferiscono la denominazione semantica non sono d’accordo sullo stesso sistema. io ho descritto il mio approccio in modo più dettagliato in un biglietto GitHub più recente e avere un theme.json Gist per altri che potrebbero volerlo provare.

Altre impostazioni JSON del tema

Al di fuori dei colori e della tipografia, il sondaggio chiede quali altre impostazioni hanno utilizzato gli autori del tema. Questo è un altro scenario in cui in genere uso tutto: se c’è un’opzione per questo, la sto definendo.

Un caso d’uso per il quale WordPress non ha attualmente un preset è la spaziatura globale. La maggior parte degli autori di temi utilizza un unico valore per la maggior parte dei margini verticali (spazio bianco tra blocchi ed elementi). Viene spesso utilizzato anche per il riempimento verticale e orizzontale predefinito.

Non sono sicuro di volere un preset perché non so come WordPress lo utilizzerà. È qualcosa che altri hanno chiesto, ed è quasi onnipresente in uso. Definire un intero sistema attorno ad esso potrebbe causare grattacapi lungo la strada, ma mi piacerebbe comunque vedere qualche discussione sull’implementazione di almeno un preset di spaziatura globale standard.

Impostazioni e stili per blocco

Questa sezione del sondaggio era una domanda sì/no, che chiedeva semplicemente se gli autori del tema includevano impostazioni o stili per blocco nei loro theme.json File. Naturalmente, ho lasciato alcuni commenti aggiuntivi più avanti nella sezione dei commenti facoltativi.

Sono soddisfatto del sistema quando si tratta di impostazioni, che consentono ai temitori di definire quali funzionalità sono abilitate a livello globale o per blocco. Tuttavia, non sono venduto sull’aggiunta di stili tramite theme.json.

Scrivere CSS in JSON, essenzialmente ciò di cui stiamo parlando, sembra sbagliato su così tanti livelli. Attualmente, è limitato a pochi stili configurabili, quindi qualsiasi cosa oltre a ciò richiede comunque l’immersione in un file CSS effettivo. Questo è problematico perché metà del codice CSS del tema è diviso tra theme.json e un file CSS separato. Dal punto di vista dello sviluppo, rende la base di codice più difficile da mantenere.

Inizialmente, ho iniziato il percorso di configurazione degli stili per blocco ed elemento da theme.json. Tuttavia, da allora ho spostato il mio stile sui file CSS. Sembra più naturale e ho l’ulteriore vantaggio di tutti gli strumenti a cui sono abituato. In questo momento, non riesco a immaginare uno scenario in cui tornerei indietro.

Oltre a salvare alcuni byte di codice, non ho riscontrato molti vantaggi nell’aggiungere stili per la maggior parte delle cose tramite JSON. Forse questo cambierà in futuro e io mi convertirò. Per ora, mi attengo principalmente ai CSS.

Altri feedback: un livello PHP

io ho detto prima, ma vale la pena ripeterlo. Abbiamo bisogno di un livello PHP per questo theme.json sistema di configurazione. Attualmente c’è un Apri un ticket per affrontare questo.

Ci sono due vantaggi principali per un tale sistema. Avere un’API PHP per mettere insieme la configurazione sembrerà molto più naturale per gli sviluppatori di temi tradizionali. Lo considero un po’ un ramoscello d’ulivo, una dimostrazione di buona fede che gli sviluppatori core/Gutenberg riconoscono che molti autori di temi avranno un tempo più facile per facilitare le funzionalità di FSE tramite un linguaggio di programmazione familiare.

Il secondo vantaggio è che esiste un numero incalcolabile di idee per i plugin per estendere gli stili globali, la modifica del sito e altro se esiste un modo semplice per collegarsi al sistema JSON del tema e sovrascrivere le cose. Un semplice gancio per filtro renderebbe tutto questo indolore.