WordPress 7.0 Armstrong: KI-Infrastruktur und Abilities API

Update, 23. Mai 2026: WordPress 7.0 mit dem Codenamen Armstrong ist ausgeliefert. Das Release schließt Phase 3 der Gutenberg-Roadmap mit grundlegender KI-Infrastruktur ab (Abilities API + AI Services Registry + AI Client), bringt ein modernisiertes Dashboard, die Command Palette überall, benutzerdefiniertes CSS auf Block-Ebene und den Icons-Block. Echtzeit-Zusammenarbeit wurde während der RC-Tests entfernt und ist in 7.0 nicht enthalten. Dieser Leitfaden ist die Zusammenfassung nach dem Release; ältere 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 länger als gewöhnlich dauernden Release-Candidate-Zyklus ausgeliefert. Das Release wurde von mehr als 900 Contributoren gebaut. Die Schlagzeilen-Änderung ist KI-Infrastruktur im Core: die Abilities-API-Oberfläche für sichere Admin-Operationen, die AI Services Registry für die Integration gehosteter Modelle und der WordPress AI Client, um den sich Drittanbieter-Plugins jetzt standardisieren. Ein modernisiertes Admin-Dashboard, die Command Palette überall in wp-admin, benutzerdefiniertes CSS auf Block-Ebene und der Icons-Block sind ebenfalls ausgeliefert worden. Echtzeit-Zusammenarbeit wurde während der RC-Tests aus diesem Release entfernt und ist nicht Teil des Upgrades.

Eine schärfere Polemik dazu, was die 7.0-KI-Oberfläche für Plugin-Autoren konkret bedeutet, finden Sie in unserem Beitrag dazu, warum ein MCP-Server in Ihrem WordPress-Plugin der KI-Zug ist, der überlebt. Für die Sicherheitsimplikation nach dem Release lesen Sie unsere Analyse des GuardingWP State of WordPress Security 2026 Reports, die die neue KI-Schlüssel-Oberfläche in Kontext mit dem 53-Prozent-Baseline ungepatchter CVEs setzt.

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

Erfahren Sie mehr über 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 ungewöhnlich 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 Kompatibilitätsprobleme einfängt.

#Was tatsächlich in 7.0 Armstrong ausgeliefert wurde

Dies ist die bestätigte Funktionsliste aus der wordpress.org-Release-Ankündigung, nicht die frühere Roadmap-Absicht. Alles auf der älteren Roadmap, was hier fehlt, ist nicht in 7.0 ausgeliefert worden.

• KI-Infrastruktur im Core. Die Abilities API für sichere Admin-Operationen über strukturierte Intents, die AI Services Registry für 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 Plattformänderung, die das Release definiert.
• Command Palette überall. Cmd-K / Ctrl-K öffnet die Command Palette auf jedem wp-admin-Bildschirm, nicht nur im Block-Editor. Die Tastatur-Oberfläche für Power-User ist jetzt erstklassig.
• Benutzerdefiniertes CSS auf Block-Ebene. Jeder Block kann sein eigenes CSS tragen, beschränkt 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-Oberflächen, mit den Agentic-KI-Experimenten hinter einer Feature-Flag sichtbar.
• PHP 7.4 als Mindestlaufzeit. Websites, die noch auf älterem PHP laufen, müssen 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 unterstützt haben” - das ist die ehrlichste Zeile, die seit Jahren über 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 frühere Roadmap-Beschreibung weiter unten in diesem Leitfaden bleibt als historischer Kontext erhalten.

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

Patchstack-Gründer Oliver Sild postete öffentlich 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 lässt einem Angreifer nicht mehr nur die Inhalte ändern; er lässt ihn auch eine vier- oder fünfstellige monatliche Token-Rechnung gegen Ihren KI-Anbieter abdrehen, bevor die Rechnung das einfängt. Justin Nealey hat separat darauf hingewiesen, dass der WP AI Client keine eingebaute Drosselung hat und mehrere Plugins, die sich einen Schlüssel teilen, das Token-Limit in unter einer Minute aufbrauchen können.

Die anzuwendende Kontrolloberfläche ist einfach und dieselbe Kontrolloberfläche, die ein Finanzteam auf jeden neu ausgestellten abrechnungsfähigen Credential anwenden würde:

• API-Schlüssel pro Connector skopieren, nicht pro Website. Ein Schlüssel pro Anbieter pro Connector. Rotieren in einer veröffentlichten Kadenz.
• Rate-Limits am Gateway anwenden, nicht im Plugin. Wenn Ihr Anbieter Per-Schlüssel-Rate-Limits unterstützt (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 tägliche Abrechnungs-API zur Verfügung; 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 regulären wp-admin-Audit-Log.

Für 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 für in den Geltungsbereich fallende Einheiten verlangt werden. Behandeln Sie die neue KI-Oberfläche 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 Fähigkeiten bringen, was bedeutet, dass WordPress endlich Inhaltsübersetzung auf Core-Ebene handhaben wird, statt sich auf Plugins wie WPML oder Polylang zu verlassen. Für 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 verfügbar, in produktivem WordPress:

• Yoast und Rank Math liefern beide KI-unterstützte Schreibhelfer (Titel, Meta-Beschreibungen, interne Linkvorschläge), die auf Modell-APIs von Drittanbietern basieren.
• Jetpack AI Assistant bietet In-Editor-Generierung, Zusammenfassung und Übersetzung. Die Qualität variiert nach Sprache und Prompt.
• Eigenständige Content-Generierungs-Plugins existieren in einer breiten Qualitätsspanne; nützlich für Entwürfe, gefährlich, wenn direkt an die Veröffentlichung ohne menschliche Prüfung verdrahtet.
• Automattic und Beitragsteams führen Phase-3-Experimente durch, einschließlich kollaborativer Bearbeitung und editorseitiger KI-Aufrufe, im Gutenberg-Plugin vor jedem Merge in den Core.

Eine pragmatische Architektur für das Hinzufügen von KI zu einer WordPress-Site heute, die wahrscheinlich überleben 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 Konfigurationsänderung 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 über 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 über Prompt plus Modellversion. KI-Aufrufe sind teuer und werden häufig 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 während Traffic-Spitzen, die das Editor-Erlebnis stillschweigend degradieren, wenn es keinen Fallback gibt.
• Halluzinierte Fakten, Zitate oder Produktspezifikationen, die ohne menschlichen Prüfschritt veröffentlicht werden. Die Kosten einer schlechten Seite in der Suche sind höher als die Kosten eines beliebigen Prüf-Workflows.

Wenn 7.0 eine Core-Abilities- oder Connectors-Schicht einführt, gelten dieselben Grenzen: Die API-Oberfläche ändert sich, die Fehlerszenarien nicht. Für Ethik und redaktionelle Rahmen siehe den KI-Content-Ethik-Leitfaden für Herausgeber.

#Wie man sich vorbereitet, ohne die Migration zu erraten

Was Sie jetzt tun können, ist, die zukünftigen Migrationskosten unabhängig 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 großen 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-Blöcke, die gegen frühere @wordpress/scripts Versionen gebaut wurden. Pinnen und gegen die neueste stabile Version testen.
• Page Builder mit eigener Rendering-Schicht. Diese sind die häufigste Ursache von “wir können nicht upgraden” Schulden.
• Benutzerdefinierte REST-Endpoints ohne Versionierung. Fügen Sie jetzt /v1/ Namespacing hinzu, damit ein zukünftiges 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-Parität ist wichtiger, als die Leute erwarten.
• Automatisierte Backups mit getestetem Wiederherstellungspfad. Ein ungetestetes Backup ist Theater.
• Plugin- und Theme-Updates, die in regelmäßigem Rhythmus laufen, nicht aufgeschoben bis zur nächsten großen. 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 für jedes große WordPress-Release funktioniert hat: Erst auf Staging laufen lassen, das Error-Log beobachten, zwei bis vier Wochen nach allgemeiner Verfügbarkeit warten, bevor man die Produktion für Kundensites anfasst, und den offiziellen Field Guide Post auf Make WordPress lesen, bevor man annimmt, dass irgendein Drittanbieter-Leitfaden (dieser eingeschlossen) das widerspiegelt, was tatsächlich ausgeliefert wurde.

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

Mit dem ausgelieferten 7.0 ist die nützliche Arbeit operativ: Staging-Upgrade, Plugin-Kompatibilitätsprüfungen, 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 für Field-Guide-Änderungen in letzter Minute. Für 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 wünschen, unser WordPress-Entwicklungsteam macht diese Arbeit für produktive Sites in jedem Release-Zyklus.