Kundsäker Site Editor: En theme.json-playbook

Sammanfattning

När en kund öppnar WordPress Site Editor för första gången kan möjligheten att redigera varje block, färg och layout kännas som en funktion för dem – och som ett hot för dig. Den här artikeln förklarar hur du använder theme.json för att dra en tydlig gräns mellan innehållsredigering och designkontroll. Istället för att kämpa mot Site Editor sätter du upp förinställningar, standardvärden och gränser som gör det säkert för icke-tekniska kunder att uppdatera sin egen webbplats. Vi går igenom vad du ska låsa, vad du ska lämna öppet och varför överlåsning är en verklig risk. Metoden är uppbyggd kring designtokens och begränsningar på mallnivå, så den fungerar konsekvent på alla kundsajter du underhåller. I slutet har du ett repeterbart arbetsflöde för att överlämna Site Editor utan att lämna ifrån dig nycklarna till ditt designsystem.

Vad är det första du gör när en kund mejlar och säger att de "bara försökte uppdatera rubriken" och hela webbplatsens mellanrum har kollapsat?

Om du underhåller mer än en WordPress-webbplats har du förmodligen fått det meddelandet i någon form. Site Editor gav din kund nycklarna till en bil med fem växlar och ingen broms. De tror att de gör en enkel textändring, och plötsligt är den globala typografin fel, hemsidans hero har en neonfärg du inte valde, och två block är nu staplade istället för sida vid sida.

Under tiden tänker du på de sex andra kundsajter du stödjer, och det sista du behöver är en underhållsfälla där varje "hjälpsam" kundändring kräver en återställning från säkerhetskopia.

Svaret är inte att ta bort Site Editor. Det är att sätta gränser inuti den med hjälp av theme.json. Enligt WordPress Developer Resources är theme.json den centrala källan till sanning för blockredigerarens inställningar och stilar – den definierar färgpaletter, typografi och layoutalternativ som visas för kunden. Det betyder att samma fil som styr din design också kan styra vad din kund kan och inte kan redigera.

Låt oss gå igenom hur du ska tänka kring detta, eftersom de flesta handledningar fokuserar på vad theme.json kan göra för utvecklare. Frågan för en byrå är annorlunda: hur använder vi det för att göra kunder säkra utan att de känner sig inrutade?

Varför känns Site Editor så farlig?

Din kund försöker inte förstöra webbplatsen. De försöker göra det du har tränat dem att göra i åratal i den gamla redigeraren: ändra en rubrik, byta ut en bild, kanske lägga till ett stycke. Faran ligger inte i deras avsikt – det är att Site Editor visar globala kontroller på samma plats som innehållskontroller.

Här är ett vanligt scenario. En kund öppnar en mall i Site Editor och ser ett rubrikblock. De ändrar dess färg så att den matchar den nya varumärkesfärgen. Men eftersom rubriken finns i en mall gäller ändringen överallt där mallen används. För kunden såg det ut som en enda redigering. För webbplatsen var det en global ändring.

Den allmänna principen: när du ger någon en sidbyggare kommer de så småningom hitta "inställningarna med skyddsräcken" och stänga av dem. Men med theme.json kan du dölja själva skyddsräckena. Istället för att säga till kunden "rör inte de globala stilarna" visar du helt enkelt inte en färgpalett som kan ge ett dåligt resultat. Du definierar en palett med godkända färger, en skala med teckenstorlekar och en uppsättning mellanrumsförinställningar – och kunden väljer från dessa, inte från hela CSS-spektrumet.

Det är den första förändringen: sluta tänka på regler och börja tänka på fabriker. theme.json är din produktionslinje. Du konfigurerar alternativen som kunden ser, och begränsningarna upprätthålls av gränssnittet självt, inte av en uppsättning instruktioner i ett överlämningsdokument.

Vad ska du faktiskt låsa?

Inte allt. Om du låser innehållsområdet för hårt kommer kunden antingen ringa dig varje gång de behöver lägga till ett stycke, eller så hittar de en väg runt dig – ofta genom att lägga till ett engångsplugin eller kopiera HTML från sin gamla webbplats.

Här är en praktisk tabell över vad du ska låsa, vad du ska lämna och varför:

Redigeringsyta	Låsa?	Varför
Mallstruktur och blocklayouter	Lås	Förhindrar oavsiktlig borttagning eller omordning av centrala layoutblock
Globala stilar (färger, typsnitt, mellanrumsförinställningar)	Lås med förinställningar	Kunder väljer från en godkänd uppsättning, inte godtyckliga värden
Innehållstext och bilder	Lämna öppet	Det är deras jobb; låt dem göra det utan att behöva fråga om lov
Mellanrum mellan block	Delvis lås	Tillhandahåll mellanrumsförinställningar så att de kan justera rytmen utan att bryta justeringen
Kurerade blockmönster	Lämna öppet om du har granskat dem	Ett säkert sätt för kunder att lägga till nya sektioner utan att bygga från grunden

Den viktiga nyansen är "lås med förinställningar", inte "lås ute". För globala stilar döljer du inte inställningspanelen; du minskar antalet val till en kurerad uppsättning. För mallstruktur kan du låsa vissa block så att de inte kan tas bort, men fortfarande tillåta kunder att redigera texten inuti dem.

Ett varningsord: att låsa ett block i en mall är annorlunda än att låsa det på en specifik sida. Mallås påverkar allt innehåll som använder mallen. Om du behöver olika låsningsnivåer på olika sidor måste du arbeta på blocknivå inuti redigeraren, vilket är mer ömtåligt. För repeterbart byråarbete, designa dina mallar så att de låsta områdena är konsekventa.

Hur sätter du gränser utan att redigeraren känns som en fälla?

Tekniken är att definiera dina designtokens i theme.json och sedan motstå att göra något annat i CSS.

Till exempel, istället för att låta kunden sätta en godtycklig färg på en knapp, definierar du en knappstil i theme.json som använder en specifik färg från din palett. Kunden kan fortfarande välja knappen och ändra dess text, men färgväljaren visar bara dina godkända färgprover. Det är samma sak för teckenstorlekar, radhöjder och mellanrum.

Samma princip gäller för mallar. Du kan använda "lås"-funktionen på specifika block i en mall – till exempel låsa kolumnstrukturen i ett citatblock så att kunden kan ändra citattexten men inte göra om tre kolumner till två. Om du inte har använt blocklåsning ännu finns den i redigerarens verktygsfält; när du låser ett block kan du välja om kunden ska kunna redigera innehåll, flytta det eller både och. Du kan till och med tillämpa detta i theme.json för standardvärden på blocknivå.

Målet är en redigerare där kunden aldrig ser en kontroll som kan förstöra designen. Det betyder inte att de inte kan göra något fel; det betyder att det värsta fel de kan göra är att ändra en rubriks formulering, inte hela webbplatsens utseende.

Om du använder anpassade inläggstyper gäller samma principer bortom standardmallarna – se vår guide om utöka theme.json till anpassade inläggstyper och pluginutdata.

Vad händer när du låser för mycket?

Här är den konträra poängen: överlåsning är lika skadligt som underlåsning. En kund som inte kan ändra storlek på en rubrik eller lägga till ett mellanrum mellan sektioner kommer så småningom be dig att "bara få det att se rätt ut" – och då är du tillbaka till att göra små ändringar gratis. Värre: de kanske bestämmer att Site Editor är värdelös och går tillbaka till en tredjeparts sidbyggare, vilket ger dem för mycket kontroll igen.

Avvägningen är verklig. Nedlåsta redigerare ger färre akuta samtal, men de ger också fler "kan du bara flytta upp den här knappen fem pixlar"-förfrågningar. Öppna redigerare ger det motsatta. Ditt jobb är att hitta balanspunkten för varje kund, inte att tillämpa en konfiguration universellt.

En bra startheuristik: lås allt som påverkar alla instanser av något (globala stilar, mallstruktur) och lämna öppet allt som påverkar en instans (en enskild sidas text och bilder). Om en kund förstör en enskild sida är det en 5-minuters fix. Om de förstör en global stil är det en 20-minuters fix och en säkerhetsfråga.

Hur gör du detta repeterbart mellan kunder?

Det är här byråarbetsflödet kommer in. Du bör ha en bas-theme.json som definierar dina designtokens – färgpaletten, typografiskalan och mellanrumsförinställningarna – och sedan en kundspecifik överstyrningsfil som utökar eller ändrar specifika värden.

Börja med att skapa ett "starter"-blocktema. Så här bygger du ett anpassat blocktema med theme.json – när du har utvecklat och dokumenterat det handlar det om att kopiera det till en ny kund genom att byta ut varumärkesfärger och typsnitt. Du bygger inte hjulet på nytt; du byter ut tokens. Det är exakt sluta bygga om varje WordPress-webbplats -mentaliteten, men tillämpad på redigeraren snarare än backend.

Eftersom theme.json är en enda fil är det också lätt att versionshantera och distribuera över flera miljöer. Du kan granska ändringar, se vad en kund har modifierat i de globala stilarna och diffa dessa ändringar mot din basfil. Det ger dig ett starkt revisionsspår för supportärenden.

Om du underhåller flera webbplatser och inte har satt upp ett bastema ännu är det här din chans. Det är den enda anpassade WordPress-delen som betalar för sig själv varje gång en kund öppnar redigeraren.

Hur är det med kunder som hela tiden ber om "en färg till"?

Din palett är ett löfte. Om du definierar fem varumärkesfärger och en kund ber om en sjätte är svaret inte "nej" – det är "ja, men den kommer som ett medvetet tillägg till paletten, inte som en engångs-hex-kod i en rubrik." När du lägger till en färg i theme.json blir den tillgänglig på hela webbplatsen konsekvent. Det är rätt sätt att hantera sådana förfrågningar.

Det är också här du behöver kommunicera med kunden. Förklara att Site Editor bara visar dem de färger och typsnitt som matchar deras varumärkesstandard. Om de vill utöka dessa standarder tar du hand om det i designsystemet, och sedan kommer varje ny färg att finnas tillgänglig överallt – även på framtida sidor de ännu inte har byggt. Det är ett mycket bättre svar än "vi gör inte så."

Samtidigt ska du inte samla på dig en palett med fyrtio färger. Gå igenom den kvartalsvis och ta bort allt som var en engångsolycka. Målet är en liten, medveten uppsättning alternativ.

Om du låser layouten men lämnar innehållet öppet, och du gör paletten till en levande del av din kundrelation, slutar Site Editor att vara ett hot. Det blir ett sätt att ge dina kunder verklig självständighet utan att offra de designstandarder du är betald för att skydda.