WordPress 7.0 Armstrong: KI-Infrastruktur und Abilities API

Update, 23. Mai 2026: WordPress 7.0 mit dem Codenamen Armstrong ist ausgeliefert. Das Release schliesst Phase 3 der Gutenberg-Roadmap mit grundlegender KI-Infrastruktur ab (Abilities API + AI Services Registry + AI Client), bringt ein modernisiertes Dashboard, die Command Palette ueberall, benutzerdefiniertes CSS auf Block-Ebene und den Icons-Block. Echtzeit-Zusammenarbeit wurde waehrend der RC-Tests entfernt und ist in 7.0 nicht enthalten. Dieser Leitfaden ist die Zusammenfassung nach dem Release; aeltere Roadmap-Abschnitte weiter unten bleiben als historischer Kontext erhalten, nicht als Beschreibung dessen, was auf einer 7.0-Installation heute aktiv ist.

WordPress 7.0 "Armstrong" wurde im Mai 2026 nach einem laenger als gewoehnlich dauernden Release-Candidate-Zyklus ausgeliefert. Das Release wurde von mehr als 900 Contributoren gebaut. Die Schlagzeilen-Aenderung ist KI-Infrastruktur im Core: die Abilities-API-Oberflaeche fuer sichere Admin-Operationen, die AI Services Registry fuer die Integration gehosteter Modelle und der WordPress AI Client, um den sich Drittanbieter-Plugins jetzt standardisieren. Ein modernisiertes Admin-Dashboard, die Command Palette ueberall in wp-admin, benutzerdefiniertes CSS auf Block-Ebene und der Icons-Block sind ebenfalls ausgeliefert worden. Echtzeit-Zusammenarbeit wurde waehrend der RC-Tests aus diesem Release entfernt und ist nicht Teil des Upgrades.

Eine schaerfere Polemik dazu, was die 7.0-KI-Oberflaeche fuer Plugin-Autoren konkret bedeutet, finden Sie in unserem Beitrag dazu, warum ein MCP-Server in Ihrem WordPress-Plugin der KI-Zug ist, der ueberlebt. Fuer die Sicherheitsimplikation nach dem Release lesen Sie unsere Analyse des GuardingWP State of WordPress Security 2026 Reports, die die neue KI-Schluessel-Oberflaeche in Kontext mit dem 53-Prozent-Baseline ungepatchter CVEs setzt.

Verfolgen Sie make.wordpress.org/core und den offiziellen wordpress.org/news Feed fuer nachfolgende Patch-Releases.

Erfahren Sie mehr ueber professionelle WordPress-Entwicklung bei WPPoland.

#WordPress 7.0 Release-Datum und Codename

WordPress 7.0 mit dem Codenamen Armstrong wurde im Mai 2026 nach einem ungewoehnlich langen Release-Candidate-Zyklus ausgeliefert (RC4 erschien am 14. Mai 2026, das finale Release folgte kurz darauf). Der Name “Armstrong” setzt die WordPress-Tradition fort, Major-Releases nach Jazzmusikern zu benennen.

Wenn Sie ein Produktions-Upgrade planen, liegt das sicherste Fenster weiterhin zwei bis vier Wochen nach dem finalen Release, sobald der erste Patch-Zyklus die von Early Adoptern gemeldeten Kompatibilitaetsprobleme einfaengt.

#Was tatsaechlich in 7.0 Armstrong ausgeliefert wurde

Dies ist die bestaetigte Funktionsliste aus der wordpress.org-Release-Ankuendigung, nicht die fruehere Roadmap-Absicht. Alles auf der aelteren Roadmap, was hier fehlt, ist nicht in 7.0 ausgeliefert worden.

• KI-Infrastruktur im Core. Die Abilities API fuer sichere Admin-Operationen ueber strukturierte Intents, die AI Services Registry fuer die Verbindung von Anbietern gehosteter Modelle (Anthropic, OpenAI, Vercel AI Gateway, self-hosted) und der WordPress AI Client, gegen den Drittanbieter-Plugins jetzt bauen. Das ist die Plattformaenderung, die das Release definiert.
• Command Palette ueberall. Cmd-K / Ctrl-K oeffnet die Command Palette auf jedem wp-admin-Bildschirm, nicht nur im Block-Editor. Die Tastatur-Oberflaeche fuer Power-User ist jetzt erstklassig.
• Benutzerdefiniertes CSS auf Block-Ebene. Jeder Block kann sein eigenes CSS tragen, beschraenkt auf diesen Block. Entfernt einen lange bestehenden Grund, in ein Custom-Theme abzusteigen.
• Icons-Block. Ein nativer Block zum Einbetten von SVG-Icons aus einer kuratierten Bibliothek mit themenbewussten Farbtokens.
• Modernisiertes Dashboard. Aufgefrischte Admin-Landing-Oberflaechen, mit den Agentic-KI-Experimenten hinter einer Feature-Flag sichtbar.
• PHP 7.4 als Mindestlaufzeit. Websites, die noch auf aelterem PHP laufen, muessen ihre Serverumgebung vor dem Update auf 7.0 aktualisieren.
• Mehr als 900 Contributoren. WP Charitable Product Manager David Bisset dankte den Contributoren und “ihren Ehepartnern, Partnern, Familien, Haustieren, Coping-Mechanismen und Beratern, die sie unterstuetzt haben” - das ist die ehrlichste Zeile, die seit Jahren ueber ein WordPress-Major-Release geschrieben wurde.

Was nicht ausgeliefert wurde und auf der 7.0-Linie nicht mehr erwartet wird:

• Echtzeit-Zusammenarbeit wurde nach Release-Candidate-Tests aus diesem Release entfernt. Die fruehere Roadmap-Beschreibung weiter unten in diesem Leitfaden bleibt als historischer Kontext erhalten.

#Sicherheit: KI-Anbieter-API-Schluessel vom ersten Tag an schuetzen

Patchstack-Gruender Oliver Sild postete oeffentlich auf X um den Release herum: “there will be an absolute rush by hackers to steal API keys.” Das Risiko ist konkret. Ein kompromittierter wp-admin-Credential auf einer 7.0-Installation laesst einem Angreifer nicht mehr nur die Inhalte aendern; er laesst ihn auch eine vier- oder fuenfstellige monatliche Token-Rechnung gegen Ihren KI-Anbieter abdrehen, bevor die Rechnung das einfaengt. Justin Nealey hat separat darauf hingewiesen, dass der WP AI Client keine eingebaute Drosselung hat und mehrere Plugins, die sich einen Schluessel teilen, das Token-Limit in unter einer Minute aufbrauchen koennen.

Die anzuwendende Kontrolloberflaeche ist einfach und dieselbe Kontrolloberflaeche, die ein Finanzteam auf jeden neu ausgestellten abrechnungsfaehigen Credential anwenden wuerde:

• API-Schluessel pro Connector skopieren, nicht pro Website. Ein Schluessel pro Anbieter pro Connector. Rotieren in einer veroeffentlichten Kadenz.
• Rate-Limits am Gateway anwenden, nicht im Plugin. Wenn Ihr Anbieter Per-Schluessel-Rate-Limits unterstuetzt (Anthropic, OpenAI, Vercel AI Gateway tun das alle), setzen Sie sie niedrig genug, dass anomaler Verbrauch in einem Abrechnungszyklus sichtbar wird.
• Auf anomale Token-Ausgaben alarmieren innerhalb des Zyklus, nicht zum Monatsende. Die meisten Anbieter stellen eine taegliche Abrechnungs-API zur Verfuegung; verdrahten Sie sie in Ihr Monitoring.
• Connector-Nutzung auf WordPress-Seite auditlogen. Die Abilities API liefert Operation-IDs; loggen Sie sie in einem separaten Stream vom regulaeren wp-admin-Audit-Log.

Fuer KRITIS-Sektoren in Deutschland fallen diese Kontrollen direkt in den Geltungsbereich der BSI-Orientierungshilfe zu sicheren KI-Anbindungen und der KRITIS-Verordnung; behandeln Sie die Connector-Anbindung als auditierungspflichtige Lieferkettenkomponente und protokollieren Sie sie entsprechend. Diese mappen direkt auf die Lieferkettenkontrollen, die bereits durch NIS2 Artikel 21 Absatz 2 Buchstabe d fuer in den Geltungsbereich fallende Einheiten verlangt werden. Behandeln Sie die neue KI-Oberflaeche als neue Klasse einer ICT-Drittvereinbarung und registrieren Sie sie entsprechend.

#WordPress 7.0 Roadmap

WordPress 7.0 steht am Ende von Phase 3 des vierphasigen Plans des Gutenberg-Projekts:

Phase 4 wird native mehrsprachige Faehigkeiten bringen, was bedeutet, dass WordPress endlich Inhaltsuebersetzung auf Core-Ebene handhaben wird, statt sich auf Plugins wie WPML oder Polylang zu verlassen. Fuer Agenturen, die heute mehrsprachige Sites betreuen, ist das die Funktion, die man auf der Post-7.0-Roadmap beobachten sollte.

#KI in WordPress jetzt, da 7.0 ausgeliefert ist

Die ehrliche Version von “KI-Funktionen in WordPress 7.0” beginnt mit dem, was bereits in 6.x funktioniert, denn das ist es, was echte Sites laufen.

Heute verfuegbar, in produktivem WordPress:

• Yoast und Rank Math liefern beide KI-unterstuetzte Schreibhelfer (Titel, Meta-Beschreibungen, interne Linkvorschlaege), die auf Modell-APIs von Drittanbietern basieren.
• Jetpack AI Assistant bietet In-Editor-Generierung, Zusammenfassung und Uebersetzung. Die Qualitaet variiert nach Sprache und Prompt.
• Eigenstaendige Content-Generierungs-Plugins existieren in einer breiten Qualitaetsspanne; nuetzlich fuer Entwuerfe, gefaehrlich, wenn direkt an die Veroeffentlichung ohne menschliche Pruefung verdrahtet.
• Automattic und Beitragsteams fuehren Phase-3-Experimente durch, einschliesslich kollaborativer Bearbeitung und editorseitiger KI-Aufrufe, im Gutenberg-Plugin vor jedem Merge in den Core.

Eine pragmatische Architektur fuer das Hinzufuegen von KI zu einer WordPress-Site heute, die wahrscheinlich ueberleben wird, was auch immer 7.0 liefert:

• Stellen Sie einen kleinen REST API Endpoint pro Anbieter bereit (OpenAI, Anthropic, Google oder ein selbst gehostetes Modell). Halten Sie anbieterspezifischen Code hinter einer Schnittstelle, sodass das Wechseln von Modellen eine Konfigurationsaenderung und keine Neuentwicklung ist.
• Lassen Sie alles, was langsamer als ein paar Sekunden ist, durch Action Scheduler laufen, nicht durch eine synchrone Anfrage. Das ist dasselbe Muster, das WooCommerce verwendet; es skaliert.
• Speichern Sie API-Keys als wp-config.php Konstanten oder ueber einen verwalteten Secret Store, der beim Boot geladen wird. Setzen Sie niemals Live-Keys in Plugin-Optionen oder .env Dateien, die in ein Repo committet werden.
• Cachen Sie Antworten, gehasht ueber Prompt plus Modellversion. KI-Aufrufe sind teuer und werden haeufig wiederholt.

Fehlerszenarien, gegen die man von Tag eins an entwerfen sollte:

• API-Key Leakage durch Plugin-Auto-Updates oder Backups, die wp-content Dumps enthalten.
• Rate-Limit-Fehler waehrend Traffic-Spitzen, die das Editor-Erlebnis stillschweigend degradieren, wenn es keinen Fallback gibt.
• Halluzinierte Fakten, Zitate oder Produktspezifikationen, die ohne menschlichen Pruefschritt veroeffentlicht werden. Die Kosten einer schlechten Seite in der Suche sind hoeher als die Kosten eines beliebigen Pruef-Workflows.

Wenn 7.0 eine Core-Abilities- oder Connectors-Schicht einfuehrt, gelten dieselben Grenzen: Die API-Oberflaeche aendert sich, die Fehlerszenarien nicht. Fuer Ethik und redaktionelle Rahmen siehe den KI-Content-Ethik-Leitfaden fuer Herausgeber.

#Wie man sich vorbereitet, ohne die Migration zu erraten

Was Sie jetzt tun koennen, ist, die zukuenftigen Migrationskosten unabhaengig davon zu reduzieren, wie 7.0 aussieht. Die Arbeit ist undankbar und zahlt sich bei jedem Release aus, nicht nur bei diesem.

Auditieren Sie die Teile des Stacks, die bei einem grossen Upgrade am wahrscheinlichsten brechen:

• Themes, die noch functions.php Template Tags anstelle von Block Themes verwenden. Konvertieren Sie zu Block Themes oder planen Sie den Aufwand.
• Benutzerdefinierte Gutenberg-Bloecke, die gegen fruehere @wordpress/scripts Versionen gebaut wurden. Pinnen und gegen die neueste stabile Version testen.
• Page Builder mit eigener Rendering-Schicht. Diese sind die haeufigste Ursache von “wir koennen nicht upgraden” Schulden.
• Benutzerdefinierte REST-Endpoints ohne Versionierung. Fuegen Sie jetzt /v1/ Namespacing hinzu, damit ein zukuenftiges Bump nicht-brechend ist.

Richten Sie die langweilige Infrastruktur ein, die Ihnen erlaubt, schnell zu upgraden:

• Eine Staging-Umgebung, die die produktive PHP-Version, Plugin-Set und Inhaltsvolumen widerspiegelt. Datenbank-Paritaet ist wichtiger, als die Leute erwarten.
• Automatisierte Backups mit getestetem Wiederherstellungspfad. Ein ungetestetes Backup ist Theater.
• Plugin- und Theme-Updates, die in regelmaessigem Rhythmus laufen, nicht aufgeschoben bis zur naechsten grossen. Sites, die auf 6.0 feststecken, stecken fest, weil niemand 6.1 bis 6.8 aktualisiert hat.
• Eine kurze Liste von Plugin-Autoren, denen Sie vertrauen, mit E-Mail-Kontakten. Sie werden innerhalb einer Woche wissen wollen, welche Ihrer Plugins gegen 7.0 getestet sind.

Der Upgrade-Pfad ist derselbe, der fuer jedes grosse WordPress-Release funktioniert hat: Erst auf Staging laufen lassen, das Error-Log beobachten, zwei bis vier Wochen nach allgemeiner Verfuegbarkeit warten, bevor man die Produktion fuer Kundensites anfasst, und den offiziellen Field Guide Post auf Make WordPress lesen, bevor man annimmt, dass irgendein Drittanbieter-Leitfaden (dieser eingeschlossen) das widerspiegelt, was tatsaechlich ausgeliefert wurde.

#Was in der 7.0-Release-Woche zu tun ist

Mit dem ausgelieferten 7.0 ist die nuetzliche Arbeit operativ: Staging-Upgrade, Plugin-Kompatibilitaetspruefungen, WooCommerce- und LMS-Flow-Tests sowie ein Rollback-Plan vor Produktion.

Beobachten Sie den Make WordPress Core Blog, Gutenberg Release Notes und den trac-Meilenstein fuer Field-Guide-Aenderungen in letzter Minute. Fuer ein bestehendes Projekt auf 6.x behalten Sie Block Themes, theme.json und die REST API als zukunftskompatible Grundlage.

Wenn Sie Hilfe beim Auditieren eines Stacks auf Upgrade-Bereitschaft wuenschen, unser WordPress-Entwicklungsteam macht diese Arbeit fuer produktive Sites in jedem Release-Zyklus.