Lõpeta iga WordPressi saidi uuesti ehitamine

Kokkuvõte

Enamik agentuure ehitab iga WordPressi saidi tühja teema pealt, isegi kui ühine alus säästaks ajakavast nädalaid. See artikkel väidab, et theme.json, plokimustrid ja dünaamilised plokid võimaldavad standardiseerida struktuurikihi, säilitades samal ajal iga kliendi eripärase disaini. See käsitleb otseselt viit vastuväidet, mis hoiavad meeskondi muutustest eemal: „meil on erinevad kliendid", „kohandatud plokid on kallid", „redaktor on segane", „me kaotame oma hookid ja filtrid" ning „FSE ei ole tootmisküps". Iga vastuväide saab praktilise vastuargumendi ja konkreetse mustri, mida saate järk-järgult kasutusele võtta. Tulemuseks on korratav ehitusprotsess, mis austab siiski kohandatud tööd seal, kus see vajalik on. Hoiatus: ühe klõpsuga lähtestusnuppe ei lubata.

Kui paljudel teie kliendisaitidel on ühine isegi üks koodirida? Mitte autoriõiguse rida — tegelik kood. Kui vastus on „peaaegu ühelgi", olete seda valu juba tundnud: sama hero-sektsioon ehitatud üheksandat korda, sama meeskonnagridi märgistus kopeeritud ühelt projektilt teisele, samad eeltöötluse nipikoodid viidatud poole tosina teema vahel. Olete kuulnud ka kaitset: „Igal kliendil on erinevad vajadused." Tõsi. Kuid järeldus, mille kõik teevad — et iga sait vajab ainulaadset alust — on väär. WordPressi ökosüsteem pakub nüüd viisi struktuuriosade standardiseerimiseks ilma disaini standardiseerimata: theme.json disainitokenite jaoks, plokimustrid korduvate paigutuste jaoks ja dünaamilised plokid nende funktsioonide jaoks, mis vajavad päris serveripoolset loogikat. See artikkel räägib vastuväidetest, mis hoiavad agentuure sellest sammust eemal, ja sellest, mis tegelikult toimib, kui neile vastu vaidlete.

Vastuväide „aga iga klient on erinev"

Aluspõhimõte: standardiseerige alus, mitte pind. Põhjus, miks hoida struktuuri ühises teegis, on täpselt see, et visuaalne kiht jääks vabaks. theme.json-fail ei ole disain — see on hulk disainitokeneid. Värvid, ruum ja tüpograafia on väärtused, mitte märgistus. See on oluline nihe: saate jagada märgistust, samal ajal kui saidipõhine theme.json muudab saidi teise kaubamärgi jaoks täiesti erinevaks.

Võtke kaks klienti: advokaadibüroo ja õuespordi jaemüüja. Nende disainikeeled on kilomeetrite kaugusel. Kuid mõlemad vajavad hero-sektsiooni, soovituste gridi ja tegevuskutse riba. Selle asemel, et iga kord märgistust uuesti ehitada, hooldage kolme plokimustrit ja laske iga kliendi theme.json-l määrata värvid, fondid ja ruum. Struktuur jääb identseks; disainitokenid muudavad selle ühest brändist teiseks. Kui jaemüüja järgmisel kevadel oma värvipaletti muudab, redigeerite ühte faili nende saidil — mitte märgistust kuues mallis.

Praktiliselt tähendab see, et teie meeskond loob mustreid koodina, registreerib need ühises pluginis ja laseb iga kliendisaidi theme.json-l tegeleda värvidega. Mustri klassinimed saavad teie arhitektuuriks; väärtused muutuvad muutujateks. Võite minna kaugemale ja laiendada theme.json-i, et lisada kohandatud seaded postitüüpidele või pluginaväljunditele, kuigi teatud hetkel ehitate konfiguratsiooniliidest, mitte saiti — lõks, mida käsitleme meie theme.json-i laiendamise käsitluses. Hoidke jagatud kiht kõhn: see peaks sisaldama ainult seda, mis klientide lõikes kordub. Hetkel, kui avastate end lisamas seadet „juhuks kui keegi kunagi seda tahab", olete loonud abstraktsiooni, mida on kulukam hooldada kui see säästab.

Uue kliendi seadistamisel peaksid esimesed kolmkümmend minutit olema: kloonige jagatud mustrite plugin, looge uus theme.json kliendi paleti ja fondiskaalaga ning registreerige nende logo ja jalus. See ei ole kohandatud ehitus; see on konfiguratsiooniülesanne. Ülejäänud kliendispetsiifiline töö läheb sisusse, struktuuri ja kõigisse tõeliselt ainulaadsetesse funktsioonidesse. See on erinevus selle vahel, kui ehitate iga maja nullist, ja selle vahel, kui teil on komplekt kokkupandavaid põrandaplaane, mida saate üle värvida ja uue tapeediga katta. Analoogia on vaba, kuid põhimõte peab paika: mida rohkem te theme.json-i väärtusi kasutate, seda vähem peate märgistust puudutama.

Üks lihtsamaid võite on vaadata, kuidas plokimustrid tegelikult töötavad. Muster on lihtsalt kogum plokke eelnevalt määratletud sisu ja kujundusega. Saate salvestada iga plokiseadistuse mustrina ja siis saab klient selle sisestada ilma teadmisteta, kuidas see on ehitatud. See tähendab, et mustrist saab „sisenemispunkt" mittetehnilistele kasutajatele. Kui teie meeskond hooldab alusmustrit koodis, saab klient ühtse teegi ilma ühtegi PHP-silti puudutamata.

Nüüd hoiatus, mille juurde ma pidevalt tagasi pöördun: ärge üle tsentraliseerige. theme.json, millel on seade iga mõeldava nüansi jaoks, on hooldussoo. Jagatud mustrid peaksid olema kindlameelsed, mitte kõikvõimsad. Kui klient vajab radikaalselt erinevat paigutust — näiteks ajakirja avalehte suure esiletõstetud gridiga — ei pruugi see teie standardsesse mustriteeki mahtuda. See on okei. Standardiseerimine tähendab, et võidate sarnaste projektide 80% puhul, mitte et surute iga saidi samasse vormi.

Vastuväide „kohandatud plokid panevad eelarve lõhki"

Siin on vastupõhimõte, mis kõlab igavalt, kuid säästab raha: enamik asju, mille arvate vajavat kohandatud plokki, tegelikult ei vaja. Tuumplokid koos mustriga katavad valdava enamuse paigutustest. Kohandatud plokk on viimane abinõu, mitte esimene kavatsus.

Klassikaline näide on meeskonnagrid. Kui see on ühekordne, kasutage tuumplokke „veerud" ja „grupp" ning laske kliendil avatari käsitsi lisada. Kui kolm klienti küsivad sama gridi sama „sotsiaallinkidega nime all" struktuuriga, on teil nüüd kandidaat plokimustri jaoks. Kui see muster hakkab koguma uusi valikuid — hõljumisefektid, sortimine, reitingutärnid — muutub muster hallatamatuks segakogumiks ja siis on aeg kirjutada kohandatud plokk. Eelarvet kahjustav viga on hüpata kohe esimesel soovil kohandatud ploki juurde.

Veel salakavalam stsenaarium: klient küsib „juhtumiuuringute karusselli". Esimene instinkt on mõelda: „Ma vajan karusselliplokki." Aga kas nad vajavad karusselli? Võib-olla vajavad nad horisontaalselt keritavat postituste gruppi, mida tuumplokid saavad hallata „grupi" ploki ja veidi CSS-iga. Või vajavad nad dünaamilist hiljutiste juhtumiuuringute loendit, mis on dünaamiline plokk, mis pärib CPT-st. Küsimus ei ole „millist funktsiooni klient soovib?", vaid „millistest andmetest see sõltub?" Kui andmed on staatilised ja kliendi poolt redigeeritavad, piisab mustrist. Kui andmed tulevad andmebaasipäringust, on dünaamiline plokk õigustatud. Kui andmed peavad reaalajas uuenema API-st, võite vaadata REST API integratsiooni hoopis — see läheb teist tüüpi ehitusse.

Kui te lõpuks ploki ehitate, on block.json teie sõber. See on ainus tõeallikas atribuutide, skriptide ja stiilide jaoks, mis muudab ploki teisaldatavaks projektide vahel. See võimaldab ka deklareerida sõltuvusi ja tõlkeid puhtalt, mis on hädavajalik, kui levitate teeki paljude kliendisaitide vahel. Sisu jaoks, mis sõltub reaalajas andmetest, renderdatakse dünaamiline plokk serveris, nii et te ei pea igal lehevaatamisel JavaScripti kimpu saatma. Ja kui teie plokk areneb, saate vananenud versioone elegantselt käsitleda, et olemasolev sisu ei puruneks — meie juhend ploki vananemise kohta näitab täpset mustrit.

Enne kui midagi ehitad, vii otsus läbi selle tabeli:

Lähenemine	Parim	Vältige, kui
Tuumplokk	Ühekordne sisu, lihtsad lehed	Paigutus kordub paljude klientide lõikes ja vajab rikkalikke valikuid
Plokimuster	Korduvad paigutused ilma loogikata	Paigutus vajab tingimuslikke harusid, dünaamilisi andmeid või keerukaid interaktsioone
Kohandatud plokk	Korduv, andmepõhine või väga spetsiifiline käitumine	Ainus põhjus on ühekordne sektsioon, mida saab hallata klassiga

Samuti peaksite mõtlema ploki nimetamisele juba esimesest päevast. Ploki nimi on sisuliselt leping teie sisuga. Kui nimetate selle wagent/team-grid ja hiljem nimetate ümber wagent/team-carousel, rikute olemasolevat sisu, kui te ei paku üleminekuteed. Valige üldised, eesmärgipõhised nimed, mis ei muutu valeks reklaamiks, kui plokk areneb. See on nimetamisdistsipliini variant, mida oleme kõik õppinud pluginaprefiksite juures, ja see kehtib sama palju ka plokinimede puhul.

Vastandlik seisukoht, mida ma saan kõige kasulikumana öelda, on see: kohandatud plokk, mille ehitate, sest klient küsis „ainult ühte tükki", on peaaegu alati viga. Öelge viisakalt ei, saatke tuumplokk klassiga ja pange tunnid panka. Saate kliendilt rohkem lugupidamist — ja väiksema rea hoolduseelarves.

Vastuväide „kliendid lõhuvad redaktori"

See vastuväide on poolenisti õige. Plokiredaktor ise ei ole probleem; probleem on anda klientidele liiga palju köit. theme.json saab lukustada seda, mis on redigeeritav: keelata vormiredaktori, piirata lubatud plokke ja määrata vaikimisi stiilid, nii et valesti paigutatud veerg teeb vähem kahju. Mõned kliendid suudavad asju siiski lõhkuda, kuid saate lehe ühe klõpsuga taastada salvestatud mustriks — midagi, mida klassikaline redaktor ei pakkunud.

Las ma maalin stsenaariumi. Klient helistab ja ütleb: „Ma liigutasin sektsiooni ja nüüd näeb terve leht vale välja." Klassikalise teemaga logiksite sisse, uuriksite CSS-i ja kulutaksite tõenäoliselt tunni paigutuse parandamisele. Plokiseadistusega saate avada lehe, valida sisuala ja lähtestada selle salvestatud mustriks. Muster on lähtetasand; kliendi muudatused on pealiskihi. Kui pealiskiht läheb valesti, eemaldate selle. See pole lihtsalt parem töövoog; see on põhimõtteliselt andestavam redaktor.

Nüüd nüanss: enamik kliente ei taha üldse palju redigeerida. Nad tahavad muuta teksti, vahetada fotosid ja võib-olla ümber korraldada sektsiooni. Plokimuster annab teile täpselt selle, ilma et kogu saidi struktuur paljastataks. Selles mõttes ei ole redaktor mänguasi; see on pildiotsija. Teie töö on kalibreerida, mida kliendid näevad. See tähendab, et võite keelata „Mallide" seaded, piirata plokkide sisestaja kureeritud loendiga ja isegi eeltäita tühjad mustrid kohatäitja sisuga. Redaktorist saab sisestusvorm, mitte veebidisaini lõuend.

Ligipääsetavuse poolelt on plokiredaktori fookusehaldus ja klaviatuuritugi üldiselt paremad kui klassikalise redaktori malliväljad. Kuid peate siiski tagama, et mustritel on korralik pealkirjade hierarhia ja ligipääsetavad nimed. Kuna muster on jagatud klientide vahel, parandate need probleemid vaid korra — see on veel üks standardiseerimise varjatud võit.

Tõeliselt raske osa on sisemine. Teie meeskonna jaoks nõuab plokkidega prototüüpimise õppimine „tee see PHP-s" harjumuse mahavõtmist. See on reaalne kulu, kuid see on ühekordne kulu inimese kohta. See ei ole põhjus lähenemisviisi vältimiseks; see on põhjus alustada ühe mustriteegiga ja ühe andestava kliendiga enne kõikjal juurutamist. Ärge laske fraasil „mu kliendid ei oska plokke kasutada" varjata tõsiasja, et te pole veel plokiseadistust konfigureerinud, et nendega poolel teel kohtuda.

Vastuväide „meil on juba hookid ja filtrid"

Põhimõte on: te ei viska hooke minema; te lisate kihi peale. Plokid on esitluspiir; hookid on ikka see, kuidas loogikat sisestate. Dünaamilise ploki renderdamise tagasihelistus töötab PHP-s, mis tähendab, et saate kutsuda samu funktsioone ja rakendada samu filtreid, mida juba usaldate.

Kujutage ette pluginat, mis laseb mis tahes postitusele filtrit kasutades lisada „esiletõstetud toote" välja. Dünaamilise plokiga saate kaasata serveripoolselt renderdatud ploki, mis käivitab selle filtri ja prindib väljundi ploki sees. Klient sisestab ploki; olemasolev PHP-loogika teeb raske töö. Midagi ei visata minema. Veelgi konkreetsema näite jaoks kaaluge kohandatud plokki, mis loetleb hiljutisi projektipostitusi. Selle renderdamise tagasihelistuses kutsute get_posts(), seejärel tsükli jooksul rakendate the_title() ja the_permalink() — samu mallikaubamärke, mida olete aastaid kasutanud.

See on ka koht, kus olla aus selle suhtes, mis ei tõlgi hästi. Mõned nutikad vanad teemad kasutavad template-parts keeruliste tingimuslike plokkidega, mis võtavad argumendid lehe konteksti põhjal. Selle plokina uuesti loomine võib olla segadust tekitav. Kuid te ei pea seda kõike korraga uuesti looma. Järkjärguline tee on jätta PHP-loogika alles, mähkida see dünaamilisse plokki ja liigutada märgistus plokimalli. Sageli leiate, et teie olemasolevad filtristruktuurid suudavad uut väljundit hallata. Ja kui loogika on tihedalt seotud mallihierarhiaga (nt „otsingutulemustes näita seda teisiti"), saate nende konkreetsete vaadete jaoks kasutada klassikalist malli, kasutades samal ajal tavaliste lehtede jaoks plokke.

REST API avab ka teise ukse: saate ehitada plokke, mis tõmbavad andmeid teistelt WordPressi saitidelt või kolmanda osapoole teenustelt. Dünaamiline plokk saab kutsuda wp_remote_get(), et laadida JSON-i ja renderdada see esiküljel. See on võimas muster agentuuritööde jaoks, kus kliendid soovivad näidata sotsiaalmeedia vooge, tooteloendeid või sisemisi andmeid ilma eraldi integratsiooni haldamata. Kompromiss on vahemälu (caching) ja veahaldus — kui kaug-API on aeglane, on teie leht aeglane. Hoidke API-põhised plokid eemal kriitilisest above-the-fold sisust või kasutage kliendipoolset renderdamist korraliku laadimisolekuga.

Toimingud ja filtrid töötavad endiselt salvestamise ja renderdamise ümber; hook-arhitektuur ei kao plokkide kasutuselevõtuga, see lihtsalt liigub uude konteksti. Kui vajate värskendust, kus toimingud ja filtrid selles uues plokimaailmas kokku puutuvad, on meie hookide süvaanalüüs kasulik meeldetuletus.

Vastuväide „FSE ei ole tootmisvalmis"

Õiglane, kuid küsige, mida „riskantne" tegelikult tähendab. Täissaidi redigeerimine (Full Site Editing, FSE) on läbinud mitu väljalaset ja theme.json on stabiliseerunud mõistlikuks skeemiks. Risk ei ole see, et redaktor „äkitselt katki läheb" — risk on see, et teie meeskonna kohandatud kood võib tugineda vana stiili PHP-mallidele, mis eksisteerivad plokimallidega kohmakalt koos. Samuti eeldavad mõned kolmanda osapoole pluginad ikka klassikalist redaktorit või kohandajat. See on ühilduvuse otsus, mitte põhjus kogu mudel minema visata.

Kasulik mõtteviis: lihtsad, korratavad saidid plokkidesse kirjutatud sisuga on kõige vähem riskantsed. Kõrge riskiga kliendid on need, kellel on sügavalt kohandatud klassikalised teemad või portitavate pluginatega, mis renderdavad oma esikülge. See on õigustatud põhjus jääda klassikaliste teemade juurde selle väikese niši jaoks. Viga on teeselda, et „tootmisvalmis" on üks lüliti, mis on kas sisse või välja lülitatud.

Enne kui pakute kliendile plokiteemat, käige kiirkontroll läbi:

• Kas kliendil on tugevalt kohandatud teema, mis nõuaks üleminekut?
• Kas hädavajalikud pluginad toetavad saidiredaktorit ja REST API-t?
• Kas hostikeskkond võimaldab failijuurdepääsu, mida plokiteema eeldab?
• Kas olete varunud aega mustrite kujundamiseks, mitte ainult plokkide registreerimiseks?
• Kas kliendi meeskond talub redaktori muudatusi või vajavad nad lukustatud malli?

Kui mõnele küsimusele on vastus ei, kohandage ulatust või kasutage hübriidlähenemist. See ei ole kompromiss; see on inseneriotsus. Ja kui ehitate hübriidi, pidage meeles ülalolevat hookide ja filtrite lugu — saate vana loogika siiski mähkida dünaamilistesse plokkidesse, samal ajal kui theme.json haldab globaalset ilmet.

Teie theme.json-i versioonihaldus ei ole ainult teoreetiline mure. Olen näinud agentuuri kohandatud plokiteeki purunemas, kui klient uuendas WordPressi ja ploki style-fail registreeriti wp_register_style() abil muudetud identifikaatoriga. Parandus oli lihtne, kuid paanika oli reaalne. Lihtne testimisprotsess — käivitage uuendus saidi testikoopial, klõpsake läbi võtmelehed, seejärel avaldage — lahendab enamiku nendest üllatustest.

Vastuväide, mida te pole endale esitanud

Siin on metavastuväide, mis hoiab agentuure standardiseerimast: „See on suur muutus ja klienditöö ajal pole selleks aega." See on tõsi — nii et ärge tehke seda klienditöö ajal. Valige sisemine projekt või väike klient ja ehitage üks mustriteek. Kasutage theme.json-i disainitokennisüsteemina. Lisage kohandatud plokk ainult siis, kui see on õigustatud. Mähi vanad hookid sinna, kus need aitavad. Itereerige.

Siin on ligikaudne esimene 30 päeva:

1. Auditige oma viit viimast kliendiehitust ja loetlege kümme kõige korduvamat paigutustükki.
2. Muutke need kümme tükki plokimustriteks väikese CSS-klasside hulgaga.
3. Ehitage ühine plugin (või mu-plugin), mis registreerib need mustrid. Kui te pole pluginakorralduse üle mõelnud, vaadake esmalt see juhend tugevate pluginate ehitamiseks.
4. Looge üks theme.json, mis vastab teie lähtekujundusele; lisage kliendispetsiifilised väärtused projektide käivitamisel.
5. Valige üks väike sisemine projekt või sõbralik klient ja migreerige see sellesse lahendusse.
6. Kirjeldage ühte kangelaslugu kliendist, kes redigeeris oma avalehte ilma teile helistamata.

Selle katse lõpus pole teil seinal „plokke-esikohal" märki. Teil on meeskond, kes suudab uue kliendisaidi luua ühisest alusest ilma ajakava pärast vabandamata. Olete ka paremas olukorras, et öelda ei kliendi taotlusele 42. kohandatud ploki jaoks — sest teate täpselt, mida tuumplokid suudavad, või sellepärast, et saate näidata, miks dünaamiline plokk oleks tõesti kiirem.

Kas ehitate ikka mõned kohandatud saidid? Jah. Mõned kliendid vajavad alati kohandatud malli, eripärast lehte või portitavat integratsiooni, mida pole mõtet ühisesse mudelisse suruda. Eesmärk ei ole kohandatud töö kaotamine — see on muuta see erandiks, mitte vaikimisi.

Korratavus tuleb igavatest osadest: kindel theme.json-skeem, selge mustriteek ja distsipliin hoida jagatud kiht kõhn. See ei ole läikiv versioon, mida veebiseminaridel kuulete. See on see, mis võidab esmaspäevahommikuse tühja teema bluusi.