WordPress 7.1 Echtzeit-Kollaboration

Die Echtzeit-Kollaboration hat einen zweiten Anlauf im WordPress-Kern bekommen, und sie hat ihn wieder verpasst. Zwei Wochen vor der Veröffentlichung von WordPress 7.0 zog das Beitragenden-Team genau das aus dem Verkehr, was das Aushängeschild der Version sein sollte. Als Grund wurden damals Performance-Probleme der Datenbank genannt, deren Behebung das Team innerhalb des Veröffentlichungsfensters nicht zusichern konnte. Sechs Wochen später stand dieselbe Funktion wieder auf dem Plan für WordPress 7.1, mit einem FSE-Testprogramm und dem 19. August als Kalenderanker.

WordPress 7.1 Mary Lou ist am 19. August 2026 ohne Live-Mehrautoren-Bearbeitung erschienen. Das sind zwei aufeinanderfolgende Major-Releases. Der Rest dieses Textes ist der Zyklus, wie er damals stand, plus das, was Agenturen jetzt tun sollten, nachdem das Paket die Funktion nicht enthält.

Für Agenturen, die redaktionelle Abläufe auf WordPress betreiben, hat das Fehlen ganz konkrete Folgen. Die Mehrautoren-Bearbeitung wäre weiterhin die größte Änderung redaktioneller Abläufe im Kern seit über einem Jahrzehnt. Sie würde die Konfliktfläche bei langen Inhalten verändern, neu definieren, was eine Sperre auf einem Beitrag bedeutet, und verschieben, wofür der Block-Editor eigentlich da ist. Nichts davon ist in 7.1 angekommen. Schulen Sie Kundinnen und Kunden nicht auf einen Ersatz der Beitragssperre, den es nicht gibt.

Wer in deutschen Redaktionen arbeitet, kennt diese Spannung übrigens schon: Großverlage wie die Süddeutsche oder die taz fahren ihre digitalen Abläufe mit mehreren Autorinnen und Schlussredakteurinnen am selben Text, und genau dort entscheidet sich, ob die Funktion tragfähig ist.

#Was aus 7.0 herausgenommen wurde und warum

Echtzeit-Kollaboration im Block-Editor braucht drei Komponenten, um im Maßstab zu funktionieren: einen Präsenz- und Cursor-Kanal mit niedriger Latenz, eine konfliktfreie Merge-Strategie für Blockänderungen und eine Speicherschicht, die die zusammengeführte Historie hält, ohne das bestehende Modell aus wp_posts und wp_postmeta zu sprengen.

Der Präsenz- und Cursor-Kanal wurde im 6.x-Zyklus gelöst, mit einer Kombination aus Long-Polling und einem optionalen WebSocket-Transport für Websites, die bereit sind, die zusätzliche Infrastruktur zu betreiben. Die konfliktfreie Merge-Strategie landete Ende 2025 im Gutenberg-Plugin mit einem CRDT-basierten Ansatz. Beim dritten Baustein, der Speicherschicht, ist 7.0 dann gescheitert.

Die 7.0-Implementierung speicherte den Kollaborationszustand in einer neuen Tabelle, die an die Post-Revisionen gekoppelt war. Auf kleineren Installationen funktionierte das. In der Größenordnung einer Automattic-Testumgebung mit 50.000+ gleichzeitigen Bearbeitungen erzeugten die Schreibvorgänge in die neue Tabelle Replikationsverzögerung und Lock-Contention, die das Team als Release-Blocker einstufte. Die Entscheidung zur Herausnahme fiel Mitte April, zwei Wochen vor dem GA-Termin von 7.0.

Anne McCarthys Ankündigung des neuen Outreach-Programms räumt ein, dass die Datenbankarchitektur die offene Frage bleibt: Das Team hat Hypothesen, wie sich das Problem beheben lässt, aber zum Start des 7.1-Zyklus keine verbindlich beschlossene Implementierung. Das ist ungewöhnlich für eine Funktion, die auf ein Release gezielt wird.

#Das Henne-Ei-Problem

Amy Kamala, Co-Repräsentantin des Hosting-Teams, brachte die Lage in einem Satz auf den Punkt: “Need testing to make decision, need decision to do testing.”

Die architektonischen Optionen für die Speicherschicht haben für unterschiedliche Hosting-Umgebungen sehr unterschiedliche Kostenprofile. Eine Lösung, die auf einer Single-Server-Installation gut funktioniert, übersteht ein Load-Balanced-Setup mit Read-Replicas möglicherweise nicht. Eine Lösung, die in einer Single-Tenant-Managed-Hosting-Umgebung passt, funktioniert vielleicht nicht im Multisite in der Größenordnung von WordPress.com.

Der 7.0-Zyklus versuchte, die architektonische Entscheidung vorab zu treffen und sie dann zu testen. Diese Reihenfolge ist gescheitert, weil die Testergebnisse die Entscheidung entwerteten und keine Zeit für eine Kurskorrektur blieb. Der 7.1-Zyklus dreht die Reihenfolge um: zuerst die Testszenarien auswählen, dann validieren, welche architektonischen Varianten sie überstehen, und die überlebende Variante bestimmt die Implementierung.

Das ist dasselbe Muster, das das Team für die vollständige Website-Bearbeitung im Zyklus von 5.8 bis 6.0 verwendet hat, als die Kluft zwischen Beitragenden- und realen Hosting-Umgebungen wiederholt Regressionen produzierte. Das FSE-Testprogramm schuf eine angeworbene Testgruppe, die echte Websites mit echten Plugins betrieb, und das Programm legte Fehler offen, die das Beitragenden-Team isoliert nicht gefunden hätte.

Dasselbe Muster auf die Echtzeit-Kollaboration anzuwenden, ist der neue strukturelle Schritt. Das ist auch der Grund, warum Hoster gebeten werden, Testende aus ihrer Managed-Kundenbasis anzuwerben.

#Die Form des Testprogramms

Anne McCarthys Ankündigung positioniert die Testpopulation in drei Schichten:

1. Entwicklerorientierte Tests. Der bestehende Testzyklus. Plugins, Themes, REST-API-Oberfläche, Performance-Regressionen. Durchgeführt von Beitragenden und auf Automattic-Infrastruktur.
2. Unternehmensnahe und deterministische Tests. Durchgeführt mit Hosting-Partnern auf verwalteten Kundenumgebungen unter kontrollierter Last. Sie sollen validieren, dass die Speicherarchitektur Szenarien mit Datenbankkonflikten übersteht.
3. Engagierte Anwenderinnen und Anwender aus der Praxis. Die neue Schicht. Angeworben aus Agenturen, Verlagen und Inhaltsteams, die produktive WordPress-Sites mit redaktioneller Kollaboration als echte Ablaufanforderung betreiben.

Aus der dritten Schicht wird der größte Teil des neuen Testdurchsatzes kommen. Die Anwerbung fragt ausdrücklich nach Sites, auf denen Echtzeit-Kollaboration ein reales Problem löst, und nicht nach synthetischen Testinstallationen.

Was von Testenden erwartet wird:

• Aktive redaktionelle Abläufe mit mehr als einer Person, die gleichzeitig an langen Inhalten arbeitet
• Bereitschaft, einen Veröffentlichungskandidaten in Testumgebungen zu fahren
• Berichtszyklus: wöchentliche Abstimmungen mit einem strukturierten Rückmeldeformular
• Fehlerberichte, die sowohl Editor-Verhalten als auch datenbankseitige Metriken aus der Hosting-Schicht erfassen

Was Testende bekommen:

• Direkter Draht zum Beitragenden-Team, das die Funktion baut
• Einblick in die architektonischen Entscheidungen, während sie getroffen werden
• Sponsoring-Anerkennung für Sites, die verlängerte Testzyklen mitfahren
• Den frühestmöglichen Blick darauf, was Echtzeit-Kollaboration für den eigenen redaktionellen Prozess bedeutet

Für Agenturen mit Verlagskundschaft ist das der direkteste Weg, im Raum zu sein, wenn die Funktion finalisiert wird. Der Agenturnutzen ist nicht die Anerkennung. Es ist der frühe Einblick in die technischen Entscheidungen.

#Der 19. August und was er tatsächlich geliefert hat

WordPress 7.1 Mary Lou ist am 19. August auf dem WordCamp US in Phönix erschienen. Das Datum hat gehalten. Die Echtzeit-Kollaboration nicht. Der Testkalender unten ist der Zyklus, wie er im Juni geplant war, und bleibt hier, weil er zeigt, wie wenig Raum ein architektonischer Neustart je hatte.

Rückwärts vom 19. August gerechnet:

• Ende Juli: erster Veröffentlichungskandidat. Funktionsstopp. RTC muss stabil genug für allgemeine Testkreise sein. Die architektonische Entscheidung zur Datenbank muss festgezurrt sein.
• Mitte Juli: Beta 3. Letzte Gelegenheit für Verhaltensänderungen. Die Daten aus dem Testprogramm sollten Entscheidungen informieren, nicht mehr anstoßen.
• Anfang Juli: Beta 2. Letzte Gelegenheit für nicht-triviale architektonische Änderungen. Die Testdaten der Hosting-Partner sollten vorliegen.
• Ende Juni: Beta 1. Erster breit getesteter Build. Die Speicherarchitektur sollte bis dahin verbindlich beschlossen sein.
• Mitte Juni: Anlauf des Testprogramms. Angeworbene Testende fahren Builds in Testumgebungen. Erster Rückmeldezyklus.
• Anfang Juni: Anwerbung. Das war der Plan. Hoster sollten Testende anwerben. Die Funktion hat den Zip trotzdem verfehlt.

Acht Wochen reichten für eine festgezurrte Architektur. Sie reichten nicht für einen architektonischen Neustart. Die Architekturentscheidung war bei Zyklusstart noch offen. 7.1 ist ohne die Funktion erschienen. 7.2 ist derzeit auf den 9. Dezember 2026 angesetzt. Behandeln Sie das als Planungsdatum, nicht als RTC.

#Was Echtzeit-Kollaboration in Agenturabläufen verändert

Lassen Sie die Datenbankfrage einen Moment beiseite. Wie sieht WordPress mit Echtzeit-Kollaboration für Agenturen konkret aus?

Drei konkrete Ablaufänderungen, die mit der Funktion kommen:

• Redaktionelle Prüfschleifen verkürzen sich. Der aktuelle WordPress-Redaktionsablauf ist sequenziell. Autorin schreibt. Redakteur prüft, nachdem die Autorin fertig ist. Autorin arbeitet die Kommentare ein. Redakteur gibt frei. Mit Echtzeit-Kollaboration arbeiten Autorin und Redakteur parallel. Für Agenturen, die Redaktionskalender für Inhaltskundschaft betreuen, reduziert das die Zykluszeit pro Artikel und verändert, wie abrechenbare Stunden aussehen. In klassischen deutschen Nachrichtenredaktionen, die noch mit getrennten Schichten von Schreibenden und Schlussredaktion arbeiten, schrumpft damit eine Übergabe, die heute oft einen halben Tag kostet.
• Plugin-Kompatibilität wird zum laufenden Thema. Viele der am häufigsten installierten Redaktions-Plugins gehen von Einzelautoren-Bearbeitung aus. ACF-Feld-Speicherungen, Yoast-SEO-Analysen, Rank-Math-Metabox-Updates, eigene Taxonomie-Metaboxen und ein langer Schwanz von agenturgebauten Plugins müssen alle auf Sicherheit beim gleichzeitigen Schreiben geprüft werden. Das Plugin Review Team hat klargemacht, dass Echtzeit-Kollaboration Plugins mit unsicheren Schreibmustern offenlegen wird.
• Die Post-Lock-UX würde ersetzt. Das vertraute “Dieser Beitrag wird gerade bearbeitet von…”-Modal seit WordPress 3.6 würde Anwesenheitsanzeigen weichen. In 7.1 ist das nicht passiert. Das alte Modal ist weiterhin das, was Nutzerinnen und Nutzer sehen.

Das sind keine Sonderfälle. Das ist die Tag-eins-Wirkung auf die Nutzungsoberfläche, falls die Funktion jemals ausgeliefert wird. In 7.1 ist sie nicht ausgeliefert worden, also ist nichts davon ein Support-Ticket vom 19. August. Behalten Sie das Plugin-Audit. Schreiben Sie Schulungsmaterialien nicht für eine UX um, die nicht im Kern liegt.

#Die Datenbankarchitektur-Frage, vereinfacht

Die ingenieurtechnische Kernfrage ist einfach. WordPress speichert den Beitragsinhalt in wp_posts.post_content als einzelnes Blob. Revisionen erzeugen neue Zeilen. Echtzeit-Kollaboration muss parallele Bearbeitungen in dieses Blob zusammenführen, ohne Daten zu verlieren und ohne ein Davonlaufen des Revisions-Wachstums.

Die drei architektonischen Varianten, die derzeit diskutiert werden:

1. Append-only Operations-Log. Eine neue Tabelle speichert einzelne Operationen (Einfügen, Löschen, Format-Änderung) mit Zeitstempel und Autor-IDs. Das post_content-Blob wird beim Speichern aus dem Operations-Log rekonstruiert. Pro: saubere Konfliktauflösung. Contra: hohes Schreibvolumen auf die neue Tabelle.
2. Snapshot plus Deltas. Periodische Snapshots von post_content plus Delta-Datensätze zwischen den Snapshots. Pro: begrenztes Schreibvolumen. Contra: Die Logik zum Timing der Snapshots ist komplex und die Wiederherstellung nach ausgelassenen Snapshots heikel.
3. In-Memory-Merge mit periodischer Persistierung. Der Kollaborationszustand wird im Speicher auf der Anwendungsschicht gehalten und in Intervallen oder beim expliziten Speichern in post_content und eine einzelne Revisionszeile persistiert. Pro: niedriges Datenbank-Schreibvolumen. Contra: erfordert Sticky Sessions oder eine gemeinsame Cache-Schicht.

Jede Variante hat Folgen für das Hosting. Variante 1 belastet die Datenbank. Variante 2 belastet die Anwendungsschicht mit Timing-Logik. Variante 3 belastet Cache- und Session-Infrastruktur, also typischerweise Redis oder Memcached und entsprechend konfigurierte PHP-FPM-Pools.

Das Testprogramm für 7.1 sollte diese Varianten gegen realistische Hosting-Konfigurationen prüfen. Die architektonische Entscheidung sollte bis Ende Juni stehen. Sie kam nicht rechtzeitig. 7.1 erschien ohne RTC.

#Was Agenturen jetzt tun sollten

Drei konkrete Schritte nach dem 7.1-Fehlschlag.

1. Versprechen Sie Kundinnen und Kunden keine Live-Mehrautoren-Bearbeitung in 7.1. Sie ist nicht da. Der sequenzielle Redaktionsablauf ist weiterhin das Produkt.
2. Prüfen Sie Ihren redaktionellen Plugin-Bestand trotzdem. Jedes Plugin, das sich an save_post, wp_insert_post_data oder Meta-Speicherungen des Block-Editors anhängt, ist ein Kandidat für gleichzeitiges Schreiben, sobald RTC zurückkehrt. Die Liste nützt auch dann, wenn die Funktion einen Zyklus entfernt ist.
3. Schreiben Sie die Post-Lock-Schulung nicht für den August um. Das Modal “Dieser Beitrag wird gerade bearbeitet von…” ist weiterhin das Verhalten in 7.1. Heben Sie die einseitige Erklärung auf, bis ein Praxisleitfaden sagt, dass Anwesenheitsanzeigen ausgeliefert sind.

#Das größere Muster: Die Form der Beitragsarbeit ändert sich

Hinter dem 7.1-Zyklus steckt eine strukturelle Geschichte, die über die Funktion hinausgeht.

Den größten Teil seiner Geschichte hat sich die WordPress-Core-Entwicklung an Entscheidungen der Beitragenden orientiert, die in Beitragenden-Umgebungen getestet wurden. Das FSE-Outreach-Programm im Zyklus 5.8 bis 6.0 war der erste Versuch, reale Tests formell in die Core-Entscheidungsschleife einzubinden. Das Outreach für Echtzeit-Kollaboration in 7.1 ist der zweite.

Das Muster lautet: Das Projekt wird abhängiger von Input aus produktiven Umgebungen und weniger in der Lage, Aushängeschild-Funktionen allein in Beitragenden-Umgebungen zu landen. Es ist derselbe Wandel, den reife Open-Source-Projekte durchlaufen, wenn ihre Installationsbasis sich diversifiziert. Es verändert auch, wer Einfluss auf die Richtung hat. Agenturen, die echte Kundenseiten mit echten redaktionellen Workflows betreiben, sind zunehmend diejenigen, deren Feedback den Core formt. Das ist ein berechtigter Sitz am Tisch, den es noch ein bis zwei Release-Zyklen vorher nicht gab. Felix Arntz und Pascal Birchler haben in der deutschsprachigen WordPress-Community wiederholt darauf hingewiesen, dass genau dieser Schritt überfällig war.

Für deutsche und europäische Agenturen waren die Flurgespräche auf dem WCEU in Krakau im Juni das Angebot zur Testpartnerschaft. Dieses Angebot hat keine Auslieferung in 7.1 erzeugt. Das nächste Datum im Kalender ist 7.2, derzeit angesetzt auf den 9. Dezember 2026 zusammen mit State of the Word. Erscheinen Sie in diesen Gesprächen mit Produktionsdaten, nicht mit einer Vertriebsfolie, die behauptet, RTC sei im Kern.

#CRDT vs. Operational Transformation: Die theoretischen Hürden

Die Verschiebung der Live-Kollaboration beruht auf tiefgreifenden architektonischen Grundlagenfragen:

• Conflict-free Replicated Data Types (CRDT): Systeme wie Yjs ermöglichen die dezentrale Zusammenführung von Textständen ohne zentralen Koordinator. Bei großen Beiträgen führt der Metadaten-Overhead im Browser jedoch zu spürbarem Ressourcenverbrauch.
• Operational Transformation (OT): Der aus Google Docs bekannte Ansatz verlangt einen permanenten Vermittlungsserver. Auf herkömmlichem PHP-Hosting ohne dauerhafte Hintergrundprozesse lässt sich dies kaum zuverlässig betreiben.
• Das Datenbank-Dilemma in MySQL: Die Transformation feingranularer Delta-Operationen in das klassische post_content-Blob erforderte mehr Zeit, als die Beta-Phase von Version 7.1 hergab.

#Serverbelastung: WebSockets und die Grenzen von PHP-FPM

Klassische Hosting-Umgebungen stoßen bei dauerhaften Netzwerkverbindungen an Grenzen:

• Prozessverwaltung unter Last: PHP-FPM ist auf kurzlebige Anfragen ausgelegt. Die dauerhafte Übertragung von Cursor-Positionen und Auswahlen erfordert externe Socket-Server auf Basis von Node.js oder Edge-Workern.
• Präsenzerkennung ohne Serverabsturz: Ohne optimierte Zwischenschichten drohen geteilte Hosting-Plattformen unter der Flut von Telemetriedaten einzubrechen.

#Herausforderungen für das Plugin-Ökosystem (ACF und SEO-Metaboxen)

Die Einführung von Live-Kollaboration erfordert tiefgreifende Anpassungen bei beliebten Erweiterungen:

• Gefahr von Race Conditions: Speichern zwei Autoren gleichzeitig einen Beitrag mit benutzerdefinierten Feldern (ACF), überschreibt die spätere Anfrage häufig die Änderungen des Kollegen. Künftig sind atomare Updates auf Feldebene zwingend erforderlich.
• Auslagerung in Web Worker: Rechenintensive Analysen von SEO-Plugins müssen in separate Browser-Threads verlagert werden, um Eingabeverzögerungen bei paralleler Texterfassung zu vermeiden. Dies garantiert ein flüssiges Schreibgefühl und höchste Datensicherheit im Redaktionsalltag.

#Strategischer Ausblick auf WordPress 7.2 und die Zukunft des Publizierens

Die Verschiebung der Mehrbenutzer-Bearbeitung auf den Entwicklungszyklus von WordPress 7.2 ist kein Rückschritt, sondern ein Beleg für ingenieurmäßige Reife:

• Stabilität vor übereilten Veröffentlichungsterminen: Für anspruchsvolle Medienhäuser und Unternehmensblogs ist ein sorgfältig getesteter, robuster Synchronisationsmechanismus unendlich wertvoller als eine fehleranfällige Beta-Funktion im Produktivbetrieb.
• Zukunftssichere Standards für das Web: Die fortlaufende Zusammenarbeit von Core-Entwicklern, Hosting-Partnern und Agenturen stellt sicher, dass Echtzeit-Kollaboration auf einem absolut stabilen Fundament debütieren wird. Sorgfältiges Handwerk und offene Standards sichern den nachhaltigen Erfolg von WordPress auf lange Sicht. Qualität und Verlässlichkeit setzen sich in der Praxis immer durch. Solide Softwareentwicklung schafft dauerhafte Werte für das gesamte Web-Ökosystem.

#Das Fazit

Echtzeit-Kollaboration ist keine ausgelieferte Funktion. Sie hat 7.0 verpasst und sie hat 7.1 verpasst. Die Entscheidung zur Datenbankarchitektur wurde nicht rechtzeitig festgezurrt. Das Outreach-Programm hat die Funktion nicht über die Linie gebracht.

Beschlossen ist: 7.1 Mary Lou ist am 19. August ohne Live-Mehrautoren-Bearbeitung erschienen. Der sequenzielle Redaktionsablauf ist weiterhin das, womit Sie arbeiten. Beobachten Sie Make WordPress Core für das, was 7.2 tatsächlich listet. Behandeln Sie ein Dezember-Ziel nicht als Liefertermin.

Die Threads auf make.wordpress.org/core bleiben die primäre Quelle. Die Berichterstattung darüber, was 7.1 tatsächlich ausgeliefert hat, steht in der 7.1-Roadmap-Notiz.

Zuletzt aktualisiert: 2026-06-06.