WordPress 7.0 wurde am 20. Mai 2026 veröffentlicht – nach einer fünfwöchigen Verzögerung und einer Entscheidung, die das Vorzeigefeature nur wenige Tage vor dem Release strich. Bei WATA Factory betreiben wir WordPress parallel zu unseren PHP-, Symfony- und Angular-Projekten für Kunden in Spanien und Deutschland. Ein großes Core-Release bedeutet für uns also Staging-Umgebungen, Plugin-Audits und ein paar späte Abende, bevor wir irgendetwas an einer Live-Seite anfassen. Hier ist, was tatsächlich ausgeliefert wurde, was gestrichen wurde und was ihr vor einem Update einer Kunden-Website prüfen solltet.
Was WordPress 7.0 tatsächlich mitbringt
WordPress 7.0, intern während der Entwicklung als „Armstrong“ bezeichnet, kam nach der Verschiebung des Release-Termins durch das Core-Team von ursprünglich 9. April auf 20. Mai. Die zusätzlichen fünf Wochen flossen in die Stabilisierung der Datenschicht hinter einem Feature, das es am Ende nicht ins Release geschafft hat. Dazu weiter unten mehr.
Was tatsächlich kam: eine neue KI-Infrastrukturebene, eine neu gestaltete Admin-Oberfläche auf Basis eines React-basierten Systems namens DataViews, einige neue Blöcke sowie eine angehobene PHP-Mindestanforderung. Nichts davon ist so auffällig wie es Echtzeit-Co-Editing gewesen wäre, aber es ist die Art von Release, die verändert, wie Plugins und Themes in den nächsten zwei bis drei Jahren gebaut werden – nicht, wie ein einzelner Beitrag nächste Woche aussieht.
Für Agenturen lautet die eigentliche Frage nicht „Was ist neu?“, sondern „Was bricht?“. Introduction to WordPress page builders beleuchtet einige der tiefergehenden Editor-Änderungen, die wir über die letzten WordPress-Versionen hinweg verfolgt haben, und dieselbe Logik gilt auch hier: Alles, was tief in den Block-Editor, die Admin-Listentabellen oder das Post-Locking eingreift, braucht einen ordentlichen Testdurchlauf, bevor 7.0 in die Nähe einer Produktivumgebung kommt.
PHP 7.4 ist die neue Untergrenze, nicht die Obergrenze
WordPress 7.0 streicht die Unterstützung für PHP 7.2 und 7.3. Die Mindestanforderung liegt jetzt bei PHP 7.4, wobei das Core-Team PHP 8.2 oder neuer für Websites empfiehlt, denen Performance und Sicherheits-Patches wichtig sind – was auf jede Website zutreffen sollte.
Das klingt nach einer Fußnote, bis man selbst dreißig Kundenkonten auf Shared Hosting verwaltet, von denen einige vor Jahren auf „Serverstandard übernehmen“ eingestellt und seitdem nie wieder angefasst wurden. Läuft der Stack eines Kunden noch auf 7.2 oder 7.3, ist das Update auf WordPress 7.0 keine Kür mehr, sondern ein Blocker. Das Update schlägt entweder komplett fehl oder läuft in einem kaputten, nicht unterstützten Zustand.
Unser Rat an Kunden hat sich seit Jahren nicht geändert: die PHP-Version explizit prüfen, „Serverstandard übernehmen“ nicht blind vertrauen, und zuerst auf einer Staging-Kopie testen. Es ist dieselbe Disziplin, die wir auch bei unseren eigenen PHP- und Symfony-Projekten anwenden – nur eben mit einem WordPress-Dashboard statt einer Deployment-Pipeline.
Der WP AI Client und die Abilities API
Das ist der Teil von 7.0, der für alle, die Plugins oder Themes entwickeln, am meisten zählt – auch wenn die meisten Website-Betreiber davon nie etwas bemerken werden.
WordPress 7.0 führt den WP AI Client ein, eine in den Core integrierte PHP-API, die Plugins einen einheitlichen Weg gibt, mit externen KI-Modellen zu kommunizieren, ohne für jeden Anbieter eine eigene Integration schreiben zu müssen. Entwickler rufen eine einzige Funktion auf, wp_ai_client_prompt(), und WordPress übernimmt die Übersetzung zu dem jeweiligen Anbieter, den der Website-Betreiber verbunden hat. Es gibt einen neuen Connectors-Bildschirm unter Einstellungen, auf dem Website-Betreiber einen Anbieter auswählen können, wobei OpenAI, Google Gemini und Anthropic Claude als vorregistrierte Optionen zur Verfügung stehen. Solange niemand explizit ein Modell verbindet, kommuniziert nichts mit einem externen Modell.
Daneben steht die Abilities API, die es Plugins und Themes ermöglicht, ihre Fähigkeiten in einem Format zu registrieren, das sowohl Menschen als auch KI-Agenten lesen können. In der Praxis bedeutet das: Ein Plugin kann „einen Entwurfsbeitrag erstellen“ oder „dieses Bild verkleinern“ als strukturierte Fähigkeit bereitstellen, statt als eine Kette bedingter Logik, die ein KI-Assistent erraten muss.
Für Entwickler, die es gewohnt sind, maßgeschneiderte KI-Funktionen Plugin für Plugin zu bauen, lohnt sich hier die gründliche Lektüre der Developer Notes. Für eine Website, die keinen Anbieter verbindet, ändert sich nichts – aber für diejenigen, die es tun, verschiebt sich die Verantwortung für die Integrationsschicht.
DataViews, die Command Palette und ein leiseres Admin-Redesign
Die Admin-Überarbeitung in 7.0 ist kein bloßer Anstrich. DataViews ersetzt die alten, PHP-gerenderten Listentabellen für Beiträge, Seiten, Medien und Benutzer durch eine React-basierte Oberfläche, die filtert, sortiert und Massenbearbeitungen durchführt, ohne die Seite komplett neu zu laden. Wer schon einmal miterlebt hat, wie ein Kunde darauf wartet, dass eine Listentabelle nach einer Filteränderung neu lädt, bekommt hier die Lösung.
Die Command Palette (Cmd-K bzw. Strg-K) funktioniert jetzt auf jedem wp-admin-Bildschirm statt nur im Block-Editor – was mehr ausmacht, als es zunächst klingt, sobald man sich daran gewöhnt hat. Dazu kommen blockbasiertes benutzerdefiniertes CSS und ein paar neue Blöcke für Breadcrumbs und Icons. In der Summe wirkt der Admin-Bereich weniger wie 2013, ohne dass jemand neu lernen müsste, wo was zu finden ist.
Nichts davon erfordert zwangsläufig Plugin-Anpassungen, aber alles, was eigenes JavaScript in die alten Listentabellen einschleust – Page Builder eingeschlossen – sollte vor einem Update bei Kunden gegen die neuen DataViews-Bildschirme geprüft werden.
Echtzeit-Zusammenarbeit: gebaut, getestet, dann zurückgezogen
Das ist die Schlagzeile, die es nicht gegeben hat. Echtzeit-Zusammenarbeit – das Feature im Stil von Google Docs, mit dem mehrere Personen gleichzeitig denselben Beitrag hätten bearbeiten können – sollte das Herzstück von WordPress 7.0 sein und der offizielle Meilenstein für Phase 3 der Gutenberg-Roadmap.
Am 8. Mai, zwölf Tage vor dem Release, traf WordPress-Lead Matt Mullenweg die Entscheidung, es zu streichen. Die genannten Gründe waren konkret: Angriffsfläche, Race Conditions, Serverlast, Speichereffizienz und Bugs, die beim Fuzz-Testing immer wieder auftauchten. Statt ein Feature auszuliefern, das unter diesen Bedingungen live Inhalte berührt, strich das Team es und brachte den Rest des Releases wie geplant heraus.
Wer schon einen Kunden hatte, der nach Live-Co-Editing gefragt hat, weil er irgendwo von WordPress 7.0 gelesen hat: Die ehrliche Antwort lautet, dass es das noch nicht gibt und es kein bestätigtes Datum dafür gibt, wann es kommt. Wir sagen das einem Kunden lieber gleich, als ein Feature zu versprechen, das zwölf Tage vor dem Launch gestrichen wurde.
Eine praktische Checkliste, bevor ihr eine Kunden-Website anfasst
Ein großes Core-Release ist Routinearbeit, wenn man es so behandelt. Bevor ihr eine Kundeninstallation auf WordPress 7.0 aktualisiert:
- Prüft die PHP-Version explizit. Verlasst euch nicht auf die „Serverstandard übernehmen“-Einstellung des Hosts; kontrolliert sie in cPanel oder per php -v.
- Testet Page Builder und editorlastige Plugins zuerst auf Staging, insbesondere alles, was den Block-Editor oder die alten Admin-Listentabellen anpasst.
- Lasst eure bestehende automatisierte Testsuite gegen die Staging-Kopie laufen, bevor ihr sie live schaltet. Falls ihr noch keine habt, ist das Abwägen von Vor- und Nachteilen automatisierter Tests ein sinnvoller Einstieg in dieses Gespräch mit einem Kunden.
- Lasst KI-Connectoren getrennt, bis ihr geprüft habt, was jedes verbundene Plugin über die Abilities API tatsächlich tun kann.
- Sichert vor dem Update immer eine Datensicherung, ausnahmslos, egal wie routinemäßig das Release wirkt.
Wir betreiben den Großteil unseres eigenen Stagings über einen Docker-basierten WordPress-Entwicklungsworkflow, der es einfach macht, eine Wegwerf-Kopie einer Kunden-Website hochzufahren, das Update zu testen und den Container bei Problemen einfach zu verwerfen.
FAQ
Ist es sicher, WordPress 7.0 jetzt auf einer Live-Kunden-Website zu installieren?
Ja, die stabile Version ist am 20. Mai 2026 erschienen, aber „sicher“ heißt weiterhin: zuerst auf Staging testen, genau wie bei jedem größeren Core-Update.
Erfordert WordPress 7.0 ein PHP-Upgrade?
Die harte Untergrenze ist PHP 7.4. Alles darunter lässt 7.0 nicht korrekt laufen. Empfohlen wird PHP 8.2 oder neuer.
Kommt Echtzeit-Zusammenarbeit in einem zukünftigen WordPress-Release?
Das Core-Team hat kein Datum genannt. Sie wurde aus Stabilitätsgründen aus 7.0 gestrichen und bleibt ein offener Punkt für ein späteres Release.
Muss ich einen KI-Anbieter verbinden, um WordPress 7.0 zu nutzen?
Nein. Der Connectors-Bildschirm und der WP AI Client sind additiv. Eine Website ohne verbundenen Anbieter verhält sich exakt so wie vor dem Update.
Funktioniert mein Page Builder nach dem Upgrade auf WordPress 7.0 noch?
Die meisten sollten funktionieren, aber alles, was den Block-Editor oder die alten Admin-Listentabellen anpasst, braucht einen Staging-Test, da DataViews verändert, wie diese Bildschirme gerendert werden.
Was ist der häufigste Grund, warum ein WordPress-7.0-Update auf Kunden-Websites fehlschlägt?
Unserer Erfahrung nach eine veraltete PHP-Version, die niemand vor dem Klick auf „Aktualisieren“ geprüft hat. Das lässt sich vermeiden, und es ist das Erste, was sich zu prüfen lohnt.
Zusammenfassung
WordPress 7.0 ist ein entwicklerorientiertes Release im frischen Admin-Gewand. Der AI Client und die Abilities API schaffen eine Infrastruktur, auf der Plugin-Autoren noch jahrelang aufbauen werden, DataViews und die Command Palette machen die Arbeit im Admin-Bereich spürbar schneller, und die PHP-7.4-Untergrenze wird still und leise die eine oder andere vergessene Hosting-Konfiguration lahmlegen. Echtzeit-Zusammenarbeit, das Feature, auf das alle gewartet haben, hat es nicht geschafft, und es gibt keinen festen Zeitplan, wann es kommt.
Für Agenturen ist all das kein Grund, ein Update zu überstürzen oder es zu vermeiden. Es ist ein Grund, PHP-Versionen ordentlich zu prüfen, auf Staging zu testen und ein großes Core-Release so zu behandeln wie jedes andere Produktiv-Deployment. Wenn ihr Unterstützung bei der Prüfung einer WordPress-Installation vor dem nächsten großen Update wollt, meldet euch bei unserem Team.
