Vom Bleiben des Classic Editors bis zu responsiven Stylings ohne CSS
Nach dem Eklat um WordPress 7.0 kommt bereits drei Monate später, am 19. August, das WordPress 7.1 Update. Während das vorangegangene Major Release WordPress 7.0 im Mai 2026 primär als architektonischer Meilenstein diente und grundlegende KI-Funktionalitäten verankerte , konzentriert sich Version 7.1 auf die Beseitigung alltäglicher Workflow-Reibungen. Die Einführung von nativem responsivem Design im Site-Editor hin zu den ersten Schritten zur redaktionellen Zusammenarbeit findet jetzt mit WordPress 7.1 ihren Platz.
Dabei steht die kollaborative Zusammenarbeit immer noch im Zentrum des Interesses, da bis zum finalen Release noch einige strategische Entscheidungen getroffen werden müssen.
Wir zeigen dir hier, welche spannenden neuen Features es wahrscheinlich ins finale Release schaffen und welche Veränderungen du genau im Auge behalten solltest.
Beim Rollout des WordPress 7.1 Update kam es zu Problemen in Kombination mit WP Rocket.
Solltest du davon betroffen sein, findest du hier eine passende Lösung inkl. Tutorial .
In unserem dazugehörigen Artikel “ WordPress Updates 2026 – Risikos und Sicherheitslücken“ findest du zudem weitere Informationen und eine aktuelle Gefahrenanalyse rund um das Thema Updates.
Inhaltsverzeichnis
1. Rückblick und Hintergründe zu WordPress 7.1
Das schließlich am 20. Mai veröffentlichte Update zu WordPress 7.0 hatte eine extrem hohe Erwartungshaltung in der WordPress Community. Die erhoffte Real-Time Collaboration (RTC) wurde allerdings erst wenige Tage vor dem Release von Gründer Matt Mullenweg gecancelt.
Technische Ursachen für die Absage der Real-time-Collaboration in WordPress 7.0
Das Entfernen der Echtzeit-Kollaboration aus dem WordPress 7.0-Update war das Ergebnis verschiedenster Tests, die diverse Konflikte zwischen synchroner Status-Synchronisation und der Infrastruktur des WordPress-Ökosystems aufgezeigt haben . Dabei lassen sich vier Hauptprobleme identifizieren:
Race Conditions und Datenverlust: Bei gleichzeitiger Bearbeitung desselben Blocks durch mehrere Benutzer kommt es zu Synchronisationsfehlern und Datenkonflikten . Aufgrund fehlender Algorithmen wurden Bearbeitungszustände überschrieben oder visuelle Abweichungen in der Datenbank hinterlegt.
Server- und WebSocket-Skalierung: Das RTC-System benötigt extrem viele Ressourcen. Auf klassischen Shared-Hosting-Umgebungen führten die vielen Anfragen zu extremen Performanceproblemen und Server-Timeouts .
Speichereffizienz des Datenmodells: Das Speichern von kurzfristigen Synchronisationszuständen hat nicht ausgereicht und verursachte daher gerade für umfangreiche Webseiten mit komplexeren Strukturen Probleme.
Unzulänglichkeit der Last-Write-Wins-Logik: Der einfach gedachte Ansatz, den letzten eingehenden Schreibbefehl als gültig zu deuten, zeigte sich bei feingliedrigen Block-Architekturen als ineffizient und fehleranfällig.
Diese leider sehr zentralen Problemquellen konnten keinen sinnvollen Release abdecken. Daher wurde die Veröffentlichung der vollumfänglichen Echtzeit-Teamkollaboration bis auf weiteres gestrichen, damit sich das WordPress Core Team ausreichend Zeit nehmen kann, die Funktionen zu optimieren. Mit dem WordPress 7.1 Update kann mit der Umsetzung des Notes-Pakets bereits ein kleiner Schritt in Richtugn Ziel getan werden.
RTC-Fehler und ihre Konsequenzen für das WordPress 7.1 Update
| Probleme WordPress 7.0 | Ursache | Technische Konsequenz | Auswirkung WordPress 7.1 |
|---|---|---|---|
Concurrency Control | Fehlender Algorithmus | Überschreiben von Daten bei zeitgleichem Editieren | Implementierung von Operational Transformation |
Serverinfrastruktur | Hohe WebSocket-Anforderung | Überlastung von Shared-Hosting-Servern | Einführung von Host-seitigen-Feature-Flags (Opt-in) |
Netzwerk-Resilienz | Mangelnde Offline-Pufferung | Verbindungsabriss führt zu Datenverlust | Lokale Datenbankspeicherung bei Diskonnektivität |
Zugriffssteuerung | Globale Bearbeitungsfreigabe | Unkontrollierte Eingriffe in Live-Dokumente | Granulare rollenbasierte Simultanzugriffe |
Nach der etwas anderen Veröffentlichung von WordPress 7.0 fokussierte sich das Entwickler-Team auf die strategische Neuausrichtung des nächsten Updates. Anstatt die bisher noch fehleranfällige Kollaboration zu erzwingen, wurde dieser Bereich in zwei Entwicklungsstränge eingeteilt: die Perfektionierung der asynchronen Zusammenarbeit und die Rekonstruktion der synchronlaufenden Echtzeit-Architektur. Für das WordPress 7.1 Update wurde daher eine neue Outreach-Initiative gebildet:
Collaborative features require an inherently collaborative way of testing. For the 7.0 cycle, a lot of time and effort was spent with more developer oriented testing, enterprise level testing, and deterministic testing with hosts. While incredibly useful, this effort broadens the scope of testing by bringing in passionate real-world early adopters across a range of hosting environments and backgrounds. For collaborative editing to truly succeed, it’s important to go beyond just getting stability, performance, and reliability right.
Veröffentlichungszeitplan für WordPress 7.1
Der Entwicklungszyklus von WordPress 7.1 folgt einem strengen Zeitplan, da nach der Veröffentlichung von WordPress 7.0 nicht mal drei Monate bis zum nächsten Update geblieben sind.
Besonders spannend ist auch, dass das WordPress 7.1 Update ebenfalls wie 7.0 während eines WordCamps final releast werden soll – diesmal aber beim WordCamp US.
Der Zeitplan für WordPress 7.1 sieht aktuell so aus:
| Phase | Geplantes Datum | Status |
|---|---|---|
Entwicklungsbeginn | März 2026 | Zusammenstellung des Release Squads & Roadmap Definition |
Beta 1 | 15. Juli 2026 | Feature Freeze & Veröffentlichung der Testversion |
Beta 2 | 22. Juli 2026 | Wöchentlicher Bug Scrub & Komponenten Stabilisierung |
Beta 3 | 29. Juli 2026 | Behebung von Trac-Tickets & Gutenberg Snyc |
Release Candidate 1 | 05. August 2026 | Finalisierung der Strings & Übersetzungsprozesse |
Release Candidate 2 | 12. August 2026 | Letzte Korrekturen der Entwickler-APIs |
Dry Run | 18. August 2026 | Generalprobe des Veröffentlichungsprozesses |
Final Release | 19. August 2026 | Offizieller globaler Rollout (WordCamp US 2026) |
Status Quo der Real-time-Collaboration für das WordPress 7.1 Release
Seit WordPress 7.0 beschäftigt sich das Core Team mit der Weiterentwicklung und der Unterscheidung zwischen dem asynchronen Feedback-System und der kontrollierten Weiterentwicklung der synchronen Echtzeit-Funktionen . Daraus soll später eine optimierte Form der Teamkollaboration entstehen.
Asynchrone Zusammenarbeit bedeutet, dass Teammitglieder zeitversetzt arbeiten – etwa durch Kommentare, Änderungsvorschläge oder Freigaben.
Synchrone Zusammenarbeit beschreibt die gleichzeitige Bearbeitung eines Beitrags durch mehrere Personen. Änderungen werden dabei in Echtzeit angezeigt, ähnlich wie bei Google Docs.
Das asynchrone Kollaborationspaket: Weiterentwicklung von Notes
Die asynchrone Bearbeitung funktioniert als erweitertes Notizen Paket: das primäre Werkzeug für redaktionelle Teams. Darüber werden klassische Korrekturprozesse, wie zum Beispiel Kommentare oder Anmerkungen, direkt in den Editor Canvas übertragen.
Diese Funktion soll auch im WordPress 7.1 Update erscheinen, um zumindest einen Teil der Zusammenarbeit zu ermöglichen.
Der redaktionelle Arbeitsablauf im neuen System soll einer klaren Struktur folgen:
Sobald ein Redakteur einen Beitrag erstellt, können andere Autoren in den integrierten Vorschlagsmodus (Suggestion Mode) wechseln . In diesem Modus kannst du Textänderungen, Löschungen oder Ergänzungen initiieren, die aber nicht direkt in die Datenbank übernommen werden. Sie werden stattdessen in Form einer transparenten Änderungsebene gerendert und quasi als eine Art Vorschlag hinterlegt.
Admins und verantwortliche Redakteure können deine Vorschläge anschließend in der Seitenleiste einsehen und per Mausklick annehmen oder verwerfen .
Dieser Prozess wird durch ein spezielles Inline-Kommentarsystem ergänzt . Darüber kannst du dann Notizen an einzelnen Sätzen, Absätzen oder Gutenberg-Blöcken anbringen.
Die Kommentare können zudem mit klassischen Rich-Text-Formatierungen versehen werden, zum Beispiel:
- Fett- und Kursivdruck
- Inline-Code und Hyperlinks
- direkte Tastatur-Shortcuts
Durch bekannte Funktionen wie die Eingabe des @ –Symbols kannst du deine Teammitglieder gezielt taggen und automatisch benachrichtigen lassen. Das Hinzufügen von Emoji-Reaktionen ermöglicht dir zudem die schnelle Bestätigung (oder Ablehnung) von Feedback im Redaktionsalltag.
Der Entwicklungsstand der synchronen Echtzeit-Kollaboration
Die synchrone Echtzeit-Kollaboration wird gemeinhin mit Plattformen wie Google Docs oder Figma verglichen – ist in WordPress 7.1 aber bislang nicht standardmäßig für den Arbeitsalltag freigeschaltet . Sie bleibt aktuell als experimentelles System primär über spezielle Testprogramme und Entwicklerumgebungen zugänglich.
Um die Fehler der Version 7.0 zu beheben, wurde die technische Architektur für WordPress 7.1 nach folgenden Grundsätzen überarbeitet:
Einführung von Operational Transformation (OT): Anstelle der anfälligen „Last-Write-Wins“-Logik nutzt das System nun Operational Transformation . Das ermöglicht ein korrektes Zusammenführen von Text- und Blockänderungen ohne Datenverlust.
Opt-in auf Provider-Ebene: Hosting-Anbieter erhalten über ein standardisiertes Server-Flag die Möglichkeit die Real-time-Collaboration zu aktivieren oder zu deaktivieren . Dadurch wird die Überlastung von WebSocket-Verbindungen durch ressourcenbeschränkte Serverumgebungen verhindert.
Visuelle Cursor- und Selektionsanzeige: Als Nutzer siehst du nun im Editor die farblich codierten Cursormarker und aktiven Selektionen anderer Teammitglieder in Echtzeit .
Lokale Offline-Toleranz: Bei Netzwerkschwankungen oder kurzen Verbindungsabbrüchen puffert der Browser vorgenommene Editierschritte lokal und synchronisiert diese automatisch nach Verbindungswiederherstellung.
Granulare Berechtigungssteuerung: Du kannst im Editor detailliert festlegen, welche Benutzerrollen (z. B. Redakteure, Autoren, Mitarbeiter) zeitgleich im selben Dokument arbeiten dürfen .
2. Die Kernfeatures des WordPress 7.1 Updates im Detail
Neben der Weiterentwicklung der Kollaborationswerkzeuge führt WordPress 7.1 umfangreiche Neuerungen ein, von denen alle Nutzer profitieren sollen. Zum Beispiel in den Bereichen Design-Steuerung, Medienverarbeitung, Admin-Schnittstellen und Entwickler-APIs. Die Neuerungen und Anpassungen reagieren unter anderem auf Kritik aus der Community in Bezug auf Styling und Interaktionszustände.
Wie bei jedem Release gilt aber, dass die vom WordPress Core Team vorgestellten Neuerungen je nach Entwicklungsstadium nicht zwingend im finalen WordPress 7.1 Update erscheinen müssen.
👉🏻 Die genaue Roadmap zu WordPress 7.1 in allen Details kannst du hier noch einmal nachlesen.
Auch wenn die Weiterentwicklung der Real-time-Collaboration voranschreitet und in zwei grundlegende Bereiche aufgeteilt wurde, wird die Funktion nicht im WordPress 7.1 erscheinen. Das WordPress Core Team äußert sich dazu wie folgt:
These decisions, along with the readiness of the feature, are the key aspects to get right for all of WordPress and to align with project leadership on. They impact who gets access to the feature and what the experience will be like. To help aid the decision making and reliability of the feature, there’s a new dedicated outreach effort for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs.
Mehr Informationen zur Real-time-Collaboration findest du hier.
KI – Weiterentwicklung des KI Clients
Der KI-Client wird derzeit so bearbeitet, dass er Plugin-Entwickler primär unterstützen soll. Der Client bildet allerdings auch die Grundlage für weitere KI-Integrationen im WordPress Core. Aktuell sind zwei weitere Funktionen geplant:
- Generation Streaming
- Embeddings (stellt Inhalte als Vektoren da, um eine Suche über die Webseite zu ermöglichen)
Integrierter AI-Client (Bring Your Own Key)
- Funktionsweise: WordPress integriert eine native KI-Schnittstelle (AI Client API) im Core.
- Besonderheit: Es wird kein Standard-Modell (wie OpenAI oder Anthropic) mitgeliefert und keine externe Verbindung standardmäßig aufgebaut.
- Diskussion: Entwickler können eigene API-Keys und KI-Anbieter per PHP anbinden. In der Community wird diskutiert, ob dies ein mächtiger neuer Standard ist oder überflüssiger Code für Seiten, die keine KI nutzen.
Darüber hinaus wird aktuell daran gearbeitet, über API-Schlüssel hinaus weitere Authentifizierungsmethoden für Connectoren anzubieten. Geplant ist ein einfacher Start mit der Unterstützung von Benutzernamen und Anwendungspasswörtern.
Ein neues Richtlinien Feature definiert Schreib- und Inhaltsrichtlinien, die an KI-Tools angebunden sind. Diese Integration fördert ein dauerhaftes, strukturiertes System, in dem redaktionelle Regeln, der Markenauftritt und Inhaltsstandards direkt in WordPress selbst festgelegt werden können. Das fördert nochmals die direkte Zusammenarbeit innerhalb von WordPress und sorgt für eine höhere Konsistenz und Personalisierung der eigenen Marke.
Mehr Informationen zur Integration von KI in den WordPress Core kannst du hier nachlesen:
👉🏻 Was kommt im KI Client bei WordPress 7.1?
👉🏻 GitHub: Connectoren Konfiguration
👉🏻 Core Trac: Connectoren Erweiterung für die Bridge
Highlight: Responsive Styling – Mehr Kontrolle ohne zusätzliches CSS
Schon lange heißt es eigentlich Mobile First – mit der Anpassung der responsiven Styling Oberfläche wird das jetzt noch einfacher. Inhalte für Smartphones und Tablets lassen sich jetzt deutlich einfacher anpassen und direkt über den Editor organisieren.
Im Editor kannst du nun direkt Schriftgrößen, Abstände oder andere Designwerte für unterschiedliche Bildschirmbreiten festlegen. Das gilt sowohl für globale Styles, als auch für einzelne Blöcke.
Zu dem neuen Gestaltungsspielraum zählen unter anderem auch die interaktiven Zustände wie :hover, :focus und :active. Darüber kannst du Buttons oder Verlinkungen ganz einfach und ohne CSS-Kenntnisse beim Darüberfahren oder Anklicken verändern. Im Editor wird jetzt auch sichtbar dargestellt, ob eine Einstellung des Themes aus
- den globalen Styles kommt
- oder von einem übergeordneten Block übernommen wurde.
Diese Funktion soll zukünftig auf weitere Elemente ausgedehnt werden. Dazu gehören zum Beispiel Navigationen, Formularfelder oder auch Bilder.
Überarbeitete Responsive-Controls im Block-Editor
- Funktionsweise: Verbesserte Steuerung von Layouts für Mobil-, Tablet- und Desktop-Ansichten direkt im Editor.
- Diskussion: Viele sehen darin einen Schritt, der klassische Page-Builder (wie Elementor) weiter entlastet, auch wenn einige Community-Mitglieder die Umsetzung als noch ausbaufähig bezeichnen.
Admin-Bereich – mehr UX und neue Identitäts-Zentrale
Auch die Admin Oberfläche soll mit dem WordPress 7.1 Update weitere punktuelle Verfeinerungen erhalten, die den Wechsel zwischen den unterschiedlichen Editoren einfacher gestalten und administrative Wege verkürzen .
Die Befehlspalette fasst Ergebnisse in klareren Abschnitten zusammen und gliedert diese in kürzlich verwendete, vorgeschlagene und passende Befehle.
Diese Liste der aktiv genutzten Befehle wird gespeichert und dadurch effizienter genutzt werden. Zudem wurde das Design überarbeitet, die insbesondere das Verständnis der Ergebnisliste vereinfacht darstellt.
- Admin-Farbschema im Website-Editor: Der Website-Editor übernimmt nun das gewählte Admin-Farbschema statt eines festen dunklen Hintergrunds, was für ein einheitliches Erscheinungsbild sorgt.
- DataViews & DataForms: Konsistenteres Design durch Migration auf neue Design-System-Primitiven, Zusammenführung von Quick-Edit mit der Editor-Seitenleiste
- Bereich für Website-Identität: Ein neuer Bereich (Design → Identität) bündelt Einstellungen für Logo, Favicon, Titel und Untertitel an einem zentralen Ort.
- Widget „An diesem Tag“: Besonders liebevoll ist dieses neue Dashboard-Widget. Es zeigt vergangene Beiträge an, um an frühere Inhalte zu erinnern und zum Schreiben zu motivieren.
- Dauerhafte Admin-Leiste (Omnibar): Die Admin-Leiste ist nun in allen Editoren direkt verfügbar; inklusive Design-Updates wie entferntem Begrüßungstext, runden Profilbildern und modernen SVG-Icons.
APIs
Die Weiterentwicklung der WordPress APIs bringt wichtige Neuerungen mit, die vor allem darauf abzielen, die Leistung für Entwickler zu verbessern und auf moderne Standards anzuheben. Dazu zählen die folgenden Neuerungen:
Native SVG-Icon-Registrierung (PHP API)
- Funktionsweise: Eigene SVG-Icons können nun direkt über eine PHP-API im Core registriert werden.
- Vorteil: Entwickler benötigen keine JavaScript-Workarounds oder Extra-Plugins mehr, um benutzerdefinierte Icons in den Block-Editor zu integrieren.
Abilities-API: Verbessertes Abfragen und Filtern von Funktionen sowie die Integration von zentralen Core-Funktionen für Entwickler und KI-Tools.
Block Bindings: Erweiterte Unterstützung für Listenelemente und innere Blöcke. Inhalte lassen sich dynamischer mit externen Datenquellen verknüpfen.
Iframed Editor: Bei blockbasierten Themes wird die Ausführung des Editors in einem iframe ab jetzt zur Pflicht. Darüber sollen Editor-Styles sauber vom Admin-Bereich getrennt werden.
Unicode für E-Mail-Adressen: Erweiterte Speicherung und Validierung (damit auch Nicht-ASCII-Zeichen in E-Mail-Adressen unterstützt werden.
⚠️ Cancelled – U pgrade auf React 19: Aktualisierung des Frameworks von React 18 auf React 19 bringt neue APIs und geänderte Typen; vor dem Core-Rollout zunächst als Test-Experiment im Gutenberg-Plugin verfügbar.
Auch wenn React 19 Ende Juli offiziell aus dem WordPress 7.1 Update gestrichen wurde, sollten Pluginentwickler ihre Tools frühzeitig darauf vorbereiten bzw. anpassen. Grund für das Streichen von React 19 sind anhaltende Kompatibilitätsprobleme. WordPress 7.1 wird jetzt mit React 18.3 veröffentlicht.
Besonders kritisch sind Plugins, die React oder den react/jsx-runtime selbst in ihre JavaScript-Dateien integrieren. Treffen dabei React 18 und React 19 aufeinander, können Blöcke oder ganze Editor-Oberflächen abstürzen.
Nach einer Umstellung solltest du alle Editor-Funktionen unbedingt testen und insbesondere auch Warnungen in deiner Browserkonsole achten. So vermeidest du später schwere Kompatibilitätsprobleme.
Blöcke
Auch im Bereich der Blöcke soll sich was tun. Der Fokus liegt darauf, das Erstellen von Inhalten flexibler zu gestalten, den Editor durch moderne Block-Typen zu erweitern und alltägliche Hürden beim Schreiben sowie bei der Anordnung von Elementen abzubauen.
- Erweiterung der Icon-API: Öffnung der API für Drittanbieter (u. a. eigene Icon-Sets), neuer wiederverwendbarer Icon-Auswahl-Dialog, Funktionen wie Spiegeln und Drehen für den Icon-Block sowie ein optisches Refresh des Core-Icon-Sets.
- Neue Core-Blöcke:
- Wiedergabeliste (Playlist): Mit Audio-Visualisierung per Wellenform.
- Inhaltsverzeichnis (Table of Contents): Automatische Links zu den Überschriften im Text.
- Reiter (Tabs): Strukturierung von Inhalten in Registerkarten.
Verbesserung bestehender Blöcke
Verbesserungen bestehender Blöcke:
- Galerie-Block: Überarbeitete Lightbox mit Wisch-Gesten und mobilen Bildunterschriften.
- HTML-Block: Ermöglicht nun verschachtelte, bearbeitbare Blöcke (besonders nützlich bei KI-generierten Inhalten).
- Bild-Block: Neuer Umschalter „Als dekorativ markieren“ zur Ausblendung für Screenreader.
- Shortcode- & Embed-Blöcke: Intelligente Umwandlung von Shortcodes in vollwertige Blöcke oder Embeds.
- Gruppen-Block: Neue Unterstützung für Hintergrundverläufe parallel zu Hintergrundbildern.
Optimierter Schreibfluss: Bessere Drag-and-Drop-Funktionalität und verlässlichere Mehrfachauswahl auf Touch-Geräten.
Highlight: Kehrtwende beim Classic-Block
Für größere Diskussionen in der Entwickler-Community sorgte im Vorfeld des WordPress 7.1 Releases die geplante Entfernung des Classic-Blocks (core/freeform ) aus dem Inserter. Da Gutenberg seit jeher bei vielen Nutzern in der Kritik bzgl. Leistungsfähigkeit und Funktionsumfang steht, war zu erwarten, dass diese Ankündigung Anfang Juni nicht ohne Folgen blieb. Am 07 Juli wurde die Entscheidung, den Classic Editor einzustampfen, offiziell zurückgenommen.
Ursprünglich sollte dieser Schritt die finale Umstellung auf den Gutenberg Block-Editor erzwingen . Der Classic-Block bleibt somit weiterhin regulär im WordPress Core bestehen und ist über die Blocksuche sowie über den Slash-Befehl (/classic) abrufbar. Die Strategie des Core-Teams verlagert sich damit vom „Zwang“ hin zur freiwilligen Adaption durch eine hoffentlich kontinuierliche Verbesserung der Gutenberg-Experience.
Das Feedback aus der WordPress Community zum Classic Editor war mehr als eindeutig. Mit der Entfernung würde der Nutzer dazu gezwungen, den Gutenberg Editor zu verwenden – ein Ziel, das gut gemeint ist, in der Praxis aber für viele unrealistisch ist. Die Nutzererfahrung bleibt ohne den Classic Editor für viele schlechter. Einige Community-Mitglieder schlugen zudem vor, den Gutenberg Editor durch andere Features interessanter zu gestalten und nicht über einen künstlich erzeugten Zwang zugänglich zu machen.
Sonstige Anpassungen und Erweiterungen
Neben den Kernfunktionen bringt das Update zahlreiche Verbesserungen in den Bereichen Design-Anpassung, Medienverarbeitung und Systemleistung.
- Funktionsweise: Bilder werden beim Upload direkt im Browser (Client-seitig) skaliert und komprimiert, bevor sie an den Server gesendet werden.
- Vorteil: Reduziert die Serverlast beim Upload erheblich.
- Diskussion: Entwickler testen derzeit, wie sich dies auf benutzerdefinierte Bildgrößen (Hooks) auswirkt, da sich das Verhalten je nach Browser (z. B. Chrome vs. Firefox) und Editor-Umfeld unterscheidet.
- Diverse Optimierungen im Gutenberg-Editor (u. a. freies Zuschneiden von Bildern, verbesserte Barrierefreiheit und UI-Updates).
Ein langjähriger Kritikpunkt an Gutenberg ist die Notwendigkeit, für feingliedrige responsive Anpassungen auf benutzerdefiniertes CSS zurückzugreifen . WordPress 7.1 soll diese Lücke durch die Integration visueller Steuerungselemente endlich schließen.
Transparenz bei vererbtem Styling: Die Editor-Seitenleiste zeigt künftig an, ob ein Stil übernommen wurde.
Styling interaktiver Zustände: Pseudo-Zustände wie :hover, :focus und :active lassen sich direkt anwenden.
Optimierte Pattern-Bearbeitung: UX-Verbesserungen und Fehlerbehebungen.
Erweiterte clientseitige Medienverarbeitung: Unterstützung für HEIC und Ultra-HDR, Umwandeln von GIFs in Videos.
Neues Medien-Editor-Modal
Dynamische Mediengalerien: Verbesserte Umwandlung alter Shortcodes
Schnelleres Laden durch Speculative Loading
Performance-Plugins: Weiterentwicklung der Plugins View Transitions
3. Zukunftsausblick für 2027: Wie wird sich der WordPress Core verändern?
Was 2026 wohl nicht mehr realisiert wird, steht bei vielen Nutzern für 2027 auf der absoluten Wunschliste. Die Entwicklung von Gutenberg zeigt sich in seinen vier Phasen langatmiger als zunächst angenommen. Seit bereits einigen Jahren soll Gutenberg der Standard Page-Builder für WordPress werden.
Die Verzögerung und technischen Herausforderungen rund um die kollaborative Zusammenarbeit zeigen aber, warum so viele Nutzer skeptisch bleiben – weil es dauert und viele wichtige Features nicht ausgereift sind.
Und obwohl die Nutzer sehnsüchtig auf das Gutenberg Update warten, setzt das WordPress Core Team eine ganz zentrale strategische Entscheidung. Anstatt fehleranfällige bzw. problembehaftete Funktionen zu veröffentlichen, wird das Release erst einmal geparkt. Die Zurückstellung der synchronen Echtzeit-Kollaboration zugunsten des hochfunktionalen, asynchronen „Notes“-Systems schützt Millionen Nutzer von Shared-Hosting-Instanzen vor Performance-Problemen und bietet Redaktionsteams dennoch einen direkten Mehrwert im täglichen Workflow .
Die vollständige RTC-Integration soll noch 2026 final realisiert werden können und damit wahrscheinlich mit dem WordPress 7.2 Update kommen.
Die gesamte Roadmap für WordPress in 2026 findest du hier:
⁉️ Schon gewusst?
Gutenberg wurde zum ersten Mal im Juni 2017 vorgestellt und im Dezember 2018 offiziell mit WordPress 5.0 im WordPress Core veröffentlicht. Seit 2019 wird Gutenberg in den vier Phasen weiterentwickelt.
Zudem steht immer noch der Übergang der Gutenberh Phase 4 für 2027 im Raum: die Mehrsprachigkeit (Multilingual Core). Diese wird aber ganz eindeutig von der Beendigung der dritten Phase abhängig sein.
Mit der Stabilisierung von DataViews, DataForms und den erweiterten REST/GraphQL‑Endpunkten würde sich WordPress 2027 endlich zu einem hybriden Headless Content Operating System wandeln. Entwickler können das Backend als hochspezialisiertes Eingabe- und Kollaborationswerkzeug nutzen, während die Auslieferung über moderne Frontend-Frameworks erfolgt.
Ob das aber eine realistische Erwartungshaltung für 2027 ist? Davon gehen wir erst einmal nicht aus. Auch wir bleiben gespannt, wie und in welchem Zeitrahmen sich das große Gutenberg Jahrzehnt abschließen lässt.
4. WordPress 7.1 – lohnt sich das Update wirklich
Wir sagen: Ja!
Obwohl die Real-time-Collaboration mit WordPress 7.1 nicht aktiv und vollumfänglich releast wird, bleibt das Update trotzdem voller wichtiger Anpassungen. Das Major-Release verzichtet damit auf überstürzte Experimente und konzentriert sich stattdessen auf die Lösung alltäglicher Reibungspunkte im Redaktions- und Design-Alltag.
Die wichtigsten Neuerungen auf einen Blick:
- Asynchrone Kollaboration
- No-Code-Design
- Marken-Guidelines
- Gefühlte UX-Gewinne, wie die präsente Admin-Leiste
- Technische Fundament Anpassungen
Wir haben einige Tipps, wie du deine Webseite auf das Update vorbereiten kannst:
- Staging-Tests erzwingen: Aufgrund der strikten Durchsetzung des Editor-Iframes und der Anforderungen der Block API v3 solltest du dein Theme und Custom Blocks zwingend auf einer Testumgebung auf Darstellungskompatibilität überprüfen.
- PHP-Version prüfen: Überprüfe, ob dein Server mindestens auf PHP 8.2 läuft.
- Plugin-Kompatibilität abgleichen: Prüfe komplexe Page Builder sowie Formular- und E-Commerce-Plugins für das React 19 Readiness Update.
- Guidelines definieren: Wenn du viel auf redaktioneller Ebene arbeitest, kannst du ab sofort Redaktionsleitfäden und Markenregeln unter Einstellungen → Richtlinien hinterlegen, um menschliche Autoren und KI-Tools nahtlos zu steuern.
Wieso eigentlich halten so viele noch an dem alten Editor fest? Gibt es da einen echten Grund? Ich hatte schon immer neidisch auf die ganzen Website Builder geguckt, wollte die aber ungern als Abhängigkeit für den Grundlegenden Inhalt einbinden. Der Gutenberg Editor mit seinen Blöcken war da einfach ein Segen und ich freue mich das man jetzt endlich noch die Möglichkeit gibt für unterschiedliche Screens Anpassungen machen zu können. Das fehlte bisher wirklich bei dem Konzept.
In Gutenberg steckt auf jeden Fall sehr viel Potenzial und ich finde es auch extrem gut, dass die Weiterentwicklung so viele wichtige Anpassungen wie eben die Screen-Anpassungen mitbringt. Wichtig und richtig. Bezüglich des alten Editors halten viele Nutzer daran fest, weil er für reines Texteschreiben oft gut geeignet ist, ohne dabei das Design versehentlich zu verändern. Viele alte Webseiten laufen mit den individuellen Eingabefeldern schlicht stabiler und einfacher. Eine Umstellung bedeutet auch einfach viel Arbeit, die sich nicht jeder machen möchte. 🙂