WordPress 7.0 sollte ursprünglich eines der spannendsten Updates der letzten Jahre werden. Im Mittelpunkt stand die geplante Echtzeit-Zusammenarbeit im Block-Editor – also die Möglichkeit, dass mehrere Personen gleichzeitig an Beiträgen, Seiten oder Layouts arbeiten können. Gerade für Agenturen, Redaktionen und Unternehmen wäre das ein wichtiger Schritt gewesen: weniger Abstimmung über externe Dokumente, weniger Bearbeitungskonflikte und ein modernerer Workflow direkt im WordPress-Backend.
Kurz vor der Veröffentlichung wurde dieses Feature jedoch aus WordPress 7.0 gestrichen. Das klingt im ersten Moment nach einem Rückschritt, ist aus technischer Sicht aber eine vernünftige Entscheidung. WordPress läuft auf sehr unterschiedlichen Hosting-Umgebungen – von einfachen Shared-Hosting-Paketen bis zu komplexen Enterprise-Setups. Ein Feature, das laufend Änderungen synchronisiert, darf deshalb nicht nur unter Idealbedingungen funktionieren. Es muss stabil, performant und möglichst kompatibel mit bestehenden Websites, Plugins und Serverkonfigurationen sein.
Was war mit der Echtzeit-Zusammenarbeit geplant?
Die Real-Time Collaboration gehört zur dritten Phase des Gutenberg-Projekts. Während Phase 1 den Block-Editor eingeführt und Phase 2 den Site Editor sowie blockbasierte Website-Strukturen vorangetrieben hat, dreht sich Phase 3 um Zusammenarbeit, Workflows und bessere redaktionelle Prozesse.
Geplant war im Kern ein deutlich moderneres Bearbeitungserlebnis. Mehrere Nutzer sollten parallel im Editor arbeiten können, Änderungen sollten synchron sichtbar werden und klassische Bearbeitungssperren sollten langfristig weniger wichtig werden. Für Websites mit mehreren Redakteuren, Freigabeprozessen oder Agentur-Workflows wäre das ein großer Schritt gewesen.
Gerade deshalb wurde die Funktion mit hohen Erwartungen verbunden. WordPress hätte sich damit stärker in Richtung kollaboratives Content-System entwickelt – näher an Arbeitsweisen, die viele Teams bereits aus Tools wie Google Docs, Notion oder modernen SaaS-Plattformen kennen.
Warum wurde das Feature aus WordPress 7.0 entfernt?
Der wichtigste Punkt: Die Funktion war offenbar noch nicht stabil genug für den Einsatz im WordPress-Core.
Matt Mullenweg entschied laut Make WordPress Core, die Echtzeit-Zusammenarbeit nicht mit WordPress 7.0 auszuliefern. Als Gründe wurden mehrere technische Risiken genannt, darunter eine zu große technische Angriffs- und Fehlerfläche, mögliche Race Conditions, Serverlast, Speicherverbrauch sowie wiederkehrende Fehler, die bei Fuzz-Tests gefunden wurden.
Das ist besonders relevant, weil WordPress kein geschlossenes System ist. Ein neues Core-Feature muss mit vielen Themes, Plugins, Hosting-Umgebungen und individuellen Konfigurationen zusammenspielen. Eine instabile Kollaborationsfunktion könnte im schlimmsten Fall zu verlorenen Änderungen, Performance-Problemen oder schwer nachvollziehbaren Fehlern im Editor führen.
Aus unserer Sicht ist die Entscheidung daher richtig. Ein verzögertes Feature ist ärgerlich. Ein instabiles Feature im WordPress-Core wäre deutlich problematischer.
Datenbank, Serverlast und Plugin-Kompatibilität als Knackpunkte
Die technische Herausforderung liegt nicht nur im sichtbaren Editor. Echtzeit-Zusammenarbeit benötigt eine zuverlässige Synchronisierung im Hintergrund. Änderungen müssen gespeichert, verteilt, abgeglichen und bei Konflikten sauber verarbeitet werden.
Ein zentraler Streitpunkt war die Datenstruktur. Zunächst standen offenbar Übergangslösungen über bestehende WordPress-Strukturen wie postmeta und transients im Raum. Gleichzeitig wurde diskutiert, ob eine eigene Datenbanktabelle der bessere Weg wäre, um das Feature langfristig sauber und performant abzubilden. HostPress fasst diesen Punkt ebenfalls als wichtigen Hintergrund der Verschiebung zusammen.
Dazu kommt die Serverlast. Wenn mehrere Nutzer gleichzeitig arbeiten und der Editor Änderungen regelmäßig synchronisiert, entstehen zusätzliche Anfragen und Schreibvorgänge. Das muss auf kleinen Hosting-Paketen genauso verlässlich funktionieren wie auf leistungsstarken Servern. Für ein System mit der Verbreitung von WordPress ist das kein Detail, sondern eine Grundsatzfrage.
Auch Plugins spielen eine Rolle. Viele WordPress-Websites nutzen noch klassische Metaboxen, Custom Fields, Pagebuilder-Elemente oder eigene Editor-Erweiterungen. Wenn diese nicht sauber mit der neuen Kollaborationslogik zusammenspielen, entstehen Fehler genau dort, wo WordPress besonders stark individualisiert ist: bei realen Kundenprojekten.
Was bedeutet das für WordPress 7.0?
WordPress 7.0 wird damit nicht das große Collaboration-Release, als das es ursprünglich erwartet wurde. Die Echtzeit-Zusammenarbeit bleibt aber ein wichtiges Ziel des Gutenberg-Projekts und soll nach weiteren Tests und Iterationen für eine spätere Version vorbereitet werden. Das offizielle Core-Team spricht ausdrücklich davon, dass Real-Time Collaboration weiterhin ein wichtiges Feature für WordPress bleibt.
Für Website-Betreiber bedeutet das: WordPress 7.0 sollte vor allem unter dem Blickwinkel Stabilität, Kompatibilität und technische Weiterentwicklung bewertet werden. Wer auf das Collaboration-Feature gewartet hat, muss sich noch gedulden. Wer eine bestehende Website betreibt, profitiert aber davon, dass ein potenziell problematisches Feature nicht überhastet ausgeliefert wird.
Der neue Release-Fahrplan für WordPress 7.0
Der ursprüngliche Zeitplan wurde bereits angepasst. Laut offiziellem Make-WordPress-Beitrag ist WordPress 7.0 nun für den 20. Mai 2026 geplant. Der aktualisierte Fahrplan sieht beziehungsweise sah folgende Stationen vor:
| Datum | Meilenstein |
|---|---|
| 19. Februar 2026 | Beta 1 |
| 26. Februar 2026 | Beta 2 |
| 5. März 2026 | Beta 3 |
| 10. März 2026 | zusätzliche Beta 4 |
| 12. März 2026 | Beta 5 |
| 24. März 2026 | Release Candidate 1 |
| 26. März 2026 | Release Candidate 2 |
| 24. April 2026 | Aufruf zu Hosting-Kompatibilitätstests |
| 8. Mai 2026 | Release Candidate 3 |
| 14. Mai 2026 | Release Candidate 4 |
| 19. Mai 2026 | Dry Run / 24-Stunden-Code-Freeze |
| 20. Mai 2026 | geplante Veröffentlichung von WordPress 7.0 |
Darüber hinaus nennt die offizielle WordPress-Roadmap bereits die nächsten geplanten Major-Releases: WordPress 7.1 ist für den 19. August 2026 vorgesehen, WordPress 7.2 für den 10. Dezember 2026. Neue Funktionen werden jeweils rund einen Monat vor Veröffentlichung eingefroren, danach liegt der Fokus auf Qualität und Performance.
Sollte man WordPress 7.0 sofort installieren?
Bei Major-Releases empfehlen wir grundsätzlich einen kontrollierten Ablauf. WordPress 7.0 sollte nicht ungetestet auf produktiven Unternehmensseiten installiert werden – vor allem dann nicht, wenn viele Plugins, ein individuelles Theme, WooCommerce, mehrsprachige Inhalte oder komplexe Custom-Fields-Strukturen im Einsatz sind.
Sinnvoll ist ein Update zuerst in einer Staging-Umgebung. Dort sollten Backend, Editor, Formulare, Shop-Funktionen, individuelle Blöcke, Caching, SEO-Plugins und zentrale Seitentypen geprüft werden. Erst wenn keine Auffälligkeiten auftreten, sollte die Live-Website aktualisiert werden.
Für kleinere Websites ohne komplexe Erweiterungen kann das Update meist zeitnah erfolgen. Bei geschäftskritischen Websites ist es dagegen oft klüger, die ersten Wartungs- und Fehlerbehebungsupdates abzuwarten.
Unser Fazit
Dass WordPress die Echtzeit-Zusammenarbeit kurzfristig aus Version 7.0 entfernt, ist keine Schwäche, sondern ein Zeichen technischer Vorsicht. Collaboration im Editor ist ein großer Schritt – aber genau deshalb muss die Grundlage stimmen.
Für Unternehmen, Redaktionen und Agenturen bleibt das Feature hochinteressant. Sobald es stabil genug ist, kann es redaktionelle Abläufe in WordPress deutlich verbessern. Für den Moment ist aber entscheidend, dass WordPress 7.0 stabil veröffentlicht wird und bestehende Websites nicht durch ein zu früh integriertes Kernfeature gefährdet werden.
Wer WordPress professionell einsetzt, sollte WordPress 7.0 daher nicht als verpasstes Versprechen sehen, sondern als Übergang in eine neue Entwicklungsphase. Die Richtung ist klar: WordPress wird kollaborativer, moderner und stärker auf komplexe Workflows ausgerichtet. Nur der technische Unterbau braucht noch mehr Zeit.
