Die Roadmap für WordPress 7.1

#Einleitung

Am 19. Juni 2026 veröffentlichte Anne McCarthy von Automattic die WordPress-7.1-Roadmap im Make-WordPress-Core-Blog, ihr erster Zyklus als Release-Leiterin. Ihre Einordnung auf LinkedIn war typisch herzlich: “I am so excited about what’s taking shape.” (Ich freue mich riesig über das, was hier Gestalt annimmt.) Die Roadmap ist wirklich prall gefüllt, und das Schlagwort lautet Kollaboration, angelegt als roter Faden, der die Release zusammenhält.

Ein Widerspruch gehört gleich vorweg benannt. Beworben wurde die Release mit dem Thema Kollaboration, doch die zugkräftigste Kollaborationsfunktion, die Echtzeit-Kollaboration, ist genau das, was immer wieder vertagt wird. Sie wurde rund zwei Wochen vor dem Release aus WordPress 7.0 gestrichen. Sie kehrte in der 7.1-Roadmap zurück, eingewickelt in “big, open strategy questions” (große, offene strategische Fragen) statt in einem Erscheinungsdatum. Und auf der WordCamp Europe 2026 stellten Core-Committer offen in Frage, ob die vollständige Funktion überhaupt in den Core gehört. Die ehrliche Lesart von 7.1 sind also zwei Releases in einer: ein solides Paket aus Styling-, Medien- und Plattformverbesserungen, das am 19. August tatsächlich erschien, und eine Kollaborationsgeschichte, über die noch offen gestritten wird.

Update, 20. August 2026: WordPress 7.1 Mary Lou erschien am 19. August, zum Termin. Der Umstieg von React 18 auf React 19, Unicode-E-Mail, Guidelines / wp_knowledge, Echtzeit-Kollaboration und die Ausmusterung des Classic-Blocks verließen die Release. Was landete, ist responsives Styling, clientseitige Medien, eine persistente Admin-Leiste, ein immer im iframe laufender Beitragseditor, Playlist und Tabs sowie reichere Notes. Die Beta-3-Notiz vom 28. Juli gilt weiter für die zwei Punkte, die zuerst herausfielen.

#Das Wichtigste in Kürze

• Anne McCarthy leitete 7.1 zum ersten Mal. WordPress 7.1 Mary Lou erschien am 19. August 2026, dem Abschlusstag der WordCamp US in Phönix.
• Die Release drehte sich um Kollaboration, doch die Echtzeit-Kollaboration (RTC) wurde nach dem Schnitt aus 7.0 erneut verschoben.
• Was wirklich landete: responsives Styling, clientseitige Medien, persistente Admin-Leiste, Beitragseditor immer im iframe, Playlist und Tabs. Guidelines und die Abkündigung des Classic-Blocks kamen nicht. React 19 rutschte über 7.1 hinaus.
• Die Unterstützung für Unicode-E-Mail-Adressen wurde auf Entscheidung von Matt Mullenweg aus Sicherheitsgründen aus der Release genommen, sechs Wochen nach dem Merge in den Core.
• Core-Committer brachten ein Canary-Deployment-Modell nach Chrome-Vorbild ins Spiel, ein Signal, dass sie den Test- und Feedback-Prozess selbst für überdenkenswert halten.
• Das schmale Stabilisierungsfenster tat, was es immer tut: die Juni-Liste war Absicht. Die Zip-Datei vom 19. August ist die Lieferung.

#Was tatsächlich erschienen ist, geordnet danach, wen es betrifft

Die Roadmap listet vieles auf. Für einen Website-Betreiber oder eine Agentur ist die nützliche Frage nicht “Was steht auf der Liste”, sondern “Was verändert meine Arbeit”. Hier ist die Aufteilung.

Das Muster ist eindeutig. Was landete, ist infrastrukturell oder an Builder gerichtet. Die Kollaborationsgeschichte, nach der die Release benannt ist, blieb im mittleren bis niedrigen Bereich und außerhalb der Zip-Datei.

Die Mitte dieser Tabelle hat Gutenberg 23.6 festgezurrt, das letzte Feature-Release vor 7.1. Es hebt die Blöcke Playlist und Tabs von experimentell auf stabil, ergänzt Inline-Notizen an Textmarkierungen mit @Mention-Autovervollständigung, eine Dynamic-Gallery-Variante, die alle an einen Beitrag angehängten Medien zeigt, eine Icon-Registrierungs-API für Plugins und Themes sowie konfigurierbare Viewport-Breiten in theme.json, womit das responsive Styling nicht länger auf drei von jemand anderem gewählte Breakpoints festgenagelt ist.

#Responsives Styling: die leise Schlagzeile

Wenn Sie Websites für Kunden bauen, ist das Nützlichste an 7.1 nicht Kollaboration, sondern responsives Styling. Bislang bedeutete die Steuerung, wie ein Block bei verschiedenen Bildschirmgrößen aussieht, eigenes CSS, ein Plugin oder Kampf mit dem Editor. 7.1 legt Block-Styling pro Breakpoint direkt in den Editor, dazu Styling für interaktive Zustände wie Hover, Fokus und Active. Theme-Autoren setzen eigene Breakpoints in theme.json. Beta 4 ergänzte nach UX-Beschwerden eine Opt-out-Option, die Funktion ist also nicht auf jeder Website erzwungen.

Das ist unspektakulär und wiegt schwerer als die meisten der schillernderen Punkte. Responsive Kontrolle ist im echten Kundengeschäft ein täglicher Reibungspunkt, und sie in den Core zu verlagern reduziert die Plugin-Anzahl und das eigene CSS, das sich auf jeder Website sonst ansammelt. Es ist die Art von Plattformreife, die keine Schlagzeilen macht, aber im Stillen eine ganze Kategorie von Support-Anfragen überflüssig macht.

#React 19 rutscht, Classic-Block bleibt: unter der Haube

Zwei Punkte auf der Roadmap sind für Endnutzer unsichtbar und für Entwickler wichtig. Einer davon hat die Release verlassen. Das Upgrade des Editors von React 18 auf React 19 landet nicht in 7.1: Kompatibilitätsprobleme mit Plugins zeigten sich hartnäckiger als erwartet, und der von Automattic gesponserte Beitragende Jarda Snajdr sagte, das Upgrade brauche „eine erhebliche Testphase“, bevor es ausgeliefert werden könne.

Das ist die richtige und zugleich unangenehme Entscheidung. React 19 war einer der wenigen Punkte dieser Roadmap mit hoher Konfidenz und gleichzeitig der Punkt, der am ehesten fremden Code brechen konnte. Die Verschiebung macht 7.1 kleiner, als die Roadmap versprochen hatte, und schiebt die Kompatibilitätsarbeit in einen späteren Zyklus. Für Entwickler ist die praktische Folge ein Aufschub, keine Absage: das Upgrade kommt weiterhin, eigene Blöcke und Editor-Oberflächen im Gutenberg-Plugin gegen React 19 zu testen lohnt sich also nach wie vor, nur eben ohne August-Frist im Nacken.

Der Classic-Block ist der interessantere Fall, denn hier änderte sich der Plan mitten im Zyklus. Ursprünglich sollte er in 7.1 aus dem Block-Inserter ausgeblendet und schrittweise ausgemustert werden, weil er TinyMCE mitschleppt, einen schweren Editor. Die Reaktion der Community kam prompt: Einige wie Seth Rubenstein (Pew Research Center) quittierten es mit einem knappen „gut“, während erfahrene Blogger wie Jeff Chandler Ärger heraufziehen sahen: „Heilige Scheiße. Das habe ich nicht kommen sehen. Ich weiß, was das anrichten wird.“

Update: Dieser Plan, den Block aus dem Inserter auszublenden, wurde zurückgenommen. Der Classic-Block bleibt in 7.1 im Inserter, genau wie in 7.0, wobei Automattics Engineering-Director Marin Atanasov anmerkte, der ursprüngliche Ansatz habe „die Sache weitgehend verkehrt herum“ angepackt, und Nutzer ohne bessere Alternative davon wegzudrängen mache die Erfahrung ohne direkten Gewinn nur schlechter. Der Performance-Aspekt bleibt bestehen, denn TinyMCE verzögert von Seiten zu laden, die ihn nie brauchen, ist ein echter Gewinn für WooCommerce-Shops, bei denen jedes Kilobyte an Editor-Gewicht gemessen wird, doch die Migrationsuhr, die manche schon gestartet hatten, ist nie angelaufen. Wer Classic-Block-Inhalte pflegt, wird in 7.1 zu nichts gezwungen.

Update: Auch die Unterstützung für Unicode-E-Mail-Adressen ist aus 7.1 raus. Sie war sechs Wochen zuvor nach elf Jahren Entwicklung in den Core gemergt worden, und Matt Mullenweg entschied, sie aus Sicherheitsgründen zu streichen. Elf Jahre bis zum Merge und sechs Wochen bis zur Rücknahme ist ein hartes Ergebnis für die beteiligten Beitragenden, und es gehört neben die Canary-Debatte weiter unten gelesen: eine Änderung, die Review und Merge übersteht und dann spät an einer Sicherheitsabwägung scheitert, ist genau das Problem der Feedback-Schleife, das die Committer zu benennen versuchen. Wer mit Nicht-ASCII-E-Mail-Adressen in 7.1 gerechnet hat, plant weiter mit dem bisherigen Verhalten.

Zwei entwicklernahe Änderungen kamen als Merge-Proposals nach der Roadmap und lohnen die Beobachtung. Das Design-System-Theming führt ein im Core registriertes wp-theme-Stylesheet plus einen React-ThemeProvider ein, die Grundlage für das lange versprochene Admin-Redesign, mit benutzerdefinierten Farbschemata im Site-Editor als erstem sichtbaren Ergebnis. Und die Abilities API erhielt drei vorgeschlagene, rein lesende Abilities (core/read-settings, core/read-content, core/read-users), die Agenten und KI-Werkzeugen hinter Berechtigungsprüfungen den Lesezugriff auf grundlegende Website-Daten erlauben, auch wenn ein Abilities-Maintainer bereits eingewandt hat, dass sie noch nicht core-reif sind. Beides ist die Art von Verrohrung, die darüber entscheidet, ob die KI- und Admin-Geschichte sauber erscheint oder auf 7.2 rutscht.

#Guidelines und KI: die Wette auf den Workflow

Das Aushängeschild ist Guidelines, eine Funktion, mit der eine Website redaktionelle Regeln und Markenstimme an einem Ort definiert, was dann in die KI-Werkzeuge des Editors einfließt, damit generierte Inhalte diesen Regeln folgen. Hinzu kommen eine AI-Client-Iteration mit Generierungs-Streaming und Embeddings sowie eine Connectors-Iteration, die die Authentifizierung über reine API-Schlüssel hinaus erweitert.

Diese Funktion machte einen konkreten Schritt nach vorn, als der von Automattic gesponserte Core-Committer Greg Ziółkowski einen formellen Merge-Proposal veröffentlichte, um den neuen Custom Post Type wp_knowledge und die AI-Guidelines in den Core zu bringen. Die Resonanz war jedoch stark gespalten:

• George Stephanis (Bethink Studios) begrüßte die Ergänzung und wies darauf hin, dass sie Probleme mit redaktionellen Richtlinien löst, die Plugins seit Jahren mühsam umgehen mussten.
• Aaron Jorbin (unabhängiger Core-Committer) stimmte zu, dass das Fundament gut sei, die Implementierung im aktuellen Zustand jedoch unvollständig bleibe.
• Jon Brown (9seeds) argumentierte unverblümt, es sollte „erst einmal ein oder zwei Jahre als Core-Plugin entwickelt und dann vielleicht trotzdem nie in den Core überführt werden.“
• Search Engine Journal griff die Kritik der Entwickler auf und berichtete, dass viele die Funktion als an den tatsächlichen Bedürfnissen der Nutzer vorbeigehend empfinden.

Das ist die richtige Form für KI in einem CMS. Das Risiko bei KI-Schreibhilfen ist gleichförmiger, markenfremder Output, genau das Slop-Problem, gegen das jedes Content-Team heute ankämpft. Eine Guidelines-Schicht, die die Generierung an die Standards einer Website bindet, ist eine Absicherung dagegen. Sie ist nicht erschienen. Matt Mullenweg vetierte den Merge im Juli mit der Begründung, KI-Funktionen bräuchten reale Nutzung mit eindrucksvollem Wachstum von Woche zu Woche, bevor sie in den Core gehören. Das Experiment bleibt in Gutenberg und bei Automattic. Behandeln Sie es als Vorschlag, nicht als 7.1-Fähigkeit. Die Merge-Debatte haben wir in WordPress 7.1: KI-Richtlinien und der neue Inhaltstyp wp_knowledge nachgezeichnet.

#Die RTC-Saga und warum sie immer wieder stockt

Die Echtzeit-Kollaboration ist die Funktion, die WordPress immer wieder fast ausliefert. Sie wurde zwei Wochen vor 7.0 gestrichen. In der 7.1-Roadmap ordnete McCarthy sie ehrlich ein, mit weiterhin offenen “big, open strategy questions” (großen, offenen strategischen Fragen): was tatsächlich ausgeliefert werden soll und welcher Speichermechanismus zum Einsatz kommt. Wir haben die Einzelheiten dieses zweiten Anlaufs in unserem Beitrag zur Echtzeit-Kollaboration in WordPress 7.1 behandelt, und die Roadmap löste die dort aufgeworfenen Fragen weniger auf, als dass sie sie neu formulierte.

Die aufschlussreichere Entwicklung kam von den Core-Committern. Bei ihrem Treffen auf der WordCamp Europe 2026 bildete sich eine “strong opinion, loosely held” (starke, lose gehaltene Meinung) heraus, dass der gesamte RTC-Funktionsumfang gar nicht in den Core gehöre, sondern nur die zugrunde liegende Architektur, während die reichhaltige Funktionsschicht Plugins oder Hostern überlassen bleibt. Diese Trennlinie hielt in diesem Zyklus. 7.1 lieferte weder die technische Grundlage noch die sichtbare Funktion. Kollaboration als roter Faden blieb Absicht. 7.2 ist derzeit für den 9. Dezember 2026 angesetzt. Verkaufen Sie einem Kunden auch auf dieses Datum keine Live-Mehrbenutzerbearbeitung, bis ein Field Guide sagt, dass sie erschienen ist.

#Die Canary-Debatte: ein verkapptes Prozessproblem

Das Interessanteste, was die Committer auf der WordCamp Europe diskutierten, war gar keine Funktion. Sie brachten ins Spiel, WordPress auf ein Canary-Deployment-Modell nach Chrome-Vorbild mit Feature-Flags umzustellen, eine grundlegend andere Art, den Core zu bauen, zu testen und auszuliefern. Die Gruppe selbst räumte ein, es sei wohl “a technical solution to a communications problem” (eine technische Lösung für ein Kommunikationsproblem), und warf naheliegende Fragen auf, etwa wie sich Canary-Builds von dem unterscheiden würden, was das Gutenberg-Plugin bereits bietet, und ob es überhaupt noch ein Gutenberg-Plugin geben sollte.

Bis dahin ist es noch ein weiter Weg. Aber dass Committer es überhaupt zur Sprache bringen, sagt etwas darüber aus, wo sie das aktuelle Modell als unzureichend empfinden, besonders bei Tests und Feedback. Das wiederholte Scheitern von RTC kurz vor knapp ist das Symptom: Eine große Funktion, die bis auf zwei Wochen an das Release heranreicht, bevor sie gestrichen wird, ist ein Versagen der Feedback-Schleife, nicht bloß eine Funktion, die nicht fertig war. Die Canary-Idee ist ein Versuch, das früher abzufangen. Ob sie kommt oder nicht, allein dass sie zur Debatte steht, ist das ehrlichste Eingeständnis des gesamten Zyklus, dass der Build-Prozess, nicht der Funktions-Backlog, der eigentliche Engpass ist.

#Das Zeitplan-Problem

Und nun zur nüchternen Zahl. Beta 1 war der 15. Juli, das Release der 19. August, und Beta 3 brachte 71 Fixes. Das sind unter vier Wochen, um eine derart große Roadmap festzuzurren. McCarthy übernahm eine ehrgeizige Liste und wenig Zeit, und das realistische Ergebnis war von Anfang an, dass einige Punkte erscheinen, einige auf 7.2 rutschen und einige nur teilweise und hinter Feature-Flags ankommen. Das ist keine Kritik an der Release-Leiterin, es ist die strukturelle Realität eines festen Datums, das mit der WordCamp US zusammenfallen soll. React 19 und Unicode-E-Mail fielen noch vor Beta 3 heraus. Guidelines, RTC und die Ausmusterung des Classic-Blocks fielen rundherum. Die Zip-Datei, die erschien, ist die kürzere Liste.

Für Website-Betreiber lautet die praktische Lehre unverändert, die Roadmap als Absicht zu behandeln, nicht als Garantie. Planen Sie um das herum, was wirklich erschien: responsives Styling, clientseitige Medien, Playlist und Tabs sowie den iframe-Editor. Versprechen Sie einem Kunden keine Funktion, die sechs Wochen vor dem Release noch “big, open strategy questions” (große, offene strategische Fragen) mit sich trug, und setzen Sie eine gemergte Funktion nicht mit einer ausgelieferten gleich. Unicode-E-Mail wurde gemergt und dann gestrichen. Das ist dieselbe Lehre.

#Die 24-Stunden-Aktualisierungsverzögerung: Sicherheit vs. Geschwindigkeit

Parallel zu den Debatten über den Core-Release führte das Plugin-Team von WordPress.org eine bedeutende Änderung an der Infrastruktur ein: eine 24-stündige Abkühlphase (Cooldown) für alle Plugin- und Theme-Updates. Während die Ankündigung diese Maßnahme auf automatische Updates bezog, um Supply-Chain-Angriffe zu verhindern, stellte sich heraus, dass die Verzögerung für alle Aktualisierungswege gilt, einschließlich der manuellen Installation über das Dashboard.

Dies hat zu heftigem Gegenwind von Entwicklern und Agenturen geführt:

• Miriam Schwab (Elementor) wies darauf hin, dass dies ein gefährliches „Sicherheitsfenster“ schafft. Sobald ein Sicherheits-Release veröffentlicht wird, ist der Patch-Code öffentlich. Bots können ihn sofort analysieren, um Exploits zu bauen, während Website-Administratoren bis zu 24 Stunden lang daran gehindert werden, das Update einzuspielen.
• Pavel Ciorici (Theme-Entwickler) merkte an, dass das Einreichen einer schnellen Fehlerbehebung während der Abkühlphase den 24-Stunden-Timer zurücksetzt, was die Verzögerung weiter verschlimmert.
• Steve Burge (PublishPress) lieferte eine Gegenposition und lobte, dass das Verfahren bereits in der ersten Woche erfolgreich kleinere Sicherheitsprobleme abgefangen habe.
• Francisco Torres (Co-Repräsentant des Plugin-Teams) räumte den Unmut ein und bestätigte, dass das Team das Feedback aktiv prüft und Änderungen an den Regeln wahrscheinlich sind.

Für Agenturen und leistungsorientierte WordPress-Websites verschiebt diese Änderung der Infrastruktur den Rhythmus von Releases und Sicherheitspatches. Dies unterstreicht die Notwendigkeit von Bereitstellungen außerhalb des offiziellen Repositories oder dem Testen von Updates in Staging-Umgebungen vor dem Rollout.

#Was jetzt zu tun ist

• Entwickler: Der Beitragseditor läuft immer im iframe. Blöcke auf API v2 oder darunter brauchen einen v3-Durchgang. Details stehen in unserer Notiz zum iframe-Beitragseditor. React 19 ist weiterhin nicht im Core. Testen Sie weiter dagegen im Gutenberg-Plugin.
• Websites mit WP Rocket: Ein Typfehler im Cloudflare-Kompatibilitätsmodul legt Sites unter 7.1 lahm (wp-media/wp-rocket#8596). Zuerst Staging, dann Produktion. Wer Shops betreibt, macht daraus eine WooCommerce-Prüfung zu Performance und Zuverlässigkeit, keine Kosmetik.
• Altbestand-Websites: Der Classic-Block ist weiterhin im Inserter. In 7.1 gibt es keine erzwungene Migration. Prüfen Sie ihn, wenn Sie den Inhalt ohnehin anfassen, nicht weil diese Release eine Uhr gestartet hätte.
• Redaktionsteams: Guidelines sind nicht erschienen. Bauen Sie den Workflow nicht um ein Gutenberg-Experiment herum um.
• Alle: Auto-Updates auf 7.1 rollen. Testen Sie auf Staging, besonders wenn Object Cache, ein Page-Cache-Plugin oder eigener Editor-JavaScript im Spiel sind.

#Fazit

WordPress 7.1 Mary Lou ist eine nützliche Plattform-Release mit einem leicht irreführenden Namen. Die Kollaborations-Rahmung war echte Absicht. Die Kollaborationsfunktion ist nicht erschienen, im zweiten Zyklus in Folge. Streift man die Rahmung ab, bekamen Sie am 19. August eine kleinere und weiterhin lohnende Lieferung: responsives Styling, das tägliche Reibung beseitigt, clientseitige Medien, die HEIC-Uploads nicht mehr an PHP-Speichergrenzen scheitern lassen, Playlist und Tabs als stabile Blöcke, eine persistente Admin-Leiste und einen Beitragseditor immer im iframe. Guidelines landeten nicht. Die Abkündigung des Classic-Blocks landete nicht. React 19 und Unicode-E-Mail blieben draußen. Die Lücke zwischen der Juni-Roadmap und der August-Zip-Datei ist jetzt gemessen, nicht vorhergesagt.

Die tiefere Geschichte ist weiterhin die Canary-Debatte. Ein Projekt, das bereit ist, sein eigenes Deployment-Modell öffentlich zu hinterfragen, ist ein Projekt, das weiß, dass seine Feedback-Schleifen unter Spannung stehen, dieselbe Unruhe, die auch die wiederkehrende Debatte darüber nährt, ob WordPress Marktanteile verliert. Verfolgen Sie diese Diskussion, denn sie wird Releases noch lange nach dieser hier prägen. Planen Sie um das herum, was erschien. Testen Sie Staging. Behandeln Sie die nächste Roadmap so, wie diese hätte gelesen werden müssen: Absicht, bis die Zip-Datei existiert.

Zuletzt aktualisiert: 20. August 2026.