Der kundensichere Site Editor: Ein theme.json Playbook

Zusammenfassung

Wenn ein Kunde zum ersten Mal den WordPress Site Editor öffnet, kann die Möglichkeit, jeden Block, jede Farbe und jedes Layout zu bearbeiten, für ihn wie ein Feature wirken – und für dich wie eine Bedrohung. Dieser Artikel erklärt, wie du mit theme.json eine klare Grenze zwischen Inhaltsbearbeitung und Designkontrolle ziehst. Anstatt gegen den Site Editor zu kämpfen, richtest du Presets, Standardwerte und Grenzen ein, die es nicht-technischen Kunden sicher machen, ihre eigene Website zu aktualisieren. Wir gehen durch, was du sperren solltest, was du offen lassen solltest und warum Über-Sperren ein echtes Risiko ist. Der Ansatz basiert auf Design-Tokens und Vorlagen-Einschränkungen, sodass er konsistent auf jeder Client-Website funktioniert, die du betreust. Am Ende hast du einen wiederholbaren Workflow, um den Site Editor zu übergeben, ohne die Schlüssel zu deinem Designsystem aus der Hand zu geben.

Was ist das Erste, was du tust, wenn ein Kunde dir schreibt, dass er „nur die Überschrift aktualisieren wollte“ und der gesamte Abstand der Website zusammengebrochen ist?

Wenn du mehr als eine WordPress-Website betreust, hast du diese Nachricht wahrscheinlich in irgendeiner Form erhalten. Der Site Editor hat deinem Kunden die Schlüssel zu einem Auto mit fünf Gängen und ohne Bremse gegeben. Er denkt, er macht eine einfache Textänderung, und plötzlich ist die globale Typografie verschoben, der Hero-Bereich der Startseite hat eine Neonfarbe, die du nicht gewählt hast, und zwei Blöcke liegen jetzt übereinander statt nebeneinander.

In der Zwischenzeit denkst du an die sechs anderen Kunden-Websites, die du betreust, und das Letzte, was du brauchst, ist eine Wartungsfalle, bei der jede „hilfreiche“ Kundenbearbeitung eine Wiederherstellung aus dem Backup erfordert.

Die Antwort ist nicht, den Site Editor wegzunehmen. Es geht darum, mit theme.json Grenzen darin zu setzen. Laut den WordPress Developer Resources ist theme.json die zentrale Quelle der Wahrheit für Block-Editor-Einstellungen und -Stile – es definiert die Farbpaletten, Typografie und Layout-Optionen, die dem Kunden angezeigt werden. Das bedeutet, dass dieselbe Datei, die dein Design steuert, auch steuern kann, was dein Kunde bearbeiten darf und was nicht.

Lass uns durchgehen, wie du darüber denken solltest, denn die meisten Tutorials konzentrieren sich darauf, was theme.json für Entwickler tun kann. Die Frage für eine Agentur ist eine andere: Wie nutzen wir es, um Kunden sicher zu machen, ohne dass sie sich eingeengt fühlen?

Warum fühlt sich der Site Editor so gefährlich an?

Dein Kunde versucht nicht, die Website zu zerstören. Er versucht das zu tun, wofür du ihn jahrelang im alten Editor geschult hast: eine Überschrift ändern, ein Bild austauschen, vielleicht einen Absatz hinzufügen. Die Gefahr liegt nicht in seiner Absicht – sondern darin, dass der Site Editor globale Steuerungen am selben Ort anzeigt wie Inhaltssteuerungen.

Hier ist ein häufiges Szenario: Ein Kunde öffnet eine Vorlage im Site Editor und sieht einen Überschriften-Block. Er ändert dessen Farbe, um sie an den neuen Markenfarbton anzupassen. Aber weil sich diese Überschrift in einer Vorlage befindet, wird die Änderung überall dort angewendet, wo die Vorlage verwendet wird. Für den Kunden sah es wie eine einzelne Bearbeitung aus. Für die Website war es eine globale Änderung.

Das allgemeine Prinzip: Wenn du jemandem einen Page Builder gibst, wird er irgendwann die „Einstellungen mit Leitplanken“ finden und sie ausschalten. Aber mit theme.json kannst du die Leitplanken selbst verstecken. Anstatt dem Kunden zu sagen „Fass die globalen Stile nicht an“, zeigst du ihm einfach keine Farbpalette, die ein schlechtes Ergebnis produzieren kann. Du definierst eine Palette freigegebener Farben, eine Skala von Schriftgrößen und eine Reihe von Abstands-Presets – und der Kunde wählt aus diesen, nicht aus dem vollen Spektrum von CSS.

Das ist die erste Umstellung: Hör auf, über Regeln nachzudenken, und fang an, über Fabriken nachzudenken. theme.json ist dein Fließband. Du konfigurierst die Optionen, die der Kunde sieht, und die Einschränkungen werden von der Oberfläche selbst durchgesetzt, nicht durch eine Reihe von Anweisungen in einem Übergabedokument.

Was solltest du tatsächlich sperren?

Nicht alles. Wenn du den Inhaltsbereich zu stark einschränkst, wird der Kunde entweder jedes Mal anrufen, wenn er einen Absatz hinzufügen möchte, oder er findet einen Weg um dich herum – oft durch ein einmaliges Plugin oder durch Kopieren von HTML von seiner alten Website.

Hier ist eine praktische Tabelle, was du sperren, was du offen lassen solltest und warum:

Bearbeitungsoberfläche	Sperren?	Warum
Vorlagenstruktur und Block-Layouts	Sperren	Verhindert versehentliches Entfernen oder Umsortieren von Kern-Layout-Blöcken
Globale Stile (Farben, Schriften, Abstands-Presets)	Mit Presets sperren	Kunden wählen aus einem freigegebenen Satz, nicht aus beliebigen Werten
Inhaltstext und Bilder	Offen lassen	Das ist ihre Aufgabe; lass sie es tun, ohne um Erlaubnis zu fragen
Abstände zwischen Blöcken	Teilweise sperren	Stelle Abstands-Presets bereit, damit sie den Rhythmus anpassen können, ohne das Layout zu brechen
Kuratierte Block-Muster	Offen lassen, wenn du sie geprüft hast	Ein sicherer Weg für Kunden, neue Abschnitte hinzuzufügen, ohne von Grund auf neu zu bauen

Die wichtige Nuance ist „Mit Presets sperren“, nicht „aussperren“. Bei den globalen Stilen versteckst du das Einstellungsfeld nicht; du reduzierst die Anzahl der Optionen auf einen kuratierten Satz. Bei der Vorlagenstruktur kannst du bestimmte Blöcke sperren, sodass sie nicht entfernt werden können, aber Kunden weiterhin den Text darin bearbeiten dürfen.

Ein Wort der Vorsicht: Das Sperren eines Blocks in einer Vorlage unterscheidet sich vom Sperren in einer bestimmten Seite. Vorlagen-Sperren betreffen alle Inhalte, die die Vorlage verwenden. Wenn du auf verschiedenen Seiten unterschiedliche Sperrgrade benötigst, musst du auf Blockebene im Editor arbeiten, was fragiler ist. Für wiederholbare Agenturarbeit solltest du deine Vorlagen so gestalten, dass die gesperrten Bereiche konsistent sind.

Wie setzt du Grenzen, ohne dass sich der Editor wie eine Falle anfühlt?

Die Technik besteht darin, deine Design-Tokens in theme.json zu definieren und dann zu widerstehen, irgendetwas anderes in CSS zu tun.

Zum Beispiel: Anstatt dem Kunden zu erlauben, eine beliebige Farbe für einen Button festzulegen, definierst du in theme.json einen Button-Stil, der eine bestimmte Farbe aus deiner Palette verwendet. Der Kunde kann den Button weiterhin auswählen und seinen Text ändern, aber der Farbwähler zeigt nur deine freigegebenen Farbfelder. Dasselbe gilt für Schriftgrößen, Zeilenhöhen und Abstände.

Das gleiche Prinzip gilt für Vorlagen. Du kannst die „Sperren“-Funktion für bestimmte Blöcke in einer Vorlage verwenden – zum Beispiel die Spaltenstruktur eines Testimonial-Blocks sperren, sodass ein Kunde den Zitattext ändern, aber nicht aus drei Spalten zwei machen kann. Falls du die Block-Sperre noch nicht genutzt hast: Sie ist in der Editor-Symbolleiste verfügbar. Wenn du einen Block sperrst, kannst du wählen, ob der Kunde Inhalte bearbeiten, den Block verschieben oder beides darf. Du kannst dies sogar in theme.json für Block-Standardwerte anwenden.

Was du anstrebst, ist ein Editor, in dem der Kunde niemals ein Bedienelement sieht, das das Design brechen kann. Das bedeutet nicht, dass er nichts falsch machen kann; es bedeutet, dass das Schlimmste, das er falsch machen kann, die Änderung des Wortlauts einer Überschrift ist – nicht das gesamte Erscheinungsbild der Website.

Wenn du benutzerdefinierte Beitragstypen verwendest, gelten dieselben Prinzipien über die Standardvorlagen hinaus – siehe unseren Leitfaden zum Erweitern von theme.json für benutzerdefinierte Beitragstypen und Plugin-Ausgabe.

Was passiert, wenn du zu viel sperrst?

Hier ist der konträre Punkt: Über-Sperren ist genauso schädlich wie Unter-Sperren. Ein Kunde, der keine Überschrift skalieren oder keinen Abstand zwischen Abschnitten hinzufügen kann, wird dich irgendwann bitten, „es einfach richtig aussehen zu lassen“ – und dann bist du wieder bei kleinen Bearbeitungen umsonst. Schlimmer noch: Er könnte entscheiden, dass der Site Editor nutzlos ist, und zu einem Drittanbieter-Page-Builder zurückkehren, der ihm wieder zu viel Kontrolle gibt.

Der Kompromiss ist real. Stark gesperrte Editoren erzeugen weniger Notrufe, aber auch mehr „Kannst du diesen Button einfach um fünf Pixel nach oben verschieben“-Anfragen. Offene Editoren erzeugen das Gegenteil. Deine Aufgabe ist es, für jeden Kunden den Gleichgewichtspunkt zu finden, nicht eine Konfiguration universell anzuwenden.

Eine gute Faustregel für den Anfang: Sperre alles, was alle Instanzen von etwas betrifft (globale Stile, Vorlagenstruktur), und lasse alles offen, was eine Instanz betrifft (Text und Bilder einer einzelnen Seite). Wenn ein Kunde eine einzelne Seite zerstört, ist das eine 5-Minuten-Korrektur. Wenn er einen globalen Stil zerstört, ist das eine 20-Minuten-Korrektur und ein Sicherheitsproblem.

Wie machst du das über mehrere Kunden hinweg wiederholbar?

Hier kommt der Agentur-Workflow ins Spiel. Du solltest eine Basis-theme.json haben, die deine Design-Tokens definiert – die Farbpalette, Typografieskala und Abstands-Presets – und dann eine kundenspezifische Override-Datei, die bestimmte Werte erweitert oder ändert.

Beginne mit der Erstellung eines „Starter“-Block-Themes. Hier erfährst du, wie du ein benutzerdefiniertes Block-Theme mit theme.json erstellst – sobald du es entwickelt und dokumentiert hast, ist das Kopieren auf einen neuen Kunden nur eine Frage des Austauschens von Markenfarben und Schriftarten. Du erfindest das Rad nicht neu; du tauschst Tokens aus. Das ist genau die Mentalität, mit dem Neuaufbau jeder WordPress-Website aufzuhören, aber auf den Editor statt auf das Backend angewendet.

Da theme.json eine einzelne Datei ist, ist sie auch einfach versionierbar und über mehrere Umgebungen bereitstellbar. Du kannst Änderungen überprüfen, sehen, was ein Kunde an den globalen Stilen geändert hat, und diese Änderungen mit deiner Basisdatei abgleichen. Das gibt dir einen starken Audit-Trail für Support-Anfragen.

Wenn du mehrere Websites betreust und noch keine Basis-Theme eingerichtet hast, ist das deine Chance. Es ist das eine Stück individuelle WordPress-Arbeit, das sich jedes Mal bezahlt macht, wenn ein Kunde den Editor öffnet.

Was ist mit Kunden, die immer wieder nach „einer weiteren Farbe“ fragen?

Deine Palette ist ein Versprechen. Wenn du fünf Markenfarben definierst und ein Kunde nach einer sechsten fragt, ist die Antwort nicht „Nein“ – sondern „Ja, aber sie kommt als bewusste Ergänzung zur Palette, nicht als einmaliger Hex-Code in einer Überschrift“. Wenn du eine Farbe zu theme.json hinzufügst, wird sie überall auf der Website konsistent verfügbar. Das ist der richtige Weg, mit solchen Anfragen umzugehen.

Hier musst du auch mit dem Kunden kommunizieren. Erkläre, dass der Site Editor ihm nur die Farben und Schriftarten zeigt, die zu seinen Markenstandards passen. Wenn er diese Standards erweitern möchte, kümmerst du dich im Designsystem darum, und dann wird jede neue Farbe überall verfügbar sein – auch auf zukünftigen Seiten, die er noch nicht gebaut hat. Das ist eine viel bessere Antwort als „Das machen wir nicht“.

Gleichzeitig solltest du keine Palette mit vierzig Farben ansammeln. Überprüfe sie vierteljährlich und entferne alles, was ein einmaliger Unfall war. Das Ziel ist eine kleine, bewusste Auswahl an Optionen.

Wenn du das Layout sperrst, aber den Inhalt offen lässt, und du die Palette zu einem lebendigen Teil deiner Kundenbeziehung machst, hört der Site Editor auf, eine Bedrohung zu sein. Er wird zu einer Möglichkeit, deinen Kunden echte Autonomie zu geben, ohne die Designstandards zu opfern, die du bezahlt wirst zu schützen.