WordPress 7.0: Was PHP-Entwickler zur AI API wissen müssen

WordPress 7.0 "Armstrong" ist am 20. Mai 2026 erschienen. Für die WordPress-Community ist es das größte Release seit Jahren. Für PHP-Entwickler, die im Symfony- und Shopware-Ökosystem arbeiten, enthält es eine architektonisch interessante Entscheidung: WordPress bringt eine provider-agnostische AI-API direkt in den Core.

WordPress betreibt laut W3Techs rund 43% aller Websites weltweit. Wenn ein CMS mit dieser Verbreitung eine AI-Abstraktion in den Core integriert, verändert das den Markt. Nicht morgen, aber in 12 bis 18 Monaten, wenn Plugin-Entwickler darauf aufbauen und Kunden AI-Features als Standard erwarten.

Für die technische Einordnung habe ich den offiziellen Dev Note zum WP AI Client und die Developer News ausgewertet. Für die KMU-Nutzer-Perspektive auf WordPress 7.0 hat meine Marke Level Nord einen separaten Artikel veröffentlicht.

Was bringt WordPress 7.0 für Entwickler?

Wie funktioniert der WP AI Client architektonisch?

WordPress 7.0 bringt den WP AI Client als eingebaute PHP-Bibliothek mit. Die Architektur besteht aus zwei Schichten:

PHP AI Client (wordpress/php-ai-client): Ein provider-agnostisches PHP SDK, das als externe Library in Core gebundled ist. Es nutzt camelCase-Methoden und Exceptions. Technisch ist es framework-agnostisch, andere PHP-Projekte könnten es ebenfalls nutzen.

WordPress Wrapper (WP_AI_Client_Prompt_Builder): Umhüllt den PHP AI Client mit WordPress-Konventionen. snake_case-Methoden, WP_Error statt Exceptions, Integration mit WordPress-HTTP-Transport und der Connectors/Settings-Infrastruktur.

// WP AI Client: Provider-agnostischer Prompt (WordPress 7.0)
$prompt = new WP_AI_Client_Prompt_Builder();
$prompt->set_model('gpt-4o');
$prompt->set_system_message('Classify the following product.');
$prompt->add_user_message($product_description);

$result = $prompt->send();
if (is_wp_error($result)) {
// WordPress-typisches Error-Handling
}
$classification = $result->get_text();

Drei offizielle Provider-Plugins sind zum Launch verfügbar: OpenAI, Anthropic und Google. Weitere Provider können über die Connectors API registriert werden.

Wie unterscheidet sich der WP AI Client von Symfony AI?

Der Vergleich ist technisch aufschlussreich, weil beide dasselbe Problem lösen (Provider-Abstraktion für AI-Modelle), aber aus völlig verschiedenen Architekturen kommen.

Was die Dokumentation nicht erwähnt: Die WordPress-Lösung ist bewusst minimal gehalten. Kein Failover, kein Structured Output, kein Event-System für Logging/Cost-Tracking. Das passt zum WordPress-Ansatz: einfach starten, über Plugins erweitern. Aber für Production-Setups, in denen Hochverfügbarkeit und Kostenkontrolle entscheidend sind, fehlt die Infrastruktur.

Wie ich im Symfony AI v0.8 Artikel beschrieben habe, sind Failover und Cost-Tracking die entscheidenden Unterschiede zwischen "AI als Feature" und "AI als verlässliche Infrastruktur".

Interessant für die Community: Der PHP AI Client ist technisch framework-agnostisch. Andere PHP-Projekte könnten ihn theoretisch nutzen. In der Praxis wird das kaum passieren, weil Symfony AI architektonisch weiter ist und das Symfony-Ökosystem eigene Konventionen bevorzugt.

Warum erzeugt PHP 7.2/7.3 Dropping Upgrade-Druck?

WordPress 7.0 erfordert PHP 7.4 als Minimum. Installationen auf PHP 7.2 oder 7.3 bleiben auf WordPress 6.9 und erhalten nur noch Security-Updates, aber keine neuen Features.

Laut WordPress-Telemetrie laufen weniger als 4% der Installationen noch auf PHP 7.2/7.3. Das klingt wenig, sind aber bei der Verbreitung von WordPress Millionen von Websites. Im deutschen Agenturmarkt sind das oft ältere KMU-Projekte, die seit Jahren auf dem gleichen Server laufen.

Für Agenturen, die sowohl WordPress- als auch Symfony-Kunden betreuen, ist das eine Gelegenheit: Das WordPress-7.0-Upgrade kann mit einem PHP-Versionssprung auf 8.4 kombiniert werden. Als PHP-Entwickler mit Fokus auf KMU-Projekte begleite ich solche kombinierten Upgrades regelmäßig.

Was lehrt das Scheitern von Real-Time Collaboration?

Das ursprüngliche Flagship-Feature von WordPress 7.0 war Real-Time Collaboration: Mehrere Nutzer editieren gleichzeitig denselben Beitrag, ähnlich wie in Google Docs. Am 8. Mai 2026 wurde das Feature aus dem Release entfernt und auf WordPress 7.1 (August 2026) verschoben.

Der Grund: Die Datenbank-Architektur für Real-Time-Sync hatte Performance-Probleme, die einen tieferen architektonischen Fix erforderten. Das Release ging sogar vom RC-Status zurück in die Beta-Phase, was in der WordPress-Geschichte beispiellos ist.

WordPress 7.0 liefert stattdessen Block-Level Notes (Kommentare an einzelnen Blöcken) und eine verbesserte Revisions-Vergleichsansicht mit farbcodierter Darstellung (gelb für Änderungen, rot für Löschungen, grün für Ergänzungen). Das sind solide Features, die ohne die Real-Time-Architektur funktionieren.

Zusammenfassung

WP AI Client in Core standardisiert AI-Integration im WordPress-Ökosystem. Provider-agnostisch, aber architektonisch einfacher als Symfony AI (kein Failover, kein Structured Output, kein Cost-Tracking).

PHP 7.2/7.3 dropped. WordPress 7.0 erfordert PHP 7.4, das selbst EOL ist. Sinnvoller Upgrade-Pfad: direkt auf PHP 8.3 oder 8.4.

Real-Time Collaboration verschoben auf 7.1 (August 2026). Architektur-Probleme unter Last. Richtige Entscheidung.

Für Symfony-/Shopware-Agenturen: WordPress 7.0 ist relevant, wenn Sie WordPress-Kunden parallel betreuen. Der AI-Architekturvergleich zeigt, dass Symfony AI für Production-Setups die reifere Lösung ist.