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.
Phase 3: Zusammenarbeit, was geliefert wurde und was nicht
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.
Phase 4: Mehrsprachigkeit, noch ein Name auf einer Liste
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_DEwird ungültig, sobald die Translation-Schicht wandert. - WPML und Polylang als langfristige Abhängigkeiten behandeln, nicht als Übergangslösung. Sie überleben diesen Roadmap-Punkt.
Data Liberation: fünf Phasen und die Tools, die es heute gibt
Die Projektseite unter wordpress.org/data-liberation erschien am 6. Dezember 2023 und nennt fünf Phasen ausdrücklich:
| Phase | Name | Status |
|---|---|---|
| 1 | Migration Guides | Laufend |
| 2 | Importing and Exporting Structured Data | Laufend |
| 3 | Liberating Data From Closed Platforms | Gestartet |
| 4 | Direct WordPress-to-WordPress Synchronization | Zukunft |
| 5 | Content Creation Powerhouse | Zukunft |
Phasen 4 und 5 - 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.
Das Admin-Redesign: was 7.1 wirklich geliefert hat
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-thememit 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 eineThemeProvider-React-Komponente aus@wordpress/themeexportiert.
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:
- Die Prop
__next40pxDefaultSizeist ab 7.1 ein No-Op: noch akzeptiert, aber ignoriert. Form Controls rendern ohnehin bei 40px - Admin-Screens, deren Abstände am alten Default gemessen waren, verrutschen. wp_get_tooltip()undwp_get_toggletip()liefern barrierefreie Tooltips als Core-Funktion statt als Plugin-Eigenbau.- 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 ihr lernen solltet
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 - 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.
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 - die Architekturentscheidung bleibt eure.
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.
