Deschideți ancheta pentru autorii de teme WordPress pe fișiere JSON și teme bloc

WordPress 5.8 a introdus un sistem de înscriere pentru teme pentru a configura setările blocurilor, stilurile, șabloanele și multe altele. Se realizează printr-un nou fișier theme.json pe care autorii îl pot pune la rădăcina folderelor cu teme. Anne McCarthy, liderul Programului de informare FSE, a anunțat mai devreme un sondaj pentru a obține feedback de la dezvoltatori cu privire la această funcție.

„Deoarece acest nou mecanism este un pas timpuriu către un sistem de stil cuprinzător pentru viitorul WordPress, este important să auzim de la toți cei care folosesc în prezent theme.json pentru a afla mai multe despre cum oamenii folosesc acest instrument și ce ar putea avea sens să includă. în Core în continuare”, a scris ea în anunț.

Sondajul este deschis tuturor autorilor de teme care au folosit theme.json , oferindu-le șansa de a oferi feedback din timp și de a ajuta la conducerea navei înainte.

Deoarece am lucrat intens cu acest sistem în ultimele luni, am avut câteva lucruri de spus. În plus, îmi place să particip la sondaje legate de WordPress. De asemenea, am decis că ar fi o oportunitate de a împărtăși unele dintre gândurile mele nefiltrate din perspectiva dezvoltării asupra stării actuale a theme.json .

Ceea ce urmează sunt răspunsurile mele la întrebările sondajului - ei bine, versiunea ordonată.

Notă: aceasta este o postare centrată pe dezvoltatori, care s-ar putea să nu atragă în mod universal toți cititorii noștri. Am încercat să explic unele lucruri într-o terminologie ușor de utilizat, dar pot fi necesare anumite cunoștințe prealabile despre dezvoltarea temei.

Experienţă

Prima întrebare a sondajului este destul de simplă. Vă întreabă care este experiența dvs. cu temele de bloc sau cu utilizarea theme.json . Oferă patru opțiuni (și o opțiune „altă”):

• Am construit și lansat teme de bloc.
• Am experimentat cu teme de bloc.
• Am explorat utilizarea theme.json cu o temă clasică.
• Am folosit o temă bloc, dar încă nu am construit una.

Am ales prima opțiune pentru că am construit deja două teme bloc pentru familie și prieteni. Acestea erau simple site-uri personale pe care le întrețin deja gratuit - sincer, trebuie să încep să încarc . De asemenea, lucrez la o temă pe care sper să o lansez public.

Cum a început și cum merge

A doua întrebare se referă la cum s-a început cu temele bloc și theme.json . Alegerile sunt între bifurcarea unei teme existente, folosirea temei goale sau pornirea de la zero.

Din nou, acesta este unul dintre acele lucruri în care am experimentat cu fiecare direcție, dar nu-mi amintesc exact punctul de plecare. Cea mai mare parte a muncii mele a provenit din apariția unei teme la care am lucrat ultima oară în 2019.

Plănuiesc să lansez asta ca o nouă temă gratuit la un moment dat. Aștept mai ales următoarele:

• Dezvoltarea blocului de navigare pentru a se stabili
• Blocul Post Autor să fie împărțit în blocuri mai mici
• Un set robust de blocuri legate de comentarii
• Blocați imaginea prezentată pentru a avea o opțiune de dimensiune

Cred că aș putea lansa în mod realist o versiune beta a temei mele, care poate fi utilizată pe propriul risc, dacă aceste elemente ar fi abordate.

Șabloane și părți de șabloane

Sondajul a întrebat ce șabloane și părțile de șabloane includ întotdeauna în temele lor bazate pe blocuri. A existat un câmp de comentarii în formă liberă - pași pe soapbox...

Am o relație de dragoste/ura cu șabloanele de bloc în acest moment. Natura statică a șabloanelor HTML îmi amintește de vremurile mai simple când dezvoltarea temei era mai puțin complicată. Totuși, acest lucru prezintă și o problemă într-un sistem dinamic.

Nu-mi amintesc ultima dată când am construit o temă tradițională, bazată pe PHP, cu mai mult de un șablon de nivel superior: index.php . Piesele dinamice au fost întotdeauna măruntaiele obiectului, care sunt părți șablon. Cu PHP, este ușor să setați o variabilă sau să utilizați un apel de funcție pentru a încărca contextual părțile șabloane necesare pentru orice pagină pe care vizitatorul o vede în prezent pe un site.

Sistemul de șabloane bloc nu funcționează așa. În esență, îi obligă pe dezvoltatori să încalce principiul Don’t Repeat Yourself (DRY).

De exemplu, dacă un designer ar dori să afișeze o altă parte a șablonului de antet pentru pagini și postări, ar trebui doar să creeze un șablon header-page.php sau header-post.php în temele tradiționale. Cu toate acestea, deoarece sistemul de șabloane bloc este diferit, acum trebuie să creeze două șabloane de nivel superior, single.html (post) și page.html , pentru a realiza același lucru.

Acesta este un „lucru rău”, deoarece autorii de teme trebuie să dubleze tot restul codului din fiecare dintre șabloanele de nivel superior. Nu există nicio modalitate de a încărca contextual diferite părți ale șablonului.

Pentru a răspunde la întrebare: folosesc aproape toate șabloanele posibile de nivel superior din necesitate.

Am răspuns, de asemenea, la a doua parte a întrebării și am enumerat părțile mele de șablon cele mai frecvent utilizate (defalcate pe ierarhii):

• Antet
• Conţinut
  – Bucla
  – Bara laterală
• Subsol

Părțile de șablon content-*.html și loop-*.html sunt cele cu cele mai multe variații.

Definirea culorilor

Următoarea secțiune a sondajului întreabă cum își definesc autorii temelor paletele de culori în theme.json . Credeți sau nu, numirea culorilor poate fi cel mai controversat subiect din lumea tematică din ultimii ani. Singurele două lucruri asupra cărora se convine în general sunt culorile „fundal” și „prim-plan”.

Morten Rand-Hendriksen a deschis un bilet în 2018 pentru standardizarea unei scheme de denumire a culorilor temei. Nu a fost prima discuție și nici ultima. Problema pe care trebuia s-o abordeze au fost problemele de culoare din sistem, care este modul în care temele își definesc paletele. Odată ce un utilizator folosește o culoare prestabilită, slug-ul este codificat în conținutul său. Treceți la o altă temă cu melci diferite, iar culorile vechi dispar și nu se schimbă automat la culorile noii teme.

Folosesc nume semantice care urmează ceva care seamănă mult cu sistemul de umbrire al cadrului CSS Tailwind. În loc de red-medium (descriptiv), aș folosi primary-500 (semantic), de exemplu. O abordare semantică ar permite autorilor de teme să definească un set de culori care sunt actualizate de fiecare dată când un utilizator schimbă teme.

Desigur, există și alte școli de gândire și chiar și toți cei care preferă denumirea semantică nu sunt de acord cu același sistem. Am descris abordarea mea mai detaliat într-un bilet GitHub mai recent și am un theme.json Gist pentru alții care ar dori să-l încerce.

Alte setări JSON ale temei

În afară de culori și tipografie, sondajul întreabă ce alte setări au folosit autorii temei. Acesta este un alt scenariu în care de obicei folosesc totul - dacă există o opțiune pentru el, o definesc.

Un caz de utilizare pentru care WordPress nu are în prezent o presetare este spațierea globală. Majoritatea autorilor de teme folosesc o singură valoare pentru majoritatea marginilor verticale (spații albe între blocuri și elemente). De asemenea, este adesea folosit pentru căptușeală verticală și orizontală implicită.

Nu sunt sigur dacă vreau o presetare, deoarece nu știu cum o va folosi WordPress. Este ceva pe care alții l-au cerut și este aproape omniprezent în utilizare. Definirea unui întreg sistem în jurul acestuia ar putea provoca dureri de cap pe drum, dar aș dori totuși să văd câteva discuții despre implementarea cel puțin a unei presetări standard de spațiere globală.

Setări și stiluri pe bloc

Această secțiune a sondajului a fost o întrebare da/nu, pur și simplu întrebând dacă autorii temei au inclus setări sau stiluri per bloc în fișierele lor theme.json . Desigur, am lăsat câteva comentarii suplimentare mai târziu în secțiunea opțională de comentarii.

Sunt mulțumit de sistem când vine vorba de setări, care le permite tematorilor să definească ce caracteristici sunt activate la nivel global sau pe bază de bloc. Cu toate acestea, nu sunt vândut să adaug stiluri prin theme.json .

Scrierea CSS în JSON, în esență despre ce vorbim, este greșită la atât de multe niveluri. În prezent, este limitat la doar câteva stiluri configurabile, așa că orice altceva dincolo de aceasta necesită oricum să vă scufundați într-un fișier CSS real. Acest lucru este problematic deoarece jumătate din codul CSS al temei este împărțit între theme.json și un fișier CSS separat. Din punct de vedere al dezvoltării, face baza de cod mai greu de întreținut.

Inițial, am pornit pe calea configurării stilurilor pe bloc și elemente din theme.json . Cu toate acestea, de atunci mi-am mutat stilul înapoi la fișierele CSS. Se simte mai natural și am avantajul suplimentar al tuturor instrumentelor cu care sunt obișnuit. În acest moment, nu-mi pot imagina un scenariu în care să mă întorc.

Pe lângă salvarea câțiva octeți de cod, nu am văzut multe beneficii pentru adăugarea de stiluri pentru majoritatea lucrurilor prin JSON. Poate că asta se va schimba în viitor și voi fi convertit. Deocamdată, mă ocup în primul rând de CSS.

Alte feedback: un strat PHP

Am mai spus-o, dar merită repetat. Avem nevoie de un strat PHP pentru acest sistem de configurare theme.json . În prezent, există un bilet deschis pentru a rezolva acest lucru.

Există două avantaje principale ale unui astfel de sistem. Având un API PHP pentru a pune împreună configurația se va simți mult mai natural pentru dezvoltatorii de teme tradiționale. Îl privesc ca pe o ramură de măslin, o dovadă de bună-credință că dezvoltatorii de bază/Gutenberg recunosc că mulți autori de teme vor avea mai ușor de accesat caracteristicile FSE printr-un limbaj de programare familiar.

Al doilea avantaj este că există un număr nespus de idei de pluginuri pentru a extinde stilurile globale, editarea site-urilor și multe altele dacă există o modalitate ușoară de a conecta sistemul de teme JSON și de a suprascrie lucrurile. Un cârlig simplu de filtru ar face acest lucru nedureros.