Nehajte znova graditi vsako WordPress stran

Povzetek

Večina agencij gradi vsako WordPress spletno stran iz prazne teme, tudi če bi jih skupna osnova prihranila tedne delovnega časa. Ta članek zagovarja, da vam theme.json, vzorci blokov in dinamični bloki omogočajo standardizacijo strukturne plasti, hkrati pa ohranjajo izrazit dizajn vsake stranke. Neposredno se ukvarja s petimi ugovori, ki ekipe zadržujejo pred spremembami: »imamo različne stranke«, »lastni bloki so dragi«, »urejevalnik je zmeden«, »izgubili bomo hooke in filtre« in »FSE ni pripravljen za produkcijo«. Vsak ugovor dobi praktičen protiargument in konkreten vzorec, ki ga lahko uvedete postopoma. Rezultat je ponovljiv postopek gradnje, ki še vedno spoštuje delo po meri tam, kjer mu je mesto. Opozorilo: niso obljubljeni gumbi za en klik.

Koliko vrstic kode si delijo spletne strani vaših strank? Ne vrstice o avtorskih pravicah – prave kode. Če je odgovor »komaj kakšno«, ste to bolečino že občutili: isti hero odsek zgrajen že devetič, ista struktura ekipne mreže skopirana iz projekta v projekt, iste preglede predprocesorskih nastavitev primerjate med pol ducata tem. Slišali ste tudi obrambo: »Vsaka stranka ima drugačne potrebe.« Res je. A zaključek, ki ga vsi potegnejo – da vsaka stran nujno potrebuje temelje po meri – je napačen. Ekosistem WordPress zdaj ponuja način, kako standardizirati strukturne dele brez standardizacije dizajna: theme.json za oblikovne žetone, vzorce blokov za ponavljajoče se postavitve in dinamične bloke za peščico funkcij, ki potrebujejo pravo strežniško logiko. Ta članek govori o ugovorih, zaradi katerih agencije tega koraka ne naredijo, in o tem, kaj dejansko deluje, ko jim nasprotujete.

Ugovor »ampak vsaka stranka je drugačna«

Temeljno načelo: standardizirajte temelje, ne površine. Razlog, da strukturo ohranjate v skupni knjižnici, je prav ta, da vizualna plast ostane svobodna. Datoteka theme.json ni dizajn – je niz oblikovnih žetonov. Barve, razmiki in tipografija so vrednosti, ne oznake. To je ključni premik: oznake lahko delite, medtem ko theme.json za posamezno stran poskrbi, da je spletna stran videti povsem drugače za drugo znamko.

Vzemite dve stranki: odvetniško pisarno in prodajalca opreme za na prostem. Njun oblikovalski jezik je povsem različen. A oba potrebujeta hero odsek, mrežo priporočil in pas za poziv k dejanju. Namesto da bi oznake gradili znova za vsako stran, vzdržujte tri vzorce blokov in naj theme.json vsake stranke določa barve, pisave in razmike. Struktura ostane enaka; oblikovni žetoni jo spremenijo iz ene znamke v drugo. Ko trgovec prihodnjo pomlad spremeni barvno paleto, uredite eno datoteko na njihovi strani – ne oznak v šestih predlogah.

V praksi to pomeni, da vaša ekipa ustvarja vzorce kot kodo, jih registrira v skupnem vtičniku in pusti, da theme.json na vsaki strani stranke poskrbi za videz. Imena razredov v vzorcih postanejo vaša arhitektura; vrednosti postanejo spremenljivke. Lahko greste še dlje in theme.json razširite s posebnimi nastavitvami za tipe objav ali izhod vtičnikov, čeprav na neki točki gradite vmesnik za konfiguracijo namesto spletne strani – past, ki je obravnavana v našem pregledu razširitve theme.json. Skupno plast ohranjajte vitko: vsebovati mora samo tisto, kar se ponavlja pri različnih strankah. Ko se enkrat ujamete, da dodajate nastavitev »za vsak slučaj, da jo bo nekdo nekoč želel«, ste ustvarili abstrakcijo, ki bo za vzdrževanje stala več, kot prihrani.

Ko pripravljate novo stranko, naj prvih trideset minut izgleda tako: klonirajte skupni vtičnik z vzorci, ustvarite nov theme.json s paleto in velikostjo pisav stranke ter registrirajte njen logotip in nogo. To ni gradnja po meri; to je naloga konfiguracije. Preostalo delo, specifično za stranko, gre v vsebino, strukturo in vse dejansko posebne funkcije. To je razlika med gradnjo vsake hiše iz nič in imeti nabor montažnih talnih načrtov, ki jih lahko prebarvate in na novo opremite. Analogija je ohlapna, a načelo drži: več ko prenesete v vrednosti theme.json, manj se morate dotikati oznak.

Ena najpreprostejših zmag je, da si dejansko ogledate, kako delujejo vzorci blokov. Vzorec je le zbirka blokov z vnaprej določeno vsebino in slogom. Vsako konfiguracijo bloka lahko shranite kot vzorec, nato pa jo stranka vstavi brez znanja o tem, kako je zgrajena. To pomeni, da vzorec postane »vstopna točka« za tehnično nezahtevne uporabnike. Ko vaša ekipa vzdržuje osnovni vzorec v kodi, stranka dobi dosledno knjižnico brez dotikanja ene same PHP oznake.

Zdaj pa opozorilo, h kateremu se vedno vračam: ne pretiravajte s centralizacijo. Theme.json z nastavitvijo za vsako zamislivo nianso je močvirje za vzdrževanje. Skupni vzorci morajo biti odločni, ne vsemogočni. Če stranka potrebuje radikalno drugačno postavitev – recimo domačo stran revije z veliko osrednjo mrežo – se morda ne bo ujemala z vašo standardno knjižnico vzorcev. To je v redu. Standardizacija pomeni, da zmagujete pri 80 % projektov, ki so si podobni, ne pa da vsako stran silite v isti kalup.

Ugovor »lastni bloki presežejo proračun«

Tu je protinačelo, ki se sliši dolgočasno, a prihrani denar: večina stvari, za katere mislite, da potrebujejo lastni blok, jih ne. Osnovni bloki in vzorec lahko pokrijejo veliko večino postavitev. Lastni blok je zadnja možnost, ne prvi namen.

Klasičen primer je ekipna mreža. Če gre za enkraten primer, uporabite osnovna bloka »stolpci« in »skupina« ter pustite stranki, da ročno doda avatar. Če tri stranke zahtevajo isto mrežo z isto strukturo »družbena omrežja pod imenom«, je to zdaj kandidat za vzorec bloka. Ko se temu vzorcu začnejo dodajati nove možnosti – učinki pri prehodu, razvrščanje, zvezdice za ocene – vzorec postane neobvladljiva mešanica in takrat je čas za pisanje lastnega bloka. Napaka, ki škodi proračunu, je skok naravnost k lastnemu bloku ob prvi zahtevi.

Bolj zahrbten scenarij: stranka zahteva »vrteč prikaz študij primerov«. Prvi nagon je pomisliti: »Potrebujem blok za vrtiljak.« A ali res potrebujejo vrtiljak? Morda potrebujejo vodoravno drsečo skupino objav, kar lahko osnovni bloki obdelajo z blokom »skupina« in nekaj CSS. Ali pa potrebujejo dinamičen seznam nedavnih študij primerov, kar je dinamični blok, ki poizveduje po CPT. Vprašanje ni »kakšno funkcijo želi stranka?«, ampak »od kakšnih podatkov je odvisna?« Če so podatki statični in jih stranka lahko ureja, zadostuje vzorec. Če podatki prihajajo iz poizvedbe baze podatkov, je dinamični blok upravičen. Če se morajo podatki posodabljati v realnem času iz API-ja, morda gledate na integracijo REST API – to seže v drugačno vrsto gradnje.

Ko gradite blok, je block.json vaš prijatelj. Je enotni vir resnice za atribute, skripte in sloge, zaradi česar je blok prenosljiv med projekti. Prav tako čisto omogoča deklaracijo odvisnosti in prevodov, kar je bistveno, ko razdeljujete knjižnico med mnoga spletišča strank. Za vsebino, ki je odvisna od živih podatkov, se dinamični blok izriše na strežniku, tako da ni treba prenašati svežnja JavaScript ob vsakem ogledu strani. In če se vaš blok razvija, lahko deprecacije obravnavate elegantno, da se obstoječa vsebina ne pokvari – naš vodnik o deprecaciji blokov vas popelje skozi točen vzorec.

Preden karkoli zgradite, preženite odločitev skozi to preglednico:

Pristop	Najboljše za	Izogibajte se, ko
Osnovni blok	Enkratna vsebina, preproste strani	Je postavitev ponavljajoča se pri mnogih strankah in potrebuje bogate možnosti
Vzorec bloka	Ponavljajoče se postavitve brez logike	Postavitev potrebuje pogoje, dinamične podatke ali zapletene interakcije
Lastni blok	Ponavljajoče se vedenje, odvisno od podatkov ali zelo specifično	Je edini razlog enkraten odsek, ki se lahko obravnava z razredom

Že od prvega dne boste želeli razmišljati tudi o poimenovanju blokov. Ime bloka je bistveno pogodba z vašo vsebino. Če ga poimenujete wagent/team-grid in ga pozneje preimenujete v wagent/team-carousel, boste pokvarili obstoječo vsebino, razen če ne zagotovite poti za deprecacijo. Izberite generična imena, osnovana na namenu, ki ne bodo postala zavajajoča, ko se blok razvija. To je različica discipline poimenovanja, ki smo se je vsi naučili iz predpon vtičnikov, in enako velja za imena blokov.

Kontrarna misel, ki jo lahko povem, je najbolj uporabna: lastni blok, ki ga zgradite, ker je stranka zahtevala »samo en element«, je skoraj vedno napaka. Vljudno recite ne, oddajte osnovni blok z razredom in prihranite ure. Stranka vas bo bolj spoštovala – in v proračunu za vzdrževanje bo manjša postavka.

Ugovor »stranke bodo pokvarile urejevalnik«

Ta ugovor je napol pravilen. Blokovni urejevalnik sam po sebi ni problem; problem je, da strankam dajemo preveč vrvi. theme.json lahko zaklene, kaj je mogoče urejati: onemogoči urejevalnik predlog, omeji dovoljene bloke in nastavi privzete sloge, da napačno postavljen stolpec povzroči manj škode. Nekatere stranke bodo kljub vsemu kaj pokvarile, a stran lahko v enem kliku povrnete na shranjen vzorec – nekaj, česar klasični urejevalnik ni mogel ponuditi.

Naj narišem scenarij. Stranka pokliče in reče: »Premaknil sem odsek in zdaj je cela stran videti narobe.« S klasično temo bi se prijavili, preverili CSS in verjetno porabili uro za popravilo postavitve. S postavitvijo blokov lahko odprete stran, izberete območje vsebine in ga ponastavite na shranjen vzorec. Vzorec je izhodišče; strankine spremembe so prekrivni sloj. Ko gre prekrivni sloj narobe, ga odstranite. To ni samo lepši delovni tok; je bistveno bolj prizanesljiv urejevalnik.

Zdaj pa niansa: večina strank ne želi urejati veliko. Želijo spremeniti besedilo, zamenjati fotografije in morda preurediti odsek. Vzorec bloka vam to omogoči brez razkrivanja celotne strukture spletišča. V tem smislu urejevalnik ni igrača; je iskalo. Vaša naloga je umeriti, kaj stranke lahko vidijo. To pomeni, da lahko onemogočite nastavitve »Predloge«, omejite vstavljalnik blokov na izbran seznam in celo vnaprej napolnite prazne vzorce z ogrodjem. Urejevalnik postane obrazec za vnos vsebine in ne platno za oblikovanje spleta.

Na področju dostopnosti so upravljanje fokusa in podpora za tipkovnico v blokovnem urejevalniku na splošno boljši kot polja predlog v klasičnem urejevalniku. A še vedno morate zagotoviti, da imajo vzorci pravilno hierarhijo naslovov in dostopna imena. Ker je vzorec skupen med strankami, te težave odpravite le enkrat, kar je še ena skrita prednost standardizacije.

Resnično težko je notranjega značaja. Za vašo ekipo učenje prototipiranja z bloki zahteva odvajanje od navade »naredi v PHP«. To je resničen strošek, a je enkratni strošek na osebo. To ni razlog, da se izognete pristopu; je razlog, da začnete z eno knjižnico vzorcev in eno prizanesljivo stranko, preden stvar razširite povsod. Ne dovolite, da refren »moje stranke ne znajo uporabljati blokov« prikrije dejstvo, da še niste konfigurirali postavitve blokov, da bi jim šla naproti.

Ugovor »mi že imamo hooke in filtre«

Načelo tu je: ne zavržete hookov; dodajate plast na vrh. Bloki so meja predstavitve; hooki so še vedno način, kako vstavljate logiko. Povratni klic za izris dinamičnega bloka teče v PHP, kar pomeni, da lahko kličete iste funkcije in uporabljate iste filtre, ki jim že zaupate.

Predstavljajte si vtičnik, ki prek filtra doda polje »izpostavljen izdelek« k vsaki objavi. Z dinamičnim blokom lahko vključite strežniško izrisan blok, ki zažene ta filter in natisne izhod znotraj ovojnice bloka. Stranka vstavi blok; obstoječa PHP logika opravi glavno delo. Nič ni zavrženo. Za še bolj konkreten primer si oglejte lastni blok, ki navaja nedavne projektne objave. V njegovem povratnem klicu za izris pokličete get_posts(), nato v zanki uporabite the_title() in the_permalink() – iste predloge, ki jih uporabljate že leta.

Tu je tudi prostor, kjer moramo biti iskreni o tem, kaj se ne prevede. Nekatere pametne stare teme uporabljajo template-parts z zapletenimi pogoji, ki sprejemajo argumente glede na kontekst strani. Poustvarjanje tega kot bloka je lahko zamudno. A vam ni treba vsega poustvariti naenkrat. Postopna pot je, da PHP logiko ohranite, jo zavijete v dinamični blok in oznake premaknete v predlogo bloka. Pogosto boste ugotovili, da vaši obstoječi vzorci filtrov lahko obdelajo nov izhod. In če je logika tesno povezana s hierarhijo predlog (npr. »na rezultatih iskanja pokaži to drugače«), lahko za te posebne poglede še vedno uporabite klasično predlogo, medtem ko za običajne strani uporabljate bloke.

REST API odpira tudi druga vrata: zgradite lahko bloke, ki črpajo podatke iz drugih WordPress spletišč ali storitev tretjih oseb. Dinamični blok lahko pokliče wp_remote_get() za pridobivanje JSON in ga izriše na sprednji strani. To je zmogljiv vzorec za agencijske gradnje, kjer stranke želijo prikazati družbene vire, sezname izdelkov ali notranje podatke brez upravljanja ločene integracije. Slabost sta predpomnjenje in obravnava napak – če je oddaljeni API počasen, je počasna vaša stran. API-jevskih blokov ne postavljajte v kritično vsebino nad pregibom ali pa uporabite izris na odjemalčevi strani z ustreznim stanjem nalaganja.

Akcije in filtri še vedno tečejo okoli shranjevanja in izrisa; arhitektura hookov ne izgine, ko sprejmete bloke, le premakne se v nov kontekst. Če morate osvežiti svoje razumevanje, kje se akcije in filtri srečajo s tem novim svetom blokov, je naš poglobljeni pregled hookov uporaben osvežitveni tečaj.

Ugovor »FSE ni pripravljen za produkcijo«

Pošteno, a vprašajte, kaj »tvegano« dejansko pomeni. Full Site Editing je šel skozi več izdaj in theme.json se je ustalil v stabilni shemi. Tveganje ni, da bi urejevalnik »kar naenkrat odpovedal« – tveganje je, da se vaša koda po meri zanaša na stare PHP predloge, ki se nerodno sobivajo s predlogami blokov. Poleg tega nekateri vtičniki tretjih oseb še vedno predpostavljajo klasični urejevalnik ali prilagajalnik. To je odločitev o združljivosti, ne razlog, da zavržete celoten model.

Uporaben način razmišljanja: preprosta, ponavljajoča se spletišča z vsebino, napisano v blokih, so najmanj tvegana. Visoko tvegane stranke so tiste z globoko prilagojenimi klasičnimi temami ali lastniškimi vtičniki, ki izrisujejo svoj sprednji del. To je legitimni razlog, da pri tisti majhni niši ostanete pri klasičnih temah. Napaka je pretvarjanje, da je »pripravljen za produkcijo« en sam stikalo, ki je bodisi vklopljeno bodisi izklopljeno.

Preden stranki predlagate blokovno temo, preverite kratek seznam:

• Ali ima stranka zelo prilagojeno temo, ki bi zahtevala selitev?
• Ali vtičniki, ki jih mora imeti, podpirajo urejevalnik spletišča in REST API?
• Ali okolje gostovanja omogoča dostop do datotek, ki ga blokovna tema pričakuje?
• Ali ste si vzeli čas za oblikovanje vzorcev, ne le za registracijo blokov?
• Ali bo strankin tim prenesel spremembe v urejevalniku ali potrebuje zaklenjeno predlogo?

Če je odgovor na katero koli vprašanje ne, prilagodite obseg ali uporabite hibridni pristop. To ni kompromis; to je inženirska presoja. In če gradite hibrid, se spomnite zgodbe o hookih in filtrih zgoraj – staro logiko lahko še vedno zavijete v dinamične bloke, medtem ko theme.json poskrbi za globalni videz.

Različica vašega theme.json ni le teoretična skrb. Videl sem, da se je knjižnica lastnih blokov agencije pokvarila, ko je stranka posodobila WordPress in se je style datoteka bloka, registrirana z wp_register_style() pod spremenjenim priročnikom (handle), porušila. Popravek je bil enostaven, a panika je bila resnična. Preprost postopek testiranja – posodobitev na preskusni kopiji spletišča, klik skozi ključne strani, nato izdaja – reši večino teh presenečenj.

Ugovor, ki si ga niste postavili

Tukaj je meta-ugovor, ki agencijam preprečuje standardizacijo: »To je velika sprememba in med delom za stranke ni časa zanjo.« To drži – zato je ne delajte med delom za stranke. Izberite notranji projekt ali majhno stranko in zgradite eno knjižnico vzorcev. Uporabite theme.json kot sistem oblikovnih žetonov. Dodajte lastni blok le, ko je upravičeno. Kjer pomaga, zavijte stare hooke. Ponavljajte.

Tukaj je približnih prvih 30 dni:

1. Preglejte svojih zadnjih pet gradenj za stranke in naredite seznam desetih najbolj ponavljajočih se delov postavitve.
2. Te dele spremenite v vzorce blokov z majhnim naborom CSS razredov.
3. Zgradite skupni vtičnik (ali mu-vtičnik), ki te vzorce registrira. Če še niste razmišljali o organizaciji vtičnikov, najprej preletite ta vodnik o gradnji robustnih vtičnikov.
4. Ustvarite en theme.json, ki ustreza vašemu izhodiščnemu dizajnu; pri zagonu projektov dodajte vrednosti za posamezne stranke.
5. Izberite en majhen notranji projekt ali prijazno stranko in ga preselite na ta sklop.
6. Zapišite eno zgodbo o uspehu stranke, ki je uredila svojo domačo stran, ne da bi vas poklicala.

Na koncu tega eksperimenta ne boste imeli značke »bloki na prvem mestu« za na steno. Imeli boste ekipo, ki lahko zažene novo spletno stran stranke iz skupne osnove brez opravičevanja glede rokov. Prav tako boste v boljšem položaju, da rečete ne stranki, ki zahteva 42. lastni blok – ker natančno veste, kaj zmorejo osnovni bloki, ali ker lahko pokažete, zakaj bi bil dinamični blok resnično hitrejši.

Boste še vedno gradili nekatera spletišča po meri? Da. Nekatere stranke bodo vedno potrebovale predlogo po meri, stran po meri ali lastniško integracijo, ki se je ne splača siliti v skupni model. Cilj ni odpraviti delo po meri; cilj je, da postane izjema in ne privzeto.

Ponovljivost prihaja iz dolgočasnih delov: trdne sheme theme.json, jasne knjižnice vzorcev in discipline, da skupna plast ostane vitka. To ni bleščeča različica, ki jo slišite na spletnih seminarjih. To je tista, ki premaga ponedeljkove jutranje tegobe s prazno temo.