Die Zukunft von WordPress: Roadmap 2026-2030 und darüber hinaus

2015 drehte sich die WordPress-Diskussion um die REST API. Im September 2026, mit 7.1.1 als stabilem Stand, geht es darum, wer denselben Beitrag gleichzeitig bearbeiten darf, was ein KI-Agent aufrufen darf und ob Inhalte aus einem geschlossenen Builder ohne Copy-Paste herauskommen.

Zwei Zahlen rahmen den Rest. W3Techs maß WordPress am 20. September 2026 bei 40,2 % aller Websites und 58,8 % der Sites mit bekanntem CMS, nach 43,2 % aller Websites im Dezember 2025. Die Roadmap reagiert auf diesen Abwärtstrend, sie feiert ihn nicht. Der Start von Cloudflares EmDash CMS ist ein sichtbares Stück derselben Konkurrenz: in DACH-Agenturen taucht die Frage inzwischen in RFP-Gesprächen auf, nicht nur in Hacker News.

Was folgt, ist die Roadmap gegen Core geprüft, Release für Release. Wo eine Funktion real ist, steht der Funktionsname. Wo sie noch Diskussion ist, steht das auch.

#Hat WordPress 2026 Echtzeit-Zusammenarbeit

Die Roadmap auf wordpress.org nennt vier Gutenberg-Phasen: Easier Editing, Customization, Collaboration, Multilingual. Phase 3 ist aktiv und nur teilweise geliefert.

Notes sind da. Kommentare auf Blockebene landeten in WordPress 6.9 am 2. Dezember 2025, nach einem Experiment im Gutenberg-Plugin. Umbenannt von „block comments“ zu Notes, damit sie nicht mit wp_comments für Leser verwechselt werden. Die erste Version deckt Anlegen, Threading, Auflösen und Löschen auf dem ganzen Block ab, nicht auf einer Selektion darin. Ansehen oder Anlegen braucht die Capability edit_post, weil Notes nur im Beitragseditor leben.

WordPress 7.1 hat Notes erweitert, nicht ersetzt: E-Mail bei Erwähnungen, teilbare Revisionslinks und ein Fix, damit Notes nicht mehr in Kommentar-Feed-Queries lecken. Wer in 6.9 einen Custom-Comment-Feed gebaut hat, kann Note-Datensätze gesehen haben, die niemand angefragt hat. Das ist der Bug-Report, den man kennen sollte, bevor man „unser Feed ist kaputt“ schreibt.

Echtzeit-Zusammenarbeit ist nicht da. Sie kam als Beta in den Core und wurde wieder gezogen. Der Testaufruf vom 11. März 2026 bat darum, WordPress 7.0 Beta 1 auf einem erreichbaren Server zu installieren, unter Einstellungen > Schreiben „Enable real-time collaboration“ zu aktivieren und denselben Beitrag mit zwei Accounts zu öffnen. Am 8. Mai 2026 flog sie aus 7.0; die Gründe sind der nützliche Teil: Oberflächenumfang, Race Conditions, Serverlast, Speichereffizienz und Bugs, die Fuzz-Tests weiter ans Licht brachten. In 7.1 ist sie ebenfalls nicht aktiviert. Die Sync-Schicht baut auf Yjs; core/freeform (Classic) gilt als inkompatibel. Den Release-für-Release-Blick liefert die WordPress-7.1-Roadmap.

Was euren Code betrifft. Blöcke synchronisieren über Attribute. Die meisten Blöcke unterstützen Zusammenarbeit deshalb von selbst; kaputt gehen die, die Editor-State woanders halten. Felder in block.json mit Typ deklarieren, aus attributes lesen, mit setAttributes schreiben, statt den Wert in einem React-useState in edit() bis zum Blur zu parken. Das zahlt sich schon bei Undo, Revisionen und Autosave aus und entscheidet, ob der Block überlebt, falls Collaboration zurückkommt.

#Wann kommt Mehrsprachigkeit in den WordPress-Core

Die Roadmap beschreibt Phase 4 in einem Satz: Core-Implementierung für mehrsprachige Sites. Es gibt kein Schema, keine API, keinen Dev-Note und kein Datum. Das Advanced Administration Handbook führt Mehrsprachigkeit weiterhin als Plugin-Thema.

Die Reihenfolge ist der interessante Teil und steht in den Phase-3-Updates offen: Die Collaboration-Infrastruktur muss stehen, bevor Mehrsprachigkeit sinnvoll designed werden kann, weil beide dieselbe Frage beantworten müssen: wie ein logischer Inhalt auf mehrere gespeicherte Versionen mappt. Andersherum hieße das, die Frage zweimal zu lösen. Phase 4 hängt also nicht an Desinteresse, sondern daran, dass Phase 3 hinter dem eigenen Beta liegt.

In DACH-Projekten mit DE/EN/FR und oft WPML oder Polylang gilt deshalb pragmatisch:

• Übersetzungsidentität in Post-Meta oder einer Taxonomie halten, nicht in Template-Logik einbrennen.
• Keine Locale-Strings in Block-Attributen speichern. Ein Block mit hartcodiertem de_DE wird ungültig, sobald die Translation-Schicht wandert.
• WPML und Polylang als langfristige Abhängigkeiten behandeln, nicht als Übergangslösung. Sie überleben diesen Roadmap-Punkt.

#Kann Data Liberation eine Website zu WordPress migrieren

Die Projektseite unter wordpress.org/data-liberation erschien am 6. Dezember 2023 und nennt fünf Phasen ausdrücklich:

Phasen 4 und 5, also die, die Leute meinen, wenn sie „Ein-Klick-Migration“ sagen, haben nicht begonnen.

Was existiert, ist enger und nützlicher als der Slogan. Das Data-Liberation-Agent-Plugin von Studio by WordPress.com liefert Extraktoren für benannte Plattformen: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly und Wix. Das sind Scraper für konkrete Builder, kein Universalformat. Parallel baut das Playground-Team PHP-Importer als Streaming-Parser; der Blueprint-Schritt importWxr kann über den Data-Liberation-Importer statt über den Legacy-Weg laufen.

Für Agenturen: Bei den acht Plattformen auf der Liste lohnt ein Test vor dem Angebot für manuelle Content-Migration. Sonst bleibt WXR das Core-Exportformat, und WXR trägt weiterhin keine Mediendateien, Plugin-Einstellungen oder Block-Pattern-Bibliotheken. In Angeboten für Schweizer oder deutsche Shops, die von Shopify kommen, das Budget entsprechend setzen.

#Was hat sich im Admin von WordPress 7.1 geändert

Zuerst eine Korrektur, die oft kursiert. MP6 kam nicht 2012. Es war ein Feature-Plugin von Oktober 2013 und landete in WordPress 3.8 am 12. Dezember 2013. Und das Admin war nicht eingefroren: 7.1 hat es verändert.

Was am 19. August 2026 in WordPress 7.1 landete, ist eine Designsystem-Grundlage, beschrieben in der Core-Dev-Note vom 31. Juli 2026. Zwei Ressourcen sind standardmäßig registriert:

• Ein Stylesheet wp-theme mit semantischen Design-Tokens als CSS Custom Properties, etwa --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• Ein Script-Handle wp-theme, das eine ThemeProvider-React-Komponente aus @wordpress/theme exportiert.

ThemeProvider nimmt fünf Props: color.primary und color.background als Seed-Farben, cursor.control, cornerRadius mit den Presets none, subtle, moderate und pronounced, sowie isRoot für Theming am Document-Root.

Drei weitere 7.1-Admin-Änderungen, die im Ticket-Tracker vor dem Blogpost auftauchen:

1. Die Prop __next40pxDefaultSize ist ab 7.1 ein No-Op: noch akzeptiert, aber ignoriert. Form Controls rendern ohnehin bei 40px, also verrutschen Admin-Screens, deren Abstände am alten Default gemessen waren.
2. wp_get_tooltip() und wp_get_toggletip() liefern barrierefreie Tooltips als Core-Funktion statt als Plugin-Eigenbau.
3. Der Zeilenkopf der Beitragsliste wanderte von der Checkbox- zur Titelspalte, ein A11y-Fix, der ändert, was Screenreader pro Zeile ansagen.

Was 7.1 nicht ist: Ersatz für wp-admin, Kunden-Dashboard oder White-Label-Übergabe. Tokens und ein Provider sind der Anfang, nicht das fertige Redesign. Kunden-Admin weiter so planen, als ob ihr diese Schicht selbst besitzt.

#Was sollten WordPress-Entwickler 2026 lernen

Drei Dinge sind konkret genug für Lernzeit; eine häufige Behauptung ist es nicht.

Die Abilities API, seit 6.9. Das Registry, mit dem Plugins, Core und externe Agenten entdecken, was eine Site kann. Action wp_abilities_api_init, dann wp_register_ability() mit einem Namespaced-Namen wie my-plugin/my-ability, Execute- und Permission-Callback plus typisierte Input-/Output-Schemas. Abilities sind standardmäßig privat: show_in_rest ist false, bis ihr es setzt; erst dann erscheinen sie unter dem REST-Namespace wp-abilities/v1. WordPress 7.0 brachte das Client-Pendant. Core registriert drei read-only Abilities in wp-includes/abilities.php (core/get-site-info, core/get-user-info, core/get-environment-info). Namen vor dem Coding gegen Trunk prüfen, denn frühere Entwürfe trugen andere.

Der AI Client, in 7.0 gemerged. Provider-agnostische Infrastruktur: PHP-Prompt-Builder, Provider- und Model-Abstraktion, geteilte Credential-Speicherung, REST und JavaScript-API. Das SDK liegt unter wp-includes/php-ai-client/; die WordPress-Glue darunter in wp-includes/ai-client/. Der Connectors-Screen: wp-admin/options-connectors.php. Praktische Folge: nicht mehr in jedem Plugin API-Key und HTTP-Client bundeln. Was der Core nicht enthält: Seitengenerierung aus einer Beschreibung, Content-Optimierung oder vorausschauende Updates. Das bleibt Plugin-Terrain.

React, speziell die Editor-Datenschicht. JSX ist die einfache Hälfte. Die Hälfte, die entscheidet, ob euer Block Collaboration und den neuen Admin überlebt, ist @wordpress/data, Attribute in block.json und jetzt @wordpress/ui sowie @wordpress/theme für Admin-Oberflächen, die Core-Tokens folgen statt dagegen zu kämpfen.

Und die Behauptung, die ihr fallen lassen könnt: Es gibt keine „kanonische API“, die Headless WordPress einfach macht. Es gibt REST, WPGraphQL als Plugin und die Abilities API für agentenbezogene Aufrufe. Drei Verträge, drei Wartungsgeschichten, und die Architekturentscheidung bleibt eure.

#Wie die WordPress-Roadmap Plugins betrifft

Die Roadmap betrifft nicht nur den Core, sie verändert, wie Plugins sich auf die Plattform stützen. Es lohnt sich, zu trennen, was schon Handeln verlangt und was noch an Bedingungen hängt.

#Müssen Plugins für Echtzeit-Zusammenarbeit angepasst werden

Solange gleichzeitiges Bearbeiten nicht in den Core zurückkehrt, zwingt euch nichts, ein Plugin umzubauen. Was ihr heute tun könnt, weil es sich auch ohne Collaboration auszahlt: Tabelleneditoren, Formularbuilder und SEO-Tools halten ihren Zustand in Block-Attributen statt in lokalem React-State. Das ist dieselbe Anforderung, die der Testaufruf zu 7.0 Beta 1 gestellt hat, und genau das sorgt dafür, dass Undo und Revisionen sauber funktionieren.

#Müssen Plugins für Mehrsprachigkeit im Core angepasst werden

Hier gibt es nichts gegen eine API vorzubereiten, weil es keine API gibt. Der einzige konkrete Schritt: sich nicht festlegen. Übersetzungsidentität in Meta oder einer Taxonomie halten und Sprach-Strings aus Block-Attributen heraushalten. Jede Liste standardisierter Übersetzungs-APIs im Core ist Stand heute erfunden.

#Was nach WordPress 7.0 aus der Echtzeit-Zusammenarbeit wurde

Die Entfernung hat die Arbeit nicht beendet, sie hat sie aus dem Release-Branch herausgenommen. Am 3. Juni 2026 kündigte das Core-Team ein Outreach-Programm für kollaboratives Bearbeiten in 7.1 an: Early Adopter nutzen die aktuelle Version des Gutenberg-Plugins, aktivieren die Zusammenarbeit unter Einstellungen > Schreiben und berichten im Slack-Kanal #collaborative-editing-outreach, über den 7.1-Zyklus hinweg und mindestens bis zum 18. August 2026. Der Beitrag des Hosting-Teams vom selben Tag bat Hoster, ihre eigenen Kunden einzuladen, damit die Funktion auf vielen Serverumgebungen getestet wird statt auf einer. Das passt zu den Gründen für die Entfernung: Serverlast und Speichereffizienz hängen vom Hosting ab.

Zwei Repositories zeigen, wohin die Entwicklung danach ging. Gutenberg Sync Engines, angelegt am 10. August 2026, beschreibt sich als Vergleich möglicher Sync-Engines und Transportwege für die Echtzeit-Zusammenarbeit in Gutenberg. Das Feature-Plugin Presence API, seit dem 21. Juli 2026 auf wordpress.org gelistet und mit WordPress 7.0 als Voraussetzung, erfasst, welche Nutzer angemeldet sind, auf welchem Admin-Screen sie sich befinden und welche Beiträge sie bearbeiten. Die Daten laufen über die Heartbeat API in eine eigene Tabelle wp_presence mit 150 Sekunden TTL, und auch die Post-Locks liegen dort statt in Post-Meta. Ein gehaltener Lock macht gecachte Post-Queries damit nicht mehr veraltet. Version 0.18.1 erschien am 13. Oktober 2026.

Die Zusammenfassung des Presence-API-Meetings vom 12. Oktober 2026 legt die Hürde für einen Core-Vorschlag fest: drei externe Projekte, die die API nutzen, und acht Wochen ohne Breaking Change, gezählt ab Version 0.17.0. Frühestes Datum ist damit der 3. Dezember. Post-Locks sind der erste Nutzer, Gutenberg Sync Engines ist das erste externe Projekt. Eine Ziel-Version von WordPress wird nicht genannt. Wenn euer Plugin das Post-Meta _edit_lock liest oder schreibt, ist das die Arbeit, die ihr verfolgen solltet, denn genau die Post-Locks verlagert das Plugin.

#Wann erscheint WordPress 7.2

Der Aufruf an Freiwillige vom 12. August 2026, veröffentlicht von Jeffrey Paul, schlägt den 9. Dezember 2026 als finales Release-Datum vor und nennt es flexibel. Die Alpha-Entwicklung begann am 10. August 2026. Die vorgeschlagenen Meilensteine folgen im Wochentakt:

Die Roadmap-Seite, zuletzt geändert am 20. August 2026, führt 7.2 für den 10. Dezember 2026 und schreibt, dass die projizierten Termine nur der groben Planung dienen. Dort steht auch, dass neue Features einen Monat vor einem Release eingefroren werden. Der Aufruf nennt Rollen (Release Lead, Release-Koordination, Tech Leads, Triage Lead, Test Lead), aber keine Features. Stand Mitte Oktober gibt es keinen veröffentlichten Umfang für 7.2, und alles, was vor Beta 1 als Neuerung von 7.2 verkauft wird, ist geraten. Für die Planung in der Agentur zählen die Release Candidates: Kundensites und eigene Blöcke in der Woche ab 17. November gegen RC1 testen, nicht am Release-Tag.

#Wie bereitet man Plugins und Blöcke auf WordPress 7.1 vor

Ohne die Zukunft zu raten, lässt sich mit dem, was veröffentlicht ist, schon Folgendes tun:

1. Block-Attribute in block.json deklarieren, mit Typ, und mit setAttributes schreiben. Genau diese Bedingung hat der Testaufruf selbst gesetzt, damit ein Block synchronisiert.
2. Eigene Fähigkeiten über die Abilities API registrieren, statt einen eigenen REST-Endpunkt zu erfinden, den ein Agent aufrufen soll, und show_in_rest auf false lassen, bis klar ist, wer die Ability nutzt.
3. Die --wpds--Tokens verwenden, in eigenen Admin-Screens, statt Farben und Radien hart zu codieren, die mit dem nächsten Release auseinanderlaufen.
4. Abstände eigener Admin-Screens prüfen, gegen die 40px-Controls, denn __next40pxDefaultSize ändert nichts mehr.

WordPress bremst nicht, sprintet aber auch nicht: ein Collaboration-Feature geliefert, eines verschoben, Admin-Redesign auf Token-Stufe, Mehrsprachigkeit noch nicht begonnen. Wenn ihr diese Lesart auf einen konkreten Stack anwenden wollt, machen wir genau solche Audits als WordPress-Entwickler.