WordPress 7.0 erschien am 20. Mai 2026 unter dem Release-Namen Armstrong, sechs Wochen später als im ursprünglichen Zeitplan für 2026 vorgesehen, und ist die folgenreichste Core-Version für Agenturen seit dem block editor. Die Schlagzeile lautet, dass der Core jetzt mit generativen KI-Modellen sprechen kann. Wichtiger ist das Detail dahinter: Der Core legt nun fest, wie ein Plugin mit ihnen zu sprechen hat, und das verschiebt still und leise, was jedes Plugin auf einer Website über sein eigenes Revier annehmen darf.

Für Redakteure sind die sichtbaren Änderungen bescheiden. Es gibt eine Command Palette, ein aufgeräumteres Dashboard, einen Bildschirm zur Schriftverwaltung und bessere Revisionen. Für alle, die Websites beruflich betreuen, liegen die wichtigen Änderungen unter dem Adminbereich: ein Speicher für Zugangsdaten in der Options-Tabelle, ein Register dessen, was die Website kann, und eine REST-Schnittstelle, die es auflistet. Nichts davon ist optional, denn es kommt mit dem Core und nicht mit einem Plugin, das jemand ausgewählt hat.

Das hier ist die Lesart aus der Praxis. Was tatsächlich gelandet ist, was zwölf Tage vor dem Release gestrichen wurde und warum, was das Update kaputt macht und was nicht, und was Sie einem Kunden sagen, der gerade eine Schlagzeile über KI in WordPress gelesen hat.

Sollten Sie aktualisieren? Ja, aber gehen Sie auf 7.1, statt bei 7.0 stehen zu bleiben. WordPress 7.1 erschien am 19. August 2026, und hinter 7.0 liegen vier Wartungsreleases. Die KI-Funktionen bleiben untätig, bis ein Administrator unter Einstellungen, dann Connectors, einen Anbieterschlüssel speichert. Das Update allein sendet also nichts von Ihren Inhalten irgendwohin. Das echte Risiko liegt in der gewöhnlichen Plugin- und Theme-Kompatibilität, nicht in der KI.

Was in WordPress 7.0 tatsächlich erschienen ist

Das Release ist nach Louis Armstrong benannt, gemäß der Konvention des Projekts, Hauptversionen nach Jazzmusikern zu benennen. Die Release-Ankündigung nennt mehr als 875 Mitwirkende und über 420 Verbesserungen und Fehlerbehebungen.

Die Liste des Gelandeten ist kurz genug, um nützlich zu sein. Der Core bekam einen AI Client, eine anbieterunabhängige PHP-Schnittstelle zum Senden von Prompts an generative Modelle. Er bekam einen Connectors-Bildschirm unter Einstellungen, auf dem ein Administrator Anbieter-Zugangsdaten hinterlegt. Er bekam die JavaScript-Hälfte der Abilities API, deren PHP-Hälfte bereits in 6.9 erschienen war.

Auf der redaktionellen Seite gibt es eine Command Palette über Strg+K oder Cmd+K, ein modernisiertes Dashboard, eine eigene Seite zur Schriftverwaltung, visuelles Durchblättern von Revisionen sowie neue Heading-, Breadcrumbs- und Icons-Blöcke samt Lightbox-Diashow für Galerien.

Was nicht erschienen ist, war die Funktion, um die herum das ganze Release gebaut worden war. Die kollaborative Echtzeit-Bearbeitung wurde zwölf Tage vor dem Start entfernt. Dieses Fehlen und der Grund dahinter sagen mehr über den aktuellen Zustand des Core als die Funktionsliste.

Warum sich der Termin verschob

Ursprünglich war das Release für den 9. April 2026 geplant. Es rutschte auf den 20. Mai, weil die kollaborative Bearbeitung nicht fertig war und das Projekt sie in diesem Zustand nicht ausliefern wollte. Der Beitrag zum weiteren Weg sagt ausdrücklich, die Verzögerung habe bestanden, um mehr Zeit für die Rückmeldungen aus den Tests zur Umsetzung der Echtzeit-Zusammenarbeit zu schaffen, und der Zyklus ging zurück in die Beta, behielt aber aus technischen Gründen die Versionsnummern der Release Candidates.

Das ist ungewöhnlich. Eine Hauptversion, die nach dem Release Candidate in die Beta zurückkehrt, ist ein starkes Signal, und es war die richtige Entscheidung.

Der AI Client: Der Core liefert die Abstraktion, nicht das Modell

Die architektonisch wichtigste Tatsache an WordPress 7.0 ist, dass der Core kein KI-Modell, keinen API-Schlüssel und keine Beziehung zu irgendeinem Anbieter enthält. Die Entwicklernotiz zum AI Client stellt schlicht fest, dass der WordPress-Core keine KI-Anbieter direkt mitliefert.

Was der Core liefert, ist eine einheitliche PHP-Schnittstelle. Ein Plugin ruft wp_ai_client_prompt() auf, erhält ein WP_AI_Client_Prompt_Builder-Objekt zurück, verkettet Konfiguration wie using_temperature() oder using_model_preference() und schließt mit generate_text() oder generate_image() ab. Fehler kommen als WP_Error zurück, Anfragen laufen über den HTTP-Transport von WordPress, und das Ganze hängt am Hook-System.

Praktisch bedeutet das, dass Plugin-Autoren nicht länger für jeden Modellanbieter einen HTTP-Client, eine Wiederholungsschleife, einen Bildschirm zur Schlüsselverwaltung und eine Einstellungsseite schreiben. Sie beschreiben, was sie wollen, und der Core leitet es weiter.

Das ist eine echte Verringerung von doppeltem Code. Es ist zugleich eine Zentralisierung von Vertrauen, und über diesen Teil sollten Sie nachdenken, bevor Sie irgendetwas einschalten.

Was ein Connector ist

Ein Connector ist die registrierte Beziehung zwischen Ihrer Website und einem externen Dienst. In 7.0 ist der einzige Connector-Typ der von KI-Anbietern, und es gibt drei Flaggschiff-Plugins für Anthropic, Google und OpenAI, die jeweils separat installiert werden.

Die Entwicklernotiz zur Connectors API beschreibt, wie Zugangsdaten aufgelöst werden. Ein Schlüssel kann aus einer Umgebungsvariablen, einer PHP-Konstanten oder einer Datenbankeinstellung kommen, in dieser Reihenfolge geprüft, wobei die Optionsnamen dem Muster connectors_ai_{$id}_api_key folgen.

Ein Detail verdient die Aufmerksamkeit aller, die für eine Website verantwortlich sind. Die Entwicklernotiz sagt, in der Datenbank gespeicherte API-Schlüssel seien nicht verschlüsselt, sondern in der Oberfläche nur maskiert, und die Verschlüsselung sei als spätere Arbeit vorgemerkt. Wenn Sie einen Schlüssel über den Adminbereich setzen, liegt er im Klartext in wp_options, und jede Sicherung dieser Datenbank enthält nun einen abrechnungsrelevanten Zugangsschlüssel.

Was das bedeutet, wenn Sie nicht programmieren

Für Websitebetreiber ist die Änderung einfacher, als sie klingt. Nichts erzeugt, fasst zusammen oder schreibt etwas um, solange nicht zwei Dinge zutreffen: Ein Anbieter-Plugin ist installiert, und jemand hat einen funktionierenden Schlüssel unter Einstellungen, dann Connectors, eingefügt.

Bis dahin ist der AI Client eine schlafende Bibliothek. Das Update auf WordPress 7.0 sendet Ihre Beiträge nicht an ein Modell, legt nirgends ein Konto an und verursacht keine Kosten.

Was es sehr wohl tut, ist die Hürde für das nächste Plugin zu senken, das Sie installieren. Ein Plugin, das Sie früher nach einem Schlüssel fragen musste, findet nun einen bereits auf der Website konfigurierten und benutzt ihn. Das ist bequem, und genau dazu sollte eine Richtlinie existieren, bevor es aus Versehen passiert.

Die Abilities API und warum sich Plugin-Design ändert

Die Abilities API ist das Stück, das in drei Jahren noch zählen wird, und sie hat von sich aus nichts mit KI zu tun. Sie ist ein Register. Ein Plugin registriert eine benannte Funktionseinheit mit wp_register_ability() in der Form namespace/ability-name, mit einer für Menschen lesbaren Beschreibung, JSON Schema für Ein- und Ausgaben, einem Ausführungs-Callback und einem optionalen Berechtigungs-Callback.

Die offizielle Dokumentation zeigt das Berechtigungs-Callback als gewöhnliche Rechteprüfung, die zum Beispiel current_user_can( 'manage_options' ) zurückgibt. Das ist das gesamte Sicherheitsmodell, und es ist nur so gut wie das Urteilsvermögen des Plugin-Autors.

Sobald Abilities existieren, können andere Dinge sie aufzählen. Einem Modell lässt sich eine Liste dessen übergeben, was genau diese Website kann, in Schema-Form, und es kann eine davon aufrufen. Dasselbe gilt für eine clientseitige Command Palette, weshalb die JavaScript-Hälfte der API im selben Release erschien wie die Palette.

Die Folge für das Design von Plugins ist real. Eine Funktion, die früher nur über Ihren eigenen Adminbildschirm erreichbar war, mit Ihrer Nonce und Ihrem Formular, ist nun etwas, das Sie womöglich als Ability mit maschinenlesbarem Vertrag anbieten sollen. Das ist eine andere Angriffsfläche und eine andere Dokumentationslast.

Was sich in 7.1 geändert hat

WordPress 7.1 hat das Register verschärft statt erweitert. Die Entwicklernotiz zu den Abilities in 7.1 ergänzt die Validierungsfilter wp_ability_validate_input und wp_ability_validate_output, eine Aktion wp_ability_invoked, die zu Beginn der Ausführung feuert, und ein public-Metadatenfeld, das steuert, ob eine Ability über REST unter /wp-json/wp-abilities/v1/abilities auffindbar ist.

Diese Notiz enthält auch den Satz, den jeder Autor eines Logging-Plugins lesen sollte. Der Aufruf-Hook erhält rohe, nicht normalisierte Eingaben, und Entwickler sollten es vermeiden, Eingaben wahllos zu protokollieren, weil sie Zugangsdaten, personenbezogene Daten oder andere sensible Informationen enthalten können.

Echtzeit-Zusammenarbeit und die Tabelle, die sie gebraucht hätte

Die kollaborative Bearbeitung baut auf Yjs auf, einem konfliktfreien replizierten Datentyp, mit einer Abstraktion für Sync-Provider. Der Core liefert standardmäßig einen HTTP-Polling-Provider mit, gewählt statt WebSockets, weil er bei jedem Hoster funktioniert, und Plugins können den Transport über einen Filter austauschen.

Das Problem war nie der Merge-Algorithmus. Es war der Ort, an dem die Sync-Daten lagen. Die ursprüngliche Umsetzung legte sie in Post-Meta ab, was in WordPress die naheliegende Wahl ist und die falsche für Daten, die sich mehrmals pro Sekunde ändern.

Schreibvorgänge auf Post-Meta lösen Cache-Invalidierung aus. Bei geöffnetem Editor wurden fortwährend Sync-Daten geschrieben, sodass jeder Schreibvorgang die zwischengespeicherten Abfragen für diesen Beitrag verwarf. In der Praxis konnte eine einzige Person, die eine Seite bearbeitet, den persistenten Objekt-Cache der Website für die Dauer der Sitzung durchgehend leeren lassen.

Das ist eine gute allgemeine Lektion über Post-Meta. Es ist ein Schlüssel-Wert-Speicher, der am Cache-Lebenszyklus des Inhalts hängt, an dem er befestigt ist, und er ist in Ordnung für Attribute, die sich mit dem Beitrag ändern. Er ist kein Notizblock für hochfrequenten Zustand.

Die gemessene Lösung und die Entscheidung

Mitwirkende testeten Speicherstrategien in acht Hosting-Umgebungen. Die Performance-Analyse kam zu dem Schluss, dass eine eigene Tabelle mit Transients rund 52% schneller war als die bestehende Umsetzung und eine schlichte eigene Tabelle rund 37% schneller. Mit vorhandenem persistentem Objekt-Cache fielen beide Transient-Varianten auf eine einzige Datenbankabfrage pro Übertragung.

Gewählt wurde die eigene Tabelle mit Transients. Dann wurde die Funktion am selben Tag gestrichen.

Die Streichungsmitteilung nennt Bedenken zu Angriffsfläche, Race Conditions, Serverlast, Speichereffizienz und wiederkehrenden Fehlern aus dem Fuzz-Testing und hält fest, die Entscheidung sei gefallen, um ein stabiles und verlässliches WordPress 7.0 für die Nutzer auszuliefern.

Wo es heute steht

Auch in 7.1 ist es nicht erschienen. Der Field Guide zu 7.1 hält fest, dass die kollaborative Echtzeit-Bearbeitung im Zyklus von WordPress 7.1 ausgiebig getestet und kommentiert wurde, im finalen Release aber nicht aktiviert ist.

Notes, die verwandte, aber eigenständige Funktion für Kommentare auf Blockebene, ist erschienen und wurde in 7.1 um Rich-Text-Formatierung und Erwähnungen per @ erweitert. Wenn ein Kunde nach gemeinsamem Bearbeiten im Stil von Google Docs fragt, lautet die ehrliche Antwort heute, dass Notes den Review-Ablauf abdeckt und gleichzeitiges Tippen weiterhin nicht im Core ist.

Die Änderungen im Adminbereich und die Tickets, die sie erzeugen

Zwei Änderungen werden Supportanfragen produzieren, und keine davon ist ein Fehler.

Die Command Palette über Strg+K oder Cmd+K ist wirklich schnell, sobald man sie kennt, aber Strg+K ist in vielen Editoren das Tastenkürzel zum Einfügen eines Links, und manche Nutzer werden melden, das Einfügen von Links sei kaputt. Ist es nicht; der Fokuskontext entscheidet, welcher Handler gewinnt.

Das modernisierte Dashboard ist der größere Punkt. Jeder Kunde, dessen Mitarbeitende an Screenshots geschult wurden, hat nun veraltetes Schulungsmaterial, und jedes Plugin, das Markup in Adminbildschirme eingefügt hat und dabei bestimmte Klassen oder DOM-Strukturen voraussetzt, kann seltsam aussehen. Das ist kosmetisch und nicht funktional, aber es erscheint am Tag des Updates, auf jeder Website, für jeden Nutzer, was es zum sichtbarsten Teil des Releases für alle macht, die nicht entwickeln.

Kalkulieren Sie eine Stunde je Kunde für eine kurze schriftliche Notiz mit neuen Screenshots ein, bevor Sie irgendetwas aktualisieren. Das ist billiger als dieselbe Erklärung fünfzehnmal per E-Mail.

Die Kompatibilitätsfrage, auf die es wirklich ankommt

Die Versionsnummer legt ein Release mit Brüchen nahe. Die PHP-Anforderungen tun das nicht. Wie die Klarstellung zur PHP-Unterstützung darlegt, ist die minimal unterstützte PHP-Version seit WordPress 7.0 die 7.4, und die minimal empfohlene Version bleibt 8.3. Die Unterstützung für PHP 7.2 und 7.3 wurde in diesem Release eingestellt.

Die Klarstellung hat außerdem das alte Beta-Etikett für neuere PHP-Versionen abgeschafft und hält die volle Unterstützung für PHP 8.5 in WordPress 6.9 und 7.0 fest.

Der Abstand zwischen unterstützt und vernünftig ist der Punkt. PHP 7.4 erreichte im November 2022 sein Lebensende. Eine Website, die das Minimum gerade so erfüllt, läuft also auf einem Interpreter, der seit fast vier Jahren keine Sicherheitsupdates bekommen hat. Wenn Ihr Hosting 2026 noch auf 7.4 läuft, ist die WordPress-Version nicht Ihr dringendstes Problem.

Brüche folgen in der Praxis einem vorhersehbaren Muster. Verwaiste Plugins fallen zuerst aus, besonders alles, was das Admin-DOM oder den Editor-iframe manipuliert. Individuelle Themes mit fest verdrahtetem Admin-Styling sehen falsch aus. Page Builder, die eigene React-Bundles mitbringen, sind die übliche Quelle weißer Seiten im Editor, und sie sind meist auch am schnellsten gepatcht.

Ein konkretes Update-Vorgehen

Bauen Sie eine Staging-Umgebung. Klonen Sie die Produktion samt Datenbank in eine Umgebung, die nicht indexierbar ist und keine E-Mails versendet. Nichts von dem, was unten steht, sollte auf einer Live-Website passieren.

Halten Sie den Ausgangszustand fest. Notieren Sie die PHP-Version, die Plugin- und Theme-Liste mit Versionen und die aktuelle WordPress-Version. Machen Sie Screenshots der zwei oder drei Adminbildschirme, die der Kunde täglich nutzt.

Aktualisieren Sie zuerst nur WordPress. Lassen Sie Plugins und Themes unangetastet, gehen Sie dann durch das Frontend, den Beitragseditor, den Website-Editor, den WooCommerce-Checkout, falls vorhanden, und alle eigenen Adminbildschirme. Ein Fehler hier gehört dem Core oder einer inkompatiblen Erweiterung, und genau diese Trennung von einem Plugin-Update ist der Grund für diese Reihenfolge.

Aktualisieren Sie danach Plugins in kleinen Chargen und testen Sie zwischen den Chargen, damit eine Regression eine kurze Verdächtigenliste hat.

Prüfen Sie Fehlerprotokolle, statt Seiten anzusehen. PHP-Hinweise aus einem veralteten Aufruf werden nicht immer sichtbar gerendert und füllen still monatelang ein Log.

Lassen Sie den Connectors-Bildschirm leer. Liefern Sie das Update ohne konfigurierten KI-Anbieter aus und behandeln Sie das Einschalten als eigene, bewusste Änderung mit eigener Freigabe. Unsere Checkliste zur WordPress-Sicherheitshärtung deckt die umgebenden Kontrollen ab, und der Leitfaden zum Performance-Audit deckt ab, was danach zu messen ist.

Governance: Was ein Connector tun darf

Hier ist die Frage, die die Abilities-Schicht aufwirft und die kein Plugin-Autor für Sie beantworten kann. Ein Drittanbieter-Plugin kann eine Ability registrieren, die Kundendatensätze liest, Nutzer exportiert oder veröffentlichte Inhalte bearbeitet, und ein Modell mit Zugriff auf das Register kann sie aufrufen. Das Berechtigungs-Callback ist eine Rechteprüfung, das Modell handelt also mit den Rechten der Person, die angemeldet ist.

Ist diese Person Administrator, kann das Modell Administratordinge tun. Das ist kein Fehler im Entwurf, sondern der dokumentierte Entwurf bei der Arbeit. Es bedeutet aber, dass die Entscheidung, welche Connectors auf einer Website existieren, eine Datenschutzentscheidung ist und keine IT-Vorliebe.

Inhalte in einem CMS sind selten bloß Werbetexte. Kommentare, Formulareingänge, Bestelldaten und Nutzerprofile sind personenbezogene Daten, und sie an ein externes Modell zu senden ist eine Verarbeitung, die Sie rechtfertigen können müssen. Der Leitfaden der ICO zu KI und Datenschutz legt die Erwartungen an Rechenschaft und Transparenz dar, einschließlich Datenschutz durch Technikgestaltung und einer Governance, die im Verhältnis zum Einsatz steht.

Das praktische Minimum für eine Kundenwebsite ist eine kurze schriftliche Richtlinie: welche Connectors erlaubt sind, wer einen hinzufügen darf, welche Abilities öffentlich über REST sichtbar sind und wie die Aufbewahrung beim Anbieter geregelt ist. Schreiben Sie sie, bevor jemand einen Schlüssel einfügt, denn danach ist es ein Vorfallsbericht und keine Richtlinie.

Was als Nächstes ansteht

WordPress 7.1 kam am 19. August 2026 mit responsiven Gestaltungsoptionen in den Global Styles, einer durchgehenden Adminleiste über alle Editoren, einem richtigen Modal zur Medienbearbeitung, Playlist- und Tabs-Blöcken und den bereits erwähnten Verbesserungen an Notes. Es hat außerdem den Umstieg auf einen Beitragseditor im iframe abgeschlossen, auch für Websites, die klassische Meta-Boxen registrieren, und das ist die Änderung, die alte Plugins am ehesten auffliegen lässt.

WordPress 7.2 ist als letztes Hauptrelease des Jahres 2026 geplant. Die Release-Seite zu 7.2 setzt das finale Release in das Fenster vom 8. bis 10. Dezember 2026, mit Betas ab Ende Oktober. Dieser Zeitplan ist geplant und nicht ausgeliefert, und dieses Projekt hat in diesem Jahr bereits einen Termin für eine Hauptversion verschoben.

Die kollaborative Bearbeitung bleibt der offensichtliche Kandidat für ein künftiges Release, aber sie hat inzwischen zwei verpasst, und niemand sollte einem Kunden ein Datum dafür versprechen.

Was sich geschäftlich ändert

Drei Kundengespräche ändern sich, und nur eines davon dreht sich um KI.

Das erste ist das Update-Gespräch. WordPress 7.0 und 7.1 sind es wert, als betreutes Update mit einem Staging-Durchgang berechnet zu werden, weil der Editor im iframe und das neue Admin-Design alte Erweiterungen tatsächlich auffliegen lassen. Das als Festpreispaket mit schriftlichem Testplan zu verkaufen ist ehrlicher und einträglicher, als es in einem Wartungsvertrag zu verstecken und um 18 Uhr einen kaputten Page Builder zu entdecken.

Das zweite ist Governance. Connector-Richtlinien, die Prüfung von Abilities und der Umgang mit Zugangsdaten sind abrechenbare Beratungsleistungen, die es vor Mai 2026 nicht gab, und sie passen weit besser zu einer Agentur als zu einem internen Marketingteam.

Das dritte ist die Umsetzung. Der AI Client nimmt einem die langweilige Hälfte beim Einbau einer KI-Funktion ab, was den Preis der Installationsarbeit senkt und den Wert des Wissens erhöht, was überhaupt gebaut werden sollte. Wenn Sie das gegen eine Individualentwicklung abwägen, zeigt unser Vergleich von WordPress und Individualentwicklung, wo die Grenze üblicherweise verläuft, und unsere Notizen zu Honoraren für WordPress-Entwickler zeigen, was die Arbeit kosten sollte.

Mecanik übernimmt Core-Upgrades, Connector-Governance und KI-Funktionsarbeit im Rahmen unserer Leistungen für WordPress-Entwicklung und KI-Integration. Das Muster, das wir sehen, ist beständig: Das Update selbst ist Routine, und die teuren Überraschungen kommen von Erweiterungen, die seit drei Jahren niemand geprüft hat.

Häufig gestellte Fragen

Wann erschien WordPress 7.0 und warum verzögerte es sich? WordPress 7.0 mit dem Release-Namen Armstrong erschien am 20. Mai 2026, sechs Wochen nach dem ursprünglich geplanten 9. April. Die Verzögerung diente dazu, Rückmeldungen aus den Tests zur Umsetzung der kollaborativen Echtzeit-Bearbeitung aufzuarbeiten, und der Zyklus kehrte nach dem Release Candidate in die Beta zurück. Die kollaborative Bearbeitung wurde am 8. Mai 2026 letztlich aus dem Release entfernt.

Sendet WordPress 7.0 meine Inhalte an einen KI-Anbieter? Nein. Der Core liefert einen AI Client mit, aber keine KI-Anbieter, keine Modelle und keine API-Schlüssel. Nichts wird irgendwohin gesendet, bis ein Administrator ein Anbieter-Plugin installiert und unter Einstellungen, dann Connectors, einen funktionierenden Zugangsschlüssel speichert. Bis dahin ist der AI Client eine schlafende Bibliothek, die nichts kostet und nichts überträgt.

Wofür ist die Abilities API da? Sie ist ein Register, in dem ein Plugin eine benannte Funktionseinheit mit JSON Schema für Ein- und Ausgaben, einem Berechtigungs-Callback und einem Ausführungs-Callback beschreibt. Andere Software, darunter KI-Modelle und die Command Palette, kann dann aufzählen, was eine Website kann, und es aufrufen. Die PHP-Hälfte erschien in WordPress 6.9, die JavaScript-Hälfte in 7.0.

Welche PHP-Version verlangt WordPress 7.0? Die minimal unterstützte Version ist seit WordPress 7.0 PHP 7.4, das die Unterstützung für PHP 7.2 und 7.3 eingestellt hat. Die minimal empfohlene Version bleibt PHP 8.3. Da PHP 7.4 im November 2022 sein Lebensende erreichte, bedeutet das blanke Minimum einen nicht mehr unterstützten Interpreter, behandeln Sie also 8.3 oder höher als die echte Anforderung.

Ist die kollaborative Echtzeit-Bearbeitung schon verfügbar? Nicht im Core. Sie wurde zwölf Tage vor dem Release aus WordPress 7.0 entfernt, wegen Bedenken zu Race Conditions, Serverlast und Speichereffizienz, und sie ist auch in WordPress 7.1 nicht aktiviert. Die separate Funktion Notes, die Kommentare auf Blockebene mit Erwähnungen erlaubt, ist erschienen und deckt Review-Abläufe ab, nicht gleichzeitiges Tippen.