WordPress 7.0 ist da. Einen Monat später als geplant und das war eine gute Entscheidung. Hier steht alles an einem Ort: was sich ändert, warum der Release verschoben wurde und was vor dem Update zu prüfen ist.
Warum 7.0 später kam
Geplant war der Release für April. Dann hat das Team etwas getan, was in der Software-Welt selten passiert: Es hat einen Release, der schon in der Release-Candidate-Phase war, zurück in die Beta geschickt.
Der Grund lag in der Datenbank. Die Real-Time Collaboration, das Flaggschiff-Feature von 7.0, mit dem mehrere Menschen gleichzeitig an einem Beitrag schreiben, speicherte ihre Sync-Daten über post_meta in einem internen Post-Typ. Das funktionierte, schaltete aber die persistenten Post-Query-Caches ab, sobald jemand den Editor offen hatte.
Übersetzt für alle, die nicht in der Datenbank leben: Stell dir eine Bibliothek mit Millionen Büchern und einem sehr schnellen Suchkatalog vor. Das neue Feature machte den Katalog unbrauchbar, solange auch nur ein Mensch am Schreibtisch saß. Auf einem kleinen Blog merkt man das nicht. Auf einer Website mit Traffic wird es zum Performance-Problem.
Die Lösung ist so einfach wie richtig: eine eigene Datenbank-Tabelle für die Collaboration-Daten. Kein Workaround, keine Krücke, kein “das reparieren wir in 7.1”. Am 20. Mai ist 7.0 dann erschienen.
Während viele erklären, dass man jetzt mit KI in einer Stunde Websites baut, verschiebt WordPress einen Release um vier Wochen, damit eine Datenbank-Architektur auch in fünf Jahren noch trägt. Genau diese Art von Entscheidung ist der Grund, warum WordPress seit über 20 Jahren läuft.
Architektur schlägt Geschwindigkeit. Jedes Mal.
Das eigentlich Spannende: wie die KI eingebaut ist
Alle reden über KI. Zu Recht, aber aus dem falschen Grund. Spannend ist nicht, dass KI drin ist, sondern wie sauber sie eingebaut wurde.
Bisher hat jedes KI-Plugin sein eigenes Süppchen gekocht: eigener Schlüssel, eigene Anbindung, eigenes Chaos. Drei Plugins, drei Baustellen. 7.0 bringt einen zentralen Konnektoren-Screen im Backend: ein API-Schlüssel, einmal hinterlegt, von allen kompatiblen Plugins gemeinsam genutzt. Die Anbindung an OpenAI, Google oder Anthropic läuft über eine gemeinsame Ebene im Core statt über jedes Plugin einzeln.
Aufgeräumt statt Wildwuchs, das ist die eigentliche Nachricht.
Und für alle, die “KI überall” befürchten: Nichts passiert von allein. Frisch installiert telefoniert 7.0 nirgendwohin. Nach dem Update gibt es keinen KI-Button, nur einen leeren Konnektoren-Screen. Die eigentlichen Werkzeuge, also Texte, Bilder oder Alt-Texte generieren, stecken in einem eigenen Plugin, das man bewusst installieren muss. Doppeltes Opt-in: Das Fundament liegt, aktiv wird es nur auf Ansage.
Zum Start waren OpenAI, Google und Anthropic direkt anbindbar, weitere Anbieter sind für spätere Versionen angekündigt. Erst das Fundament stabil, dann die Breite.
Was mir beim Testen aufgefallen ist
Für Kundenseiten gilt bei einem großen Release: abwarten, bis die ersten Punkt-Updates durch sind. Auf meinen eigenen Testumgebungen mache ich das Gegenteil. Ich will wissen, wo es hakt, bevor mich jemand danach fragt.
Erfreulich: Die Seiten wurden ein Stück schneller, ohne mein Zutun. WordPress hat zuletzt viel an Datenbank-Abfragen, Caching und Lazy Loading im Core gearbeitet. Tempo kommt inzwischen aus dem Unterbau, nicht mehr aus nachträglichen Eingriffen.
Nicht perfekt: Der Editor zickte am ersten Tag noch mit kleinen Anzeige-Eigenheiten, wie bei jedem großen Release. Nichts Dramatisches, aber genau solche Dinge will ich gesehen haben, bevor sie auf einer Kundenseite auftauchen.
Vor dem Update prüfen
- PHP-Version: 7.0 verlangt mindestens PHP 7.4, PHP 7.2 und 7.3 werden nicht mehr unterstützt. Gut läuft WordPress ab PHP 8.3, für neue Installationen empfiehlt das Hosting-Team von WordPress PHP 8.4 oder 8.5.
- Datenbank: Die Mindestversion bleibt niedrig, sinnvoll ist trotzdem eine aktuelle Version. Empfohlen sind MySQL 8.4 oder MariaDB ab 10.11.
- Automatische Updates: einmal bewusst durchgehen, welche Plugins sich selbst aktualisieren dürfen. Praktisch, solange vorher jemand getestet hat.
- Plugins mit Classic Meta Boxes: Wo WordPress sie erkennt, schaltet es die Real-Time Collaboration für diesen Bereich ab. Kein Fehler, sondern Absicht.
- Anpassungen im Admin: 7.0 verändert den Admin an mehreren Stellen. Eigenes Customizing und Plugins, die dort eingreifen, gezielt testen.
- Backup und Staging: vorher sichern, auf einer Testumgebung ausprobieren, dann erst live.
Mein Rat: Läuft deine Seite stabil, lass sie laufen. Ein, zwei Punkt-Updates abwarten, dann mit Backup und Test aktualisieren.
Mehr als ein neues Feature
Die entscheidende Frage ist nicht mehr, ob eine Website gut aussieht, sondern ob sie die nächsten Entwicklungsschritte aushält. Viele WordPress-Seiten waren nie als System gedacht, eher als Sammlung aus Plugins, Themes und Workarounds, die funktioniert, bis sie es nicht mehr tut.
Mit 7.0 verschiebt sich der Schwerpunkt von “Seite bauen” zu “System betreiben”: mehr Logik im Backend, mehr Abhängigkeiten, mehr Dynamik. Was dann trägt, ist saubere Architektur mit wenigen Abhängigkeiten und klarer Systemlogik.
7.0 macht deine Seite heute nicht hübscher. Es macht sie zukunftsfest. Den Unterschied sieht man nicht, aber man merkt ihn in fünf Jahren.
Quellen: Make WordPress Core, neuer Zeitplan für 7.0 · Make WordPress Hosting, Server-Kompatibilität 7.0
Soll ich sofort auf WordPress 7.0 aktualisieren?
Läuft die Seite stabil, lohnt es sich, ein, zwei Punkt-Updates abzuwarten. Vorher ein Backup anlegen, auf einer Testumgebung prüfen und die PHP-Version kontrollieren.
Welche PHP-Version braucht WordPress 7.0?
Mindestens PHP 7.4. Gut läuft es ab PHP 8.3, für neue Installationen empfiehlt das Hosting-Team von WordPress PHP 8.4 oder 8.5.
Schaltet WordPress 7.0 automatisch KI-Funktionen ein?
Nein. Nach dem Update gibt es nur einen leeren Konnektoren-Screen. KI-Funktionen laufen erst, wenn ein API-Schlüssel hinterlegt und ein passendes Plugin installiert ist.
Warum kam WordPress 7.0 später als geplant?
Die neue Echtzeit-Zusammenarbeit im Editor hätte auf Seiten mit Traffic die Datenbank-Caches ausgebremst. Das Team hat dafür eine eigene Datenbank-Tabelle gebaut, statt das Problem später zu flicken.