WordPress 7.0 und 7.1 in der Praxis: Was wirklich hakt
WordPress 7.0 ist seit dem 20. Mai 2026 draußen, WordPress 7.1 seit dem 19. August 2026. Dieser Beitrag ist der Erfahrungsbericht aus vier Monaten Praxis: was gut funktioniert, was bricht und warum die eigentliche Baustelle inzwischen 7.1 heißt.
Vor dem Release habe ich hier eine Vorschau auf WordPress 7.0 geschrieben. Die muss ich in zwei Punkten korrigieren und das ist der ehrlichere Teil dieses Beitrags. Die Echtzeit-Kollaboration kam nicht und die Version, über die wir eigentlich reden müssten, ist längst eine andere.
Denn 7.0 hatte einen kurzen Sommer. Vier Sicherheitsupdates in vier Wochen, teils mit erzwungenen automatischen Aktualisierungen, dann am 19. August 2026 schon WordPress 7.1 mit dem Codenamen Mary Lou.
Ich betreue als Digitalagentur eine Reihe von WordPress-Installationen für kleine und mittlere Unternehmen. Der Blick hier ist deshalb der eines Betreuers und nicht der eines Testers: Was kostet dieses Update Zeit und wo muss man aufpassen?
Läuft überhaupt noch jemand auf 7.0?
Nur ein kleiner Teil. Nach den offiziellen Statistiken von WordPress.org liegt 7.0 bei rund 14 Prozent aller erfassten Installationen, während 7.1 schon bei rund 54 Prozent steht. Der gesamte 7er-Zweig kommt auf gut 68 Prozent.
Diese ungewöhnliche Verteilung hat einen Grund. Am 17. Juli 2026 erschien 7.0.2 mit einer SQL-Injection und einer Lücke in der REST-API, die bis zur Codeausführung reichen konnte. Wegen der Schwere wurden automatische Updates erzwungen.
Danach ging es weiter: 7.0.3 am 6. August mit elf Sicherheitsproblemen, 7.0.4 am 12. August mit einer Lücke in der Bildverarbeitung über Imagick und Ghostscript. Wer automatische Updates aktiviert hat, ist längst auf 7.1.
Was 7.0 im Adminbereich tatsächlich gebracht hat
Der Adminbereich hat ein neues Farbschema namens Modern bekommen, mit besserem Kontrast und überarbeiteter Typografie. Dazu kamen weiche Übergänge zwischen den Adminseiten, die die Systemeinstellung für reduzierte Bewegung respektieren.
Die größte Alltagsverbesserung ist für mich die Befehlspalette, die jetzt im gesamten Admin über Strg K oder Cmd K erreichbar ist. Wer viel im Backend arbeitet, spart damit messbar Klicks.
Praktisch für Kundenprojekte sind zwei weitere Punkte. Die Font Library ist jetzt eine eigene Seite und funktioniert für alle Themes, nicht mehr nur für Block Themes. Und die Revisionen lassen sich über einen Schieberegler visuell vergleichen und per Klick zurückholen.
Dazu kamen neue Blöcke für Breadcrumbs, Icons und aufklappbare Details, eine Icon-Bibliothek mit über 500 SVG-Symbolen im Kern sowie die Möglichkeit, einzelne Blöcke je nach Gerätetyp ein- und auszublenden.
Nicht 7.0 ist der kritische Schritt, sondern 7.1 mit dem erzwungenen Iframe-Editor.
Der eine Fehler, der Bestandsseiten wirklich trifft
Es gibt genau eine offene Regression mit echter Praxisrelevanz und sie betrifft Classic Themes. Themes ohne theme.json und ohne Unterstützung für Editor-Styles verlieren im Beitragseditor die Standardformatierung.
Statt der Systemschrift in 18 Pixel mit großzügiger Zeilenhöhe greifen plötzlich die Browser-Voreinstellungen, also Serifenschrift in 16 Pixel. Der Beitrag sieht im Editor völlig anders aus als im Frontend, was beim Schreiben massiv stört.
Das Problem ist im Gutenberg-Projekt als Fehler dokumentiert und bis heute offen. Es ist außerdem die Wiederkehr eines Bugs aus dem Jahr 2022. Reparieren lässt es sich im Theme mit einer Zeile Unterstützung für Editor-Styles und einer eigenen Stylesheet-Datei.
Barrierefreiheit ist der unterschätzte Teil
In 7.0 stecken 24 Verbesserungen zur Barrierefreiheit im Kern und 16 weitere im Blockeditor. Das Projekt hat sich dabei ausdrücklich WCAG 2.2 Stufe AA als Ziel für neuen und geänderten Code gesetzt.
Konkret heißt das unter anderem: Die Medienbibliothek lässt sich per Spracheingabe bedienen, Alt-Texte werden aus den Metadaten eines Bildes übernommen, Kontraste wurden nachgezogen und überflüssige Mehrfachlinks entfernt.
Das ist der Teil des Releases, über den niemand schreibt, weil er sich schlecht bebildern lässt. Für Betreiber, die wegen des Barrierefreiheitsstärkungsgesetzes ohnehin nachbessern müssen, nimmt er trotzdem Arbeit ab.
Warum die Kollaboration fehlt
Die Echtzeit-Kollaboration war die Leitfunktion von 7.0 und wurde zwölf Tage vor dem Release gestrichen. Als Begründung nannte das Projekt mangelndes Vertrauen in die Robustheit, konkret Angriffsfläche, Wettlaufsituationen, Serverlast und wiederkehrende Fehler aus automatisierten Tests.
Bis heute gibt es keine offizielle Zielversion. Auch in 7.1 ist sie nicht enthalten. Ausgeliefert wurden dort nur Notizen mit Formatierung, Erwähnungen und Platzierung im Text, was etwas ganz anderes ist.
Wer seinen Redaktionsprozess auf gemeinsames gleichzeitiges Schreiben umstellen wollte, muss also weiter warten. Meine Empfehlung dazu ist unverändert: Plane nichts auf eine Funktion, die noch keinen Termin hat.
Was 7.1 verändert und warum das der eigentliche Bruch ist
In 7.0 wird der Beitragseditor nur dann in einen Iframe gepackt, wenn alle verwendeten Blöcke die Block-API in Version 3 oder höher nutzen. Bei gemischten Setups blieb alles beim Alten.
Ab 7.1 gilt das nicht mehr. Der Beitragseditor läuft dort immer in einem Iframe, unabhängig vom Theme-Typ und von der Block-API-Version. Genau das ist der Punkt, an dem ältere Meta-Boxen und selbstgebaute Blöcke Probleme bekommen können.
Dazu passt der größte dokumentierte Ausfall des ganzen Zyklus und der gehört ebenfalls zu 7.1. Ein weit verbreitetes Caching-Plugin erzeugte durch geänderte Hook-Kennungen schwere Fehler, betroffen war nach Angaben des Herstellers rund ein Zehntel der Nutzerbasis.
Für die Planung heißt das: Nicht 7.0 ist der kritische Schritt, sondern 7.1. Wer noch auf 6.9 steht, sollte den Sprung auf einer Kopie testen, statt ihn im Livebetrieb zu wagen. Warum das zur laufenden Website-Pflege gehört und nicht zum Sonderprojekt, habe ich dort ausführlich beschrieben.
Was mit Page Buildern passiert ist
Deutlich weniger, als die Foren vermuten lassen. Für Elementor ist kein Bruch durch 7.0 dokumentiert, der Changelog nennt nur die aktualisierte Kompatibilität bis 7.1.
Bei Divi gab es einen kosmetischen Fehler im Datumsfilter der Medienbibliothek des Visual Builders, behoben in der Version 5.7 vom 10. Juni 2026. Für WPBakery liegt keine öffentlich abrufbare Kompatibilitätsaussage zu 7.0 vor, das Plugin liegt nicht im offiziellen Verzeichnis.
Die pauschale Behauptung, 7.0 habe die Page Builder reihenweise zerlegt, lässt sich also nicht belegen. Wer trotzdem vorsichtig sein will, hat den besseren Grund bei 7.1 und dem erzwungenen Iframe.
Systemanforderungen: weniger streng, als viele denken
WordPress 7.0 und 7.1 verlangen weiterhin nur PHP 7.4 und MySQL 5.5.5 als Minimum. Die verbreitete Behauptung, 7.0 hebe die Anforderung auf PHP 8, stimmt nicht.
Empfohlen wird allerdings deutlich mehr: PHP 8.3 oder höher und MySQL 8.0 beziehungsweise MariaDB 10.11 oder höher. WordPress.org weist ausdrücklich darauf hin, dass PHP 7.4 und MySQL 5.5.5 das Ende ihres Lebenszyklus erreicht haben und ein Sicherheitsrisiko darstellen können.
In der Realität läuft immer noch rund ein Sechstel aller Installationen auf PHP 7.4. Wenn du dir also eine Baustelle für dieses Jahr aussuchen willst, ist die PHP-Version die lohnendere als der Sprung auf ein Block Theme.
Meine Empfehlung für Bestandsseiten
Das offizielle Test-Team sagt es unaufgeregt und richtig: Aktualisiere ein Produktivsystem nicht ungetestet, besonders nicht bei eigenem Code, vielen Plugins, eigenem Theme oder komplexen Anbindungen. Eine gesonderte Warnung für Classic Themes oder Page Builder gibt es nicht.
- Prüfe, auf welcher Version du wirklich stehst. Bei aktivierten automatischen Updates bist du wahrscheinlich längst auf 7.1.
- Wenn dein Theme ein Classic Theme ohne theme.json ist, prüfe den Beitragseditor auf die verlorene Standardformatierung.
- Teste den Sprung auf 7.1 auf einer Kopie, nicht live. Der erzwungene Iframe ist der Punkt, an dem es hakt.
- Sieh dir deine PHP-Version an. Alles unter 8.2 gehört auf die Liste für dieses Jahr.
- Lass das Classic-Editor-Plugin liegen, wenn du es nutzt. Es wird weiter gepflegt und ist bis 7.0.4 getestet.
Der KI-Teil von 7.0 ist ein eigenes Thema und hat mehr Substanz, als der Name vermuten lässt. Was der Core an dieser Stelle wirklich tut, und vor allem was er nicht tut, habe ich im Beitrag über
Wenn du nicht sicher bist, ob deine Seite den Sprung verträgt, schauen wir uns das im kostenlosen Erstgespräch von dreißig Minuten an. Wie die creativecouch Updates in der laufenden WordPress-Wartung abwickelt und was davon in ein Webdesign-Projekt gehört, steht auf der Leistungsseite, die zehn Punkte dazu unter bewährte Methoden zur WordPress-Wartung.
Hinweis zur Erstellung des Beitrags
Dieser Beitrag wurde mit Unterstützung einer KI erstellt, um effiziente und präzise Inhalte zu liefern. Im Anschluss wurde er sorgfältig von einem Experten überprüft und überarbeitet, um sicherzustellen, dass er den höchsten Qualitätsstandards entspricht und den Anforderungen der Leser gerecht wird.