Klienttrygg Site Editor: En theme.json-håndbok

Sammendrag

Når en klient åpner WordPress Site Editor for første gang, kan muligheten til å redigere hver blokk, farge og layout føles som en funksjon for dem – og som en trussel for deg. Denne artikkelen forklarer hvordan du bruker theme.json til å trekke en tydelig linje mellom innholdsredigering og designkontroll. I stedet for å kjempe mot Site Editor, setter du opp forhåndsinnstillinger, standardverdier og grenser som gjør det trygt for ikke-tekniske klienter å oppdatere sitt eget nettsted. Vi går gjennom hva du bør låse ned, hva du bør la være åpent, og hvorfor overlåsing er en reell risiko. Tilnærmingen er bygget rundt design-tokens og begrensninger på malnivå, så den fungerer konsekvent på alle klientnettsteder du vedlikeholder. Når du er ferdig, vil du ha en repeterbar arbeidsflyt for å overlevere Site Editor uten å overlevere nøklene til designsystemet ditt.

Hva er det første du gjør når en klient e-poster for å si at de «bare prøvde å oppdatere overskriften» og hele nettstedets mellomrom har kollapset?

Hvis du vedlikeholder mer enn ett WordPress-nettsted, har du sannsynligvis mottatt den meldingen i en eller annen form. Site Editor ga klienten din nøklene til en bil med fem gir og ingen brems. De tror de gjør en enkel tekstendring, og plutselig er den globale typografien feil, hero-seksjonen på forsiden har en neonfarge du ikke valgte, og to blokker er nå stablet i stedet for side om side.

I mellomtiden tenker du på de seks andre klientnettstedene du støtter, og det siste du trenger er en vedlikeholdsfelle der hver «hjelpsomme» klientredigering krever en gjenoppretting fra sikkerhetskopi.

Svaret er ikke å ta bort Site Editor. Det er å sette grenser inni den ved hjelp av theme.json. Ifølge WordPress Developer Resources er theme.json den sentrale sannhetskilden for innstillinger og stiler i blokkeditoren – den definerer fargepaletter, typografi og layoutalternativer som vises for klienten. Det betyr at den samme filen som styrer designet ditt også kan styre hva klienten din kan og ikke kan redigere.

La oss gå gjennom hvordan du kan tenke på dette, fordi de fleste opplæringsprogrammer fokuserer på hva theme.json kan gjøre for utviklere. Spørsmålet for et byrå er annerledes: hvordan bruker vi det til å gjøre klienter trygge uten at de føler seg begrenset?

Hvorfor føles Site Editor så farlig?

Klienten din prøver ikke å ødelegge nettstedet. De prøver å gjøre det du har trent dem til å gjøre i årevis i den gamle editoren: endre en overskrift, bytte bilde, kanskje legge til et avsnitt. Faren ligger ikke i intensjonen deres – den ligger i at Site Editor viser globale kontroller på samme sted som innholdskontroller.

Her er et vanlig scenario. En klient åpner en mal i Site Editor og ser en overskriftsblokk. De endrer fargen for å matche den nye merkevarefargeprøven. Men fordi overskriften er i en mal, gjelder endringen overalt der malen brukes. For klienten så det ut som én redigering. For nettstedet var det en global endring.

Det generelle prinsippet: når du gir noen en sidebygger, vil de etter hvert finne «innstillingene med rekkverk» og slå dem av. Men med theme.json kan du skjule selve rekkverkene. I stedet for å si til klienten «ikke rør de globale stilene», viser du dem rett og slett ikke en fargepalett som kan gi et dårlig resultat. Du definerer en palett med godkjente farger, en skala for skriftstørrelser og et sett med mellomrom-innstillinger – og klienten velger fra disse, ikke fra hele CSS-spekteret.

Det er det første skiftet: slutt å tenke på regler, og begynn å tenke på fabrikker. theme.json er produksjonslinjen din. Du konfigurerer alternativene klienten ser, og begrensningene håndheves av selve grensesnittet, ikke av et sett med instruksjoner i et overleveringsdokument.

Hva bør du faktisk låse ned?

Ikke alt. Hvis du låser innholdsområdet for stramt, vil klienten enten ringe deg hver gang de trenger å legge til et avsnitt, eller finne en vei rundt deg – ofte ved å legge til et engangsplugin eller kopiere HTML fra det gamle nettstedet sitt.

Her er en praktisk tabell over hva du skal låse, hva du skal la være, og hvorfor:

Redigeringsflate	Låse ned?	Hvorfor
Malstruktur og blokkoppsett	Lås	Hindrer utilsiktet fjerning eller omorganisering av kjernelayoutblokker
Globale stiler (farger, fonter, mellomrom-innstillinger)	Lås med forhåndsinnstillinger	Klienter velger fra et godkjent sett, ikke vilkårlige verdier
Innholdstekst og -bilder	La være åpent	Dette er jobben deres; la dem gjøre det uten å spørre om tillatelse
Mellomrom mellom blokker	Delvis lås	Gi mellomrom-innstillinger slik at de kan justere rytmen uten å ødelegge justeringen
Kuraterte blokkmønstre	La være åpent hvis du har kvalitetssikret dem	En trygg måte for klienter å legge til nye seksjoner uten å bygge fra bunnen av

Den viktige nyansen er «lås med forhåndsinnstillinger», ikke «lås ute». For globale stiler skjuler du ikke innstillingspanelet; du reduserer antallet valg til et kuratert sett. For malstruktur kan du låse bestemte blokker slik at de ikke kan fjernes, men fortsatt la klienter redigere teksten inne i dem.

Ett advarselsord: å låse en blokk i en mal er forskjellig fra å låse den på en bestemt side. Mallåser påvirker alt innhold som bruker malen. Hvis du trenger ulike låsenivåer på ulike sider, må du jobbe på blokknivå inne i editoren, noe som er mer skjørt. For repeterbart byråarbeid, design malene dine slik at de låste områdene er konsistente.

Hvordan setter du grenser uten at editoren føles som en felle?

Teknikken er å definere design-tokens i theme.json og deretter motstå å gjøre noe annet i CSS. For eksempel, i stedet for å la klienten sette en vilkårlig farge på en knapp, definerer du en knappstil i theme.json som bruker en bestemt farge fra paletten din. Klienten kan fortsatt velge knappen og endre teksten, men fargevelgeren viser bare dine godkjente fargeprøver. Det samme gjelder for skriftstørrelser, linjehøyder og mellomrom.

Det samme prinsippet gjelder for maler. Du kan bruke «lås»-funksjonen på bestemte blokker i en mal – for eksempel låse kolonnestrukturen i en testimonials-blokk slik at en klient kan endre sitatteksten, men ikke gjøre tre kolonner om til to. Hvis du ikke har brukt blokklåsing ennå, er den tilgjengelig i editorverktøylinjen; når du låser en blokk, kan du velge om klienten kan redigere innhold, flytte den, eller begge deler. Du kan til og med bruke dette i theme.json for standardverdier på blokknivå.

Målet ditt er en editor der klienten aldri ser en kontroll som kan ødelegge designet. Det betyr ikke at de ikke kan gjøre noe galt; det betyr at det verste gale de kan gjøre er å endre ordlyden i en overskrift, ikke hele nettstedets utseende.

Hvis du bruker egendefinerte innholdstyper, gjelder de samme prinsippene utover standardmalene – se guiden vår om å utvide theme.json til egendefinerte innholdstyper og plugin-utdata.

Hva skjer når du låser for mye?

Her er det kontrære poenget: overlåsing er like skadelig som underlåsing. En klient som ikke kan endre størrelsen på en overskrift eller legge til et mellomrom mellom seksjoner, vil til slutt be deg om å «bare få det til å se riktig ut» – og da er du tilbake til å gjøre små endringer gratis. Verre: de kan bestemme at Site Editor er ubrukelig og gå tilbake til en tredjeparts sidebygger, som gir dem for mye kontroll igjen.

Avveiningen er reell. Nedlåste editorer gir færre nødtelefoner, men de gir også flere «kan du bare flytte denne knappen opp fem piksler»-forespørsler. Åpne editorer produserer det motsatte. Jobben din er å finne balansepunktet for hver klient, ikke å bruke én konfigurasjon universelt.

Et godt utgangspunkt er en tommelfingerregel: lås alt som påvirker alle forekomster av noe (globale stiler, malstruktur), og la alt som påvirker én forekomst (en enkelt sides tekst og bilder) være åpent. Hvis en klient ødelegger en enkelt side, er det en 5-minutters fiks. Hvis de ødelegger en global stil, er det en 20-minutters fiks og et sikkerhetsproblem.

Hvordan gjør du dette repeterbart på tvers av klienter?

Det er her byråarbeidsflyten kommer inn. Du bør ha en base theme.json som definerer design-tokensene dine – fargepaletten, typografiskalaen og mellomrom-innstillingene – og deretter en overstyringsfil per klient som utvider eller endrer spesifikke verdier.

Start med å lage et «starter»-blokktema. Slik bygger du et egendefinert blokktema med theme.json – når du har utviklet og dokumentert det, er det bare å bytte merkevarefarger og fonter når du kopierer det til en ny klient. Du finner ikke opp hjulet på nytt; du bytter ut tokens. Dette er nøyaktig slutt å gjenoppbygge hvert WordPress-nettsted-mentaliteten, men brukt på editoren i stedet for backend.

Fordi theme.json er én enkelt fil, er den også enkel å versjonskontrollere og distribuere på tvers av flere miljøer. Du kan gjennomgå endringer, se hva en klient har endret i de globale stilene, og differe disse endringene mot basisfilen din. Det gir deg et solid revisjonsspor for støtteforespørsler.

Hvis du vedlikeholder flere nettsteder og ikke har satt opp et basistema ennå, er dette sjansen din. Det er det ene stykket med egendefinert WordPress-arbeid som betaler for seg selv hver gang en klient åpner editoren.

Hva med klienter som fortsetter å spørre etter «én farge til»?

Paletten din er et løfte. Hvis du definerer fem merkevarefarger, og en klient spør om en sjette, er ikke svaret «nei» – det er «ja, men den kommer som et bevisst tillegg til paletten, ikke som en engangs hex-kode i en overskrift.» Når du legger til en farge i theme.json, blir den tilgjengelig gjennom hele nettstedet på en konsistent måte. Det er den riktige måten å håndtere slike forespørsler på.

Det er også her du må kommunisere med klienten. Forklar at Site Editor bare viser dem fargene og skriftene som samsvarer med merkevarestandardene deres. Hvis de vil utvide disse standardene, tar du hånd om det i designsystemet, og deretter vil hver nye farge være tilgjengelig overalt – også på fremtidige sider de ikke har bygget ennå. Det er et mye bedre svar enn «det gjør vi ikke».

Samtidig bør du ikke samle opp en palett med førti farger. Gå gjennom den kvartalsvis og fjern alt som var et engangsuhell. Målet er et lite, bevisst sett med alternativer.

Hvis du låser layouten, men lar innholdet være åpent, og gjør paletten til en levende del av klientforholdet ditt, slutter Site Editor å være en trussel. Den blir en måte å gi klientene dine reell autonomi uten å ofre designstandardene du er betalt for å beskytte.