WordPress 7.0 : Infrastruktur statt Features

Liest man die ersten Berichte zu WordPress 7.0, ergibt sich ein vertrautes Bild: modernes Dashboard, Command Palette, neue Blocks, einige Verbesserungen für mobile Ansichten. Das ist nicht falsch, aber es greift zu kurz. „Armstrong", wie die am 20. Mai 2026 erschienene Version offiziell heißt, ist die strukturellste Umstellung am WordPress-Core seit der Einführung von Gutenberg. Drei Achsen verschieben sich gleichzeitig, und jede für sich hätte eine eigene Schlagzeile verdient.

Die KI bekommt ein offizielles Zuhause im Core, nicht als Feature, sondern als Schnittstelle. Die Abilities API positioniert WordPress als Knoten in der wachsenden Welt agentischer Systeme. Und die Block-Entwicklung verlagert sich leise zurück Richtung PHP, eine Korrektur der jahrelangen React-Verengung, die viele Entwickler aus dem System gedrängt hatte.

Was Sie ab dem ersten Login sehen, ist die sichtbare Spitze. Der strategische Teil läuft unter der Haube.

Die zentrale Neuerung ist der WP AI Client: ein einheitliches Interface, über das Plugins mit generativen KI-Modellen kommunizieren. Wichtig dabei: WordPress selbst stellt keine KI-Verbindung her. Was es bringt, ist Routing, Konfiguration und eine standardisierte Sprache. Welcher Provider tatsächlich antwortet, entscheidet der Betreiber im neuen Bereich Einstellungen > Connectors.

Vorgesehen sind zunächst drei offizielle Connector-Pfade für Anthropic, Google und OpenAI. Im Core selbst sind die Provider nicht enthalten; ihre Anbindung läuft über Connector- und Provider-Plugins. Eigene Verbindungen lassen sich konfigurieren, sowohl per API-Key als auch ohne Authentifizierung, etwa für selbstgehostete Modelle. Plugin-Entwickler nutzen using_model_preference(), um Modell-Vorlieben anzugeben, und eine WP_AI_Client_Prompt_Builder-Klasse für die Erstellung der Anfragen. Was die Connectors API leistet, ist also nicht KI-Magie. Sie sorgt für eine saubere Trennung zwischen Anfrage und Anbieter.

Das hat Konsequenzen, die über das Technische hinausgehen. Bisher war jeder KI-Einsatz in WordPress eine Plugin-Frage. Jedes Marketing-Tool, jeder SEO-Helfer, jeder Content-Assistent brachte seine eigene Anbindung mit, oft an einen einzigen Anbieter. Wer als Verbandsbetreiber oder Mittelständler den Überblick behalten wollte, welche Inhalte wohin geflossen sind, hatte keine Chance.

Mit dem Connectors-Modell liegt diese Entscheidung erstmals zentral beim Betreiber. Wer welchen Provider zulässt, ist ab 7.0 eine Konfigurationsfrage, keine Plugin-Wahl mehr. Diese Sovereignty-Komponente wird in vielen schnellen Release-Übersichten unterschätzt. Für jede Organisation, die ihre Daten ernst nimmt, ist sie das eigentliche Argument für ein bewusstes Umrüsten.

Die zweite Achse ist subtiler und weitreichender. Die Abilities API kam bereits mit WordPress 6.9 in den Core; 7.0 ergänzt sie um eine clientseitige JavaScript-Schicht, die sie direkt in den agentischen Kontext einklinkt. Die API erlaubt Plugins, ihre Fähigkeiten zu registrieren und maschinenlesbar zu beschreiben. Ein Newsletter-Plugin meldet die Fähigkeit, Empfänger zu einer Liste hinzuzufügen. Ein Termin-Plugin meldet, freie Termine im Kalender zu finden. Ein CRM-Anschluss meldet, Kontakte mit Quellenangabe anzulegen. Was bisher in Plugin-Dokumentationen vergraben war, wird zu einer abfragbaren Schnittstelle.

Für Menschen ist das eine Randnotiz. Für KI-Assistenten und Agenten ist es die Tür. Eine Fähigkeit, die registriert ist, kann angesteuert werden. Genau dieses Prinzip steht hinter dem Model Context Protocol, das große KI-Anbieter inzwischen unterstützen, und nach demselben Muster funktioniert auch die kommende Agent-to-Agent-Kommunikation. WordPress positioniert sich mit der Abilities API still als kompatibler Knoten in dieser Topologie.

Die Implementierung kommt in zwei Paketen. @wordpress/core-abilities lädt server- und client-seitige Fähigkeiten gemeinsam, @wordpress/abilities nur den Client-Teil. Fähigkeiten sind kategorisierbar, lassen sich filtern und über die REST-API abrufen. Auch das Abmelden ist möglich, was für Sicherheits- und Compliance-Setups wichtig ist.

Was das in der Praxis heißt: Ein WordPress-System, das heute „nur" eine Verbandswebsite betreibt, kann morgen Teil eines automatisierten Workflows sein, in dem ein KI-Agent Anfragen kategorisiert, Termine vorschlägt, Newsletter triggert. Vorausgesetzt, die nötigen Abilities sind registriert. Wer jetzt aufpasst, ob die eigenen Plugins und individuellen Funktionen mit Abilities annotieren, ist später anschlussfähig. Wer es ignoriert, baut heute eine Website, die morgen schwerer ansprechbar ist.

Die dritte Achse ist die unauffälligste, hat aber für Entwicklungsteams und Agenturen die handfestesten Folgen. WordPress 7.0 öffnet das Block-System wieder für PHP-orientierte Entwicklung. Drei Bausteine wirken zusammen:

Erstens die PHP-only Block-Registrierung mit autoRegister, die wir an anderer Stelle ausführlich beschrieben haben. Sie erlaubt es, einfache Blöcke vollständig serverseitig zu definieren, ohne block.json, ohne Build-Prozess, ohne eine eigene Zeile JavaScript.

Zweitens die Refaktorisierung von @wordpress/scripts. Der bisherige Build-Mechanismus war eng an Webpack gekoppelt, was bedeutete: Wer einen Block bauen wollte, hatte eine vollständige Node-Toolchain im Schlepptau. In 7.0 baut @wordpress/scripts aus Verzeichnisstrukturen heraus und reduziert die Webpack-Abhängigkeit deutlich. Für viele einfache Fälle ist Webpack damit optional, nicht mehr zwingend.

Drittens @wordpress/boot, ein neues Paket, das Plugins eigene Site-Editor-Seiten ermöglicht, mit Route-Validierung und einem klaren Erweiterungsmodell. Das war bisher ein Bastelfeld; jetzt ist es vorgesehene Schnittstelle.

Die Summe dieser drei Bausteine ist eine leise Korrektur der jahrelangen React-Verengung. WordPress war auf gutem Weg, sich aus der Reichweite klassischer PHP-Entwickler zu entfernen. 7.0 dreht das nicht zurück, aber öffnet eine zweite Spur. Wer in PHP zuhause ist, hat wieder einen vollständigen Pfad ohne Umweg durch eine JavaScript-Welt.

Auf der sichtbaren Seite gibt es eine ganze Reihe nützlicher Verbesserungen. Das neue Admin-Theme „Modern" wirkt klarer und kontrastreicher. Die Command Palette ist nun mit ⌘K oder Strg-K aus dem gesamten Backend erreichbar. Visual Revisions erlauben den direkten Vergleich zweier Versionen per Slider, ohne in einen separaten Vergleichsbildschirm wechseln zu müssen. Block Visibility nach Gerätetyp ersetzt das, was Theme-Entwickler bisher per CSS gelöst haben. Custom CSS pro Block reduziert den Bedarf an theme-weiten Overrides. Neue Blocks kommen hinzu: Heading, Breadcrumbs und Icons.

Bemerkenswerter ist, was nicht enthalten ist. Die seit langem angekündigte Echtzeit-Kollaboration wurde vor dem Release entfernt und neu bewertet. Aus Sicht von Verbänden und mittelständischen Unternehmen ist das die richtige Entscheidung. Eine halbgare Live-Sync-Funktion wäre für ernsthafte redaktionelle Workflows ein Risiko, kein Feature. Lieber kein Feature als ein instabiles.

Auf der Sicherheitsseite hat das Core-Team eine vorsichtige, aber wichtige Änderung gemacht: Administrator- und Editor-Rollen sind aus dem Default-Selector für neue Benutzer entfernt. Wer sich registriert, bekommt nicht mehr versehentlich Zugriffsrechte, die Inhalte verändern können. Site Health warnt bei bestehenden Installationen, die noch alte Defaults nutzen.

Migrations-Updates sind in WordPress meist unkritisch. Wer eine gepflegte Installation mit aktuellem PHP betreibt (Mindestanforderung ist nun PHP 7.4), wird beim Update auf 7.0 wenige Probleme haben. Die echten Fragen liegen woanders.

Provider-Sovereignty entscheidet sich jetzt. Mit der Connectors-Architektur können Betreiber zum ersten Mal zentral festlegen, welche KI-Anbieter Zugang zu welchen Daten bekommen. Wer diese Konfiguration früh trifft und sie auch in eigene Plugins und Anbindungen einarbeitet, wird in zwei Jahren nicht in einer chaotischen Plugin-zu-Provider-Landschaft stehen. Wer wartet, baut sich diese Komplexität auf.

Was heute „nur" die Andockstelle für KI-Funktionen ist, wird sich in den nächsten zwei Jahren zur Standard-Schnittstelle für agentische Workflows entwickeln. Plugins, die Abilities sauber registrieren, sind anschlussfähig. Solche, die es nicht tun, müssen ihre Hintertüren öffnen, mit allen Risiken. Für Eigenentwicklungen, etwa verbandsspezifische Workflows oder branchenspezifische Funktionen, sollte die Abilities-Annotation ab sofort Standard sein.

Wer Eigenentwicklungen bisher mangels JavaScript-Kompetenz ausgelagert hat, kann ab 7.0 mehr im Haus halten. Das senkt die Gesamtkosten und verkürzt die Reaktionszeit auf Änderungswünsche. Gleichzeitig bleibt React der richtige Weg für komplexe, interaktive Editor-Komponenten. Es geht nicht mehr um „PHP oder React". Es geht um den richtigen Weg für die jeweilige Aufgabe.

Das Update selbst ist also nicht der Punkt. WordPress 7.0 zu installieren ist eine Routine-Aufgabe. Zu entscheiden, welche KI-Provider erlaubt sind, welche Abilities die eigenen Plugins exponieren sollen und wo der PHP-Pfad lohnt: das sind die Fragen, die die nächsten zwei Jahre prägen. Wer sie jetzt klärt, ist später entspannter.