Asiakkaalle turvallinen Site Editor: theme.json-pelikirja

Yhteenveto

Kun asiakas avaa WordPressin Site Editorin ensimmäistä kertaa, mahdollisuus muokata jokaista lohkoa, väriä ja asettelua voi tuntua hänestä ominaisuudelta — ja sinusta uhkalta. Tämä artikkeli selittää, miten theme.json-tiedostolla vedetään selkeä raja sisällön muokkauksen ja suunnittelun hallinnan välille. Sen sijaan, että taistelisit Site Editoria vastaan, määrität esiasetukset, oletusarvot ja rajat, joiden avulla ei-tekniset asiakkaat voivat päivittää omaa sivustoaan turvallisesti. Käymme läpi, mitä kannattaa lukita, mitä jättää avoimeksi ja miksi ylilukitseminen on todellinen riski. Lähestymistapa perustuu suunnittelutokeneihin ja mallipohjatason rajoitteisiin, joten se toimii johdonmukaisesti kaikilla ylläpitämilläsi asiakassivustoilla. Lopuksi sinulla on toistettava työnkulku Site Editorin luovuttamiseen ilman, että luovutat avaimet koko suunnittelujärjestelmääsi.

Mikä on ensimmäinen asia, jonka teet, kun asiakas sähköpostitse kertoo "yrittäneensä vain päivittää otsikkoa" ja koko sivuston välistys on romahtanut?

Jos ylläpidät useampaa kuin yhtä WordPress-sivustoa, olet todennäköisesti saanut tuon viestin jossain muodossa. Site Editor antoi asiakkaallesi avaimet autoon, jossa on viisi vaihdetta eikä jarrua. Hän luulee tekevänsä yksinkertaisen tekstimuutoksen, ja yhtäkkiä globaali typografia on pielessä, kotisivun hero-osiossa on neonväri, jota et valinnut, ja kaksi lohkoa on pinottu päällekkäin vierekkäisen sijaan.

Sillä välin ajattelet kuutta muuta ylläpitämääsi asiakassivustoa, ja viimeinen asia, jota tarvitset, on ylläpitoansa, jossa jokainen "avulias" asiakkaan muokkaus vaatii palautuksen varmuuskopiosta.

Vastaus ei ole Site Editorin poistaminen käytöstä. Se on rajojen asettaminen sen sisälle theme.json-tiedoston avulla. WordPress Developer Resources -dokumentaation mukaan theme.json on lohkomuokkaimen asetusten ja tyylien keskeinen lähde — se määrittää väripaletit, typografian ja asetteluvaihtoehdot, jotka näkyvät asiakkaalle. Tämä tarkoittaa, että sama tiedosto, joka hallitsee suunnitteluasi, voi hallita myös sitä, mitä asiakas voi ja ei voi muokata.

Käydään läpi, miten tästä kannattaa ajatella, koska useimmat opetusohjelmat keskittyvät siihen, mitä theme.json voi tehdä kehittäjille. Toimiston näkökulmasta kysymys on erilainen: miten käytämme sitä varmistaaksemme, että asiakkaat eivät riko sivustoa ilman, että he kokevat olevansa ahtaalla?

Miksi Site Editor tuntuu niin vaaralliselta?

Asiakkaasi ei yritä rikkoa sivustoa. Hän yrittää tehdä sitä, mihin olet kouluttanut häntä vuosia vanhassa muokkaimessa: vaihtaa otsikon, vaihtaa kuvan tai lisätä kappaleen. Vaara ei ole hänen tarkoituksensa — vaan se, että Site Editor tuo globaalit hallinnat samaan paikkaan kuin sisältöön liittyvät hallinnat.

Tässä on tyypillinen skenaario. Asiakas avaa mallipohjan Site Editorissa ja näkee otsikkolohkon. Hän vaihtaa sen värin vastaamaan uutta brändiväriä. Mutta koska otsikko on mallipohjassa, muutos koskee kaikkia paikkoja, joissa mallipohjaa käytetään. Asiakkaasta se näytti yhdeltä muokkaukselta. Sivustolle se oli globaali muutos.

Yleinen periaate: kun annat jollekkin sivunrakentimen, hän löytää ennen pitkää "suojakaiteilla varustetut asetukset" ja kytkee ne pois päältä. Mutta theme.json-tiedoston avulla voit piilottaa itse suojakaiteet. Sen sijaan, että sanoisit asiakkaalle "älä koske globaaleihin tyyleihin", et yksinkertaisesti näytä hänelle väripalettia, joka voi tuottaa huonon lopputuloksen. Määrittelet hyväksyttyjen värien paletin, fonttikokojen asteikon ja joukon välistysesiasetuksia — ja asiakas valitsee niistä, ei koko CSS-spektristä.

Tämä on ensimmäinen muutos: lopeta sääntöjen ajatteleminen ja ala ajatella tehtaita. theme.json on sinun tuotantolinjasi. Määrität vaihtoehdot, jotka asiakas näkee, ja rajoitteet toteuttaa käyttöliittymä itse, eivätkä ne ole ohjeita luovutusdokumentissa.

Mitä sinun oikeasti kannattaa lukita?

Ei kaikkea. Jos lukitset sisältöalueen liian tiukasti, asiakas joko soittaa sinulle joka kerta, kun hänen täytyy lisätä kappale, tai löytää tien ympäri — usein asentamalla kertaluontoisen lisäosan tai kopioimalla HTML:ää vanhalta sivustoltaan.

Tässä on käytännön taulukko siitä, mitä lukita, mitä jättää avoimeksi ja miksi:

Muokkauspinta	Lukitaanko?	Miksi
Mallipohjan rakenne ja lohkoasettelut	Lukitaan	Estää ydinasettelulohkojen vahingossa poistamisen tai uudelleenjärjestämisen
Globaalit tyylit (värit, fontit, välistysesiasetukset)	Lukitaan esiasetuksilla	Asiakkaat valitsevat hyväksytystä joukosta, eivät mielivaltaisia arvoja
Sisällön tekstit ja kuvat	Jätetään avoimeksi	Tämä on heidän tehtävänsä; anna heidän tehdä se ilman lupaa
Lohkojen välinen välistys	Osittain lukitaan	Tarjoa välistysesiasetukset, jotta he voivat säätää rytmiä rikkomatta kohdistusta
Kuratoidut lohkokuviot	Jätetään avoimeksi, jos ne on tarkistettu	Turvallinen tapa lisätä uusia osioita ilman alusta aloittamista

Tärkeä vivahde on "lukitseminen esiasetuksilla", ei "täysi uloslukitus". Globaalien tyylien kohdalla et piilota asetuspaneelia; vähennät valintojen määrän kuratoituun joukkoon. Mallipohjan rakenteessa voit lukita tiettyjä lohkoja, jotta niitä ei voida poistaa, mutta sallit silti asiakkaiden muokata niiden sisällä olevaa tekstiä.

Yksi varoituksen sana: lohkon lukitseminen mallipohjassa on eri asia kuin sen lukitseminen tietyllä sivulla. Mallipohjan lukitukset vaikuttavat kaikkeen sisältöön, joka käyttää kyseistä mallipohjaa. Jos tarvitset eri lukitustasoja eri sivuille, sinun on työskenneltävä lohkotasolla muokkaimen sisällä, mikä on hauraampaa. Toistuvassa toimistotyössä suunnittele mallipohjasi niin, että lukitut alueet ovat yhtenäisiä.

Miten asetat rajat ilman, että muokkain tuntuu ansalta?

Tekniikka on määritellä suunnittelutokenit theme.json-tiedostossa ja sitten pidättäytyä tekemästä mitään muuta CSS:ssä.

Jos esimerkiksi et anna asiakkaan asettaa mielivaltaista väriä painikkeelle, määrität theme.json-tiedostossa painikkeen tyylin, joka käyttää tiettyä väriä paletistasi. Asiakas voi edelleen valita painikkeen ja muuttaa sen tekstiä, mutta värien valitsin näyttää vain hyväksytyt värimallit. Sama pätee fonttikokoihin, rivikorkeuksiin ja välistykseen.

Sama periaate koskee mallipohjia. Voit käyttää "lukitus"-ominaisuutta mallipohjan tietyissä lohkoissa — esimerkiksi lukita suosituslohkon sarakerakenne, jotta asiakas voi muuttaa lainaustekstiä mutta ei muuttaa kolmea saraketta kahdeksi. Jos et ole vielä käyttänyt lohkon lukitusta, se on saatavissa muokkaimen työkalupalkista; kun lukitset lohkon, voit valita, voiko asiakas muokata sisältöä, siirtää sitä vai molempia. Voit jopa soveltaa tätä theme.json-tiedostossa lohkotason oletuksina.

Tavoitteena on muokkain, jossa asiakas ei koskaan näe hallintaa, joka voisi rikkoa suunnittelun. Se ei tarkoita, etteikö hän voisi tehdä mitään väärin; se tarkoittaa, että pahin väärä asia, jonka hän voi tehdä, on muuttaa otsikon sanamuotoa, ei koko sivuston ilmettä.

Jos käytät mukautettuja sisältötyyppejä, samat periaatteet pätevät oletusmallipohjien lisäksi — katso oppaamme theme.json-tiedoston laajentaminen mukautettuihin sisältötyyppeihin ja lisäosien tulosteisiin.

Mitä tapahtuu, kun lukitset liikaa?

Tässä on vastakkainen näkökulma: ylilukitseminen on yhtä haitallista kuin alilukitseminen. Asiakas, joka ei voi muuttaa otsikon kokoa tai lisätä väliä osioiden väliin, pyytää lopulta sinua "vain laittamaan sen näyttämään oikealta" — ja sitten olet taas tekemässä pieniä muokkauksia ilmaiseksi. Pahempaa: hän saattaa päättää, että Site Editor on hyödytön, ja palata kolmannen osapuolen sivunrakentajaan, joka antaa jälleen liikaa hallintaa.

Tämä kompromissi on todellinen. Lukitut muokkaimet tuottavat vähemmän hätäpuheluita, mutta myös enemmän "voitko siirtää tämän painikkeen viisi pikseliä ylöspäin" -pyyntöjä. Avoimet muokkaimet tuottavat päinvastoin. Sinun tehtäväsi on löytää tasapainopiste jokaiselle asiakkaalle, ei soveltaa yhtä kokoonpanoa kaikille.

Hyvä aloitusheuristiikka: lukitse kaikki, mikä vaikuttaa kaikkiin esiintymiin (globaalit tyylit, mallipohjan rakenne), ja jätä avoimeksi kaikki, mikä vaikuttaa yhteen esiintymään (yhden sivun tekstit ja kuvat). Jos asiakas rikkoo yhden sivun, se on 5 minuutin korjaus. Jos hän rikkoo globaalin tyylin, se on 20 minuutin korjaus ja vakava huolenaihe.

Miten teet tästä toistettavan eri asiakkaiden välillä?

Tässä kohtaa toimiston työnkulku tulee mukaan. Sinulla tulisi olla perustason theme.json, joka määrittelee suunnittelutokenit — väripaletin, typografia-asteikon ja välistysesiasetukset — sekä asiakaskohtainen ohitustiedosto, joka laajentaa tai muuttaa tiettyjä arvoja.

Aloita luomalla aloituslohkoteema. Näin rakennat mukautetun lohkoteeman theme.json-tiedoston avulla — kun olet kehittänyt ja dokumentoinut sen, kopiointi uudelle asiakkaalle on vain brändivärien ja fonttien vaihtamista. Et pyöräytä pyörää uudelleen; vaihdat tokeneja. Tämä on täsmälleen sitä Lopeta jokaisen WordPress-sivuston rakentaminen alusta -ajattelutapaa, mutta sovellettuna muokkaimeen eikä taustajärjestelmään.

Koska theme.json on yksittäinen tiedosto, se on myös helppo versioida ja käyttöönottaa useissa ympäristöissä. Voit tarkistaa muutokset, nähdä, mitä asiakas on muokannut globaaleissa tyyleissä, ja verrata niitä perustiedostoosi. Tämä antaa vahvan jäljityspolun tukipyyntöjä varten.

Jos ylläpidät useita sivustoja etkä ole vielä perustanut perusteemaa, tämä on tilaisuutesi. Se on se yksi mukautetun WordPressin työ, joka maksaa itsensä takaisin joka kerta, kun asiakas avaa muokkaimen.

Entä asiakkaat, jotka pyytävät jatkuvasti "yhtä väriä lisää"?

Palettisi on lupaus. Jos määrittelet viisi brändiväriä ja asiakas pyytää kuudetta, vastaus ei ole "ei" — vaan "kyllä, mutta se lisätään palettiin harkitusti, ei kertakäyttöisenä heksakoodina otsikossa." Kun lisäät värin theme.json-tiedostoon, se tulee saataville koko sivustolla johdonmukaisesti. Se on oikea tapa käsitellä tällaisia pyyntöjä.

Tässä kohtaa sinun on myös kommunikoitava asiakkaan kanssa. Selitä, että Site Editor näyttää heille vain värit ja fontit, jotka vastaavat heidän brändistandardejaan. Jos he haluavat laajentaa standardeja, hoidat sen suunnittelujärjestelmässä, ja sitten jokainen uusi väri on saatavilla kaikkialla — myös tulevilla sivuilla, joita he eivät ole vielä rakentaneet. Se on paljon parempi vastaus kuin "me emme tee sellaista".

Samaan aikaan älä kerää neljänkymmenen värin palettia. Käy se läpi neljännesvuosittain ja poista kaikki, mikä oli kertaluonteinen vahinko. Tavoitteena on pieni, harkittu valikoima vaihtoehtoja.

Jos lukitset asettelun mutta jätät sisällön vapaaksi ja teet paletista elävän osan asiakassuhdettasi, Site Editor lakkaa olemasta uhka. Siitä tulee tapa antaa asiakkaille aitoa itsenäisyyttä tinkimättä niistä suunnittelustandardeista, joita sinulle maksetaan suojellaksesi.