WordPress 7.1 Echtzeit-Kollaboration: der zweite Anlauf, das Outreach-Programm im FSE-Stil und die Achtwochenfrist

Die Echtzeit-Kollaboration bekommt einen zweiten Anlauf im WordPress-Core. Zwei Wochen vor dem Release 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 Release-Fensters nicht zusichern konnte. Sechs Wochen später steht dieselbe Funktion wieder auf der Roadmap für WordPress 7.1, mit einem startenden Outreach-Programm im FSE-Stil und einem Release-Datum am 19. August als kalendarischem Anker.

Für Agenturen, die redaktionelle Workflows auf WordPress betreiben, hat das ganz konkrete Folgen. Die Mehrautoren-Bearbeitung ist die größte Workflow-Änderung im Core seit über einem Jahrzehnt. Sie verändert die Konfliktfläche bei langen Inhalten, definiert neu, was ein „Lock” auf einem Beitrag bedeutet, und verschiebt, wofür der Block-Editor eigentlich da ist. Der 7.1-Anlauf signalisiert außerdem, wie sich die Art der WordPress-Beitragsarbeit wandelt: Ein Outreach-Programm für eine im Kern datenbankarchitektonische Frage ist ein neues Format für das Projekt.

Wir haben die Ankündigung verfolgt, die Threads auf make.wordpress.org/core gelesen und an zwei frühen Outreach-Gesprächen teilgenommen. Hier ist, was Agenturen zum Start des 7.1-Zyklus wissen sollten. Wer in deutschen Redaktionen arbeitet, kennt diese Spannung übrigens schon: Großverlage wie die Süddeutsche oder die taz fahren ihre digitalen Workflows 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.

Annes 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 Full-Site-Editing-Team im Zyklus von 5.8 bis 6.0 verwendet hat, als die Kluft zwischen Beitragenden- und realen Hosting-Umgebungen wiederholt Regressionen produzierte. Das FSE-Outreach-Programm schuf eine angeworbene Testpopulation, die echte Websites mit echten Plugins betrieb, und das Programm legte Bugs 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 Outreach-Programms

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. Enterprise- und deterministische Tests. Durchgeführt mit Hosting-Partnern auf Managed-Kundenumgebungen unter kontrollierter Last. Sie sollen validieren, dass die Speicherarchitektur Szenarien mit Datenbank-Contention übersteht.
3. Passionate real-world early adopters. Die neue Schicht. Angeworben aus Agenturen, Verlagen und Content-Teams, die produktive WordPress-Sites mit redaktioneller Kollaboration als echte Workflow-Anforderung 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 Workflows mit mehr als einer Person, die gleichzeitig an langen Inhalten arbeitet
• Bereitschaft, einen Release-Candidate-Build gegen Staging-Umgebungen zu fahren
• Reporting-Zyklus: wöchentliche Check-ins mit einem strukturierten Feedback-Formular
• Bug-Reports, 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 Engineering-Preview.

#Der 19. August und warum er zählt

WordPress 7.1 ist für den 19. August geplant. Dieses Datum ist nicht willkürlich. Es fällt mit dem WordCamp US in Phoenix zusammen, wo der Release als Teil des Konferenzprogramms gefeiert werden soll. Das Release-Datum ankert auch den gesamten Testkalender für 7.1.

Rückwärts vom 19. August gerechnet:

• Ende Juli: Release Candidate 1. Feature-Freeze. 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 Outreach-Programm 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 Outreach-Programms. Angeworbene Testende fahren Staging-Builds. Erster Feedback-Zyklus.
• Jetzt (Anfang Juni): Anwerbung. Hoster werben Testende an, das Beitragenden-Team skizziert das Outreach-Material.

Acht Wochen reichen aus. Sie reichen nicht aus für einen architektonischen Neustart. Die Folge für Agenturen, die das mitverfolgen: Gehen Sie davon aus, dass die architektonische Entscheidung bis Ende Juni fällt. Wenn Sie eine klare Meinung oder Produktionsdaten haben, die in die Entscheidung einfließen sollten, geben Sie sie dem Beitragenden-Team in den nächsten drei Wochen.

#Was Echtzeit-Kollaboration in Agentur-Workflows verändert

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

Drei konkrete Workflow-Änderungen, die mit der Funktion kommen:

• Redaktionelle Review-Schleifen verkürzen sich. Der aktuelle WordPress-Redaktionsworkflow ist sequenziell. Autorin schreibt. Redakteur reviewt, 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 Content-Kundschaft 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 wird ersetzt. Das vertraute „Dieser Beitrag wird gerade bearbeitet von…”-Modal, das seit WordPress 3.6 ausgeliefert wird, wird zugunsten von Anwesenheitsanzeigen abgekündigt. Anwenderinnen und Anwender, die über ein Jahrzehnt auf das alte Verhalten trainiert wurden, müssen das neue Muster lernen. Interne Kommunikation und Schulungsmaterialien müssen aktualisiert werden.

Das sind keine Sonderfälle. Das ist die Tag-eins-Wirkung der Funktion auf die Nutzungsoberfläche.

#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 Outreach-Programm für 7.1 wird darauf ausgelegt, alle drei Varianten gegen realistische Hosting-Konfigurationen zu testen. Welche Variante übersteht, ist die architektonische Entscheidung, die das Team bis Ende Juni treffen muss.

#Was Agenturen in diesem Monat tun sollten

Drei konkrete Schritte für Agenturen, die WordPress für Verlags- oder Redaktionskundschaft betreiben.

1. Auditieren Sie Ihren redaktionellen Plugin-Stack. 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. Listen Sie die Plugins, notieren Sie die Autoren und prüfen Sie, ob die Autoren öffentliche Aussagen zur RTC-Kompatibilität gemacht haben. Die ohne Aussagen sind die, um die herum geplant werden muss.
2. Melden Sie eine Verlagskundschaft zum Outreach-Programm an. Wenn Sie eine Kundin oder einen Kunden mit zwei oder mehr Redaktionspersonen haben, die an derselben Inhaltsoberfläche arbeiten, will das Outreach-Team genau diesen Workflow. Die Anmeldung bringt Ihre Kundschaft in die Testpopulation und Sie in den Raum für die architektonische Diskussion. Die Einreichung läuft über den verlinkten Beitrag auf make.wordpress.org/core aus McCarthys Ankündigung.
3. Bereiten Sie interne Schulungen zur Post-Lock-UX-Änderung vor. Auch wenn Ihre Kundschaft Echtzeit-Kollaboration nicht aktiv nutzt, wird die sichtbare Änderung am „Beitrag ist gesperrt”-Verhalten im August Support-Tickets erzeugen. Halten Sie eine einseitige Erklärung bereit.

#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 ist die Folge direkt: Das WCEU in Krakau wird diese Woche Gespräche über RTC-Testpartnerschaften auf den Fluren, zwischen den gesponserten Pausen und beim Kaffee hosten. Seien Sie dort.

#Das Fazit

Echtzeit-Kollaboration ist noch keine ausgelieferte Funktion. Die Entscheidung zur Datenbankarchitektur ist noch nicht gefallen. Das Outreach-Programm wirbt noch. Nichts davon ist beschlossene Sache.

Beschlossen ist: Die Funktion steht wieder auf der Roadmap, das Release-Datum am 19. August ist der Arbeitsanker, die Teststrategie wurde über Enterprise- und Beitragenden-Umgebungen hinaus erweitert, und Hoster werden gebeten, beim Anwerben produktiver Testender zu helfen. Wenn die architektonische Entscheidung bis Ende Juni fällt und die Outreach-Daten sie bestätigen, liefert WordPress 7.1 die Funktion auf dem WordCamp US aus.

Für Agenturen mit Redaktionskundschaft ist das der Release-Zyklus, an dem man teilnehmen sollte. Die Form der Mehrautoren-Bearbeitung in WordPress für den Rest des Jahrzehnts wird in den nächsten acht Wochen definiert.

Die Ankündigung auf make.wordpress.org/core und die Details zum Outreach-Programm finden Sie unter Make WordPress Core. Die Berichterstattung läuft weiter auf The Repository und auf dem WPPoland-Blog durch den gesamten 7.1-Zyklus.

Zuletzt aktualisiert: 2026-06-06.