Trennen Sie in einem Block-Theme Templates, wiederverwendete Template Parts, globale Styles und Inhaltsvorlagen (Patterns). Geben Sie normalen Redakteuren Zugriff auf die Inhaltserstellung, Eingriffe in globale Bereiche nur geschulten Rollen. Verfolgen Sie Theme-Versionen und Template-Änderungen in der Datenbank gemeinsam und testen Sie vor einem Release die gesamte Website.
Full Site Editing ermöglicht es, in einem Block-Theme nicht nur den Seiteninhalt, sondern auch Templates, Header, Footer und globale Stile zu bearbeiten. Für das richtige Team bedeutet das schnellere Änderungen ohne Eingriff in PHP-Templates. Gleichzeitig verschiebt sich jedoch die Grenze zwischen Inhalt und Designsystem in den Administrationsbereich. Ein Benutzer mit zu weitreichenden Berechtigungen kann mit einer einzigen Änderung die Navigation oder das Template aller Beiträge verändern.
Eine erfolgreiche Einführung hängt daher nicht davon ab, wie viele Optionen der Editor freischaltet. Sie benötigt eine klare Template-Architektur, benannte Bereiche, globale Tokens, Rollenkontrolle und eine Versionierung von Änderungen. Diese Anleitung hilft bei der Entscheidung, was von normalen Redakteuren, was von Design-Verantwortlichen bearbeitet werden kann und was im Theme-Code verbleibt.
Erfassen Sie die Ebenen eines Block-Themes
Ein Template legt den Rahmen eines Seitentyps fest, zum Beispiel einen einzelnen Artikel (Single) oder ein Archiv. Ein Template Part ist ein wiederkehrender Teil wie Header oder Footer. Eine Vorlage (Pattern) hilft beim Einfügen eines Inhaltsabschnitts, und globale Stile definieren Farben, Typografie, Abstände und das Standardverhalten von Blöcken. Wenn jede Ebene ihre Aufgabe erfüllt, sind Änderungen vorhersehbar und es entstehen keine kopierten Footer in Dutzenden Templates.
Führen Sie die Bestandsaufnahme über alle Inhaltstypen und Zustände durch. Ein Artikel, eine Leistungsseite, ein Suchergebnis und eine 404-Seite können ein unterschiedliches Grundgerüst benötigen, aber denselben Header teilen. Unnötig viele Vorlagen erhöhen die Änderungskosten. Erstellen Sie eine Variante nur bei einem tatsächlich abweichenden Informationsbedarf und benennen Sie sie so, dass Redakteure die Folgen der Zuweisung verstehen.
Verwenden Sie globale Stile als Markenregeln
Definieren Sie eine begrenzte Farbpalette, eine typografische Skala, Inhaltsbreiten und Abstände in einem einzigen System. Blöcke verwenden dann benannte Werte statt zufälliger Pixelangaben. Redakteure können eine Primär- oder Neutralfarbe auswählen, müssen aber keinen eigenen Code eingeben. So wird eine Markenänderung konsistent übernommen, und neue Inhalte halten Kontrast und Rhythmus ganz selbstverständlich ein.
Beschränken Sie die Optionen von Blöcken auf den tatsächlichen Bedarf. Das Deaktivieren eigener Farben oder Abmessungen ist kein Selbstzweck, sondern schützt das responsive Design. Benötigt das Team eine Ausnahme, erstellen Sie einen benannten Stil mit getestetem Verhalten. Eigenes CSS in einzelnen Einträgen lässt sich schwer inventarisieren, migrieren und kontrollieren und gehört daher eher in ein versioniertes System.
- Benannte Farben und typografische Skala
- Einheitliche Breiten und Abstände
- Begrenzte lokale Ausnahmen
- Getestete Stilvarianten von Blöcken
Schützen Sie Header, Footer und Navigation
Eine Änderung an einem globalen Bereich wirkt sich auf die gesamte Website aus und sollte daher kein gewöhnlicher Nebenschritt beim Schreiben eines Artikels sein. Legen Sie eine Rolle oder eine kleine Gruppe fest, die die Navigation und die Template Parts verwaltet. Nehmen Sie Änderungen mit Vorschau für Desktop und Mobilgeräte, für angemeldete Nutzer und für längere Menüs vor. Bereiten Sie bei kritischer Navigation eine Möglichkeit zur schnellen Rückkehr vor.
Die Sperrung der Struktur schützt Logo, Skip-Link, Container und die Reihenfolge der Bedienelemente, während die zulässigen Menüpunkte bearbeitbar bleiben. Prüfen Sie Fokus, Tastaturbedienung und den Zustand des geöffneten mobilen Menüs. Ein globaler Bereich sollte keinen einmaligen Kampagnentext ohne Verantwortlichen enthalten; für vorübergehende Hinweise eignet sich besser eine separate, verwaltete Komponente mit Enddatum.
Unterscheiden Sie Theme-Dateien und Datenbankänderungen
Ein in den Theme-Dateien mitgeliefertes Template kann nach einer Bearbeitung im Editor durch eine Version aus der Datenbank überlagert werden. Der Entwickler ändert dann die Datei, die Website verwendet aber weiterhin die alte gespeicherte Kopie. Das Team muss wissen, welche Templates angepasst wurden und wie entschieden wird, ob eine Änderung ins Theme exportiert, in der Datenbank belassen oder die ursprüngliche Version wiederhergestellt wird.
Halten Sie das Produktivdesign in einem versionierten Repository, wenn es zwischen Umgebungen übertragen und per Code-Review geprüft werden soll. Redaktionelle Inhaltsänderungen sollten in der Datenbank bleiben. Achten Sie bei der Übertragung eines Templates vom Staging darauf, kein neueres Produktivmenü oder globale Inhalte zu überschreiben. Der Release-Prozess muss jede Ebene und ihre maßgebliche Quelle benennen.
- Bestandsaufnahme der in der Datenbank bearbeiteten Templates
- Single Source of Truth für das Design im Repository
- Trennung der Inhalte von der Theme-Veröffentlichung
- Kontrollierter Export und Rückführung
Führen Sie einen Test- und Freigabeprozess ein
Erstellen Sie vor der Einführung repräsentative Vorlagen und lassen Sie Redakteure konkrete Aufgaben erledigen. Beobachten Sie, ob sie das richtige Muster finden, eine globale Änderung erkennen und eine Vorschau anzeigen können. Die Schulung sollte auch Revisionen, Wiederherstellung und das Melden von Fehlern abdecken, nicht nur eine Liste von Schaltflächen. Entfernen Sie überflüssige Optionen, bevor sie zur Gewohnheit werden.
Testen Sie bei einem Update von WordPress oder des Themes die Templates, Template Parts, die Navigation, die Stile der Core-Blöcke und vorhandene eigene Blöcke. Die visuelle Regressionsliste umfasst Startseite, Artikel, Archiv, Formular und 404-Seite. Änderungen an globalen Bereichen genehmigt ein festgelegter Verantwortlicher. So bringt Full Site Editing Flexibilität, ohne dass jeder Redakteur das Risiko für die gesamte Website trägt.
Häufige Fragen
Was ist Full Site Editing in WordPress?
Es ist eine blockbasierte Methode, um Templates, globale Bereiche und Stile der Website im Site Editor zu bearbeiten. Sie funktioniert mit einem Block-Theme und erweitert den Block-Editor über den Inhalt einer einzelnen Seite hinaus.
Darf jeder Redakteur den Header der Website ändern?
Technisch hängt das von Rollen und Einstellungen ab, betrieblich ist es aber meist nicht sinnvoll. Globale Bereiche sollte eine geschulte Rolle mit Freigabe und Vorschau bearbeiten, während normale Redakteure Inhalte erstellen.
Warum wirkt sich die Änderung der Vorlagendatei nicht aus?
Der Site Editor kann in der Datenbank eine angepasste Version gespeichert haben, die die Theme-Datei überlagert. Prüfen Sie den Status des Templates und entscheiden Sie bewusst, ob die Anpassung exportiert, beibehalten oder ohne Arbeitsverlust zurückgesetzt wird.