Pārtrauciet pārbūvēt katru WordPress vietni

Kopsavilkums

Lielākā daļa aģentūru veido katru WordPress vietni no tukšas tēmas, pat ja kopīgs pamats ietaupītu vairākas nedēļas no grafika. Šajā rakstā tiek apgalvots, ka theme.json, bloku paraugi un dinamiskie bloki ļauj standartizēt strukturālo slāni, vienlaikus saglabājot katra klienta atšķirīgo dizainu. Tajā tieši tiek aplūkoti pieci iebildumi, kas attur komandas no pārmaiņām: “mums ir dažādi klienti”, “pielāgoti bloki ir dārgi”, “redaktors ir mulsinošs”, “mēs zaudēsim savus hookus un filtrus” un “FSE nav gatavs ražošanai”. Katrs iebildums saņem praktisku pretargumentu un konkrētu paraugu, ko var ieviešot pakāpeniski. Ieguvums ir atkārtojams izstrādes process, kas joprojām godina individuāli veidotus darbus tur, kur tas nepieciešams. Brīdinājums: nekādu “viena klikšķa” atiestatīšanas pogu netiek solīts.

Cik daudz no jūsu klientu vietnēm dala kaut vienu koda rindiņu? Ne autortiesību rindiņu—faktisko kodu. Ja atbilde ir “gandrīz neviena”, jūs jau esat izjutuši sāpes: tā pati hero sadaļa pārbūvēta devīto reizi, tas pats komandas režģa marķējums kopēts no projekta uz projektu, tie paši priekšapstrādes labojumi, kas jāpārbauda pusduci tēmu. Jūs esat dzirdējuši arī aizstāvību: “Katram klientam ir citas vajadzības.” Tiesa. Taču secinājums, ko visi izdara—ka katrai vietnei ir nepieciešams individuāls pamats—ir nepareizs. WordPress ekosistēma tagad sniedz iespēju standartizēt strukturālās daļas, nestandartizējot dizainu: theme.json dizaina tokeniem, bloku paraugus atkārtotiem izkārtojumiem un dinamiskos blokus tām retajām funkcijām, kurām nepieciešama reāla servera puses loģika. Šis raksts ir par iebildumiem, kas attur aģentūras no šī soļa, un par to, kas patiesībā strādā, kad tiem pretojaties.

Iebildums “bet katrs klients ir atšķirīgs”

Pamatprincips: standartizējiet pamatu, nevis virsmu. Iemesls, kāpēc turēt struktūru koplietotā bibliotēkā, ir tieši atstāt vizuālo slāni brīvu. Theme.json fails nav dizains—tas ir dizaina tokenu kopums. Krāsas, atstarpes un tipogrāfija ir vērtības, nevis marķējums. Tas ir izšķirošais pagrieziens: jūs varat kopīgot marķējumu, kamēr katrai vietnei atšķirīgais theme.json padara vietni pilnīgi atšķirīgu citam zīmolam.

Ņemsim divus klientus: advokātu biroju un āra apģērbu mazumtirgotāju. Viņu dizaina valodas ir ļoti atšķirīgas. Bet abiem ir nepieciešama hero sadaļa, atsauksmju režģis, aicinājuma uz darbību josla. Tā vietā, lai pārbūvētu marķējumu katram, uzturiet trīs bloku paraugus un ļaujiet katra klienta theme.json noteikt krāsas, fontus un atstarpes. Struktūra paliek identiska; dizaina tokeni pārvērš to no viena zīmola citā. Kad mazumtirgotājs nākamajā pavasarī mainīs savu krāsu paleti, jūs rediģēsit vienu failu viņu vietnē—nevis marķējumu sešās veidnēs.

Praktiski tas nozīmē, ka jūsu komanda veido paraugus kā kodu, reģistrē tos koplietotā spraudnī un ļauj katra klienta vietnes theme.json apstrādāt vizuālo noformējumu. Parauga klases nosaukumi kļūst par jūsu arhitektūru; vērtības kļūst par mainīgajiem. Varat pat iet tālāk un paplašināt theme.json, iekļaujot pielāgotus iestatījumus satura veidiem vai spraudņu izvadei, lai gan kādā brīdī jūs veidojat konfigurācijas saskarni, nevis vietni—šis slazds ir apskatīts mūsu rakstā par theme.json paplašināšanu. Uzturiet koplietoto slāni bez liekā: tajā jābūt tikai tam, kas atkārtojas dažādos klientos. Brīdī, kad pamanāt sevi pievienojam iestatījumu “katram gadījumam, ja kādreiz kāds to vēlēsies,” esat izveidojuši abstrakciju, kuras uzturēšana izmaksās vairāk nekā ietaupa.

Uzstādot jaunu klientu, pirmās trīsdesmit minūtes jābūt: noklonējiet koplietoto paraugu spraudni, izveidojiet jaunu theme.json ar klienta paleti un fonta skalu, reģistrējiet viņu logotipu un kājeni. Tas nav pielāgots izstrādes projekts; tas ir konfigurācijas uzdevums. Atlikušais klientam specifiskais darbs tiek ieguldīts saturā, struktūrā un jebkādās patiesi individuālās funkcijās. Šī ir atšķirība starp katras mājas būvēšanu no nulles un gatavu saliekamo stāvu plānu komplektu, ko var pārkrāsot un pārlīmēt ar jaunām tapetēm. Analoģija ir vaļīga, bet princips paliek: jo vairāk jūs pārnesat uz theme.json vērtībām, jo mazāk jums ir jāaiztiek marķējums.

Viena no vienkāršākajām uzvarām ir patiesībā apskatīt, kā darbojas bloku paraugi. Paraugs ir tikai bloku kolekcija ar iepriekš definētu saturu un stilu. Jūs varat saglabāt jebkuru bloku konfigurāciju kā paraugu, un tad klients to var ievietot, nezinot, kā tas uzbūvēts. Tas nozīmē, ka paraugs kļūst par “ieejas punktu” netehniskiem lietotājiem. Kad jūsu komanda uztur pamatā esošo paraugu kodā, klients iegūst konsekventu bibliotēku, neaiztiekot nevienu PHP tagu.

Tagad brīdinājums, pie kura es pastāvīgi atgriežos: nepārcentralizējiet. Theme.json ar iestatījumu katram iedomājamam niansējumam ir uzturēšanas purvs. Koplietotajiem paraugiem jābūt ar skaidru nostāju, nevis visvarenīgiem. Ja klientam ir nepieciešams radikāli atšķirīgs izkārtojums—piemēram, žurnāla mājaslapa ar lielu izcelto režģi—tie, iespējams, neiederēsies jūsu standarta paraugu bibliotēkā. Tas ir labi. Standartizācija nozīmē, ka jūs uzvarat 80% projektu, kas ir līdzīgi, nevis ka jūs spiežat katru vietni vienā veidnē.

Iebildums “pielāgotie bloki pārsniedz budžetu”

Šeit ir pretprincips, kas izklausās garlaicīgi, bet ietaupa naudu: lielākā daļa lietu, par kurām domājat, ka tām nepieciešams pielāgots bloks, neprasa to. Pamata bloki plus paraugs var aptvert lielāko daļu izkārtojumu. Pielāgotais bloks ir pēdējais līdzeklis, nevis pirmā izvēle.

Klasisks piemērs ir komandas režģis. Ja tas ir vienreizējs, izmantojiet pamata “kolonnu” un “grupas” blokus un ļaujiet klientam pašam ievietot avatāru. Ja trīs klienti prasa to pašu režģi ar to pašu “sociālo saišu zem nosaukuma” struktūru, tad jums ir kandidāts bloku paraugam. Kad šis paraugs sāk uzkrāt jaunas opcijas—hover efektus, kārtošanu, vērtējumu zvaigznes—paraugs kļūst par neizturamu maisījumu, un tad ir laiks rakstīt pielāgotu bloku. Budžetu postoša kļūda ir lēkt tieši pie pielāgotā bloka pēc pirmā pieprasījuma.

Vēl mānīgāks scenārijs: klients prasa “gadījumu izpētes karuseli.” Pirmais instinkts ir domāt: “Man vajag karuseļa bloku.” Bet vai viņiem tiešām vajag karuseli? Varbūt viņiem vajag horizontāli ritināmu ziņu grupu, ko pamata bloki var apstrādāt ar “grupas” bloku un dažiem CSS. Vai arī viņiem vajag dinamisku jaunāko gadījumu izpētes sarakstu, kas ir dinamisks bloks, kurš veic CPT vaicājumu. Jautājums nav “kādu funkciju klients vēlas?”, bet “no kādiem datiem tā ir atkarīga?” Ja dati ir statiski un rediģējami klientam, pietiks ar paraugu. Ja dati nāk no datubāzes vaicājuma, dinamisks bloks ir attaisnojams. Ja datiem ir jāatjaunojas reāllaikā no API, jūs, iespējams, skatāties uz REST API integrāciju—tas jau ir cita veida izstrāde.

Kad jūs tomēr veidojat bloku, block.json ir jūsu draugs. Tas ir vienotais patiesības avots atribūtiem, skriptiem un stiliem, kas padara bloku pārnesamu starp projektiem. Tas arī ļauj skaidri deklarēt atkarības un tulkojumus, kas ir būtiski, ja izplatāt bibliotēku daudzās klientu vietnēs. Saturu, kas atkarīgs no tiešsaistes datiem, dinamisks bloks renderē serverī, tāpēc jums nav jāpiegādā JavaScript pakete katrā lapas skatījumā. Un, ja jūsu bloks attīstās, varat eleganti apstrādāt nolietotās versijas, lai esošais saturs nesabojātos—mūsu ceļvedis par bloku nolietošanu parāda precīzu modeli.

Pirms kaut ko veidojat, izvērtējiet lēmumu ar šo tabulu:

Pieeja	Kam vislabāk	No kā izvairīties
Pamata bloks	Vienreizējs saturs, vienkāršas lapas	Izkārtojums atkārtojas daudzos klientos un nepieciešamas bagātīgas opcijas
Bloku paraugs	Atkārtojami izkārtojumi bez loģikas	Izkārtojumam nepieciešami nosacījumi, dinamiski dati vai sarežģītas mijiedarbības
Pielāgots bloks	Atkārtots, datu virzīts vai ļoti specifiska uzvedība	Vienīgais iemesls ir vienreizēja sadaļa, ko var apstrādāt ar klasi

Jums būs arī jādomā par bloku nosaukumiem jau no pirmās dienas. Bloka nosaukums būtībā ir līgums ar jūsu saturu. Ja jūs to saucat par wagent/team-grid un vēlāk pārsauciet par wagent/team-carousel, jūs salauzīsiet esošo saturu, ja vien nenodrošināsiet nolietošanas ceļu. Izvēlieties vispārīgus, uz mērķi balstītus nosaukumus, kas nekļūs par maldinošu reklāmu, blokam attīstoties. Šī ir nosaukumu disciplīnas forma, ko mēs visi esam iemācījušies no spraudņu prefiksiem, un tā attiecas tikpat lielā mērā uz bloku nosaukumiem.

Pretrunīgais viedoklis šeit ir visnoderīgākais, ko varu teikt: pielāgotais bloks, ko veidojat tāpēc, ka klients prasīja “tikai vienu gabalu”, gandrīz vienmēr ir kļūda. Pieklājīgi pasakiet nē, piegādājiet pamata bloku ar klasi un ietaupiet stundas. Jūs iegūsiet lielāku klienta cieņu—un mazāku rindiņu uzturēšanas budžetā.

Iebildums “klienti salauzīs redaktoru”

Šis iebildums ir puslīdz pareizs. Pats bloku redaktors nav problēma; problēma ir dot klientiem pārāk daudz brīvības. theme.json var ierobežot to, ko var rediģēt: atspējot veidņu redaktoru, ierobežot atļautos blokus un iestatīt noklusējuma stilus, lai nepareizi novietota kolonna nodarītu mazāk bojājumu. Daži klienti joprojām salauzīs lietas, bet jūs varat vienā klikšķī atiestatīt lapu uz saglabāto paraugu—ko klasiskais redaktors nepiedāvāja.

Ļaujiet man aprakstīt scenāriju. Klients zvana un saka: “Es pārvietoju sadaļu, un tagad visa lapa izskatās nepareizi.” Ar klasisko tēmu jūs pieslēgtos, pārbaudītu CSS un, iespējams, pavadītu stundu, labojot izkārtojumu. Ar bloku iestatījumu jūs varat atvērt lapu, atlasīt satura apgabalu un atiestatīt to uz saglabāto paraugu. Paraugs ir bāzes līnija; klienta izmaiņas ir pārklājums. Kad pārklājums sabojājas, jūs to noņemat. Tas nav tikai patīkamāks darba process; tas ir būtiski piedodošāks redaktors.

Tagad nianses: lielākā daļa klientu nemaz nevēlas daudz rediģēt. Viņi grib mainīt tekstu, nomainīt fotoattēlus un, iespējams, pārkārtot sadaļu. Bloku paraugs dod tieši to, nepakļaujot visu vietnes struktūru. Šajā ziņā redaktors nav rotaļlieta; tas ir skatu meklētājs. Jūsu uzdevums ir nokalibrēt, ko klienti var redzēt. Tas nozīmē, ka varat atspējot “Veidņu” iestatījumus, ierobežot bloku ievietošanu līdz atlasītam sarakstam un pat aizpildīt tukšus paraugus ar viettura saturu. Redaktors kļūst par satura ievades formu, nevis tīmekļa dizaina audeklu.

Attiecībā uz pieejamību bloku redaktora fokusa pārvaldība un tastatūras atbalsts parasti ir labāki nekā klasiskā redaktora veidņu lauki. Bet jums joprojām ir jānodrošina, lai paraugiem būtu pareiza virsrakstu hierarhija un pieejami nosaukumi. Tā kā paraugs ir kopīgs visiem klientiem, šīs problēmas labojat tikai vienu reizi, kas ir vēl viens slēpts standartizācijas ieguvums.

Patiesi grūtā daļa ir iekšēja. Jūsu komandai mācīšanās prototipēt ar blokiem prasa atmācīties “dari PHP” ieradumu. Tās ir reālas izmaksas, bet tās ir vienreizējas izmaksas uz vienu cilvēku. Tas nav iemesls izvairīties no pieejas; tas ir iemesls sākt ar vienu paraugu bibliotēku un vienu iecietīgu klientu, pirms ieviest to visur. Neļaujiet frāzei “mani klienti netiek galā ar blokiem” slēpt faktu, ka vēl neesat konfigurējis bloku iestatījumus, lai viņiem izietu pusceļā.

Iebildums “mums jau ir hooki un filtri”

Princips šeit ir: jūs neatmetat hookus; jūs pievienojat slāni virsū. Bloki ir noformējuma robeža; hooki joprojām ir veids, kā ievadīt loģiku. Dinamiska bloka renderēšanas atzvanīšana darbojas PHP, kas nozīmē, ka varat izsaukt tās pašas funkcijas un piemērot tos pašus filtrus, kuriem jau uzticaties.

Iedomājieties spraudni, kas ļauj pievienot “populārā produkta” lauku jebkuram ierakstam, izmantojot filtru. Ar dinamisku bloku varat iekļaut servera renderētu bloku, kas izpilda šo filtru un izvada rezultātu bloka iekšējā apvalkā. Klients ievieto bloku; esošā PHP loģika paveic smago darbu. Nekas netiek izmests. Vēl konkrētāks piemērs: pielāgots bloks, kas uzskaita jaunākos projektu ierakstus. Tā renderēšanas atzvanīšanā jūs izsaucat get_posts(), tad iterējat un lietojat the_title() un the_permalink()—tos pašus veidņu tagus, ko izmantojat gadiem.

Šī ir arī vieta, kur būt godīgiem par to, kas netiek pārnests. Dažas gudras vecās tēmas izmanto template-parts ar sarežģītiem nosacījumiem, kas pieņem argumentus atkarībā no lapas konteksta. To atjaunot kā bloku var būt sarežģīti. Bet jums tas viss nav jāatjauno uzreiz. Pakāpeniskais ceļš ir saglabāt PHP loģiku, ietīt to dinamiskā blokā un pārvietot marķējumu bloka veidnē. Bieži vien atklāsiet, ka esošie filtru modeļi var apstrādāt jauno izvadi. Un, ja loģika ir cieši saistīta ar veidņu hierarhiju (piemēram, “meklēšanas rezultātos rādīt citādi”), jūs joprojām varat izmantot klasisko veidni šiem konkrētajiem skatiem, bet parastajām lapām izmantot blokus.

REST API paver arī citu durvis: varat veidot blokus, kas iegūst datus no citām WordPress vietnēm vai trešo pušu pakalpojumiem. Dinamisks bloks var izsaukt wp_remote_get(), lai iegūtu JSON un renderētu to priekšgalā. Tas ir spēcīgs modelis aģentūru izstrādē, kur klienti vēlas rādīt sociālo tīklu plūsmas, produktu sarakstus vai iekšējos datus, neveidojot atsevišķu integrāciju. Kompromiss ir kešošana un kļūdu apstrāde—ja attālais API ir lēns, jūsu lapa ir lēna. Turiet API balstītus blokus prom no kritiskā satura, kas redzams uzreiz, vai izmantojiet klienta puses renderēšanu ar atbilstošu ielādes stāvokli.

Darbības un filtri joprojām darbojas saglabāšanas un renderēšanas laikā; hooku arhitektūra nepazūd, kad izmantojat blokus, tā vienkārši pāriet uz jaunu kontekstu. Ja nepieciešams atsvaidzināt izpratni par to, kur darbības un filtri saskaras ar šo jauno bloku pasauli, mūsu padziļinātais apskats par hookiem ir noderīgs atsvaidzinājums.

Iebildums “FSE nav gatavs ražošanai”

Pieņemams, bet pajautājiet, ko “riskants” patiesībā nozīmē. Full Site Editing ir izgājis vairākus laidienus, un theme.json ir nostabilizējies stabilā shēmā. Risks nav tas, ka redaktors “pēkšņi salūzt”—risks ir tas, ka jūsu komandas pielāgotais kods var paļauties uz vecā stila PHP veidnēm, kas neveikli sadzīvo ar bloku veidnēm. Turklāt daži trešo pušu spraudņi joprojām pieņem klasisko redaktoru vai pielāgotāju. Tas ir saderības lēmums, nevis iemesls izmest visu modeli.

Noderīgs veids, kā par to domāt: vienkāršas, atkārtojamas vietnes ar saturu, kas rakstīts blokos, ir vismazāk riskantas. Augsta riska klienti ir tie, kuriem ir dziļi pielāgotas klasiskās tēmas vai patentēti spraudņi, kas paši renderē savu priekšgalu. Tas ir pamatots iemesls palikt pie klasiskajām tēmām šajā mazajā nišā. Kļūda ir izlikties, ka “gatavs ražošanai” ir viens slēdzis, kas ir vai nu ieslēgts, vai izslēgts.

Pirms piedāvājat klientam bloku tēmu, iziet cauri ātrai pārbaudes lapai:

• Vai klientam ir dziļi pielāgota tēma, kurai būs nepieciešama migrācija?
• Vai obligātie spraudņi atbalsta Site Editor un REST API?
• Vai mitināšanas vide ļauj piekļūt failiem, ko sagaida bloku tēma?
• Vai esat atvēlējis laiku paraugu dizainam, ne tikai bloku reģistrācijai?
• Vai klienta komanda pieņems redaktora izmaiņas, vai viņiem ir nepieciešama bloķēta veidne?

Ja kāda atbilde ir nē, pielāgojiet apjomu vai izmantojiet hibrīda pieeju. Tas nav kompromiss; tas ir inženiertehnisks lēmums. Un, ja veidojat hibrīdu, atcerieties iepriekš stāstu par hookiem un filtriem—jūs joprojām varat ietīt veco loģiku dinamiskajos blokos, kamēr theme.json rūpējas par globālo izskatu.

Jūsu theme.json versiju pārvaldība nav tikai teorētiska problēma. Esmu redzējis, kā aģentūras pielāgoto bloku bibliotēka sabojājas, kad klients atjaunina WordPress un tiek mainīts bloka style faila identifikators, kas reģistrēts ar wp_register_style(). Labojums bija vienkāršs, bet panika bija īsta. Vienkāršs testēšanas process—veiciet atjauninājumu vietnes testa kopijā, noklikšķiniet cauri galvenajām lapām, tad publicējiet—atrisina lielāko daļu šo pārsteigumu.

Iebildums, ko neesat izteicis sev

Šeit ir meta-iebildums, kas attur aģentūras no standartizācijas: “Tas ir liels pārmaiņu process, un klientu darbu laikā tam nav laika.” Tā ir taisnība—tāpēc nedariet to klientu darbu laikā. Izvēlieties iekšējo projektu vai mazu klientu un izveidojiet vienu paraugu bibliotēku. Izmantojiet theme.json kā dizaina tokenu sistēmu. Pievienojiet pielāgotu bloku tikai tad, kad tas ir attaisnojams. Ietiniet vecos hookus tur, kur tie palīdz. Atkārtojiet.

Šeit ir aptuvens pirmo 30 dienu plāns:

1. Izvērtējiet savus pēdējos piecus klientu projektus un uzskaitiet desmit visbiežāk atkārtotās izkārtojuma daļas.
2. Pārvērtiet šīs desmit daļas par bloku paraugiem ar nelielu CSS klašu kopu.
3. Izveidojiet koplietotu spraudni (vai mu-spraudni), kas reģistrē šos paraugus. Ja vēl neesat domājis par spraudņu organizāciju, vispirms ieskatieties šajā ceļvedī par stabilu WordPress spraudņu veidošanu.
4. Izveidojiet vienu theme.json, kas atbilst jūsu bāzes dizainam; pievienojiet klientam specifiskas vērtības, sākot projektus.
5. Izvēlieties vienu nelielu iekšējo projektu vai draudzīgu klientu un migrējiet to uz šo tehnoloģiju komplektu.
6. Dokumentējiet vienu veiksmes stāstu par klientu, kurš rediģēja savu mājaslapu, nezvanot jums.

Šī eksperimenta beigās jums nebūs “bloku-pirmā” nozīmītes, ko pakārt pie sienas. Jums būs komanda, kas var ātri izveidot jaunu klienta vietni no kopīgas bāzes līnijas, neatvainojoties par termiņiem. Jūs būsiet arī labākā pozīcijā, lai pateiktu nē klienta lūgumam pēc 42. pielāgotā bloka—jo jūs precīzi zināt, ko pamata bloki var paveikt, vai arī tāpēc, ka varat parādīt, kāpēc dinamisks bloks patiešām būtu ātrāks.

Vai jūs joprojām veidosiet dažas individuālas vietnes? Jā. Dažiem klientiem vienmēr būs nepieciešama pielāgota veidne, individuāla lapa vai patentēta integrācija, ko nav vērts iespiest koplietotajā modelī. Mērķis nav likvidēt individuālo darbu—tas ir padarīt to par izņēmumu, nevis noklusējumu.

Atkārtojamība nāk no garlaicīgajām daļām: stabila theme.json shēma, skaidra paraugu bibliotēka un disciplīna uzturēt koplietoto slāni bez liekā. Tā nav spožā versija, ko dzirdat vebināros. Tā ir tā, kas pārvar pirmdienas rīta tukšās tēmas blūzu.