Lopeta jokaisen WordPress-sivuston uudelleenrakentaminen

Yhteenveto

Useimmat toimistot rakentavat jokaisen WordPress-sivuston tyhjästä teemasta, vaikka yhteinen perusta säästäisi viikkoja aikataulusta. Tämä artikkeli väittää, että theme.json, lohkokuvioita ja dynaamiset lohkot mahdollistavat rakenteellisen kerroksen standardoinnin säilyttäen samalla jokaisen asiakkaan omaperäisen muotoilun. Se käsittelee suoraan viittä vastaväitettä, jotka estävät tiimejä muuttumasta: "meillä on erilaisia asiakkaita", "mukautetut lohkot ovat kalliita", "editori on hämmentävä", "menetämme hookimme ja suodattimemme" ja "FSE ei ole tuotantovalmis". Jokainen vastaväite saa käytännön vasta-argumentin ja konkreettisen kuvion, jonka voit ottaa käyttöön asteittain. Palkkio on toistettava rakennusprosessi, joka kunnioittaa edelleen räätälöityä työtä siellä, minne se kuuluu. Varoitus: yhden napsautuksen palautuspainikkeita ei luvata.

Kuinka moni asiakassivustosi jakaa edes yhden koodirivin? Ei tekijänoikeusriviä – vaan varsinaista koodia. Jos vastaus on "tuskin yhtäkään", olet jo tuntenut kivun: sama hero-osio rakennettu yhdeksättä kertaa, sama tiimiruudukon markup kopioitu projektista toiseen, samat esikäsittelyviilaukset ristiviitattuna puolen tusinan teeman kesken. Olet myös kuullut puolustuksen: "Jokaisella asiakkaalla on erilaiset tarpeet." Totta. Mutta johtopäätös, jonka kaikki vetävät – että jokainen sivusto tarvitsee räätälöidyn perustan – on väärä. WordPress-ekosysteemi antaa nyt keinon standardoida rakenteelliset osat standardoimatta muotoilua: theme.json suunnittelutokeneille, lohkokuvioita toistuville asetteluille ja dynaamiset lohkot niille harvoille ominaisuuksille, jotka tarvitsevat oikeaa palvelinpuolen logiikkaa. Tämä artikkeli käsittelee vastaväitteitä, jotka estävät toimistoja ottamasta tätä askelta, ja sitä, mikä todella toimii, kun niitä vastaan työntää.

"mutta jokainen asiakas on erilainen" -vastaväite

Taustalla oleva periaate: standardoi perusta, ei pintaa. Syy pitää rakenne jaetussa kirjastossa on juuri se, että visuaalinen kerros jää vapaaksi. Theme.json-tiedosto ei ole muotoilu – se on joukko suunnittelutokeneita. Värit, välit ja typografia ovat arvoja, eivät merkintöjä. Tämä on kriittinen muutos: voit jakaa markupin, kun taas sivustokohtainen theme.json saa sivuston näyttämään täysin erilaiselta eri brändille.

Otetaan kaksi asiakasta: asianajotoimisto ja ulkoiluvälineiden jälleenmyyjä. Heidän muotokielensä ovat maailmojen päässä toisistaan. Mutta molemmat tarvitsevat hero-osion, suositusruudukon ja toimintakehotusnauhan. Sen sijaan, että rakentaisit merkinnät uudelleen kummallekin, ylläpidä kolmea lohkokuvioita ja anna kunkin asiakkaan theme.jsonin määritellä värit, fontit ja välit. Rakenne pysyy identtisenä; suunnittelutokenit muuttavat sen brändistä toiseen. Kun jälleenmyyjä vaihtaa väripalettiaan ensi keväänä, muokkaat yhtä tiedostoa heidän sivustossaan – et markupia kuudessa mallipohjassa.

Käytännössä tämä tarkoittaa, että tiimisi luo lohkokuvioita koodina, rekisteröi ne jaettuun lisäosaan ja antaa theme.jsonin hoitaa maalauksen kullakin asiakassivustolla. Kuvion luokkanimet muodostuvat arkkitehtuuriksi; arvoista tulee muuttujia. Voit jopa mennä pidemmälle ja laajentaa theme.jsonia sisältämään mukautettuja asetuksia sisältötyypeille tai lisäosan tulosteelle, vaikka jossain vaiheessa rakennatkin konfigurointiliittymän sivuston sijaan – ansa, jota käsitellään katsauksessamme theme.jsonin laajentamiseen. Pidä jaettu kerros kevyenä: sen tulisi sisältää vain se, mikä toistuu asiakkailla. Heti kun huomaat lisääväsi asetuksen "jos joku joskus haluaa sen", olet luonut abstraktion, joka maksaa enemmän ylläpitää kuin säästää.

Kun otat käyttöön uuden asiakkaan, ensimmäisen kolmenkymmenen minuutin tulisi olla: kloonaa jaetut lohkokuvioita sisältävä lisäosa, luo uusi theme.json asiakkaan paletilla ja kirjasinasteikolla sekä rekisteröi heidän logonsa ja alatunnisteensa. Se ei ole räätälöity rakennus; se on konfigurointitehtävä. Loput asiakaskohtaiset työt menevät sisältöön, rakenteeseen ja mahdollisiin aidosti räätälöityihin ominaisuuksiin. Tämä on ero sen välillä, että rakennat jokaisen talon alusta alkaen, ja että käytössäsi on joukko esivalmistettuja pohjapiirroksia, jotka voit maalata ja tapetoida uudelleen. Vertaus on löysä, mutta periaate pätee: mitä enemmän siirrät theme.json-arvoihin, sitä vähemmän joudut koskemaan merkintöihin.

Yksi yksinkertaisimmista voitoista on tutkia, miten lohkokuvioita toimivat. Kuvio on vain kokoelma lohkoja, joilla on ennalta määritetty sisältö ja tyyli. Voit tallentaa minkä tahansa lohkokonfiguraation kuvioksi, ja asiakas voi lisätä sen tietämättä, miten se on rakennettu. Tämä tarkoittaa, että kuvio tulee "sisäänkäyntipisteeksi" ei-teknisille käyttäjille. Kun tiimisi ylläpitää taustalla olevaa kuviota koodissa, asiakas saa johdonmukaisen kirjaston koskematta yhteenkään PHP-tunnisteeseen.

Nyt se varoitus, johon palaan jatkuvasti: älä keskellä liikaa. Theme.json, jossa on asetus jokaiseen kuviteltavissa olevaan vivahteeseen, on ylläpidon suo. Jaettujen kuvioiden tulisi olla mielipiteellisiä, eivät kaikkivoipia. Jos asiakas tarvitsee täysin erilaisen asettelun – sanotaan aikakauslehtityylinen etusivu isolla esittelyruudukolla – he eivät ehkä sovi tavalliseen kuviokirjastoosi. Se on okei. Standardointi tarkoittaa, että voitat 80 % projektista, jotka ovat samankaltaisia, etkä sitä, että pakotat jokaisen sivuston samaan muottiin.

"mukautetut lohkot räjäyttävät budjetin" -vastaväite

Tässä on vastaperiaate, joka kuulostaa tylsältä mutta säästää rahaa: useimmat asiat, joiden luulet tarvitsevan mukautettua lohkoa, eivät tarvitse. Ydinlohkot plus kuvio kattavat ylivoimaisen enemmistön asetteluista. Mukautettu lohko on viimeinen keino, ei ensimmäinen aikomus.

Klassinen esimerkki on tiimiruudukko. Jos se on kertaluonteinen, käytä ydin "sarakkeet"- ja "ryhmä"-lohkoja ja anna asiakkaan lisätä profiilikuva käsin. Jos kolme asiakasta pyytää samaa ruudukkoa samalla "sosiaaliset linkit nimen alla" -rakenteella, sinulla on nyt ehdokas lohkokuviolle. Kun kuvio alkaa kerätä uusia vaihtoehtoja – hover-efektit, lajittelu, arviointitähdet – kuviosta tulee hallitsematon sekasäkki, ja sitten on aika kirjoittaa mukautettu lohko. Budjettia vahingoittava virhe on hypätä suoraan mukautettuun lohkoon ensimmäisestä pyynnöstä.

Viekkaampi skenaario: asiakas pyytää "tapaustutkimuskarusellia". Ensimmäinen vaisto on ajatella: "Tarvitsen karusellilohkon." Mutta tarvitsevatko he karusellia? Ehkä he tarvitsevat vaakasuunnassa vieritettävän ryhmän julkaisuja, jonka ydinlohkot hoitavat "ryhmä"-lohkolla ja vähän CSS:ää. Tai ehkä he tarvitsevat dynaamisen listan viimeisimmistä tapaustutkimuksista, joka on dynaaminen lohko, joka hakee CPT:n. Kysymys ei ole "mitä ominaisuutta asiakas haluaa?" vaan "mistä datasta se riippuu?" Jos data on staattista ja asiakkaan muokattavissa, kuvio riittää. Jos data tulee tietokantakyselystä, dynaaminen lohko on perusteltu. Jos data pitää päivittää reaaliajassa API:sta, saatat tarvita REST API -integraation – se menee erilaiseen rakennustyyppiin.

Kun rakennat lohkon, block.json on ystäväsi. Se on yksi totuuden lähde attribuuteille, skripteille ja tyyleille, mikä tekee lohkosta siirrettävän projektien välillä. Sen avulla voit myös ilmoittaa riippuvuudet ja käännökset siististi, mikä on olennaista, kun jaat kirjaston useille asiakassivustoille. Sisällölle, joka riippuu reaaliaikaisesta datasta, dynaaminen lohko renderöityy palvelimella, joten sinun ei tarvitse toimittaa JavaScript-pakettia jokaisella sivunäkymällä. Ja jos lohkosi kehittyy, voit käsitellä vanhentamiset tyylikkäästi, jotta olemassa oleva sisältö ei rikkoudu – oppaamme lohkon vanhentamiseen käy läpi tarkan kuvion.

Ennen kuin rakennat mitään, aja päätös tämän ruudukon läpi:

Lähestymistapa	Paras tilanteisiin	Vältä, kun
Ydinlohko	Kertaluonteinen sisältö, yksinkertaiset sivut	Asettelu toistuu monilla asiakkaille ja tarvitsee runsaasti vaihtoehtoja
Lohkokuvio	Toistuvat asettelut ilman logiikkaa	Asettelu tarvitsee ehtoja, dynaamista dataa tai monimutkaisia vuorovaikutuksia
Mukautettu lohko	Toistuva, datavetoinen tai erittäin spesifinen käyttäytyminen	Ainoa syy on kertaluonteinen osio, joka voidaan hoitaa luokalla

Sinun kannattaa myös miettiä lohkon nimeämistä ensimmäisestä päivästä alkaen. Lohkon nimi on olennaisesti sopimus sisältösi kanssa. Jos kutsut sitä wagent/team-grid ja myöhemmin nimeät sen wagent/team-carousel, rikot olemassa olevan sisällön, ellet tarjoa vanhentamispolkua. Valitse yleisluontoiset, tarkoitukseen perustuvat nimet, joista ei tule harhaanjohtavia mainoksia lohkon kehittyessä. Tämä on osa nimeämiskuria, jonka olemme kaikki oppineet lisäosan etuliitteistä, ja se pätee yhtä lailla lohkon nimiin.

Vastakkaisin näkökulma on hyödyllisin asia, jonka voin sanoa: mukautettu lohko, jonka rakennat, koska asiakas pyysi "vain yhtä osaa", on melkein aina virhe. Sano ei kohteliaasti, toimita ydinlohko luokalla ja talleta tunnit. Saat enemmän kunnioitusta asiakkaalta – ja pienemmän rivin ylläpitobudjetissa.

"asiakkaat rikkovat editorin" -vastaväite

Tämä vastaväite on puoliksi oikeassa. Lohkoeditori itsessään ei ole ongelma; ongelma on antaa asiakkaille liikaa köyttä. theme.json voi lukita sen, mikä on muokattavissa: poista template-editori käytöstä, rajoita sallittuja lohkoja ja aseta oletustyylit, jotta väärään paikkaan sijoitettu sarake aiheuttaa vähemmän vahinkoa. Jotkut asiakkaat onnistuvat silti rikkomaan asioita, mutta voit pyyhkiä sivun takaisin tallennettuun kuvioon yhdellä napsautuksella – jotain, mitä klassinen editori ei voinut tarjota.

Annan esimerkin. Asiakas soittaa ja sanoo: "Siirsin osion ja nyt koko sivu näyttää väärältä." Klassisella teemalla kirjautuisit sisään, tutkisit CSS:n ja käyttäisit todennäköisesti tunnin asettelun korjaamiseen. Lohkoasetelmassa voit avata sivun, valita sisältöalueen ja palauttaa sen tallennettuun kuvioon. Kuvio on perustaso; asiakkaan muutokset ovat päällimmäinen kerros. Kun päällimmäinen kerros menee pieleen, poistat sen. Tämä ei ole vain mukavampi työnkulku; se on pohjimmiltaan anteeksiantavampi editori.

Nyt vivahteeseen: useimmat asiakkaat eivät halua muokata paljoakaan. He haluavat muuttaa tekstiä, vaihtaa kuvia ja ehkä järjestää osion uudelleen. Lohkokuvio antaa juuri sen paljastamatta koko sivuston rakennetta. Tässä mielessä editori ei ole lelu; se on etsin. Sinun tehtäväsi on kalibroida, mitä asiakkaat voivat nähdä. Se tarkoittaa, että saatat poistaa "Mallit"-asetukset käytöstä, rajoittaa lohkojen lisääjän kuratoituun luetteloon ja jopa esitäyttää tyhjät kuviot paikanpitäjäsisällöllä. Editorista tulee sisällön syöttölomake verkkosuunnittelukankaan sijaan.

Saavutettavuuden puolella lohkoeditorin kohdistuksenhallinta ja näppäimistötuki ovat yleensä parempia kuin klassisen editorin mallipohjakentät. Mutta sinun on silti varmistettava, että kuvioissa on asianmukainen otsikkohierarkia ja saavutettavat nimet. Koska kuvio on jaettu asiakkaiden kesken, korjaat nämä ongelmat vain kerran, mikä on toinen standardoinnin piilotettu voitto.

Todella vaikea osa on sisäinen. Tiimillesi lohkoilla prototyyppien tekemisen oppiminen vaatii "tee se PHP:ssä" -tavan poisoppimista. Se on todellinen kustannus, mutta se on kertaluonteinen kustannus per henkilö. Se ei ole syy välttää lähestymistapaa; se on syy aloittaa yhdellä lohkokuvio kirjastolla ja yhdellä anteeksiantavalla asiakkaalla ennen kuin otat sen käyttöön kaikkialla. Älä anna "asiakkaani eivät osaa käsitellä lohkoja" -mantran piilottaa tosiasiaa, ettet ole vielä määrittänyt lohkoasetelmaa kohtaamaan heidät puolivälissä.

"meillä on jo hookit ja suodattimet" -vastaväite

Periaate tässä on: et heitä hookeja pois; lisäät kerroksen päälle. Lohkot ovat esityksen raja; hookit ovat edelleen tapa, jolla lisäät logiikkaa. Dynaamisen lohkon render callback toimii PHP:ssä, mikä tarkoittaa, että voit kutsua samoja funktioita ja soveltaa samoja suodattimia, joihin jo luotat.

Kuvittele lisäosa, jonka avulla voit lisätä "esitelty tuote" -kentän mihin tahansa julkaisuun suodattimen avulla. Dynaamisella lohkolla voit sisällyttää palvelinpuolella renderöidyn lohkon, joka suorittaa suodattimen ja tulostaa tulosteen lohkon sisälle. Asiakas lisää lohkon; olemassa oleva PHP-logiikka tekee raskaan työn. Mitään ei heitetä pois. Vielä konkreettisempi esimerkki: mukautettu lohko, joka listaa viimeisimmät projektijulkaisut. Sen render callbackissa kutsut get_posts(), sitten loopissa käytät the_title() ja the_permalink() – samoja template-tageja, joita olet käyttänyt vuosia.

Tämä on myös paikka olla rehellinen siitä, mikä ei käänny. Jotkut näppärät vanhat teemat käyttävät template-parts-osia monimutkaisine ehtoineen, jotka ottavat argumentteja sivun kontekstin perusteella. Sen uudelleenluominen lohkona voi olla sotkuista. Mutta sinun ei tarvitse luoda sitä uudelleen kerralla. Asteittainen polku on säilyttää PHP-logiikka, kääriä se dynaamiseen lohkoon ja siirtää merkinnät lohkomallipohjaan. Huomaat usein, että olemassa olevat suodatuskuviot pystyvät käsittelemään uuden tulosteen. Ja jos logiikka on tiukasti sidottu mallipohjahierarkiaan (esim. "hakutuloksissa näytä tämä eri tavalla"), voit silti käyttää klassista mallipohjaa näissä tietyissä näkymissä ja käyttää lohkoja tavallisilla sivuilla.

REST API avaa myös toisen oven: voit rakentaa lohkoja, jotka hakevat dataa muilta WordPress-sivustoilta tai kolmannen osapuolen palveluista. Dynaaminen lohko voi kutsua wp_remote_get() hakeakseen JSON:ia ja renderöidäkseen sen etupuolella. Tämä on tehokas kuvio toimistorakennuksille, joissa asiakkaat haluavat näyttää sosiaalisen median syötteitä, tuotelistoja tai sisäistä dataa hallinnoimatta erillistä integraatiota. Kompromissi on välimuisti ja virheiden käsittely – jos etä-API on hidas, sivusi on hidas. Pidä API-pohjaiset lohkot pois kriittisestä yläpuolisesta sisällöstä tai käytä asiakaspuolen renderöintiä asianmukaisella lataustilalla.

Toiminnot (actions) ja suodattimet toimivat edelleen tallennuksen ja renderöinnin ympärillä; hook-arkkitehtuuri ei katoa, kun otat lohkot käyttöön, se vain siirtyy uuteen kontekstiin. Jos haluat päivittää ymmärryksesi siitä, missä toiminnot ja suodattimet kohtaavat tämän uuden lohkomaailman, perusteellinen oppaamme hookeista on hyödyllinen kertaus.

"FSE ei ole tuotantovalmis" -vastaväite

Kohtuullista, mutta kysy, mitä "riski" itse asiassa tarkoittaa. Full Site Editing on käynyt läpi useita julkaisuja, ja theme.json on vakiintunut vakaaseen skeemaan. Riski ei ole se, että editori "yhtäkkiä rikkoutuu" – riski on, että tiimisi mukautettu koodi saattaa tukeutua vanhanaikaisiin PHP-mallipohjiin, jotka elävät kömpelösti rinnakkain lohkomallipohjien kanssa. Lisäksi jotkin kolmannen osapuolen lisäosat olettavat edelleen klassisen editorin tai customizerin. Tämä on yhteensopivuuspäätös, ei syy heittää koko mallia pois.

Hyödyllinen tapa ajatella: yksinkertaiset, toistettavat sivustot, joiden sisältö on kirjoitettu lohkoina, ovat vähiten riskialttiita. Korkean riskin asiakkaita ovat ne, joilla on syvästi räätälöityjä klassisia teemoja tai omia lisäosia, jotka renderöivät oman etupään. Tämä on oikeutettu syy pysyä klassisissa teemoissa tuossa pienessä markkinaraossa. Virhe on teeskennellä, että "tuotantovalmis" on yksi kytkin, joka on joko päällä tai pois.

Ennen kuin ehdotat lohkoteemaa asiakkaalle, käy läpi nopea tarkistuslista:

• Onko asiakkaalla vahvasti räätälöity teema, joka vaatisi siirtymisen?
• Tukeeko välttämättömät lisäosat Site Editoria ja REST API:a?
• Salliiko hosting-ympäristö tiedostojen käytön, jota lohkoteema edellyttää?
• Oletko varannut aikaa kuvioiden suunnitteluun, et vain lohkojen rekisteröintiin?
• Sietääkö asiakkaan tiimi editorimuutoksia, vai tarvitsevatko he lukitun mallipohjan?

Jos jokin vastaus on ei, säädä laajuutta tai käytä hybridilähestymistapaa. Se ei ole kompromissi; se on insinööritaidetta. Ja jos rakennat hybridin, muista yllä oleva hookien ja suodattimien tarina – voit yhä kääriä vanhan logiikan dynaamisiin lohkoihin, kun theme.json hoitaa globaalin ilmeen.

Theme.jsonin versiointi ei ole vain teoreettinen huoli. Olen nähnyt toimiston mukautetun lohkokirjaston rikkoutuvan, kun asiakas päivitti WordPressin ja lohkon style-tiedosto rekisteröitiin wp_register_style():lla muuttuneen handlen alle. Korjaus oli helppo, mutta paniikki oli todellinen. Yksinkertainen testiprosessi – suorita päivitys sivuston staging-kopioon, klikkaile läpi keskeiset sivut ja julkaise sitten – ratkaisee suurimman osan yllätyksistä.

Vastaväite, jota et ole esittänyt itsellesi

Tässä on meta-vastaväite, joka estää toimistoja standardoimasta: "Se on iso muutos, eikä sille ole aikaa asiakastyön aikana." Se on totta – joten älä tee sitä asiakastyön aikana. Valitse sisäinen projekti tai pieni asiakas ja rakenna yksi kuviokirjasto. Käytä theme.jsona suunnittelutokenijärjestelmänä. Lisää mukautettu lohko vain, kun se on perusteltua. Kääri vanhat hookit sinne, missä niistä on apua. Iteroi.

Tässä on karkea ensimmäinen 30 päivää:

1. Auditoi viimeiset viisi asiakasrakennusta ja listaa kymmenen eniten toistuvaa asettelun osaa.
2. Muuta nämä kymmenen osaa lohkokuvioiksi pienellä CSS-luokkien joukolla.
3. Rakenna jaettu lisäosa (tai mu-plugin), joka rekisteröi nämä kuviot. Jos et ole miettinyt lisäosan organisointia tätä varten, silmäile tämä opas vankkojen lisäosien rakentamiseen ensin.
4. Luo yksi theme.json, joka vastaa perusmuotoiluasi; lisää asiakaskohtaiset arvot projektien käynnistyessä.
5. Valitse pieni sisäinen projekti tai ystävällinen asiakas ja siirrä se pinoon.
6. Dokumentoi yksi sankaritarina asiakkaasta, joka muokkasi etusivuaan soittamatta sinulle.

Kokeilun lopussa sinulla ei ole "block-first" -merkkiä seinälle. Sinulla on tiimi, joka voi pystyttää uuden asiakassivuston jaetulta perustalta ilman aikataulusta anteeksipyytelyä. Olet myös paremmassa asemassa sanomaan ei asiakkaan pyynnölle 42. mukautetusta lohkosta – koska tiedät tarkalleen, mitä ydinlohkot pystyvät tekemään, tai koska voit osoittaa, miksi dynaaminen lohko olisi aidosti nopeampi.

Rakennatko edelleen joitakin räätälöityjä sivustoja? Kyllä. Jotkut asiakkaat tarvitsevat aina mukautetun mallipohjan, räätälöidyn sivun tai oman integraation, jota ei kannata pakottaa jaettuun malliin. Tavoitteena ei ole poistaa räätälöityä työtä – se on tehdä siitä poikkeus oletuksen sijaan.

Toistettavuus tulee tylsistä osista: vankka theme.json-skeema, selkeä kuviokirjasto ja kuri pitää jaettu kerros kevyenä. Se ei ole kiiltävä versio, josta kuulet webinaareissa. Se on se, joka voittaa maanantaiaamun tyhjän teeman bluesin.