WordPress 7.1 am 19. August: der Praxis-Check vor dem Update

Die meisten Beiträge zu WordPress 7.1 erzählen von neuen Blöcken. Sie übersehen, was zwei Wochen vorher passiert ist.

Am 6. August hat das Core-Team WordPress 7.0.3 veröffentlicht, ein Sicherheitsrelease ohne Vorankündigung. Darin steckt eine als kritisch eingestufte Cross-Site-Scripting-Lücke im Login-Bildschirm, ausnutzbar ohne Anmeldung. Dazu eine Rechteausweitung in Multisite-Netzwerken und eine SSRF-Lücke in der URL-Prüfung. Bei einer SSRF-Lücke wird der Server dazu gebracht, Adressen im internen Netz abzurufen. Beide gelten als hoch eingestuft.

Damit liegen zwei Updates auf dem Tisch. Sie brauchen entgegengesetzte Behandlung. Das eine duldet keinen Aufschub, das andere darf in Ruhe getestet werden. Wer beide gleich behandelt, macht in einem der Fälle einen Fehler.

Update eins: 7.0.3 gehört heute installiert

Bei Sicherheitsreleases greift die Standard-Empfehlung "erst testen, dann live" nicht. Mit der Veröffentlichung wird die Lücke öffentlich, und die automatisierte Suche nach verwundbaren Seiten startet.

Die Ankündigung sagt dazu wörtlich: "Sites that support automatic background updates will begin updating shortly."

Prüfe deshalb zwei Dinge, das dauert zwei Minuten:

1. Steht unter Werkzeuge, Website-Zustand die aktuelle Version, also 7.0.3?
2. Sind automatische Updates für Nebenversionen überhaupt aktiv? Viele Installationen haben sie irgendwann abgeschaltet, oft aus gutem Grund, und danach nie wieder angefasst.

Wenn du bei Punkt zwei unsicher bist, ist das die Frage, die sich zuerst lohnt.

Ein Fall aus der Praxis

Ein Handwerksbetrieb meldete sich bei uns wegen eines kaputten Bestellprozesses im Shop. Kreditkartenzahlung ging nicht mehr, ein kleines Stundenpaket sollte es richten.

Gefunden haben wir etwas anderes. In der Datenbank lagen 24.476 versteckte Spam-Einträge, für Besucher unsichtbar, für Google lesbar. Dazu 375 Spam-Beiträge, sechs Injektionen in echten Produkten und zwei fremde Benutzerkonten, darunter ein Administrator.

Der Einstieg lief über eine Plugin-Lücke. Der Shop war nicht kaputt, er war seit Jahren gekapert. Wie so ein Angriff abläuft, steht in unserer Anleitung zur gehackten WordPress-Seite.

Die Bereinigung lief in einem Durchgang, ohne Verlust echter Datensätze. Die vollständige Aufarbeitung steht bei unseren Referenzen, inklusive Zeitachse: was wir in dem Shop gefunden haben.

Der Punkt daran ist nicht der Schaden. Der Punkt ist, dass niemand etwas gemerkt hat. Ein aufgeschobenes Sicherheitsupdate meldet sich nicht mit einer Fehlermeldung. Es meldet sich Jahre später, über ein ganz anderes Symptom.

Verlass dich nicht darauf, dass das automatische Update gelaufen ist

Bei der kritischen Lücke im Juli hat WordPress erzwungene automatische Updates ausgelöst. Das war richtig. Es führt aber zu einem Trugschluss: Viele halten die Sache damit für erledigt und prüfen nicht nach.

Ein erzwungenes Update kann still scheitern. Dateirechte, Zeitlimits oder eine gestörte Verbindung reichen aus. Bei verwalteten Hostern läuft es manchmal verzögert oder gar nicht.

Wie das ausgeht, beschreibt ein Dienstleister in r/ProWordPress aus erster Hand. Sinngemäß: Auf einem Server war die Namensauflösung defekt, deshalb kamen die Updates nicht an. Aufgefallen ist es erst am Montagmorgen. Bei der Untersuchung fanden sich auf drei Websites neue Administratorkonten und ein Plugin, das eine eigene Schnittstelle angelegt hatte. Die Zugriffsprotokolle zeigten, dass darüber ein Shell-Skript ausgeführt worden war. Der Betreiber hat den kompletten Server auf den Stand vom Freitag zurückgesetzt und alle Zugangsdaten gewechselt.

Sein Fazit besteht aus zwei Sätzen, wörtlich:

"Auto-updates are a good thing. Backups are a good thing."

Beides stimmt. Und beides ersetzt den Blick auf die tatsächlich installierte Version nicht.

Die weiterführenden Prüfschritte aus demselben Beitrag sind ebenfalls brauchbar: Benutzerliste auf unbekannte Administratoren durchsehen, unerwartete Anwendungspasswörter suchen, sowie die fest eingebundenen Plugins (mu-Plugins) und kürzlich geänderte Kerndateien kontrollieren. Die Grundlagen dazu haben wir in acht Tipps gegen Hackerangriffe gesammelt.

Update zwei: was in WordPress 7.1 steckt

WordPress 7.1 erscheint am 19. August, am letzten Tag des WordCamp US. Release Candidate 1 kam am 5. August, RC 2 am 6. August und enthält die Sicherheitskorrekturen aus 7.0.3.

Der Field Guide nennt Zahlen statt Schlagworte. Über 310 geschlossene Core-Tickets, über 100 Erweiterungen, mehr als 180 Fehlerbehebungen. Der Schwerpunkt liegt beim Editor mit über 40 Tickets, dahinter Barrierefreiheit mit 46, Oberfläche mit 40 und Verwaltung mit 28.

Das ist die ehrliche Zusammenfassung: 7.1 ist kein Umbau, sondern ein breites Pflege-Release.

Für Firmenwebsites sind vier Neuerungen relevant:

Eine Einschränkung gehört zu den responsiven Styles. Sie greifen automatisch nur bei Blöcken, die die Standard-Einstellungen von WordPress nutzen. Themes und Plugins mit selbst gebauten Blöcken bekommen die neuen Regler nicht geschenkt.

WordPress bekommt eine KI-Schnittstelle, aber kein KI-Modell

Diese Änderung steht in keiner Feature-Liste für Endanwender. Für Firmenkunden in Deutschland wirft sie trotzdem die meisten Fragen auf.

Mit 7.1 kommt ein sogenannter AI Client in den Kern von WordPress. Der Field Guide führt ihn unter den enthaltenen Änderungen. Dazu wird die mit 6.9 eingeführte Abilities API ausgebaut. Über sie melden Plugins ihre Funktionen für andere Programme an. Der Field Guide dazu wörtlich:

"WordPress 7.1 builds on the Abilities API introduced in WordPress 6.9, making abilities easier to discover, expose, validate, and integrate with external clients."

Wichtig ist, was nicht mitkommt. WordPress liefert kein Modell mit und setzt keinen Standard-Anbieter. Es ist eine Schnittstelle, kein Dienst. Wer sie nutzen will, hinterlegt einen eigenen Anbieter und einen eigenen Schlüssel.

In der Fachdiskussion auf Reddit fasst der Verfasser eines viel kommentierten Beitrags in r/ProWordPress den Zustand sinngemäß so zusammen: Ohne konfigurierten Anbieter verlasse nichts den Server, es gebe kein Modell, keinen Standard und keine Schlüssel im Kern. Unkonfiguriert liege die Schnittstelle einfach da.

Das ist die Antwort auf die Frage, die uns Kunden nach solchen Meldungen zuerst stellen: Nein, mit dem Update gehen keine Inhalte automatisch an einen KI-Anbieter.

Die Stimmung unter den Entwicklern ist trotzdem gemischt. Der meistbeachtete Kommentar im selben Beitrag ist knapp und ablehnend, wörtlich:

"If they could gut it instead, I'd be happy."

Ein anderer argumentiert sinngemäß, so etwas gehöre als Erweiterung ausgeliefert, nicht in den Kern. Begründung: 95 Prozent der Websites bräuchten es nicht. Ein dritter formuliert die Sorge unverblümt, wörtlich:

"I don't want AI on my server or in my CRM."

Diese Haltung teilen wir nicht in jedem Punkt, aber der Kern der Kritik ist berechtigt: Jede Funktion im Kern muss dauerhaft gepflegt werden, auch die, die kaum jemand einschaltet.

Eine Korrektur zu einer verbreiteten Angabe. In derselben Diskussion und in mehreren Artikeln taucht eine Funktion namens Guidelines auf, mit der sich redaktionelle Regeln und Markenstimme zwischen Websites übertragen lassen sollen. Diese Funktion ist nicht Teil von 7.1. Der Field Guide führt sie unter den Vorschlägen, die sich weiterentwickeln und später erneut geprüft werden können.

Der erzwungene iframe-Editor: die Änderung mit dem größten Bruch-Risiko

Dokumentiert ist sie nicht in den Feature-Listen, sondern in einer Entwickler-Notiz.

Ein iframe ist ein abgekapselter Rahmen im Browser.

Aki Hamano schreibt in der Dev-Note vom 3. August wörtlich:

"Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content."

Der entscheidende Halbsatz ist "regardless of". Bis 7.0 war der iframe an Bedingungen geknüpft. Waren alle Blöcke auf der modernen Schnittstellen-Version, wurde der Editor gekapselt, sonst nicht.

Damit fällt der bisherige Ausweg weg. Wer sein Plugin auf einer älteren Block-Version gelassen hat, war bisher außen vor. In 7.1 schützt das nicht mehr, es bricht nur noch.

Die technische Begründung steht in derselben Notiz:

"the iframe has its own document and window, separate from the admin page where editor scripts run."

Skripte, die von außen auf Elemente im Editor zugreifen, greifen ins Leere.

Ein reproduzierter Fehler aus dem Testbetrieb

Wie sich das äußert, zeigt Gutenberg-Issue 80119, gemeldet am 10. Juli.

Ein Tester reproduziert unter einer 7.1-Vorabversion mit PHP 8.3 einen JavaScript-Abbruch beim Einfügen bestimmter Blöcke. Ein Core-Entwickler nennt die Ursache. Der Editor wechselte beim Einfügen eines Blocks mit älterer Schnittstellen-Version zwischen beiden Modi. Dabei blieb ein verwaistes Element zurück.

Das Bemerkenswerte: Genau diesen Fehlermodus beseitigt 7.1, weil der Wechsel entfällt. Die Umstellung behebt also ein Problem. Gleichzeitig schafft sie ein neues für alle, die den Umbau nie mitgemacht haben.

Die Stimmung unter den Entwicklern ist dabei nicht negativ. Unter der Dev-Note steht eine einzige Reaktion, und die ist positiv. Fabian Kaegy schreibt am 3. August wörtlich:

"Big kudos to everyone that has been working on this for the last several years. I know it's been a painful path with lots of setbacks. But I'm so glad we finally made it."

Der iframe ist kein Fehler, sondern das Ende eines jahrelangen Umbaus. Er trifft nur Plugins, die nie mitgezogen haben.

So prüfst du, ob dich das betrifft

Öffne einen Beitrag im Editor und drücke F12 für die Entwicklerwerkzeuge des Browsers. Suche im Reiter Elemente nach iframe[name="editor-canvas"].

Findest du das Element, läuft dein Editor bereits gekapselt. Dann hast du den Umbau hinter dir.

Ryan Welcher stellt unter iframe-editor-examples fertige Testumgebungen bereit. Damit lässt sich das alte und das neue Verhalten in zwei Browser-Tabs nebeneinander vergleichen, ohne etwas zu installieren.

Für eigene Blöcke gibt es offizielle Umstellungsmuster. Sie stehen im Handbuch zur iframe-Kompatibilität.

Wenn dabei herauskommt, dass mehrere ältere Plugins mit eigenen Editor-Feldern im Spiel sind: Genau diese Fälle nehmen wir in der WordPress-Wartung vor dem Update auseinander.

Die stille zweite Bruchstelle: das Markup der Admin-Listen

Diese Änderung taucht in keiner Vorschau auf, weil sie unsichtbar ist.

In den Listenansichten von Beiträgen und Seiten ändert sich die Tabellenstruktur. Die Spalte mit der Auswahlbox wechselt das HTML-Element, ebenso die Titelspalte. Auslöser ist ein elf Jahre altes Ticket zur Barrierefreiheit.

Roger Montti beschreibt die Folge am 6. August im Search Engine Journal wörtlich so:

"Plugins that use CSS or JavaScript to target specific <th> or <td> elements in WordPress admin post list tables are the ones at risk."

Betroffen sind also Plugins, die eigene Spalten in diese Listen einhängen und dabei auf die bisherige Struktur zielen. Im selben Artikel steht die Entwarnung für die verbreiteten SEO-Plugins: Yoast SEO, Rank Math und All in One SEO gelten als nicht gefährdet.

Praktisch heißt das: Wenn nach dem Update eine Spalte in der Beitragsübersicht verrutscht oder leer bleibt, liegt es wahrscheinlich hier. Das Frontend ist davon nicht betroffen.

jQuery UI steigt auf 1.14.2

jQuery UI ist eine mitgelieferte Programmbibliothek für Bedienelemente wie Datumsauswahl oder Ziehen und Ablegen. Die Ankündigung vom 29. Juli nennt ausdrücklich Testbedarf für Plugins, die darauf aufsetzen.

Betroffen sind typischerweise ältere Formular-, Buchungs- und Kalender-Plugins. Also genau die Bereiche, über die Anfragen hereinkommen. Ein Datumsfeld, das sich nicht mehr öffnet, fällt im Alltag oft tagelang niemandem auf. Wer diese Prüfung dauerhaft abgeben will, findet die Konditionen unter WordPress-Wartung ab 9,90 Euro im Monat.

Drei Funktionen, die es nicht in 7.1 geschafft haben

Der Field Guide führt einen eigenen Abschnitt mit der Überschrift "What changes didn't make the 7.1 release". Wer nach der Beta-Meldung plant, plant sonst mit Funktionen, die nicht ausgeliefert werden.

Echtzeit-Zusammenarbeit kommt nicht. Der Field Guide sagt wörtlich:

"Real-time collaborative editing received extensive testing and feedback during the WordPress 7.1 cycle, but it is not enabled in the final release."

Die Begründung stammt aus dem Vorgängerzyklus. Im Mai wurde die Funktion bereits aus 7.0 genommen, zwölf Tage vor dem Launch. Das Core-Team nannte damals wörtlich:

"concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing"

Wer gemeinsames Bearbeiten für ein Redaktionsteam eingeplant hat, plant damit seit zwei Releases um.

Das "On This Day"-Widget ist raus. Die Beta-1-Meldung vom 15. Juli listet es noch als neue Funktion. Es ist auf 7.2 verschoben. Wer die Beta-Meldung als Planungsgrundlage genommen hat, arbeitet mit einem veralteten Stand.

Der Classic-Block bleibt. Der Vorgang dahinter lohnt einen genaueren Blick.

Der Fahrplan vom 19. Juni kündigte an, den Classic-Block aus der Block-Auswahl zu entfernen. Die Änderung landete auch im Code. Am 6. Juli wurde die Änderung per Pull Request 79894 wieder zurückgenommen, Titel: "Classic block: Remove migration notice and restore inserter availability".

Einen Tag später erklärte das Core-Team die Kehrtwende öffentlich, mit ungewöhnlich offenen Worten:

"This approach had things largely backward. It's one step that makes the experience worse with no direct gain."

Sinngemäß: Der Classic-Block soll aus freien Stücken überflüssig werden, nicht durch Zwang. Der zugehörige Schalter im Code hat es nie in ein Release geschafft.

Für Betriebe, die noch Inhalte im Classic-Block pflegen, ändert sich damit nichts. Eine Migration ist nicht nötig.

Und eine Falschmeldung, die sich hält. Mehrere Zweitquellen schreiben, 7.1 basiere auf einem Wechsel auf React 19, die Technik hinter der Editor-Oberfläche. Der Field Guide widerspricht wörtlich:

"The React 19 upgrade was also deferred beyond WordPress 7.1 and continues as an experiment in the Gutenberg plugin."

Was Tester im Release Candidate tatsächlich melden

Drei Themen kommen dort wiederholt vor.

Die Meta-Boxen sind der eigentliche Schmerzpunkt

Meta-Boxen sind die Zusatzfelder unter dem Editor, in denen viele Plugins ihre Einstellungen unterbringen. Mit 7.0 kam dafür ein neues, geteiltes Layout. Mit dem erzwungenen iframe in 7.1 sehen es künftig alle.

Der zugehörige Fehlerbericht 79127 ist seit dem 11. Juni offen. Ein Nutzer schreibt am 15. Juli wörtlich:

"If you never manually drag the meta boxes section, but simply click it to open it, it will have a height of auto and fill the entire screen. This is the default state I often see when opening a post / page to edit, making it look like the entire editor is missing. The way you can't simply scroll down to see meta boxes anymore is extremely frustrating."

Ein anderer beschreibt am 5. August ein Scroll-Problem, wörtlich:

"When I am at the bottom of a post and open the meta-box pane, then try to return to the post content, the editor jumps all the way back to the H1 instead of preserving my scroll position."

Dazu kommt ein Benennungsproblem. Die Sammelfläche trägt die Beschriftung "Meta Boxes". In einem weiteren Bericht heißt es sinngemäß, die Redakteure wüssten damit nichts anzufangen. Der Begriff tauchte in den früheren Oberflächen nie auf.

Für Redaktionsteams ist das der relevanteste Punkt des ganzen Releases. Nicht weil etwas kaputtgeht, sondern weil sich die Arbeitsweise ändert und Rückfragen kommen.

Beim Responsive Styling melden Tester offene Punkte

Das Responsive Styling ist die Änderung, die Redakteure zuerst bemerken. In einem Forumsthread beschreibt ein Tester im Juli zwei Bedienprobleme. Erstens verwende das Auswahlmenü dasselbe Häkchen für zwei verschiedene Bedeutungen. Zweitens sehe man einem Block nicht an, ob abweichende Einstellungen für Tablet oder Mobilgerät hinterlegt sind.

Ein zweiter Tester antwortet knapp und wörtlich:

"I'd agree this doesn't feel ready to ship."

Der Melder führte die Diskussion am 5. August als Issue 81226 weiter. Dort argumentiert der Melder aus der Sicht eines Hochschul-Netzwerks mit mehreren tausend Websites, wörtlich:

"The editors are usually not developers or experienced web creators, so any added editor complexity lands on a central support team at scale. A small point of confusion becomes many tickets, not one."

Das ist der Satz, den wir aus Kundenprojekten wiedererkennen. Eine Funktion, die für Entwickler klar ist, erzeugt bei zwanzig Redakteuren zwanzig Rückfragen.

Auch ein Core-Entwickler meldet eine Darstellungsstörung

Andy Fragen ist selbst Core-Committer. Im Forumsthread Styling error in latest nightly meldet er ein fehlendes Bedienelement in den Listenansichten. Ein weiterer Nutzer bestätigt den Befund und beschreibt die Plugin-Übersicht als fehlerhaft dargestellt.

Solche Beobachtungen sind normal in der Testphase und meist vor dem Release behoben. Sie zeigen aber, dass die Listenansichten in diesem Zyklus an mehreren Stellen angefasst wurden.

Was wir ausdrücklich nicht gefunden haben

Es gibt Stand heute keine öffentliche Meldung von Yoast, Advanced Custom Fields, WooCommerce oder Elementor über eine Unverträglichkeit mit 7.1. Diese Namen tauchen in Fehlerberichten nur als Umgebungsangabe auf, nicht als bestätigter Ausfall.

Wer schreibt, die großen Plugins würden brechen, hat dafür derzeit keinen Beleg. Wir schreiben es deshalb nicht.

Was frühere Major-Updates gelehrt haben

Die Frage "kann ein Update wirklich eine Seite zerlegen" lässt sich nicht mit Gefühl beantworten. Es gibt dokumentierte Fälle. Drei davon sind aussagekräftig.

WordPress 6.4 und die Korrektur zwei Tage später. Version 6.4 erschien am 7. November 2023, Version 6.4.1 am 9. November. Die offizielle Versionsseite sagt wörtlich: "WordPress 6.4.1 fixes 4 regressions introduced in version 6.4."

Darunter waren zwei bemerkenswerte Fälle. Core entfernte eine Eigenschaft, die es selbst nicht mehr brauchte, die Drittanbieter-Plugins aber weiter auslasen. Folge waren harte Abbrüche. Und eine aktualisierte Netzwerk-Bibliothek brach auf Servern mit älteren Bordmitteln, wodurch Updates von Core, Plugins und Themes fehlschlugen. Ein drittes Ticket trägt den Titel "Categories are removed when bulk editing posts", also stiller Datenverlust.

WordPress 6.2.1 und die Shortcodes. Ein Sicherheitsfix entfernte im Mai 2023 die Verarbeitung von Shortcodes in Block-Templates vollständig. Jede Website mit Shortcodes im Template brach, ausgerollt per automatischem Update, ohne Vorwarnung. Vier Tage später kam die Korrektur.

Ein betroffener Entwickler wird bei WPTavern wörtlich zitiert:

"This update has been nothing short of a disaster. I cannot understand how there was no warning of such a destructive, automatic roll out!"

WordPress 5.5 und jQuery Migrate. Im August 2020 lieferte Core eine Kompatibilitätsschicht für älteren JavaScript-Code nicht mehr mit. Slider, Formulare und Verwaltungsseiten hörten lautlos auf zu funktionieren. Das Core-Team schob ein Hilfs-Plugin nach. Es überschritt laut WPTavern binnen einer Woche 10.000 aktive Installationen.

Und der aktuellste Fall

WordPress 7.0 erschien am 20. Mai 2026. Sieben Wochen später erschien WordPress 7.0.1 mit 31 Fehlerbehebungen. Darunter ein Fehler, bei dem gültige CSS-Angaben für Hintergrundbilder beim Speichern zerstört wurden. Der wird direkt im Frontend sichtbar.

Daraus ergibt sich die realistische Erwartung: Ein Major-Update läuft bei der großen Mehrheit sauber durch. Und es gibt jedes Mal eine Minderheit, für die es nicht sauber durchläuft.

Zu welcher Gruppe eine bestimmte Website gehört, entscheidet sich an den Plugins, nicht am Zufall.

Der Update-Plan für den 19. August

Die Reihenfolge zählt mehr als die Gründlichkeit.

Die Grundschritte

1. 7.0.3 einspielen, sofort. Das ist der Sicherheitsteil und gehört nicht in die Testschleife.
2. Backup ziehen und den Rückweg klären. Datenbank und Dateien sichern, Wiederherstellungspunkt beim Hoster prüfen.
3. 7.1 auf einer Kopie testen, nicht live. Eine Staging-Umgebung ist eine Testkopie deiner Website. Viele Hoster legen sie per Klick an.
4. Vier Bereiche durchklicken. Startseite, eine Leistungsseite, ein Formular, ein Beitrag mit Classic-Block. Erscheinen alle Felder, lässt sich alles speichern?
5. Formulare und Buchungen zuerst prüfen. Sie hängen am häufigsten an jQuery UI und sind geschäftskritisch.
6. Plugin-Änderungslisten überfliegen. Nennt ein Anbieter 7.1 oder den iframe-Editor ausdrücklich, ist das ein gutes Zeichen.

Die Details, die in den meisten Checklisten fehlen

Diese Punkte stammen aus der Entwickler-Dokumentation und aus dem, was uns in Projekten Zeit gekostet hat.

Automatische Updates nicht pauschal abschalten. Die Einstellung WP_AUTO_UPDATE_CORE kennt drei Werte: alles, nichts oder nur Nebenversionen. Der mittlere Weg ist fast immer der richtige. Sicherheits-Patches laufen automatisch ein, die Hauptversion wartet auf deinen Termin. Wer pauschal alles abschaltet, bekommt auch die Sicherheits-Patches nicht mehr. Und merkt das nicht.

Der Release Candidate ist die eigentliche Frist, nicht der 19. August. Nach dem ersten Release Candidate landen nur noch Fehlerbehebungen im Code. Wer erst am Erscheinungstag testet, testet zu spät, um noch etwas zu melden.

Die Vorabversion lässt sich gezielt installieren. Über WP-CLI genügt wp core update --version=7.1-RC2. Die genaue Bezeichnung der jeweils aktuellen Vorabversion steht in der zugehörigen Ankündigung. Damit testest du heute, was am 19. August ausgeliefert wird.

Der Browser-Baukasten spart die halbe Testumgebung. Über den offiziellen WordPress Playground lässt sich per Adresszeile eine Kombination aus Vorabversion, PHP-Version und einem bestimmten Plugin erzeugen, ohne etwas zu installieren. Für die Frage "läuft dieses eine Plugin unter 7.1" reicht das oft.

Eigene Blöcke lassen sich maschinell prüfen. Das offizielle Werkzeug Plugin Check meldet inzwischen, wenn ein Block noch nicht auf der Schnittstellen-Version läuft, die der iframe-Editor braucht.

Ein Rollback ist kein Rückgängig. Ein Zurücksetzen tauscht die Programmdateien aus, aber nicht den Zustand der Datenbank. Läuft die Datenbank bereits auf dem neuen Schema, entstehen Symptome, die niemand zuordnet: Die Verwaltung lädt, der Editor nicht. Das Frontend wirkt normal, die Schnittstelle antwortet mit Serverfehler. Der saubere Rückweg ist immer die Sicherung von vorher, Dateien und Datenbank gemeinsam.

Für den Fall der Fälle gibt es das Plugin Core Rollback von Andy Fragen, einem Core-Committer. Es trägt eine ehrliche Warnung im eigenen Text, sinngemäß: Ein Zurücksetzen von Core kann die Website in einem unbenutzbaren Zustand hinterlassen.

Der Zwischenspeicher für Programmcode erzeugt Fehler, die wie Plugin-Fehler aussehen. WordPress leert ihn beim Update, aber nicht vollständig, und manche Hoster hängen sich aus diesem Mechanismus aus. Ein veralteter Zwischenspeicher nach einem Core-Update erzeugt Abbrüche, die wie Plugin-Fehler aussehen. Wenn direkt nach einem Update etwas Unerklärliches passiert, ist das der erste Verdacht.

Bei Multisite läuft die Datenbank-Anpassung nicht von allein für alle Websites. Sie muss für das Netzwerk angestoßen werden, und sie lässt sich vorher im Trockenlauf prüfen.

Zeitgesteuerte Aufgaben vorher und nachher vergleichen. Eine Liste der geplanten Aufgaben vor dem Update und danach zeigt sofort, ob etwas verloren gegangen ist. Fehlende Einträge erklären später Newsletter, die nicht rausgehen, oder Backups, die nicht laufen.

Wenn nach dem Update eine Verwaltungsseite hängt, prüfe zuerst ausgehende Verbindungen. Hängt eine Seite im Backend ohne Fehlermeldung, wartet oft ein Plugin auf eine Abfrage nach außen. Der Server verwirft sie stillschweigend, also wartet das Plugin bis zum Zeitlimit. Mit der Zeile define('WP_HTTP_BLOCK_EXTERNAL', true); in der wp-config.php lässt sich das in einer Minute prüfen. Lädt die Seite danach sofort, hast du die Richtung. Diskutiert wurde das in r/Wordpress an einem Fall unter 7.0.3.

Im selben Beitrag steht eine zweite brauchbare Eingrenzung. Lädt dieselbe Seite mit dem Zusatz &noheader=1 sofort, liegt das Problem im Aufbau des Verwaltungs-Kopfbereichs. Dann ist nicht die Seite selbst schuld.

Fairerweise gehört dazu: In derselben Diskussion meldet ein Nutzer nach dem Update auf 7.0.3 zufällige Serverfehler bei etwa vier Prozent der Aufrufe. Eine Ursache wurde dort nicht gefunden, und es ist eine Einzelmeldung. Wir führen sie an, weil sie zeigt, warum auch ein Sicherheitsupdate eine kurze Kontrolle danach verdient.

Die Testkopie muss der Produktion wirklich gleichen. Pantheon formuliert das wörtlich so:

"The number one cause of 'it worked on staging but broke in production' is environmental mismatch."

Gemeint sind identische PHP-Version samt Erweiterungen, dieselbe Datenbank-Konfiguration und dieselben Zwischenspeicher-Schichten. Verschärfend kommt hinzu, dass manche Hoster auf der Testkopie bewusst ein anderes Plugin-Set aktivieren. Dann testet man genau das nicht, worauf es ankommt.

Wir prüfen nach jedem Update zusätzlich die Fehlerprotokolle in den ersten Minuten. Danach kontrollieren wir, ob alle vorher aktiven Plugins noch aktiv sind. Ein fehlgeschlagenes Update schaltet Plugins stillschweigend ab.

Für wen sich 7.1 lohnt und wer warten kann

Wer ein aktuelles Block-Theme, gepflegte Plugins und einen kleinen Plugin-Bestand hat, kann zeitnah aktualisieren. Der Nutzen liegt bei den über 180 Fehlerbehebungen und den 46 Tickets zur Barrierefreiheit, nicht bei den neuen Blöcken.

Wer schon länger überlegt, das Theme grundsätzlich zu erneuern, nimmt so ein Release als Anlass. Wie ein WordPress-Relaunch ohne Page-Builder aussieht, steht auf der Leistungsseite.

Wer viele ältere Plugins mit eigenen Editor-Feldern einsetzt, wartet ein bis zwei Wochen. In dieser Zeit liefern die meisten Anbieter ihre Anpassungen. Das ist kein Zögern, das ist Reihenfolge.

Wer ein Redaktionsteam hat, sollte den Termin unabhängig von der Technik planen. Das geteilte Meta-Boxen-Layout verändert die Arbeitsweise sichtbar. Eine kurze Info an die Redaktion vorher spart mehr Zeit, als der Test kostet.

Was wir in Projekten immer wieder sehen: Der Schaden entsteht selten durch das Update. Er entsteht durch das Update ohne Testkopie und ohne Backup, freitagnachmittags. Ein Bruch fällt dann erst auf, wenn eine Anfrage ausbleibt. Und dann fehlt die Information, seit wann.

So sieht der gute Ausgang aus: Am 19. August läuft das Update durch, die Formulare nehmen weiter Anfragen entgegen, und niemand im Team merkt etwas davon. Dafür braucht es keine Glück, sondern eine Testkopie und eine Stunde vorher.

Wie so ein Sprung beim letzten Mal lief, steht in unserer Einordnung zum Update auf 7.0. Und die kritische Lücke vom Juli zeigt, wie eng die Takte inzwischen sind. Wer grundsätzlicher überlegt, ob WordPress das richtige System bleibt, findet unseren Vergleich WordPress oder TYPO3.

Wer das nicht selbst fahren will: Wir übernehmen Wartung und Updates samt Monitoring. Bestehende Installationen prüfen wir auf WordPress-Sicherheit. Wie wir mit WordPress insgesamt arbeiten, steht unter WordPress-Betreuung.

Zur Quellenlage dieses Beitrags

So arbeiten wir: Jede Zahl und jedes Zitat geht auf eine Primärquelle zurück, die wir zum genannten Datum selbst abgerufen haben. Aussagen aus Foren gelten uns als Hinweis, nicht als Beleg, und werden vor der Übernahme gegengeprüft. Was sich nicht belegen lässt, kommt nicht in den Text, auch wenn es die Geschichte besser machen würde. Zwei Angaben sind bei dieser Prüfung wieder herausgeflogen.

Dieser Beitrag ist mit KI-Unterstützung entstanden, bei Recherche und Rohfassung. Fakten, Zitate und Einordnung stammen aus geprüften Quellen und eigener Projekterfahrung, die Verantwortung für den Text liegt beim Autor.

Ausgewertet haben wir die offiziellen Primärquellen: Field Guide, Entwickler-Notizen und Release-Meldungen. Dazu kamen die WordPress.org-Support-Foren aus dem Alpha- und Beta-Bereich und die Fehlerberichte im Gutenberg-Projekt auf GitHub. Alle Zitate stehen mit Autor, Datum und Fundstelle in der Quellenliste.

Dazu kommen drei Diskussionen aus den Fachgruppen r/Wordpress und r/ProWordPress. Sie sind namentlich verlinkt. Beiträge dort stehen unter Pseudonym. Deshalb prüfen wir jede Aussage von dort gegen eine Primärquelle, bevor wir sie übernehmen.

Auf Hacker News gibt es zu WordPress 7.1 nichts.

Öffentliche Erfahrungsberichte von Hostern oder anderen Dienstleistern zu konkreten Update-Ausfällen haben wir gesucht und nicht gefunden. Das ist eine echte Lücke in der Fachliteratur.

• WordPress News, WordPress 7.0.3 Security Release. wordpress.org
• Make WordPress Core, WordPress 7.1 Field Guide. make.wordpress.org
• Make WordPress Core, Iframed editor changes in WordPress 7.1, Dev-Note von Aki Hamano. make.wordpress.org
• Make WordPress Core, jQuery UI updated to 1.14.2 in WordPress 7.1. make.wordpress.org
• Make WordPress Core, The Classic block stays in the inserter for WordPress 7.1. make.wordpress.org
• Make WordPress Core, Real-time collaboration will not ship in WordPress 7.0. make.wordpress.org
• GitHub, Gutenberg PR 79894, Classic block: Remove migration notice and restore inserter availability. github.com
• GitHub, Gutenberg Issue 80119, TypeError in getComputedStyle unter 7.1-alpha. github.com
• GitHub, Gutenberg Issue 79127, WP 7.0 Regression: Metaboxes cover full editor. github.com
• GitHub, Gutenberg Issue 81226, Rückmeldung zum Responsive Styling aus einem Hochschul-Multisite. github.com
• WordPress Support-Forum, Responsive styling 7.1: useful feature but a few UI things confused me. wordpress.org
• WordPress Support-Forum, Styling error in latest nightly. wordpress.org
• Search Engine Journal, WordPress 7.1 Accessibility Change May Break Some Plugins, Roger Montti. searchenginejournal.com
• WordPress.org, Version 6.4.1. wordpress.org
• WPTavern, WordPress 6.2.1 Update Breaks Shortcode Support in Block Templates. wptavern.com
• WPTavern, Enable jQuery Migrate Helper Plugin Passes 10K Active Installs. wptavern.com
• WordPress News, WordPress 7.0.1 Maintenance Release. wordpress.org
• WordPress Developer Resources, Upgrading WordPress. developer.wordpress.org
• WordPress Developer Resources, Block migration for iframe editor compatibility. developer.wordpress.org
• GitHub, Ryan Welcher, iframe-editor-examples. github.com
• WordPress.org Plugin-Verzeichnis, Plugin Check. wordpress.org
• WordPress.org Plugin-Verzeichnis, Core Rollback von Andy Fragen. wordpress.org
• WordPress Developer Resources, wp_opcache_invalidate. developer.wordpress.org
• Pantheon Learning Center, Staging to Production. pantheon.io
• Reddit r/ProWordPress, WordPress 7.1 ships an AI Client with no model and no default provider. reddit.com
• Reddit r/ProWordPress, If you are running 6.9 or 7.0, WordPress forced-updated you, but check anyway. reddit.com
• Reddit r/Wordpress, Admin plugin page stuck loading, WP 7.0.3. reddit.com