Den kundesikre Site Editor: En theme.json-playbog

Resumé

Når en kunde åbner WordPress Site Editor for første gang, kan muligheden for at redigere hver blok, farve og layout føles som en funktion for dem – og som en trussel for dig. Denne artikel forklarer, hvordan du bruger theme.json til at trække en klar linje mellem indholdsredigering og designkontrol. I stedet for at bekæmpe Site Editor, sætter du presets, standarder og grænser op, der gør det sikkert for ikke-tekniske kunder at opdatere deres eget site. Vi gennemgår, hvad du skal låse, hvad du skal lade være åbent, og hvorfor over-låsning er en reel risiko. Tilgangen er bygget op omkring design-tokens og skabelonniveau-begrænsninger, så den fungerer konsekvent på tværs af alle de kundesites, du vedligeholder. Til sidst har du en gentagelig arbejdsgang for at overdrage Site Editor uden at overdrage nøglerne til dit designsystem.

Hvad er det første, du gør, når en kunde skriver for at sige, at de "lige prøvede at opdatere overskriften", og hele sitets afstande er kollapset?

Hvis du vedligeholder mere end ét WordPress-site, har du sikkert modtaget den besked i en eller anden form. Site Editor gav din kunde nøglerne til en bil med fem gear og ingen bremse. De tror, de laver en simpel tekstændring, og pludselig er den globale typografi forkert, hero-sektionen på forsiden har en neonfarve, du ikke valgte, og to blokke er nu stablet i stedet for at stå side om side.

I mellemtiden tænker du på de seks andre kundesites, du supporterer, og det sidste, du har brug for, er en vedligeholdelsesfælde, hvor hver "hjælpsom" kunderedigering kræver en gendannelse fra en backup.

Svaret er ikke at fjerne Site Editor. Det er at sætte grænser inde i den ved hjælp af theme.json. Ifølge WordPress Developer Resources er theme.json den centrale kilde til sandhed for blokeditorindstillinger og -stile – den definerer farvepaletter, typografi og layoutmuligheder, der vises for kunden. Det betyder, at den samme fil, der styrer dit design, også kan styre, hvad din kunde kan og ikke kan redigere.

Lad os gennemgå, hvordan du skal tænke om dette, fordi de fleste tutorials fokuserer på, hvad theme.json kan gøre for udviklere. Spørgsmålet for et bureau er anderledes: hvordan bruger vi det til at gøre kunder sikre uden at få dem til at føle sig begrænset?

Hvorfor føles Site Editor så farlig?

Din kunde forsøger ikke at ødelægge sitet. De forsøger at gøre det, du har trænet dem til i årevis i den gamle editor: ændre en overskrift, udskifte et billede, måske tilføje et afsnit. Faren er ikke deres intention – det er, at Site Editor viser globale kontroller samme sted som indholds kontroller.

Her er et typisk scenario. En kunde åbner en skabelon i Site Editor og ser en overskriftsblok. De ændrer dens farve, så den matcher den nye brand-farve. Men fordi overskriften er i en skabelon, gælder ændringen alle steder, hvor skabelonen bruges. For kunden lignede det en enkelt redigering. For sitet var det en global ændring.

Det generelle princip: når du giver nogen en sidebygger, vil de før eller siden finde "indstillinger med autoværn" og slå dem fra. Men med theme.json kan du skjule selve autoværnet. I stedet for at fortælle kunden "rør ikke ved de globale stilarter", viser du dem simpelthen ikke en farvepalet, der kan producere et dårligt resultat. Du definerer en palet med godkendte farver, en skala af skriftstørrelser og et sæt af afstandspresets – og kunden vælger fra dem, ikke fra hele CSS-spektret.

Det er det første skift: stop med at tænke i regler, og begynd at tænke i fabrikker. theme.json er din produktionslinje. Du konfigurerer de muligheder, kunden ser, og begrænsningerne håndhæves af selve grænsefladen, ikke af en række instruktioner i et overdragelsesdokument.

Hvad skal du faktisk låse?

Ikke alt. Hvis du låser indholdsområdet for hårdt, vil kunden enten ringe til dig hver gang de skal tilføje et afsnit, eller også finder de en vej udenom dig – ofte ved at installere et enkeltstående plugin eller kopiere HTML fra deres gamle site.

Her er en praktisk tabel over, hvad du skal låse, hvad du skal lade være, og hvorfor:

Redigeringsflade	Lås?	Hvorfor
Skabelonstruktur og bloklayouts	Lås	Forhindrer utilsigtet fjernelse eller omrokering af kerne-layoutblokke
Globale stilarter (farver, skrifttyper, afstandspresets)	Lås med presets	Kunder vælger fra et godkendt sæt, ikke fra vilkårlige værdier
Indholdstekst og billeder	Lad være åbent	Det er deres job; lad dem gøre det uden at spørge om lov
Afstand mellem blokke	Delvist lås	Giv afstandspresets, så de kan justere rytmen uden at bryde justeringen
Kuraterede blokmønstre	Lad være åbent, hvis du har gennemgået dem	En sikker måde for kunder at tilføje nye sektioner uden at bygge fra bunden

Den vigtige nuance er "lås med presets", ikke "lås ude". For globale stilarter skjuler du ikke indstillingspanelet; du reducerer antallet af valgmuligheder til et kurateret sæt. For skabelonstruktur kan du låse bestemte blokke, så de ikke kan fjernes, men stadig lade kunder redigere teksten i dem.

En advarsel: at låse en blok i en skabelon er forskelligt fra at låse den på en bestemt side. Skabelonlåse påvirker alt indhold, der bruger skabelonen. Hvis du har brug for forskellige låseniveauer på forskellige sider, skal du arbejde på blokniveau inde i editoren, hvilket er mere skrøbeligt. For gentagent bureauarbejde skal du designe dine skabeloner, så de låste områder er konsistente.

Hvordan sætter du grænser uden at få editoren til at føles som en fælde?

Teknikken er at definere dine design-tokens i theme.json og derefter modstå at gøre noget andet i CSS.

For eksempel: i stedet for at lade kunden sætte en vilkårlig farve på en knap, definerer du en knapstil i theme.json, der bruger en bestemt farve fra din palet. Kunden kan stadig vælge knappen og ændre dens tekst, men farvevælgeren viser kun dine godkendte farver. Det samme gælder for skriftstørrelser, linjehøjder og afstand.

Det samme princip gælder for skabeloner. Du kan bruge "lås"-funktionen på bestemte blokke i en skabelon – for eksempel låse kolonnestrukturen i en testimonial-blok, så en kunde kan ændre citatteksten, men ikke lave tre kolonner om til to. Hvis du ikke har brugt bloklåsning endnu, er den tilgængelig i editorværktøjslinjen; når du låser en blok, kan du vælge, om kunden kan redigere indhold, flytte den eller begge dele. Du kan endda anvende dette i theme.json for blokniveau-standardindstillinger.

Det, du går efter, er en editor, hvor kunden aldrig ser en kontrol, der kan ødelægge designet. Det betyder ikke, at de ikke kan gøre noget forkert; det betyder, at det værste, de kan gøre, er at ændre ordlyden i en overskrift, ikke hele sitets udseende.

Hvis du bruger brugerdefinerede indholdstyper, gælder de samme principper ud over standardskabelonerne – se vores guide til at udvide theme.json til brugerdefinerede indholdstyper og plugin-output.

Hvad sker der, når du låser for meget?

Her er det kontrære punkt: over-låsning er lige så skadeligt som under-låsning. En kunde, der ikke kan ændre størrelsen på en overskrift eller tilføje et mellemrum mellem sektioner, vil til sidst bede dig om at "bare få det til at se rigtigt ud" – og så er du tilbage til at lave små redigeringer gratis. Værre: de kan beslutte, at Site Editor er ubrugelig, og gå tilbage til en tredjeparts sidebygger, hvilket giver dem for meget kontrol igen.

Afvejningen er reel. Låste editorer producerer færre nødopkald, men de producerer også flere "kan du lige flytte denne knap fem pixels op"-anmodninger. Åbne editorer producerer det modsatte. Din opgave er at finde balancepunktet for hver kunde, ikke at anvende én konfiguration universelt.

En god startregel: lås alt, der påvirker alle forekomster af noget (globale stilarter, skabelonstruktur), og lad alt, der påvirker én forekomst (en enkelt sides tekst og billeder), være åbent. Hvis en kunde ødelægger en enkelt side, er det en 5-minutters rettelse. Hvis de ødelægger en global stil, er det en 20-minutters rettelse og et sikkerhedsproblem.

Hvordan gør du dette gentageligt på tværs af kunder?

Det er her bureauarbejdsgangen kommer ind. Du bør have en basis-theme.json, der definerer dine design-tokens – farvepaletten, typografiskalaen og afstandspresets – og derefter en override-fil pr. kunde, der udvider eller ændrer specifikke værdier.

Start med at oprette et "starter"-bloktema. Her kan du se, hvordan du bygger et brugerdefineret bloktema med theme.json – når du har udviklet og dokumenteret det, er det bare at kopiere det til en ny kunde og udskifte brandfarver og skrifttyper. Du genopbygger ikke hjulet; du udskifter tokens. Det er præcis den stop med at genopbygge hvert WordPress-site -tankegang, men anvendt på editoren i stedet for backend.

Fordi theme.json er en enkelt fil, er den også nem at versionsstyre og implementere på tværs af flere miljøer. Du kan gennemgå ændringer, se, hvad en kunde har ændret i de globale stilarter, og sammenligne disse ændringer med din basisfil. Det giver dig en stærk revisionssporing til supportforespørgsler.

Hvis du vedligeholder flere sites, og du ikke har sat et basistema op endnu, er det din chance. Det er det ene stykke brugerdefineret WordPress-arbejde, der betaler sig selv tilbage, hver gang en kunde åbner editoren.

Hvad med kunder, der bliver ved med at bede om "én farve til"?

Din palet er et løfte. Hvis du definerer fem brandfarver, og en kunde beder om en sjette, er svaret ikke "nej" – det er "ja, men den kommer som en bevidst tilføjelse til paletten, ikke som en engangs-hex-kode i en overskrift." Når du tilføjer en farve til theme.json, bliver den tilgængelig på hele sitet. Det er den rigtige måde at håndtere sådanne anmodninger på.

Det er også her, du skal kommunikere med kunden. Forklar, at Site Editor kun viser dem de farver og skrifttyper, der matcher deres brandstandarder. Hvis de vil udvide disse standarder, klarer du det i designsystemet, og så vil hver ny farve være tilgængelig alle steder – også på fremtidige sider, de endnu ikke har bygget. Det er et meget bedre svar end "det gør vi ikke."

Samtidig skal du ikke akkumulere en palet med fyrre farver. Gennemgå den kvartalsvis og fjern alt, der var en engangs-ulykke. Målet er et lille, bevidst sæt af muligheder.

Hvis du låser layoutet, men lader indholdet være åbent, og du gør paletten til en levende del af dit kundeforhold, holder Site Editor op med at være en trussel. Det bliver en måde at give dine kunder ægte autonomi uden at ofre de designstandarder, du er betalt for at beskytte.