Ieri è iniziato il round n. 8 del programma di divulgazione Full Site Editing (FSE). Invece della chiamata incentrata sull’utente per testare le funzionalità dall’interfaccia utente, la responsabile del programma Anne McCarthy chiede ai volontari di immergersi nel codice. La nuova avventura è tutta una questione di test theme.json File.

La svolta rischia di limitare il pool di soliti volontari. Tuttavia, potrebbe aprirlo a un pubblico che potrebbe essere rimasto in disparte per i test precedenti: gli sviluppatori di temi.

Prima di saltare a capofitto file JSON del tema, probabilmente dovremmo essere tutti sulla stessa pagina.

ho chiamato theme.json il punto di svolta tra il vecchio WordPress e il nuovo WordPress. Quando la versione 5.0 della piattaforma principale è stata lanciata alla fine del 2018, è stato un passo avanti rivoluzionario, ma non in superficie. Un nuovo editor è solo un nuovo editor. Alcuni lo ameranno; altri lo odieranno. E, era più spesso goffo che no. Per la maggior parte, WordPress era ancora WordPress.

Il software principale doveva subire un ribaltamento. Le nuove tecnologie non solo stavano democratizzando l’editoria a modo loro, ma stavano anche portando lo stesso concetto nel design.

L’introduzione dei blocchi è stata semplicemente fondamentale. Il nuovo editor era uno strumento imperfetto, spesso sembrava come se il proverbiale piolo rotondo fosse spinto in un buco quadrato.

L’unico modo per realizzare la visione iniziale del progetto Gutenberg era continuare a colmare il divario tra ciò che l’utente vede nell’amministratore e ciò che viene prodotto sul front-end. Questo è ciò che theme.json il file è tutto. È un traduttore che consente a utenti, temi e WordPress di parlare tutti la stessa lingua.

Cosa significa esattamente?

Dal punto di vista di un utente, vedono tutti i tipi di controlli per modificare i loro blocchi. Colore, dimensione del carattere, allineamento e altre opzioni sono strumenti che consentono loro di personalizzare il contenuto.

Ci sono gravi limitazioni con ciò che è possibile nel sistema attuale. Gli autori del tema possono registrare una manciata di opzioni. Al di fuori di ciò, il tema e i sistemi di blocchi possono sembrare contrapposti l’uno contro l’altro per il controllo.

È lì che theme.json arriva il file. Consente a temi e WordPress di entrare nella stessa pagina, creando un sistema standardizzato che migliora l’esperienza dell’utente.

Questo file che risiede nella cartella principale di un tema ha il potere di configurare dozzine di preimpostazioni (ad esempio, opzioni di colore e carattere), proprietà CSS personalizzate e stili predefiniti per blocchi ed elementi HTML.

Dà anche ai temi il potere di abilitare o disabilitare funzionalità specifiche. Ad esempio, gli sviluppatori possono disattivare la possibilità per gli utenti di impostare una dimensione del carattere personalizzata ma fornire l’accesso alla loro scala perfetta di scelte che si adattano al ritmo verticale del design.

Tuttavia, andrà oltre la semplice configurazione dei blocchi nell’editor dei contenuti. Quando in futuro il sistema di stili globali verrà avviato insieme all’editor del sito, gli utenti personalizzeranno molti dei preset e sovrascriveranno gli stili di blocco predefiniti. Poiché tutti parlano la stessa lingua, sorgono meno conflitti.

Come ha sottolineato la designer Tammie Lister nel suo pezzo per Ephermeral Themes, Theme.json ispira, i temi sono stati bloccati. Il software, la comunità, ha messo troppe responsabilità sulle spalle dei temi nel corso degli anni. Hanno dovuto innovare e costruire i sistemi che avrebbero dovuto provenire da WordPress. Non solo la piattaforma principale doveva essere capovolta, ma il sistema di progettazione meritava una revisione.

“Sono molto consapevole che dire ‘il primo grande processo tematico al centro’ in anni è piuttosto una dichiarazione”, ha scritto Lister. “Theme.json per me è questo però. Non dico questo ignorando iterazioni e miglioramenti, WordPress è un progetto che scorre con l’energia di quelli. Tuttavia, i temi erano sul supporto vitale bloccato in una terra quando il resto dello sviluppo del front-end stava andando avanti. Non era per alcuni che cercavano di cambiarlo, soprattutto quando lo facevano il momento non era giusto e poiché non veniva dal core, era sempre un cambiamento più difficile.

È tempo di una nuova era del design front-end. Ma, prima, dobbiamo testare.

Test del tema JSON

Più mi sono avventurato in questa chiamata per i test, più mi sono reso conto che non mi sembrava giusto. Negli ultimi due mesi, sono già stato nel bel mezzo del lavoro dal theme.json file. Conosco la maggior parte delle piccole stranezze e vedo le lacune. I trucchi per lavorarci mi sembrano una seconda natura.

Ho eseguito tutti i passaggi per principianti e intermedi dozzine e dozzine di volte. Ho già archiviato i biglietti per qualsiasi problema in cui mi sono imbattuto. Oppure qualcun altro mi ha già battuto sul tempo.

Quelle fasi di questo ciclo di test hanno bisogno di occhi nuovi. Il miglior feedback verrà dagli autori del tema che visualizzeranno i problemi attraverso un diverso paio di lenti. Se sei in questo gruppo, non c’è tempo come il presente per testare e fornire feedback.

La fase avanzata richiede di ricreare un tema classico utilizzando theme.json. È meglio attenersi a qualcosa di semplice. Altrimenti, potresti guardare a un esperimento di settimane. McCarthy consiglia Twenty Twenty o Storefront. Ho già eseguito questa canzone e ballo anche. Il mio progetto di prova era un vecchio tema che ho sventrato e trasformato in un tema a blocchi.

C’è un problema generale su cui continuo a tornare. È che gli autori del tema devono assolutamente lavorare da un file JSON.

Capisco il “perché” dietro l’utilizzo di JSON. È un formato universale che possiamo passare da JavaScript a PHP. Le API di terze parti possono capirlo.

Tuttavia, attualmente sono seduto su più di 900 righe di codice nel mio theme.json. Ho sentito da un paio di altri autori di temi che hanno svolto un lavoro approfondito con numeri simili. Mi aspetto che cresca solo.

“Numero di righe” non è necessariamente una metrica in cui un totale specifico è un punto di divisione tra “buono” o “cattivo”. Il problema è che i commenti non sono consentiti nei file JSON. Uno dei capisaldi dello sviluppo del suono è la documentazione del codice. Saltare sulla documentazione di poche dozzine di righe non è poi così male. Tuttavia, quando superi i 900, le cose possono sfuggire di mano.

Inoltre, a un certo punto, inizi a voler dividere i pezzi nei loro gruppi. Tutto questo codice richiede una migliore organizzazione.

La cosa che attualmente manca è un livello PHP da utilizzare per gli autori di temi. Ricorda, JSON è un formato universale. È facile convertire PHP in JSON e viceversa. La creazione di questo livello per gli autori di temi otterrebbe due cose:

1. Possono organizzare quelle che saranno probabilmente migliaia di righe di codice.
2. Sarà più facile passare al nuovo sistema.

Quest’ultimo punto è probabilmente il più saliente. PHP è stato il linguaggio dei temi da quando il tema è stato diffuso. Gli sviluppatori lo sanno e si sentono a proprio agio nell’usarlo, e WordPress dovrebbe incontrarli nel mezzo. Se stiamo colmando le lacune, questo è quello che deve essere riempito prima che vengano aggiunte ulteriori possibilità di configurazione e theme.json file palloncino in ingombranti colossi da 5.000 righe.