De klantbestendige Site Editor: een theme.json-draaiboek

Samenvatting

Wanneer een klant voor het eerst de WordPress Site Editor opent, kan de mogelijkheid om elk blok, elke kleur en elke lay-out te bewerken aanvoelen als een functie voor hen — en als een bedreiging voor jou. Dit artikel legt uit hoe je theme.json kunt gebruiken om een duidelijke grens te trekken tussen het bewerken van content en controle over het ontwerp. In plaats van tegen de Site Editor te vechten, stel je presets, standaardwaarden en grenzen in die het veilig maken voor niet-technische klanten om hun eigen site bij te werken. We doorlopen wat je moet vergrendelen, wat je open moet laten en waarom te veel vergrendelen een echt risico is. De aanpak is gebouwd rond design tokens en beperkingen op sjabloonniveau, zodat het consistent werkt op elke clientsite die je beheert. Aan het einde heb je een herbruikbare workflow om de Site Editor over te dragen zonder de sleutels van je designsysteem uit handen te geven.

Wat is het eerste dat je doet als een klant mailt dat ze "even de kop wilden bijwerken" en de hele opmaak van de site is ingestort?

Als je meer dan één WordPress-site beheert, heb je dat bericht waarschijnlijk in een of andere vorm ontvangen. De Site Editor gaf je klant de sleutels van een auto met vijf versnellingen en geen rem. Ze denken dat ze een simpele tekstwijziging doorvoeren, en opeens is de globale typografie niet meer goed, heeft de hero op de homepage een neonkleur die jij niet hebt gekozen, en staan twee blokken nu onder elkaar in plaats van naast elkaar.

Ondertussen denk je aan de zes andere clientsites die je ondersteunt, en het laatste wat je nodig hebt is een onderhoudsval waarin elke "behulpzame" bewerking van de klant een restauratie vanaf een back-up vereist.

Het antwoord is niet om de Site Editor weg te nemen. Het is om er grenzen in te stellen met theme.json. Volgens de WordPress Developer Resources is theme.json de centrale bron van waarheid voor instellingen en stijlen van de blokeditor — het definieert de kleurenpaletten, typografie en lay-outopties die aan de klant worden getoond. Dat betekent dat hetzelfde bestand dat jouw ontwerp beheert, ook kan bepalen wat je klant wel en niet kan bewerken.

Laten we eens kijken hoe je hierover moet denken, want de meeste tutorials richten zich op wat theme.json voor ontwikkelaars kan doen. De vraag voor een bureau is anders: hoe gebruiken we het om klanten veiligheid te bieden zonder dat ze zich opgesloten voelen?

Waarom voelt de Site Editor zo gevaarlijk?

Je klant probeert de site niet te breken. Ze proberen te doen wat jij ze jarenlang hebt geleerd in de oude editor: een kop wijzigen, een afbeelding vervangen, misschien een alinea toevoegen. Het gevaar zit niet in hun bedoeling — het zit in het feit dat de Site Editor globale opties op dezelfde plek toont als contentopties.

Hier is een veelvoorkomend scenario. Een klant opent een sjabloon in de Site Editor en ziet een kopblok. Ze veranderen de kleur zodat die overeenkomt met de nieuwe merkkleur. Maar omdat die kop in een sjabloon staat, wordt de wijziging overal toegepast waar dat sjabloon wordt gebruikt. Voor de klant leek het één enkele bewerking. Voor de site was het een globale wijziging.

Het algemene principe: als je iemand een pagebuilder geeft, zullen ze uiteindelijk de "instellingen met vangrails" vinden en uitzetten. Maar met theme.json kun je de vangrails zelf verbergen. In plaats van de klant te vertellen "raak de globale stijlen niet aan", toon je simpelweg geen kleurenpalet dat een slecht resultaat kan opleveren. Je definieert een palet met goedgekeurde kleuren, een schaal van lettergroottes en een set spacing-presets — en de klant kiest daaruit, niet uit het volledige spectrum van CSS.

Dat is de eerste omslag: stop met denken in regels en begin te denken in fabrieken. theme.json is jouw productielijn. Jij configureert de opties die de klant ziet, en de beperkingen worden afgedwongen door de interface zelf, niet door een set instructies in een overdrachtsdocument.

Wat moet je daadwerkelijk vergrendelen?

Niet alles. Als je het contentgebied te strak vergrendelt, belt de klant je ofwel elke keer als ze een alinea moeten toevoegen, of ze vinden een manier om je te omzeilen — vaak door een eenmalige plugin toe te voegen of HTML van hun oude site te kopiëren.

Hier is een praktische tabel met wat je moet vergrendelen, wat je open moet laten en waarom:

Bewerkingsoppervlak	Vergrendelen?	Waarom
Sjabloonstructuur en bloklay-outs	Vergrendelen	Voorkomt per ongeluk verwijderen of herschikken van kernlay-outblokken
Globale stijlen (kleuren, lettertypen, spacing-presets)	Vergrendelen met presets	Klanten kiezen uit een goedgekeurde set, niet uit willekeurige waarden
Contenttekst en afbeeldingen	Open laten	Dit is hun taak; laat ze het doen zonder toestemming te vragen
Ruimte tussen blokken	Gedeeltelijk vergrendelen	Bied spacing-presets aan zodat ze het ritme kunnen aanpassen zonder de uitlijning te breken
Samengestelde blokpatronen	Open laten als je ze hebt gecontroleerd	Een veilige manier voor klanten om nieuwe secties toe te voegen zonder vanaf nul te bouwen

De belangrijke nuance is "vergrendelen met presets", niet "buiten sluiten". Bij globale stijlen verberg je het instellingenpaneel niet; je beperkt het aantal keuzes tot een samengestelde set. Bij de sjabloonstructuur kun je bepaalde blokken vergrendelen zodat ze niet verwijderd kunnen worden, maar klanten kunnen nog steeds de tekst erin bewerken.

Een waarschuwing: een blok in een sjabloon vergrendelen is iets anders dan het vergrendelen op een specifieke pagina. Sjabloonvergrendelingen zijn van invloed op alle content die het sjabloon gebruikt. Als je op verschillende pagina's verschillende vergrendelingsniveaus nodig hebt, moet je op blokniveau in de editor werken, wat kwetsbaarder is. Voor herhaalbare bureauwerkzaamheden ontwerp je je sjablonen zo dat de vergrendelde gebieden consistent zijn.

Hoe stel je grenzen zonder dat de editor aanvoelt als een val?

De techniek is om je design tokens in theme.json te definiëren en vervolgens te weerstaan aan de verleiding om iets anders in CSS te doen.

Stel dat je de klant niet zelf een willekeurige kleur op een knop laat zetten; je definieert een knopstijl in theme.json die een specifieke kleur uit je palet gebruikt. De klant kan de knop nog steeds selecteren en de tekst wijzigen, maar de kleurkiezer toont alleen je goedgekeurde stalen. Hetzelfde geldt voor lettergroottes, regelafstanden en spacing.

Hetzelfde principe geldt voor sjablonen. Je kunt de functie "vergrendelen" gebruiken op specifieke blokken binnen een sjabloon — bijvoorbeeld door de kolomstructuur van een testimonialblok te vergrendelen, zodat een klant de citatietekst kan wijzigen maar niet van drie kolommen twee kan maken. Als je blokvergrendeling nog niet hebt gebruikt, is deze beschikbaar in de werkbalk van de editor; wanneer je een blok vergrendelt, kun je kiezen of de klant de content kan bewerken, verplaatsen of beide. Je kunt dit ook toepassen in theme.json voor standaardinstellingen op blokniveau.

Waar je naar streeft is een editor waarin de klant nooit een optie ziet die het ontwerp kan breken. Dat betekent niet dat ze niets fout kunnen doen; het betekent dat het ergste wat ze fout kunnen doen is de formulering van een kop wijzigen, niet het hele uiterlijk van de site.

Als je aangepaste berichttypen gebruikt, gelden dezelfde principes ook buiten de standaardsjablonen — zie onze handleiding over theme.json uitbreiden naar aangepaste berichttypen en plugin-output.

Wat gebeurt er als je te veel vergrendelt?

Hier is het tegendraadse punt: te veel vergrendelen is net zo schadelijk als te weinig vergrendelen. Een klant die geen kop kan vergroten of een tussenruimte kan toevoegen, zal je uiteindelijk vragen om "het gewoon goed te laten lijken" — en dan ben je weer gratis kleine wijzigingen aan het doen. Erg nog, ze besluiten misschien dat de Site Editor nutteloos is en stappen over op een pagebuilder van derden, die ze weer te veel controle geeft.

De afweging is reëel. Vergrendelde editors leveren minder spoedtelefoontjes op, maar ook meer verzoeken als "kun je deze knop gewoon vijf pixels omhoog zetten". Open editors leveren het tegenovergestelde op. Jouw taak is om voor elke klant het evenwichtspunt te vinden, niet om één configuratie universeel toe te passen.

Een goed startpunt: vergrendel alles dat van invloed is op alle exemplaren van iets (globale stijlen, sjabloonstructuur), en laat alles open dat van invloed is op één exemplaar (de tekst en afbeeldingen van één pagina). Als een klant één pagina breekt, is dat een reparatie van 5 minuten. Als ze een globale stijl breken, is dat een reparatie van 20 minuten en een beveiligingsrisico.

Hoe maak je dit herbruikbaar voor meerdere klanten?

Hier komt de workflow van het bureau om de hoek kijken. Je zou een basis-theme.json moeten hebben dat je design tokens definieert — het kleurenpalet, de lettertypesschaal en de spacing-presets — en daarna een bestand met overschrijvingen per klant dat specifieke waarden uitbreidt of wijzigt.

Begin met het maken van een "starter"-blokthema. Hier lees je hoe je een aangepast blokthema bouwt met theme.json — als je het eenmaal hebt ontwikkeld en gedocumenteerd, is het kopiëren naar een nieuwe klant een kwestie van merkkleuren en lettertypen vervangen. Je gebruikt niet het wiel opnieuw; je verwisselt tokens. Dit is precies de mentaliteit van stop met het opnieuw opbouwen van elke WordPress-site, maar toegepast op de editor in plaats van de backend.

Omdat theme.json één bestand is, is het ook eenvoudig om versiebeheer toe te passen en te deployen in meerdere omgevingen. Je kunt wijzigingen bekijken, zien wat een klant in de globale stijlen heeft aangepast en die wijzigingen vergelijken met je basisbestand. Dat geeft je een sterke audittrail voor ondersteuningsverzoeken.

Als je meerdere sites beheert en je hebt nog geen basisthema ingesteld, dan is dit je kans. Het is het enige onderdeel van maatwerk-WordPress-werk dat zichzelf terugverdient elke keer dat een klant de editor opent.

Wat als klanten blijven vragen om "nog één kleurtje"?

Je palet is een belofte. Als je vijf merkkleuren definieert en een klant vraagt om een zesde, is het antwoord niet "nee" — het is "ja, maar het wordt een bewuste toevoeging aan het palet, niet een eenmalige hex-code in een kop." Wanneer je een kleur aan theme.json toevoegt, wordt die consistent op de hele site beschikbaar. Dat is de juiste manier om dergelijke verzoeken af te handelen.

Dit is ook het punt waarop je met de klant moet communiceren. Leg uit dat de Site Editor alleen de kleuren en lettertypen toont die overeenkomen met hun merkstandaarden. Als ze die standaarden willen uitbreiden, regel je dat in het designsysteem, en dan is elke nieuwe kleur overal beschikbaar — ook op toekomstige pagina's die ze nog niet hebben gebouwd. Dat is een veel beter antwoord dan "dat doen we niet".

Verzamel tegelijkertijd geen palet van veertig kleuren. Bekijk het elk kwartaal opnieuw en verwijder alles dat een eenmalig ongelukje was. Het doel is een kleine, weloverwogen set opties.

Als je de lay-out vergrendelt maar de content openlaat, en je maakt het palet een levend onderdeel van je klantrelatie, dan houdt de Site Editor op een bedreiging te zijn. Het wordt een manier om je klanten echte autonomie te geven zonder de ontwerpstandaarden op te offeren die jij bent ingehuurd om te beschermen.