WordPress Full Site Editing: Praxisleitfaden für 2026

WordPress Full Site Editing hat 2026 einen Wendepunkt erreicht. In WordPress 6.9 nutzen 68% aller Neuinstallationen standardmäßig die blockbasierte Architektur. Für Freelancer und Agenturen, die noch klassische PHP-Themes ausliefern, lautet die Frage nicht mehr, ob man auf FSE setzt, sondern wie man das tut, ohne laufende Produktionsabläufe zu gefährden. Dieser Leitfaden behandelt die Mechanik, nicht das Marketing. Getestet an echten Kundenprojekten unter WordPress 6.8 und 6.9.

Was FSE ersetzt und was es beibehält

Das WordPress Full Site Editing ist kein Neustart des CMS. Es ist ein Schichtenmodell: Die Gutenberg-Block-Engine ersetzt die klassische Theme-Logik der Präsentationsschicht, ohne den Rest von WordPress anzutasten. Was wegfällt: header.php, sidebar.php, functions.php für die Template-Ausgabe und get_template_part() für Partials.

Was bleibt: der Rest von WordPress. Hooks, Filter, Custom Post Types, Plugins, die Datenbank, die REST-API. FSE ändert, wie Inhalte auf dem Bildschirm zusammengesetzt werden. Die Datenschicht darunter bleibt PHP und ändert sich nicht.

Die praktische Konsequenz für Entwickler: Wer bisher klassische PHP-Themes gebaut hat, muss keine neue Programmiersprache lernen. Die Template-Hierarchie bleibt weiterhin relevant, wird aber in HTML-Dateien mit Block-Markup und JSON ausgedrückt, nicht in PHP-Dateien. Das ist ein Denkwechsel, keine Umschulung.

Der Unterschied zeigt sich am deutlichsten beim Übergabeprozess an Kunden. Ein Redakteur kann im Site Editor Templates und Template-Teile visuell bearbeiten, ohne Zugang zu den Theme-Dateien zu benötigen. Für Agenturen, die mehrere Mandanten gleichzeitig betreuen, ist das eine strukturelle Veränderung in der Art, wie Projekte übergeben und gepflegt werden. Klassische PHP-Themes erfordern für jede Template-Anpassung einen Entwicklerzugriff. FSE verlagert einen Teil dieser Aufgaben in den redaktionellen Bereich.

Das minimale Block-Theme: drei Dateien genügen

Ein funktionsfähiges Block-Theme besteht aus drei Pflichtdateien: style.css mit dem Theme-Header (Name, Version, Text Domain), templates/index.html mit dem Block-Markup für die Standarddarstellung und theme.json für globale Stile und Einstellungen.

Alles andere ist optional. Keine functions.php für grundlegende Ausgabe, keine header.php, keine Template-Teile, die vorab deklariert werden müssen. WordPress ergänzt fehlende Templates zur Laufzeit über die bekannte Template-Hierarchie. Ein minimales Theme ist kein Prototyp: Es ist ein vollständig funktionsfähiges Block-Theme, das in der Praxis eingesetzt werden kann.

Das ist keine Vereinfachung, die man später bereut. Das minimale Theme lässt sich vollständig in einer Versionskontrolle handhaben. Die editierbare Schicht liegt in der Datenbank via Theme-Overrides, die versionierte Schicht liegt im Repository. Beide Schichten sind sauber getrennt, solange man die Architektur versteht und den Override-Mechanismus nicht ignoriert.

Für Agenturen mit mehreren Mandanten ergibt sich ein klarer Vorteil: Ein versioniertes Basis-Theme kann als Startpunkt für alle Projekte dienen. Mandantenspezifische Anpassungen liegen entweder als separates Child-Theme oder als Site-Editor-Konfiguration in der Datenbank. Die Grenze zwischen diesen beiden Schichten sauber zu halten ist die eigentliche Architekturaufgabe beim Einsatz von FSE.

Der Site Editor in WordPress 6.9: fünf Bereiche, eine Hierarchie

Der Site Editor in WordPress 6.9 ist in fünf Bereiche gegliedert: Navigation, Stile (Styles), Seiten (Pages), Templates und Template-Teile (Template Parts). Die Hierarchie ist klar definiert. Globale Stile gelten für die gesamte Installation. Templates überschreiben den globalen Stil für eine bestimmte Inhaltsart, also für Einzelbeiträge, Archivseiten oder Suchseiten. Template-Teile sind die wiederverwendbaren Elemente, die in mehreren Templates auftauchen: Header, Footer, Seitenleisten.

Was viele Entwickler beim ersten Durchlauf unterschätzen: Template-Overrides werden in der Datenbank gespeichert, nicht im Dateisystem. Wenn ein Redakteur das Single-Post-Template im Site Editor bearbeitet, schreibt WordPress einen Override in wp_posts mit dem Post-Type wp_template. Die Original-Datei im Theme bleibt unberührt, wird aber ignoriert, solange der Override in der Datenbank existiert.

Das ist in der Praxis eine häufige Ursache für Verwirrung. Welche Version gilt: die im Theme oder die in der Datenbank? Antwort: immer die Datenbankversion, falls eine vorhanden ist. Die WP-CLI-Befehle wp post list --post_type=wp_template und wp post list --post_type=wp_template_part sind in diesem Kontext unverzichtbar für die Diagnose und für das Aufräumen nach unbeabsichtigten Redakteurseingriffen.

Die Navigationsstruktur des Site Editors hat sich mit WordPress 6.9 verbessert. Das Wechseln zwischen Templates, Template-Teilen und globalen Stilen ist jetzt über das linke Panel ohne vollständiges Neuladen der Seite möglich. Das klingt nach einem Detail, macht aber im täglichen Entwicklungsalltag einen spürbaren Unterschied.

Pattern Overrides: feste Struktur, überschreibbarer Inhalt

Pattern Overrides wurden mit WordPress 6.8 eingeführt und nutzen die Block Bindings API mit der Quelle core/pattern-overrides. Das ist die wichtigste neue Funktion für die professionelle Kundenübergabe in 2026.

Das Prinzip ist klar: Ein Pattern wird gesperrt (lock: {"move": true, "remove": true}), aber bestimmte Attribute wie der Text eines Paragraphen, die URL eines Links oder der Alt-Text eines Bildes werden als überschreibbar markiert. Der Redakteur kann Inhalte in diesen definierten Feldern ändern, ohne die Struktur des Patterns aufzubrechen oder Blöcke zu verschieben.

Ein konkretes Beispiel aus einem Kundenprojekt: Eine Agentur liefert eine Landing-Page-Sektion mit Überschrift, Untertitel und CTA-Button. Abstände, Typografie und Layout sind durch das Pattern fixiert. Der Kunde kann den Text der Überschrift, den Untertitel und die CTA-URL anpassen. Den Button verschieben oder die Hintergrundfarbe der Sektion ändern kann er dagegen nicht.

Pattern Overrides lösen nicht jedes Problem der Kundenübergabe. Sie lösen aber das häufigste: das zerstörte Layout nach dem ersten Redakteurszugriff. Für Agenturen, die Wartungsverträge anbieten, reduziert das den Support-Aufwand für Layout-Reparaturen messbar. Die Investition in die initiale Pattern-Erstellung zahlt sich über die Laufzeit eines Mandats aus.

theme.json v3: was er steuert, was er delegiert

theme.json in Version 3, eingeführt mit WordPress 6.7, steuert drei Kategorien von Einstellungen.

Globale Stile: Typografie (Schriftfamilien, Schriftgrößen, Zeilenabstände), Farben (Palette, Verläufe, Duotones), Abstände über spacingScale und Layout-Breiten. Alles, was man bisher in globalem CSS definiert hat, geht jetzt in theme.json rein.

Block-Einstellungen: Welche Steuerungsmöglichkeiten stehen einem Redakteur für welchen Block zur Verfügung? theme.json aktiviert oder deaktiviert diese Optionen pro Block. Das Feld "color": {"background": false} für den Paragraph-Block verhindert beispielsweise, dass ein Redakteur die Hintergrundfarbe eines einzelnen Absatzes überschreibt. Das ist Kontrolle über die Redakteursoberfläche ohne JavaScript.

Custom Properties: theme.json generiert CSS Custom Properties automatisch. Farben aus der Palette werden zu --wp--preset--color--primary, Schriftgrößen zu --wp--preset--font-size--large. Diese Properties stehen sowohl in CSS-Regeln als auch im Inline-Stil von Blöcken zur Verfügung.

Was theme.json nicht steuert: Geschäftslogik, Plugin-Verhalten, Custom Post Type Registration und REST-API-Endpunkte. Das bleibt in PHP. Wer erwartet, dass theme.json die gesamte Konfiguration des Themes übernimmt, wird an dieser Grenze anhalten müssen.

Eine praxisrelevante Einschränkung betrifft Plugin-Konflikte: Wenn zwei Plugins eigene Schriftgrößen oder Farbpaletten in theme.json registrieren, können Konflikte in der Zusammenführung entstehen. Die Reihenfolge ist in der WordPress-Dokumentation beschrieben, aber nicht immer intuitiv. Ein vollständiger Test in der Entwicklungsumgebung ist Pflicht, bevor eine neue theme.json-Konfiguration auf Produktionsseiten ausgerollt wird.

Was in der Produktion noch bricht

Keine Beschönigung: FSE hat in 2026 nachweisliche Schwachstellen in bestimmten Anwendungsfällen, die man kennen sollte.

Template-Datenbank-Override: Wie beschrieben, erzeugt ein Redakteur, der ein Template im Site Editor bearbeitet, einen Datenbankoverride. Das Theme-Update ändert danach die Original-Datei, der Override bleibt und überschreibt sie weiterhin. Die Lösung ist Customize > Templates > Revert im Site Editor oder wp post delete per WP-CLI für das betreffende Template. Für Agenturen, die 20 oder mehr Sites parallel verwalten, ist das ein realer operativer Aufwand ohne automatisierte Lösung.

RTL-Lücken: Für arabische und hebräische Seiten sind bestimmte Blöcke noch nicht vollständig RTL-kompatibel. Der Navigation-Block hat bekannte Schwierigkeiten mit Dropdown-Richtungen unter RTL-Modus. Das Core-Team hat das Problem dokumentiert, aber ein vollständiger Durchbruch ist für das laufende Jahr nicht zu erwarten. Wer Seiten für arabischsprachige oder hebräischsprachige Märkte baut, muss mit Custom-CSS-Korrekturen rechnen.

Verschachtelte DOM-Tiefe: Block-Markup erzeugt tiefer verschachtelte DOM-Strukturen als handgeschriebenes PHP-Markup. Ein einfaches Dreispalten-Layout kann 8 bis 12 div-Ebenen erzeugen. Das ist meist kein Performance-Problem, kann aber CSS-Spezifitätskonflikte verursachen, besonders wenn Legacy-CSS aus Classic-Themes portiert wird.

WooCommerce-Kompatibilität: WooCommerce hat eigene FSE-Templates eingeführt, aber die Integration ist noch nicht vollständig stabil für alle Anwendungsfälle. Komplexe Checkout-Anpassungen und Mitgliederbereich-Seiten erfordern weiterhin Custom-PHP. Wer einen WooCommerce-Shop vollständig in FSE aufbauen will, sollte deutlich mehr Planungszeit einrechnen als bei einem reinen Content-Theme.

Tools für die FSE-Praxis

Drei Werkzeugkategorien sind für produktive FSE-Arbeit relevant.

Für die Entwicklung ist Create Block Theme das unverzichtbare offizielle WordPress-Plugin. Es erlaubt, Theme-Änderungen aus dem Site Editor als Theme-Dateien zu exportieren. Das ist der einzige Weg, um Site-Editor-Anpassungen in ein versioniertes Repository zu übernehmen. Ohne dieses Plugin bleibt man im Datenbankoverride-Modus ohne Exportmöglichkeit.

Für das Debugging bleibt Query Monitor unverzichtbar, auch unter FSE. Der Block-Editor-Tab in Query Monitor zeigt Template-Hierarchie-Informationen an und hilft, Override-Konflikte zu lokalisieren. Ergänzend sind die WP-CLI-Befehle wp post list --post_type=wp_template und wp block list für die Diagnose von Blockregistrierungen und Override-Status nützlich.

Für die Pattern-Verwaltung bietet das WordPress Pattern Directory über 800 freie Block-Patterns als Ausgangspunkt. Für die produktive Arbeit empfiehlt sich zusätzlich ein lokales Pattern-Repository im Theme selbst: versioniert, über alle Mandanten teilbar und ohne Abhängigkeit von externen Diensten oder einer Netzwerkverbindung.

Das Colophon zu diesem Folio: Testen Sie WordPress Full Site Editing an einem echten Kundenprojekt, nicht nur in einer Sandbox. Die Reibungspunkte zeigen sich erst im Produktionsbetrieb, wenn echte Redakteure mit echten Inhalten und eigenen Vorstellungen von "wie das funktionieren soll" arbeiten.

Ein letzter Hinweis zur Projektplanung: FSE ist kein Fertigprodukt mit fester Lernkurve. Es entwickelt sich mit jeder WordPress-Version weiter. Wer heute in FSE investiert, investiert in eine Architektur, die in WordPress 7.x noch stärker werden wird. Die Grundlagen aus diesem Leitfaden bleiben gültig; die Details der Block-Bindungen und Pattern-APIs werden wachsen.