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.
| Funktion | Was es ist | Wen es betrifft | Konfidenz |
|---|---|---|---|
| Responsives Styling | Block-Stile je Bildschirmgröße im Editor setzen | Website-Builder, Agenturen | Hoch |
| React 18 auf 19 | Interner Bibliotheks-Upgrade für den Editor | Block- und Plugin-Entwickler | Hoch |
| Abkündigung des Classic-Blocks | Classic-Block auslaufen lassen, TinyMCE verzögert laden | Altbestand-Websites, Performance | Hoch |
| Guidelines | Redaktionelle Regeln und Markenstimme, verknüpft mit KI-Werkzeugen | Redaktionsteams | Mittel |
| Notes-Erweiterungen | Emoji-Reaktionen, Vorschlagsmodus, Rich Text | Reviewer, Teams | Mittel |
| Clientseitige Medien | HEIC, Ultra HDR, GIF-zu-Video, freier Zuschnitt | Content-Publisher | Mittel |
| Neue Blöcke | Playlist, Table of Contents, Tabs | Alle Nutzer | Mittel |
| Echtzeit-Kollaboration | Mehrbenutzer-Bearbeitung live | Teams, irgendwann | Niedrig für 7.1 |
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.
Die Abkündigung des Classic-Blocks ist die interessantere, denn sie ist eine Performance-Entscheidung im Gewand der Aufräumarbeit. Der Classic-Block trägt TinyMCE mit sich, einen schweren Editor, und der Plan ist, diesen verzögert zu laden und den Block auslaufen zu lassen. Bestehende Inhalte brechen nicht, doch Websites, die sich noch auf den Classic-Editor oder den Classic-Block stützen, sollten dies als formalen Startschuss für ihre Migration begreifen. Für performance-sensible Projekte, besonders WooCommerce-Shops, bei denen jedes Kilobyte an Editor- und Frontend-Gewicht zählt, ist es ein echter Gewinn, TinyMCE von Seiten zu entfernen, die ihn nie brauchten.
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.
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, React 19, den anlaufenden Classic-Block-Umstieg, und beobachten Sie die mit mittlerer Konfidenz, 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.
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. 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: 20. Juni 2026.



