Nustokite perkurti kiekvieną WordPress svetainę

Santrauka

Dauguma agentūrų kuria kiekvieną WordPress svetainę nuo tuščios temos, net tada, kai bendras pagrindas galėtų sutrumpinti grafiką savaitėmis. Šiame straipsnyje teigiama, kad theme.json, blokų šablonai ir dinaminiai blokai leidžia standartizuoti struktūrinį sluoksnį, išlaikant kiekvieno kliento išskirtinį dizainą. Jis tiesiogiai nagrinėja penkis prieštaravimus, kurie sulaiko komandas nuo pokyčių: „turime skirtingus klientus“, „pasirinktiniai blokai yra brangūs“, „redaktorius klaidina“, „prarasime savo hooks ir filtrus“ ir „FSE nėra paruoštas gamybai“. Kiekvienas prieštaravimas sulaukia praktinio kontrargumento ir konkretaus modelio, kurį galite diegti palaipsniui. Rezultatas – pasikartojantis kūrimo procesas, kuris vis tiek gerbia individualų darbą ten, kur jam vieta. Įspėjimas: jokių mygtukų, išsprendžiančių viską vienu paspaudimu, nežadama.

Kiek jūsų klientų svetainių turi nors vieną bendrą kodo eilutę? Ne autorių teisių eilutę – tikrą kodą. Jei atsakymas yra „beveik jokios“, jūs jau pajutote skausmą: ta pati hero sekcija perkurta devintą kartą, tas pats komandos tinklelio žymėjimas kopijuojamas iš projekto į projektą, tie patys išankstinio apdorojimo pakeitimai kryžmai minimi pusšimtyje temų. Taip pat girdėjote gynybą: „Kiekvienas klientas turi skirtingus poreikius.“ Tiesa. Tačiau išvada, kurią visi daro – kad kiekvienai svetainei reikia individualaus pagrindo – yra klaidinga. WordPress ekosistema dabar suteikia galimybę standartizuoti struktūrines dalis nestandartizuojant dizaino: theme.json dizaino žetonams, blokų šablonai pasikartojantiems maketams, o dinaminiai blokai – saujai funkcijų, kurioms reikia tikros serverio pusės logikos. Šis straipsnis yra apie prieštaravimus, kurie sulaiko agentūras nuo šio žingsnio, ir apie tai, kas iš tikrųjų veikia, kai jiems pasipriešinate.

Prieštaravimas „bet kiekvienas klientas yra kitoks“

Pagrindinis principas: standartizuokite pagrindą, o ne paviršių. Priežastis laikyti struktūrą bendroje bibliotekoje yra būtent ta, kad vizualinis sluoksnis liktų laisvas. theme.json failas nėra dizainas – tai dizaino žetonų rinkinys. Spalvos, tarpai ir tipografika yra reikšmės, o ne žymėjimas. Tai yra esminis pokytis: galite dalytis žymėjimu, o kiekvienos svetainės theme.json leidžia svetainei atrodyti visiškai kitaip pagal skirtingą prekės ženklą.

Paimkite du klientus: advokatų kontorą ir lauko įrangos parduotuvę. Jų dizaino kalbos skiriasi kaip diena ir naktis. Tačiau abiem reikia hero sekcijos, atsiliepimų tinklelio, kvietimo veikti juostos. Užuot perkūrę žymėjimą kiekvienam atvejui, sukurkite tris blokų šablonus ir leiskite kiekvieno kliento theme.json apibrėžti spalvas, šriftus ir tarpus. Struktūra išlieka identiška; dizaino žetonai paverčia ją iš vieno prekės ženklo į kitą. Kai kitą pavasarį parduotuvė pakeis savo spalvų paletę, jūs redaguosite vieną failą jų svetainėje – ne žymėjimą šešiuose šablonuose.

Praktiškai tai reiškia, kad jūsų komanda kuria šablonus kaip kodą, registruoja juos bendrame įskiepyje ir leidžia kiekvienos kliento svetainės theme.json tvarkyti dažymą. Šablono klasės pavadinimai tampa jūsų architektūra; reikšmės tampa kintamaisiais. Galite eiti dar toliau ir išplėsti theme.json, kad įtrauktumėte pasirinktinius nustatymus turinio tipams ar įskiepių išvestims, nors tam tikru metu kuriate konfigūracijos sąsają vietoj svetainės – spąstai, aptarti mūsų straipsnyje apie theme.json išplėtimą. Laikykite bendrą sluoksnį liesą: jame turėtų būti tik tai, kas kartojasi skirtinguose klientuose. Kai tik pastebite, kad pridedate nustatymą „jei kada nors kas nors to norės“, sukūrėte abstrakciją, kurią prižiūrėti kainuos daugiau nei sutaupys.

Kai pradedate dirbti su nauju klientu, pirmos trisdešimt minučių turėtų atrodyti taip: nukopijuokite bendrų šablonų įskiepį, sukurkite naują theme.json su kliento palete ir šrifto skale, ir užregistruokite jų logotipą bei poraštę. Tai nėra individualus kūrimas; tai konfigūracijos užduotis. Likęs klientui specifinis darbas atitenka turiniui, struktūrai ir tikrai unikalioms funkcijoms. Tai skirtumas tarp kiekvieno namo statymo nuo nulio ir turėjimo parengtų surenkamų grindų planų rinkinio, kurį galite perdažyti ir perklijuoti tapetais. Analogija laisva, bet principas galioja: kuo daugiau perkeliate į theme.json reikšmes, tuo mažiau tenka liesti žymėjimą.

Vienas iš paprasčiausių laimėjimų – iš tikrųjų pažiūrėti, kaip veikia blokų šablonai. Šablonas yra tik blokų rinkinys su iš anksto nustatytu turiniu ir stiliumi. Galite išsaugoti bet kurią blokų konfigūraciją kaip šabloną, ir tada klientas gali jį įterpti nežinodamas, kaip jis sukurtas. Tai reiškia, kad šablonas tampa „įėjimo tašku“ netechniniams vartotojams. Kai jūsų komanda palaiko pagrindinį šabloną kode, klientas gauna nuoseklią biblioteką nepaliesdamas nė vienos PHP žymos.

Vis dėlto, įspėjimas, prie kurio nuolat grįžtu: nepercentralizuokite. theme.json su nustatymu kiekvienam įmanomam niuansui yra priežiūros pelkė. Bendri šablonai turėtų būti principingi, o ne visagaliai. Jei klientui reikia radikaliai kitokio maketo – tarkime, žurnalo pagrindinio puslapio su dideliu išskirtinių straipsnių tinkleliu – jie gali netilpti į jūsų standartinę šablonų biblioteką. Tai gerai. Standartizavimas reiškia, kad laimite 80% projektų, kurie yra panašūs, o ne verčiate kiekvieną svetainę į tą pačią formą.

Prieštaravimas „pasirinktiniai blokai išpučia biudžetą“

Čia yra kontrprincipas, kuris skamba nuobodžiai, bet taupo pinigus: dauguma dalykų, kuriems, jūsų manymu, reikia pasirinktinio bloko, jo nereikalauja. Pagrindiniai blokai ir šablonas gali padengti didžiąją dalį maketų. Pasirinktinis blokas yra paskutinė išeitis, o ne pirmas ketinimas.

Klasikinis pavyzdys – komandos tinklelis. Jei tai vienkartinis dalykas, naudokite pagrindinius „stulpelių“ ir „grupės“ blokus ir leiskite klientui ranka įkelti avatarą. Jei trys klientai prašo to paties tinklelio su ta pačia „socialinių nuorodų po vardu“ struktūra, dabar turite kandidatą blokų šablonui. Kai tas šablonas pradeda kaupti naujas parinktis – užvedimo efektus, rūšiavimą, įvertinimo žvaigždutes – šablonas tampa nevaldomu maišalynu, ir tada laikas rašyti pasirinktinį bloką. Biudžetą žalojanti klaida – pirmą kartą paprašius iškart pereiti prie pasirinktinio bloko.

Klastingesnis scenarijus: klientas prašo „atvejų analizės karuselės“. Pirmoji instinktyvi mintis – „man reikia karuselės bloko“. Bet ar jiems tikrai reikia karuselės? Galbūt jiems reikia horizontaliai slenkančios įrašų grupės, kurią pagrindiniai blokai gali apdoroti naudodami „grupės“ bloką ir šiek tiek CSS. O gal jiems reikia dinamiško naujausių atvejų analizių sąrašo, kuris yra dinaminis blokas, užklausiantis pasirinktinį turinio tipą (CPT). Klausimas yra ne „kokios funkcijos klientas nori?“, o „kokie duomenys nuo jos priklauso?“ Jei duomenys yra statiniai ir kliento redaguojami, užtenka šablono. Jei duomenys gaunami iš duomenų bazės užklausos, dinaminis blokas yra pateisinamas. Jei duomenis reikia atnaujinti realiuoju laiku iš API, greičiausiai žiūrite į REST API integraciją – tai pereina į kitokio pobūdžio kūrimą.

Kai vis dėlto kuriate bloką, block.json yra jūsų draugas. Tai yra vienintelis tiesos šaltinis atributams, skriptams ir stiliams, todėl blokas tampa perkeliamas tarp projektų. Tai taip pat leidžia švariai deklaruoti priklausomybes ir vertimus, o tai būtina, kai platinate biblioteką daugelyje klientų svetainių. Turinčiame turinį, kuris priklauso nuo tiesioginių duomenų, dinaminis blokas atvaizduojamas serveryje, todėl nereikia kiekviename puslapio peržiūrėjime siųsti JavaScript paketo. O jei jūsų blokas evoliucionuoja, galite grakščiai tvarkyti nebenaudojamus elementus, kad esamas turinys nesulūžtų – mūsų vadovas apie blokų pasenimą žingsnis po žingsnio parodo tą patį modelį.

Prieš ką nors kurdami, peržiūrėkite sprendimą pagal šią lentelę:

Metodas	Geriausiai tinka	Venkite, kai
Pagrindinis blokas	Vienkartinis turinys, paprasti puslapiai	Maketas kartojasi daugelyje klientų ir reikalauja turtingų parinkčių
Blokų šablonas	Pasikartojantys maketai be logikos	Maketui reikia sąlygų, dinaminių duomenų ar sudėtingų sąveikų
Pasirinktinis blokas	Pasikartojantis, duomenimis pagrįstas ar labai specifinis elgesys	Vienintelė priežastis yra vienkartinė sekcija, kurią galima apdoroti su klase

Taip pat verta pagalvoti apie blokų pavadinimus nuo pat pradžių. Bloko pavadinimas iš esmės yra sutartis su jūsų turiniu. Jei pavadinsite jį wagent/team-grid, o vėliau pervadinsite į wagent/team-carousel, sulaužysite esamą turinį, nebent pateiksite nebenaudojimo kelią. Rinkitės bendrinius, pagal paskirtį paremtus pavadinimus, kurie netaps klaidinga reklama blokui vystantis. Tai yra pavadinimų disciplinos atmaina, kurios visi išmokome iš įskiepių priešdėlių, ir ji taikoma blokų pavadinimams.

Kontrargumentas, kurį galiu pasakyti, yra pats naudingiausias: pasirinktinis blokas, kurį sukuriate, nes klientas paprašė „tik vienos detalės“, beveik visada yra klaida. Mandagiai pasakykite ne, pateikite pagrindinį bloką su klase ir sutaupykite valandas. Klientas jus labiau gerbs – ir priežiūros biudžete bus mažiau eilučių.

Prieštaravimas „klientai sugadins redaktorių“

Šis prieštaravimas pusiau teisingas. Pats blokų redaktorius nėra problema; problema yra duoti klientams per daug laisvės. theme.json gali apriboti, kas yra redaguojama: išjungti šablonų redaktorių, apriboti leidžiamus blokus ir nustatyti numatytuosius stilius, kad perkelta stulpelis padarytų mažiau žalos. Kai kurie klientai vis tiek sugebės ką nors sulaužyti, bet jūs galite vienu paspaudimu grąžinti puslapį į išsaugotą šabloną – ko klasikinis redaktorius negalėjo pasiūlyti.

Leiskite man nupiešti scenarijų. Klientas skambina ir sako: „Perkėliau sekciją, ir dabar visas puslapis atrodo blogai.“ Su klasikine tema prisijungtumėte, patikrintumėte CSS ir tikriausiai praleistumėte valandą taisydami maketą. Su blokų sąranka galite atidaryti puslapį, pasirinkti turinio sritį ir atstatyti ją į išsaugotą šabloną. Šablonas yra pagrindas; kliento pakeitimai yra perdanga. Kai perdanga sugenda, ją pašalinate. Tai ne tik patogesnis darbo srautas; tai iš esmės labiau atlaidus redaktorius.

Vis dėlto, niuansas: dauguma klientų iš viso nenori daug redaguoti. Jie nori keisti tekstą, keisti nuotraukas ir galbūt perrikiuoti sekciją. Blokų šablonas suteikia būtent tai, neatskleisdamas visos svetainės struktūros. Šia prasme redaktorius nėra žaislas; tai vaizdo ieškiklis. Jūsų darbas – sukalibruoti, ką klientai gali matyti. Tai gali reikšti, kad išjungsite „Šablonų“ nustatymus, apribosite blokų įterpimo įrankį iki kuruojamo sąrašo ir netgi iš anksto užpildysite tuščius šablonus vietos rezervavimo turiniu. Redaktorius tampa turinio įvedimo forma, o ne web dizaino drobe.

Prieinamumo pusėje blokų redaktoriaus fokusavimo valdymas ir klaviatūros palaikymas paprastai yra geresni nei klasikinio redaktoriaus šablonų laukai. Bet vis tiek turite užtikrinti, kad šablonai turėtų tinkamą antraščių hierarchiją ir prieinamus pavadinimus. Kadangi šablonas yra bendras visiems klientams, šias problemas išspręsite tik vieną kartą – tai dar vienas paslėptas standartizavimo laimėjimas.

Iš tikrųjų sunkiausia dalis yra vidinė. Jūsų komandai išmokti prototipuoti su blokais reikia atsikratyti „daryk per PHP“ įpročio. Tai reali kaina, bet tai vienkartinė kaina vienam asmeniui. Tai nėra priežastis vengti šio metodo; tai priežastis pradėti nuo vienos šablonų bibliotekos ir vieno atlaidesnio kliento, prieš diegiant visur. Neleiskite, kad frazė „mano klientai nemoka dirbti su blokais“ paslėptų tai, kad dar nesukonfigūravote blokų sąrankos, kuri atitiktų juos pusiaukelėje.

Prieštaravimas „mes jau turime hooks ir filtrus“

Principas čia toks: jūs neatmetate hooks; jūs pridedate sluoksnį ant viršaus. Blokai yra pateikimo riba; hooks vis dar yra tai, kaip įterpiate logiką. Dinaminio bloko atvaizdavimo atgalinis iškvietimas vykdomas PHP, o tai reiškia, kad galite iškviesti tas pačias funkcijas ir pritaikyti tuos pačius filtrus, kuriais jau pasitikite.

Įsivaizduokite įskiepį, kuris leidžia pridėti „ypatingos prekės“ lauką prie bet kokio įrašo naudojant filtrą. Su dinaminiu bloku galite įtraukti serverio pusėje atvaizduojamą bloką, kuris paleidžia tą filtrą ir išspausdina rezultatą bloko apvalkale. Klientas įterpia bloką; esama PHP logika atlieka pagrindinį darbą. Nieko neišmetama. Dar konkretesnis pavyzdys – pasirinktinis blokas, kuris išvardija naujausius projektų įrašus. Jo atvaizdavimo atgaliniame iškvietime iškviečiate get_posts(), tada kartojate ir taikote the_title() bei the_permalink() – tuos pačius šablonų žymeklius, kuriuos naudojate metų metus.

Tai taip pat vieta, kur reikia būti sąžiningiems apie tai, kas neperkeliama. Kai kurios sumanios senos temos naudoja template-parts su sudėtingomis sąlygomis, kurios priima argumentus pagal puslapio kontekstą. Atkurti tai kaip bloką gali būti keblu. Bet jums nereikia visa to atkurti iš karto. Laipsniškas kelias – išlaikyti PHP logiką, įvynioti ją į dinaminį bloką ir perkelti žymėjimą į bloko šabloną. Dažnai pamatysite, kad esami filtrų modeliai gali apdoroti naują išvestį. O jei logika glaudžiai susijusi su šablonų hierarchija (pvz., „paieškos rezultatuose parodykite kitaip“), vis tiek galite naudoti klasikinį šabloną tiems konkretiems rodiniams, o blokus – įprastiems puslapiams.

REST API taip pat atveria kitas duris: galite kurti blokus, kurie traukia duomenis iš kitų WordPress svetainių ar trečiųjų šalių paslaugų. Dinaminis blokas gali iškviesti wp_remote_get(), kad gautų JSON ir atvaizduotų jį vartotojo sąsajoje. Tai galingas modelis agentūrų projektams, kai klientai nori rodyti socialinių tinklų srautus, produktų sąrašus ar vidinius duomenis be atskiros integracijos valdymo. Kaina yra talpykla ir klaidų valdymas – jei nuotolinė API yra lėta, jūsų puslapis yra lėtas. Laikykite API pagrįstus blokus atokiau nuo kritinio turinio pirmame ekrane arba naudokite kliento pusės atvaizdavimą su tinkama įkėlimo būsena.

Veiksmai (actions) ir filtrai vis tiek veikia aplink įrašymą ir atvaizdavimą; hook architektūra neišnyksta, kai perimate blokus, ji tiesiog persikelia į naują kontekstą. Jei jums reikia atnaujinti supratimą apie tai, kur veiksmai ir filtrai susitinka su šiuo nauju blokų pasauliu, mūsų išsamus hooks vadovas yra naudingas priminimas.

Prieštaravimas „FSE nėra paruoštas gamybai“

Teisingai, bet paklauskite, ką iš tikrųjų reiškia „rizikinga“. „Full Site Editing“ jau praėjo keletą versijų, o theme.json nusistovėjo į stabilią schemą. Rizika ne ta, kad redaktorius „staiga sulūš“ – rizika ta, kad jūsų komandos pasirinktinis kodas gali priklausyti nuo senojo stiliaus PHP šablonų, kurie nepatogiai egzistuoja kartu su blokų šablonais. Be to, kai kurie trečiųjų šalių įskiepiai vis dar daro prielaidą, kad naudojamas klasikinis redaktorius arba tinkintuvas (customizer). Tai suderinamumo sprendimas, o ne priežastis išmesti visą modelį.

Naudingas būdas apie tai galvoti: paprastos, pasikartojančios svetainės su turiniu, parašytu blokais, yra mažiausiai rizikingos. Didelės rizikos klientai yra tie, kurie turi giliai pritaikytas klasikines temas arba patentuotus įskiepius, kurie atvaizduoja savo vartotojo sąsają. Tai teisėta priežastis likti prie klasikinių temų toje mažoje nišoje. Klaida yra apsimesti, kad „paruoštas gamybai“ yra vienas jungiklis, kuris yra arba įjungtas, arba išjungtas.

Prieš siūlydami klientui blokų temą, peržiūrėkite greitą kontrolinį sąrašą:

• Ar klientas turi labai pritaikytą temą, kuriai reikėtų migracijos?
• Ar būtini įskiepiai palaiko „Site Editor“ ir REST API?
• Ar hostingo aplinka leidžia failų prieigą, kurios tikisi blokų tema?
• Ar skyrėte laiko šablonų dizainui, o ne tik blokų registracijai?
• Ar kliento komanda toleruos redaktoriaus pakeitimus, ar jiems reikia užrakinto šablono?

Jei nors vienas atsakymas yra „ne“, pakoreguokite apimtį arba naudokite hibridinį metodą. Tai ne kompromisas; tai inžinerinis sprendimas. O jei kuriate hibridą, prisiminkite anksčiau pateiktą hooks ir filtrų istoriją – vis tiek galite įvynioti seną logiką į dinaminius blokus, o theme.json tvarkys bendrą vaizdą.

Jūsų theme.json versijavimas nėra vien teorinis rūpestis. Mačiau, kaip agentūros pasirinktinių blokų biblioteka sulūžo, kai klientas atnaujino WordPress, o bloko style failas, užregistruotas su wp_register_style(), pakeitė identifikatorių (handle). Pataisymas buvo lengvas, bet panika buvo tikra. Paprastas testavimo procesas – paleiskite atnaujinimą laikinojoje svetainės kopijoje, spustelėkite pagrindinius puslapius, tada paleiskite – išsprendžia daugumą tokių netikėtumų.

Prieštaravimas, kurio sau nepasakėte

Čia yra meta-prieštaravimas, kuris sulaiko agentūras nuo standartizavimo: „Tai didelis pokytis, ir nėra laiko jį atlikti per kliento darbus.“ Tai tiesa – todėl nedarykite to per kliento darbus. Pasirinkite vidinį projektą arba mažą klientą ir sukurkite vieną šablonų biblioteką. Naudokite theme.json kaip dizaino žetonų sistemą. Pridėkite pasirinktinį bloką tik tada, kai tai pateisinama. Įvyniokite senus hooks ten, kur jie padeda. Tobulinkite palaipsniui.

Štai apytikslis pirmųjų 30 dienų planas:

1. Peržiūrėkite paskutinius penkis klientų projektus ir sudarykite dešimties dažniausiai pasikartojančių maketų dalių sąrašą.
2. Paversti tas dešimt dalių blokų šablonais su nedideliu CSS klasių rinkiniu.
3. Sukurkite bendrą įskiepį (arba mu-plugin), kuris registruoja tuos šablonus. Jei dar nesusimąstėte apie įskiepių organizavimą, pirmiausia perskaitykite šį vadovą apie tvirtų WordPress įskiepių kūrimą.
4. Sukurkite vieną theme.json, atitinkantį jūsų pagrindinį dizainą; pridėkite klientui būdingas reikšmes, kai pradedate naujus projektus.
5. Pasirinkite vieną mažą vidinį projektą arba geranorišką klientą ir migruokite jį prie šio kodo pagrindo.
6. Užfiksuokite vieną herojų istoriją apie klientą, kuris redagavo savo pagrindinį puslapį neskambindamas jums.

Po to eksperimento neturėsite „blokais pagrįsto“ ženkliuko, kurį galėtumėte pakabinti ant sienos. Turėsite komandą, kuri gali sukurti naują kliento svetainę iš bendro pagrindo be atsiprašymų dėl terminų. Taip pat būsite geresnėje padėtyje pasakyti „ne“ kliento prašymui dėl 42-ojo pasirinktinio bloko – nes tiksliai žinote, ką gali pagrindiniai blokai, arba nes galite parodyti, kodėl dinaminis blokas iš tikrųjų būtų greitesnis.

Ar vis tiek kursite kai kurias individualias svetaines? Taip. Kai kuriems klientams visada reikės pasirinktinio šablono, individualaus puslapio arba patentuotos integracijos, kurios neverta brukšti į bendrą modelį. Tikslas nėra panaikinti individualų darbą – tikslas padaryti jį išimtimi, o ne numatytąja praktika.

Pakartojamumas kyla iš nuobodžių dalykų: tvirtos theme.json schemos, aiškios šablonų bibliotekos ir disciplinos laikyti bendrą sluoksnį liesą. Tai ne blizganti versija, apie kurią girdite webinaruose. Tai ta, kuri nugali pirmadienio ryto tuščios temos bliuzą.