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 wird 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 kehrt 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 erscheinen wird, und eine Kollaborationsgeschichte, über die noch offen gestritten wird.

#Das Wichtigste in Kürze

• Anne McCarthy leitet 7.1 zum ersten Mal, das Release ist für den 19. August 2026 angesetzt, den Abschlusstag der WordCamp US in Phoenix, Beta 1 am 15. Juli.
• Die Release dreht sich um Kollaboration, doch die Echtzeit-Kollaboration (RTC) bleibt ungelöst, nachdem sie aus 7.0 gestrichen wurde.
• Die wirklich bestätigten Gewinne sind responsives Styling, React 19, die Abkündigung des Classic-Blocks sowie die Guidelines- und KI-Workflow-Funktionen.
• 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.
• Bei unter vier Wochen von Beta 1 bis zum Release ist damit zu rechnen, dass einige Roadmap-Punkte verschoben oder hinter Flags ausgeliefert werden.

#Was tatsächlich erscheint, 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. Die Punkte mit hoher Konfidenz sind infrastrukturell oder an Builder gerichtet. Die Kollaborationsgeschichte, nach der die Release benannt ist, liegt im mittleren bis niedrigen Bereich.

#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. Die Roadmap bringt Block-Styling pro Breakpoint direkt in den Editor, dazu Styling für interaktive Zustände wie Hover, Fokus und Active sowie eine “display inherited styles”-Ansicht (Anzeige geerbter Stile), damit Sie sehen, woher ein Stil tatsächlich stammt.

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 und Abkündigung des Classic-Blocks: unter der Haube

Zwei Punkte auf der Roadmap sind für Endnutzer unsichtbar und für Entwickler wichtig. WordPress hebt den Editor von React 18 auf React 19 an, zunächst im Gutenberg-Plugin, bevor irgendwann der Weg in den Core folgt. Für die meisten Websites ändert das nichts Sichtbares. Für alle, die eigene Blöcke oder Editor-Oberflächen pflegen, ist es ein Grund, vor August gegen React 19 zu testen statt danach.

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 Core-Diskussion zufolge bleibt der Classic-Block in 7.1 im Inserter, genau wie heute, 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, steht still. Wer Classic-Block-Inhalte pflegt, wird in 7.1 zu nichts gezwungen.

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

Die Roadmap setzt auf KI, aber disziplinierter als nur “eine Chatbox einbauen”. 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, sofern sie in nutzbarem Zustand erscheint. Sie wird hier mit mittlerer Konfidenz bewertet, gerade weil Funktionsehrgeiz und ein vierwöchiges Stabilisierungsfenster nicht immer zusammenpassen.

#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 ordnet 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 zu WordPress 7.1 real-time collaboration behandelt, und die Roadmap löst die dort aufgeworfenen Fragen weniger auf, als dass sie sie neu formuliert.

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. Das ist eine bedeutsame Trennlinie. Hält sie, könnte 7.1 die technische Grundlage für Kollaboration liefern, ohne die sichtbare Funktion, was das Thema “Kollaboration als roter Faden” für diesen Zyklus eher zur Absichtserklärung als zur tatsächlichen Auslieferung macht.

#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 ist für den 15. Juli geplant, das Release für den 19. August. Das sind unter vier Wochen, um eine derart große Roadmap festzuzurren. McCarthy übernimmt eine ehrgeizige Liste und wenig Zeit, und das realistische Ergebnis ist, 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.

Für Website-Betreiber lautet die praktische Lehre, die Roadmap als Absicht zu behandeln, nicht als Garantie. Planen Sie um die Punkte mit hoher Konfidenz herum, responsives Styling und React 19, und beobachten Sie die mit mittlerer Konfidenz (Guidelines, die Theming-Grundlage für das Admin-Redesign), statt Pläne darauf zu bauen. Versprechen Sie einem Kunden keine Funktion, die sechs Wochen vor dem Release noch “big, open strategy questions” (große, offene strategische Fragen) mit sich trägt.

#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 vor dem 19. August zu tun ist

• Entwickler: Testen Sie eigene Blöcke und Editor-Erweiterungen jetzt gegen React 19, mit dem Gutenberg-Plugin, nicht erst nach dem Core-Release.
• Altbestand-Websites: Prüfen Sie, wo Sie noch vom Classic-Block oder -Editor abhängen, und starten Sie einen Migrationsplan, denn die Abkündigung läuft nun offiziell an.
• Performance-Projekte: Die Umstellung auf verzögert geladenes TinyMCE bringt einen Performance-Gewinn ohne Zusatzaufwand, sobald Sie vom Classic-Block weg sind, und ist eine Überlegung wert für eine WooCommerce-Performance-Prüfung.
• Redaktionsteams: Behalten Sie Guidelines und die KI-Werkzeuge im Blick, gestalten Sie Ihren Workflow aber nicht um eine Funktion mittlerer Konfidenz herum um, bis sie tatsächlich erscheint.
• Alle: Testen Sie ab dem 15. Juli gegen Beta 1. Ein kurzes Stabilisierungsfenster bedeutet, dass Community-Tests in diesem Zyklus mehr zählen als sonst.

#Fazit

WordPress 7.1 ist eine starke Release mit einem leicht irreführenden Namen. Die Kollaborations-Rahmung ist echte Absicht, doch die Kollaborationsfunktion ist weiterhin ungelöst, und die Committer debattieren offen, ob sie in den Core gehört und ob der gesamte Build-Prozess überdacht werden muss. Streift man die Rahmung ab, erhält man am 19. August eine wirklich nützliche Plattform-Release: responsives Styling, das tägliche Reibung beseitigt, eine React-19-Modernisierung, eine Classic-Block-Abkündigung, die der Performance hilft, und einen disziplinierten ersten Schritt bei KI über Guidelines.

Die tiefere Geschichte ist 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 WordPress-Releases noch lange nach dem Erscheinen von 7.1 prägen. Planen Sie vorerst um das Bestätigte herum, testen Sie früh, und verstehen Sie den Rest der Roadmap als Absichtserklärung, nicht als Lieferversprechen.

Zuletzt aktualisiert: 11. Juli 2026.