Gutenberg: Warum ich WordPress heute anders sehe

Als Gutenberg kam, war ich ziemlich skeptisch. Eigentlich ist das zu freundlich formuliert: Ich habe den neuen Editor zunächst als negative Entwicklung wahrgenommen.

Ich kam aus der klassischen WordPress-Entwicklung. Themes, Plugins, PHP-Templates, eigene Lösungen für konkrete Anforderungen. Damit konnte ich arbeiten. Dann stand plötzlich dieses neue Blocksystem im Raum, mit anderen Konzepten, anderen Werkzeugen und einer Oberfläche, die mich anfangs eher ausgebremst hat.

Mein erster Gedanke war ungefähr: Warum machen wir etwas komplizierter, das doch funktioniert?

Mittlerweile sehe ich das anders. Besonders das Block-Theme-System hat meine Meinung verändert. Dabei geht es mir vor allem um die Frage, wie sich eine Website gestalten, weiterentwickeln und im Alltag vernünftig pflegen lässt.

Meine Skepsis hatte einen nachvollziehbaren Ausgangspunkt

Mit WordPress 5.0 wurde der Block-Editor im Dezember 2018 Teil von Core. Das war ein großer Einschnitt in gewohnte Arbeitsweisen. Die damalige Release-Ankündigung zu WordPress 5.0 zeigt gut, wie zentral dieser Wechsel war.

Für mich überwog zunächst der Aufwand. Neue Abstraktionen verstehen, die eigene Arbeitsweise hinterfragen und herausfinden, wie viel Kontrolle über Gestaltung und Ausgabe bleibt. Wenn man bereits Themes und Plugins entwickelt, wirkt ein zusätzlicher visueller Layer nicht automatisch wie eine Erleichterung.

Ich wollte Websites sauber bauen können. Überschaubares Markup, nachvollziehbare Styles, verlässliche Komponenten. Meine Sorge war, dass WordPress sich davon entfernt und immer mehr Bedienoberfläche zwischen mich und das Ergebnis schiebt.

Rückblickend habe ich die frühe Umsetzung allerdings zu stark mit dem langfristigen Konzept gleichgesetzt. Ein holpriger Einstieg hat mein Urteil über die gesamte Richtung geprägt.

Mit Block Themes wurde das größere Bild sichtbar

Der entscheidende Unterschied liegt für mich darin, wie weit das Blockmodell reicht. Einzelne Inhaltsblöcke in einem Beitrag sind nur ein Teil davon. Bei einem Block Theme lassen sich auch die Templates und wiederkehrenden Bereiche einer Website mit Blöcken beschreiben.

Mit WordPress 5.9 kamen im Januar 2022 zentrale Funktionen für Full Site Editing und mit Twenty Twenty-Two das erste Standard-Block-Theme. Header, Footer, Navigation und Seitenvorlagen wurden damit Teil einer gemeinsamen Bearbeitungsumgebung. Das war der Schritt, bei dem die Richtung deutlich erkennbar wurde. WordPress 5.9 „Josephine“

Full Site Editing bezeichnet dabei mehrere zusammenhängende Funktionen. Der Site Editor ist die Oberfläche, in der vieles davon zusammenkommt. Gutenberg wiederum ist das Entwicklungsprojekt dahinter; im gleichnamigen Plugin werden auch Funktionen erprobt, die noch nicht zum veröffentlichten WordPress-Core gehören.

Diese Unterscheidung ist hilfreich. Eine spannende Gutenberg-Neuigkeit ist noch keine Zusage, dass sie auf jeder aktuellen WordPress-Installation verfügbar ist.

Ein Theme kann einen verständlichen Gestaltungsrahmen liefern

Ein großer Teil meines Perspektivwechsels hängt an einer eher unscheinbaren Datei: theme.json.

Darin lassen sich unter anderem Farben, Typografie, Abstände und globale Styles definieren. Diese Vorgaben fließen in die Gestaltung und die verfügbaren Editor-Werkzeuge ein. Die Dokumentation zu Global Settings und Styles beschreibt diese Verbindung zwischen Theme und Oberfläche.

Das passt zu meiner Vorstellung von guter Theme-Entwicklung: Ich lege einen konsistenten Rahmen fest, innerhalb dessen Inhalte sinnvoll bearbeitet werden können.

Eine Redaktion sollte einen Text ändern oder ein Bild austauschen können, ohne dabei versehentlich das gesamte Layout umzubauen. Gleichzeitig möchte ich eine neue Gestaltungsentscheidung möglichst zentral umsetzen können. Wenn jeder Abschnitt eigene Sonderregeln bekommt, wird die Pflege schnell mühsam.

Block Themes bieten dafür eine brauchbare gemeinsame Grundlage. Wie gut sie funktioniert, hängt weiterhin davon ab, wie sorgfältig man das Theme aufbaut und welche Freiheiten man im Editor zulässt.

Patterns sind für mich besonders überzeugend

Einzelne Blöcke sind selten das, worüber jemand beim Pflegen einer Website nachdenkt. Meist geht es um einen fertigen Abschnitt: eine Leistung, ein Teammitglied, einen Hinweis oder einen Kontaktbereich.

Patterns bilden solche Zusammenstellungen ab. Mit WordPress 6.3 wurden Inhalte, Templates und Patterns enger im Site Editor zusammengeführt. Synchronisierte Patterns und Style-Revisionen machten die Arbeit damit nachvollziehbarer. WordPress 6.3 „Lionel“

Besonders interessant wurde es mit den Overrides für synchronisierte Patterns in WordPress 6.6. Damit können bestimmte Inhalte pro Verwendung unterschiedlich sein, während die gemeinsame Gestaltung erhalten bleibt. Zum Start galt das für unterstützte Inhalte in Überschriften, Absätzen, Buttons und Bildern. WordPress 6.6 „Dorsey“

Ein einfaches Beispiel: Mehrere Leistungsseiten verwenden denselben Kontaktabschnitt. Überschrift und Buttontext dürfen zum jeweiligen Thema passen. Die Struktur und Gestaltung sollen aber zusammenbleiben.

Genau solche Anforderungen machen den Ansatz für mich praktisch interessant. Sie kommen beim Bauen und Betreuen von Websites ständig vor.

Auch die seit WordPress 6.5 verfügbare Block Bindings API passt in dieses Bild. Unterstützte Blockattribute können mit Datenquellen verbunden werden, etwa mit passend registrierten Post-Metadaten. Dadurch braucht nicht jede dynamische Textausgabe sofort einen vollständig eigenen Block. Die Grenzen hängen allerdings von den unterstützten Attributen und Datenquellen ab. Einführung der Block Bindings API

Die Interactivity API macht die Entwicklung noch interessanter

Der offizielle Name lautet Interactivity API. Sie gehört seit WordPress 6.5 zu Core und schafft einen gemeinsamen Weg, interaktives Verhalten im Frontend von Blöcken umzusetzen.

Zustand, Aktionen und die Verbindung zum Markup folgen dabei einem gemeinsamen Modell. Mehrere Blöcke können zusammenarbeiten: Ändert sich ein Zustand an einer Stelle, kann eine andere darauf reagieren. Die API ist für das Frontend gedacht; sie ersetzt nicht die APIs des Block-Editors. Interactivity API in WordPress 6.5

Mich überzeugt daran vor allem die gemeinsame Grundlage. Ein Filter, eine aufklappbare Ansicht oder eine dynamische Ergebnisliste braucht nachvollziehbare Zustände und saubere Übergänge. Dafür möchte ich möglichst wenig projektspezifischen Verbindungscode pflegen müssen.

Die späteren Änderungen zeigen, dass auch die schwierigeren Details bearbeitet werden:

WordPress 6.9: Die clientseitige Navigation kann zusätzlich benötigte Stylesheets und kompatible Script-Module nachladen. Das ist relevant, wenn die nächste Ansicht andere interaktive Blöcke enthält. Die Kompatibilität der Module muss dafür entsprechend deklariert sein. Dev Note zur Navigation in 6.9
WordPress 7.0: Mit watch() lässt sich auf Änderungen reaktiver Werte auch unabhängig vom Lebenszyklus eines DOM-Elements reagieren. Außerdem wird state.url des Routers bereits serverseitig initialisiert. Änderungen der Interactivity API in 7.0

Das macht aus einer WordPress-Seite nicht automatisch eine perfekt funktionierende Web-App. Ladezustände, Fehlerfälle, Tastaturbedienung und Performance bleiben Entwicklungsaufgaben. Aber es gibt einen klareren Ort, an dem diese Arbeit ansetzen kann.

Auch die jüngsten Releases lösen konkrete Gestaltungsprobleme

WordPress 7.1, veröffentlicht am 19. August 2026, bringt weitere responsive Einstellungen in den Site Editor. Dazu gehören Anpassungen für verschiedene Bildschirmgrößen sowie eigene mobile und Tablet-Breakpoints für Block Themes über theme.json. Hinzu kommen Gestaltungsmöglichkeiten für Zustände wie Hover, Fokus und Active. WordPress 7.1 „Mary Lou“

Gerade solche Details sind für mich wichtig. Eine Oberfläche kann im ersten Entwurf gut aussehen und trotzdem bei kleineren Bildschirmen oder bei der Tastaturbedienung auseinanderfallen. Je mehr dieser Anforderungen das gemeinsame System sinnvoll abbildet, desto weniger muss jedes Theme sie separat organisieren.

Die im September veröffentlichte Roadmap für WordPress 7.2 führt diese Arbeit weiter. Geplant sind unter anderem zusätzliche Möglichkeiten für responsive Styles und ein unterstützter Weg, clientseitige Navigationen über die Interactivity API zu beobachten. Das sind Entwicklungsziele, keine bereits ausgelieferten Funktionen. Die Roadmap stellt außerdem ausdrücklich klar, dass gemeinsames Bearbeiten in Echtzeit nicht für 7.2 eingeplant ist. Roadmap zu WordPress 7.2

Diese Trennung zwischen vorhanden, experimentell und geplant gehört für mich zu einem fairen Blick auf die Entwicklung.

Es bleibt Arbeit für Entwickler

Ich halte Block Themes inzwischen für eine sehr gute Option. Trotzdem würde ich ein bestehendes, funktionierendes Projekt nicht allein deshalb umbauen, weil es noch ein klassisches Theme verwendet.

Auch der Umgang mit Änderungen braucht klare Regeln. Im Site Editor angepasste Templates werden in der Datenbank gespeichert und können die Template-Dateien des Themes überlagern. Wer zwischen Editor und Code arbeitet, muss das beim Versionieren und Ausliefern berücksichtigen. Das Theme-Handbuch zu Templates erläutert dieses Verhalten.

Dazu kommen bekannte Aufgaben: sinnvolle Inhaltsmodelle, passende Erweiterungen, zugängliche Komponenten und eine Oberfläche, mit der andere Menschen gerne arbeiten. Ein Block Theme nimmt einem diese Entscheidungen nicht ab.

Was sich verändert hat, ist meine Ausgangsfrage. Früher wollte ich vor allem wissen, wie ich Gutenberg möglichst aus dem Weg gehe. Heute schaue ich zuerst, welche Teile einer Anforderung sich mit dem vorhandenen Blocksystem sauber lösen lassen.

Ich habe meine Meinung geändert

WordPress spielt heute für mich weiterhin eine andere Rolle als React oder Next.js bei einer individuell entwickelten Anwendung. Gerade für Websites mit viel redaktionellem Inhalt finde ich die Entwicklung rund um Block Themes aber zunehmend überzeugend.

Das Ökosystem hat sich in dieser Hinsicht gut entwickelt: Gestaltung, wiederverwendbare Abschnitte, dynamische Inhalte und interaktives Verhalten finden stärker auf gemeinsamen technischen Grundlagen zusammen.

Meine anfängliche Skepsis kann ich noch nachvollziehen. Ich möchte nur nicht, dass sie meine Einschätzung für immer bestimmt.

Gutenberg ist erwachsener geworden. Und ich bin deutlich offener dafür geworden, was sich damit bauen lässt.

Stand: 29. September 2026. Die technischen Angaben stützen sich auf die verlinkten offiziellen Release Notes, Dev Notes und Handbücher. Aussagen zu WordPress 7.2 beziehen sich auf die Roadmap.