WordPress 7.1: Was auf Ihrer Website bricht

WordPress 7.1 ist am 19. August 2026 erschienen — und zwei der meistgenannten Punkte zu diesem Update stimmen nicht. React 19 ist offiziell auf eine spätere Version verschoben worden, und der neue iframe-Zwang im Editor betrifft nicht nur Block-Themes, sondern alle. Diese eine Änderung ist es, die Websites tatsächlich beschädigen kann — und sie steht in den wenigsten Übersichten.

Zwei Annahmen, die nicht mehr stimmen

Über WordPress 7.1 wird seit Monaten geschrieben. Vieles davon stammt aus der Planungsphase im Frühling und ist inzwischen überholt — die Entscheidungen sind erst während der Beta-Phase im Juli gefallen. Zwei Punkte haben sich dabei ins Gegenteil verkehrt.

React 19 ist verschoben — nicht Teil von 7.1

Der ursprüngliche Plan sah vor, den Block-Editor mit 7.1 von React 18 auf React 19 zu heben. Das ist nicht eingetreten. Der Versuch wurde im Juni im Gutenberg-Plugin unternommen — und innerhalb weniger Tage zurückgenommen: Version 23.3.0 brachte React 19, Version 23.3.2 nahm ihn am 5. Juni wieder heraus.

Der Grund ist technisch eindeutig: Viele Plugins liefern ihre eigene Kopie des react/jsx-runtime-Helfers mit. React 19 weist Elemente zurück, die von der Laufzeitumgebung aus React 18 erzeugt wurden, weil die erzeugten Objekte strukturell anders aussehen. Ergebnis waren reihenweise Abstürze in Plugins, die für die vorherige WordPress-Version gebaut wurden.

Am 24. Juli hat das Core-Team den Umstieg in einer eigenen Dev-Note offiziell auf später vertagt. Der Wortlaut lässt keinen Interpretationsspielraum: Der React-19-Upgrade wird nicht Teil von WordPress 7.1 sein, 7.1 verwendet weiterhin React 18.3. Wer testen möchte, kann den Schalter im Gutenberg-Plugin ab Version 23.4 unter «Einstellungen › Gutenberg» aktivieren.

Für die Praxis heisst das: Der am häufigsten genannte Risikofaktor dieses Updates existiert nicht. Das ist eine gute Nachricht — sie darf nur nicht dazu führen, dass die tatsächliche Bruchstelle übersehen wird.

Der iframe gilt für alle Themes, nicht nur Block-Themes

Die offizielle Roadmap vom 19. Juni kündigte den erzwungenen iframe für blockbasierte Themes an, mit Ausweitung auf alle Themes in späteren Versionen. Was dann tatsächlich einging, ist weitreichender: Der Pull Request «Post editor: always iframe» wurde am 10. Juli in Gutenberg aufgenommen und entfernt die Bedingungen für Theme-Typ und apiVersion ersatzlos. Die Entscheidung landete mit Beta 1 am 15. Juli in WordPress 7.1.

Bisher gab es einen Fluchtweg: Sobald ein einziger Block mit Block-API-Version 1 oder 2 im Beitrag steckte, lud WordPress den Editor ohne iframe. Dieser Fluchtweg ist geschlossen. Der Editor-Canvas ist ab 7.1 immer ein iframe — unabhängig davon, welches Theme läuft und welche apiVersion Ihre Blöcke deklarieren.

Was der iframe-Zwang konkret bricht

Ein iframe ist ein eigenes Dokument im Dokument. Der Beitragsinhalt lebt ab 7.1 in diesem inneren Dokument, während Ihre Editor-Skripte weiterhin in der äusseren Admin-Seite laufen. Alles, was stillschweigend annimmt, es gäbe nur ein Dokument, zielt danach ins Leere — meist ohne Fehlermeldung.

JavaScript, das ins falsche Dokument greift

Der klassische Fall ist ein Block, der auf die Fensterbreite reagiert. Vor 7.1 lieferte window.innerWidth einen brauchbaren Wert. Ab 7.1 misst dieselbe Zeile die Breite der Admin-Seite, während der Block im iframe eine ganz andere Breite hat.

// Vorher — misst nach dem Update das falsche Fenster
useEffect( () => {
    const update = () => setWidth( window.innerWidth );
    window.addEventListener( 'resize', update );
}, [] );

// Nachher — greift auf das Dokument des Blocks zu
import { useRefEffect } from '@wordpress/compose';

const ref = useRefEffect( ( element ) => {
    const { defaultView } = element.ownerDocument;
    const update = () => setWidth( defaultView.innerWidth );
    defaultView.addEventListener( 'resize', update );
    return () => defaultView.removeEventListener( 'resize', update );
}, [] );

const blockProps = useBlockProps( { ref } );

element.ownerDocument.defaultView liefert das Fenster des iframes. useRefEffect hängt die Listener neu an, falls das Element zwischen den Dokumenten wechselt — das passiert beim Umschalten zwischen Ansichten häufiger, als man denkt.

Editor-CSS, das nie im Inhalt ankommt

Dies ist die Bruchstelle, die am häufigsten übersehen wird, weil sie keine Fehlermeldung erzeugt: Das Styling sieht im Frontend korrekt aus und im Editor plötzlich nicht mehr. Der Grund liegt darin, welcher Hook in welches Dokument lädt.

Die Verwechslung der beiden erstgenannten Hooks ist die häufigste Ursache für fehlende Editor-Styles — die Namen unterscheiden sich um ein Wort, das Verhalten grundlegend. Wer Styles ausschliesslich im Editor braucht, nutzt enqueue_block_assets mit einer is_admin()-Abfrage.

add_action( 'enqueue_block_assets', function () {
    if ( is_admin() ) {
        wp_enqueue_style( 'meine-editor-styles' );  // landet im iframe
    } else {
        wp_enqueue_style( 'meine-frontend-styles' );
    }
} );

Ein zweiter, subtilerer Effekt betrifft altes CSS: Viele Editor-Stylesheets enthalten !important-Regeln und tiefe Verschachtelungen, die früher nötig waren, um sich gegen durchsickernde Admin-Styles zu behaupten. Der iframe verhindert dieses Durchsickern bereits. Die alten Regeln überschreiben jetzt Theme-Styles, die sie überschreiben sollten — die Editor-Vorschau weicht dadurch stärker vom Frontend ab als vorher.

Die stillen Änderungen neben dem iframe

Neben dem iframe bringt 7.1 eine Reihe von Änderungen an @wordpress/components, die kaum Aufmerksamkeit bekommen, aber eigene Editor-Oberflächen betreffen. Die Dev-Note vom 23. Juli nennt vier davon:

• 40 Pixel werden Pflicht. Die Eigenschaft __next40pxDefaultSize wird zur Wirkungslosigkeit degradiert; Formularelemente rendern unbedingt in 40 Pixel Höhe. Bei BorderBoxControl, BorderControl, FontSizePicker und ToggleGroupControl hat auch die size-Eigenschaft keine Wirkung mehr.
• Emotion weicht SCSS. Die css-Eigenschaft an der View-Komponente funktioniert nicht mehr; stattdessen style oder className verwenden. Betroffen sind unter anderem Divider, Surface, Truncate, Flex und Spacer.
• Die Navigation-Komponente ist entfernt, samt Unterkomponenten. Ersatz ist Navigator.
• __experimentalApplyValueToSides ist entfernt — ohne Ersatz.

Diese Änderungen betreffen keine gewöhnliche Unternehmenswebsite. Sie betreffen jede Website, für die jemand einmal einen eigenen Block, ein eigenes Sidebar-Panel oder eine eigene Einstellungsseite im Editor gebaut hat — und das ist bei individuell entwickelten Websites eher die Regel als die Ausnahme.

Menü, CSS und Daten: die Dev-Note vom 4. August

Eine zweite Sammelnote, veröffentlicht kurz vor dem Release Candidate, enthält drei Punkte, die über eigene Editor-Oberflächen hinausgehen. Zwei davon sind ausdrücklich Fehlerbehebungen — das ist wichtig, weil sie in Zusammenfassungen gern als Risiko dargestellt werden.

Der Navigations-Block schreibt seine Schriftgrösse nicht mehr in die Menüpunkte. Bisher wurde die eingestellte Grösse zwingend in das Markup jedes Unterblocks geschrieben. Weil relative Einheiten sich am übergeordneten Element multiplizieren, schaukelte sich das auf — die Dev-Note nennt 1.5em → 2.25em → 3.375em und spricht von schwer beschädigten verschachtelten Untermenüs. Die Grösse kommt weiterhin an, jetzt über normale CSS-Vererbung. Betroffen sind Themes, die has-{slug}-font-size direkt auf Menüpunkten ansprechen; für sie liefert die Dev-Note eine Funktion, die das alte Verhalten wiederherstellt.

Block-Voreinstellungen verlieren ihren Spezifitäts-Vorsprung. Voreinstellungen, die über settings.blocks.<block> definiert sind, stellten dem Klassennamen bisher den Blockselektor voran und lagen dadurch über den Voreinstellungen der Wurzelebene. In 7.1 wird der Blockselektor in :where() gekapselt, das keine Spezifität beiträgt:

Die Richtung ist wichtig, weil sie oft verdreht wird: Nicht Ihr CSS verliert, sondern die Block-Voreinstellung. Betroffen sind Themes und Plugins, die sich auf den bisherigen Vorsprung verlassen haben — etwa eigenes CSS, das bewusst zwischen einer Wurzel- und einer Block-Voreinstellung liegen sollte. Solche Regeln liegen jetzt bei 0-1-0 gleichauf, und über den Sieger entscheidet die Reihenfolge. Die Dev-Note stuft das Regressionsrisiko ausdrücklich als «relativ begrenzt» ein: Voreinstellungen laufen über CSS-Variablen, es ändern sich also nur die Entscheidungen bei Gleichstand und nicht die Werte selbst — und konkurriert hat ohnehin nur Autoren-CSS mit !important. Der Anlass der Änderung war, dass der alte Vorsprung die neuen responsiven Zustände in 7.1 brach.

Abfragen liefern nicht mehr nur zehn Datensätze. Mehrere REST-Endpunkte ignorierten die Parameter page und per_page schon immer und gaben die vollständige Sammlung zurück; getEntityRecords() schnitt sie anschliessend im Browser auf den Standardwert von zehn zurecht und verwarf den Rest. Das war der Fehler. Neu wird nur noch zugeschnitten, wo ein Datenbestand supportsPagination: true meldet. Es entsteht dadurch keine zusätzliche Datenbank- oder Netzlast — aber Listen im Adminbereich können deutlich mehr Einträge darstellen als vorher. Der bisher übliche Behelf per_page: -1 wird überflüssig.

Dazu vier kleinere Punkte aus derselben Note: @wordpress/nux ist ein wirkungsloses Kompatibilitätspaket und zeigt keine Hinweise mehr an — Ersatz ist die Guide-Komponente aus @wordpress/components. Die öffentlichen Schnittstellen von @wordpress/reusable-blocks schreiben Verfallswarnungen; für synchronisierte Muster sind die normalen Core-Methoden vorgesehen. __experimentalCloneSanitizedBlock und __experimentalSanitizeBlockAttributes heissen neu ohne Präfix und melden unter den alten Namen einen Verfall. Und der Markdown-Parser wechselt von showdown zu marked: Für Redaktionen ändert sich nichts, wer aber pasteHandler() direkt aufruft, sollte typische Eingaben erneut testen.

Beitragslisten: der Zeilenkopf wandert

Die zweite echte Bruchstelle steht in kaum einer Übersicht. In den Beitragslisten des Adminbereichs war bisher die Checkbox-Spalte der Zeilenkopf — das Element <th scope="row">. Mit 7.1 wandert diese Rolle in die Titelspalte, die Checkbox wird zur gewöhnlichen Zelle <td>, und der neue Zeilenkopf trägt den Beitragstitel als aria-label.

Der Grund ist Barrierefreiheit, und er leuchtet ein: Ein Screenreader nannte bisher beim Vorlesen der Zeile ein Auswahlkästchen statt des Beitrags, um den es geht. Der Preis ist, dass CSS und JavaScript, die auf th oder td in diesen Tabellen zielen, ins Leere greifen können. Betroffen sind nicht Themes, sondern Anpassungen im Adminbereich — Plugins, die Spalten hinzufügen oder umsortieren, und eigenes Admin-CSS. Wir haben die Änderung im ausgelieferten Code nachgeschlagen: In wp-admin/includes/class-wp-posts-list-table.php steht das <th scope="row"> jetzt in der Titelspalte, mitsamt dem aria-label.

Wer jetzt was tun sollte

Das Risiko verteilt sich sehr ungleich. Entscheidend ist nicht, welches Theme Sie verwenden, sondern ob jemand für Ihre Website eigenen Code im Editor hinterlassen hat.

Meta-Boxen: der verbreitete Fehlalarm

In mehreren Zusammenfassungen zu 7.1 steht, der iframe «zerstöre Meta-Boxen». Das ist überholt. Meta-Boxen waren bis WordPress 6.6 tatsächlich der Grund, aus dem der Editor gar nicht erst in einen iframe konnte — seit 6.7 löst WordPress das mit einer geteilten Ansicht: Der Inhalt läuft im iframe, die Meta-Boxen werden ausserhalb davon darunter gerendert. Beides ist gleichzeitig sichtbar.

Seit dem Field Guide vom 5. August kursiert dazu ein Satz, der wie ein Widerspruch klingt: 7.1 vollende den Wechsel including for sites that register legacy meta boxes. Gemeint ist nicht, dass Meta-Boxen nun brechen — gemeint ist, dass ihre blosse Anwesenheit eine Website nicht mehr vom iframe ausnimmt. Genau das leistet die geteilte Ansicht seit 6.7. Die eigene Dev-Note zum iframe in 7.1 zählt denn auch nur drei Bedingungen auf, die wegfallen: Theme-Typ sowie die Block-API-Version der registrierten Blöcke und jener im Inhalt. Meta-Boxen stehen nicht darunter.

Zwei enger gefasste Punkte bleiben laut der Dev-Note zu 6.7 bestehen, und nur die sollten Sie prüfen: Der Container der Meta-Boxen beschneidet überstehende Elemente — nach oben aufklappende Menüs werden abgeschnitten und sollten nach unten öffnen oder über die Popover-Komponente laufen. Und Plugins mit eigener Formatierungs-Oberfläche im Rich-Text-Feld müssen iframe-tauglich sein; dafür ist der Hook useAnchor aus @wordpress/rich-text vorgesehen.

Unabhängig von der Einstufung gilt der Grundsatz, der bei jedem grösseren Update trägt: erst auf einer Kopie, dann produktiv. Wie das ohne Ausfallzeit funktioniert, beschreiben wir im Leitfaden zu sicheren WordPress-Updates. Wenn Sie diesen Schritt nicht selbst übernehmen möchten, gehört er bei unserer WordPress-Wartung zum Standardablauf.

In zehn Minuten selbst testen, ob es Sie trifft

Dafür genügt eine Testkopie mit WordPress 7.1. Wer noch auf 7.0 steht und den Zustand vorwegnehmen möchte, erreicht dasselbe mit dem Gutenberg-Plugin ab Version 22.6 — es erzwingt den iframe bereits.

1. Testkopie anlegen — niemals auf der produktiven Website. Eine Staging-Umgebung oder eine lokale Kopie genügt.
2. Gutenberg-Plugin ab Version 22.6 installieren und aktivieren. Der Editor läuft danach im erzwungenen iframe.
3. Die drei komplexesten Seiten öffnen — jene mit eigenen Blöcken, Formularen, Meta-Boxen oder Slidern. Nicht die Startseite, sondern die Sonderfälle.
4. Browser-Konsole öffnen und mitlesen. Mit gesetztem SCRIPT_DEBUG erscheinen dort auch die Verfallswarnungen für Blöcke der Version 1 und 2.
5. Prüfen, ob der iframe aktiv ist: In den Entwicklerwerkzeugen muss ein <iframe name="editor-canvas"> auftauchen. Im eigenen Code beantwortet element.ownerDocument !== document dieselbe Frage.

Ein nützlicher Nebenbefund: Der Site-Editor läuft seit Jahren im iframe. Funktionieren Ihre Blöcke dort bereits einwandfrei, ist der grösste Teil der Arbeit schon getan.

Unsere Erfahrung aus der Praxis

Wir haben den Test an der eigenen Website durchgeführt — sie läuft seit Ende Juli 2026 auf einem selbst entwickelten Block-Theme und ist damit genau der Fall, über den dieser Beitrag spricht. Zwei Dinge waren dabei aufschlussreich.

Erstens haben wir die Behauptung «gilt für alle Themes» im ausgelieferten Code nachgeschlagen, statt sie aus Zusammenfassungen zu übernehmen. In Gutenberg 23.6.0 — der Fassung, die in WordPress 7.1 einfliesst — rendert die Editor-Komponente den Canvas mit shouldIframe: true als fest verdrahtetem Wert. Es gibt keine Abfrage mehr auf Theme-Typ und keine auf apiVersion; der Zweig für den Editor ohne iframe ist an dieser Stelle nicht mehr erreichbar. Das deckt sich mit dem Pull Request, aber nicht mit der offiziellen Roadmap vom Juni, die noch von einer Beschränkung auf Block-Themes ausging.

Zweitens haben wir die eigenen Erweiterungen geprüft — drei selbst entwickelte Blöcke, zwei davon aus einem eigenen Plugin. Das Ergebnis war unspektakulär, und genau das ist die Nachricht:

• Alle drei Blöcke stehen bereits auf apiVersion 3.
• Das Editor-JavaScript enthält keinen einzigen ungebundenen Zugriff auf document oder window — damit entfällt die häufigste Bruchstelle.
• Die Editor-Styles laufen über enqueue_block_assets mit einer is_admin()-Abfrage — also über den Hook, der im iframe ankommt, nicht über den, der es nicht tut.
• Das Theme lädt seine Editor-Styles über add_editor_style(). Kein Stylesheet hängt an enqueue_block_editor_assets.
• Im Editor-CSS kommt keine der Admin-Klassen .wp-admin, #wpadminbar oder .block-editor-page vor.

Die Prüfung hat rund eine halbe Stunde gedauert und bestand im Wesentlichen aus vier Textsuchen im eigenen Code. Das ist der Punkt, den wir mitgeben möchten: Sie müssen kein Beta-WordPress installieren, um Ihr Risiko einzuschätzen. Wer apiVersion, die verwendeten Enqueue-Hooks und die Admin-Klassen im Editor-CSS kennt, weiss vorher, ob das Update ein Ereignis wird oder nicht. Wo eine dieser Suchen einen Treffer liefert, lohnt der Test im Browser — wo alle vier leer bleiben, ist die Wahrscheinlichkeit gering.

Nachtrag vom 20. August: was das Update tatsächlich getan hat

Diese Website lief am Morgen des 20. August auf WordPress 7.1 — rund einen halben Tag nach der Veröffentlichung. Damit lässt sich die Vorhersage von oben gegen das Ergebnis halten, und das ist der ehrlichere Test als jede Prognose.

Die vier Textsuchen haben gehalten, was sie versprachen. Weil keine davon einen Treffer lieferte, war kein Eingriff nötig — und es gab keinen. Das Fehlerprotokoll des Containers zeigt für die Stunden nach dem Update keine Fatals und keine neuen Verfallswarnungen; die einzige Meldung stammt aus einem Analyse-Plugin und bestand schon vorher. Frontend und Editor arbeiten unverändert.

Das ist kein Freibrief für Ihre Website: Ein Befund ohne Treffer sagt nur, dass genau die geprüften Bruchstellen nicht vorlagen. Es ist aber ein Beleg dafür, dass die halbe Stunde Prüfung vorher den Ausschlag gibt — nicht das Bangen am Update-Tag.

Fazit

WordPress 7.1 ist kein riskantes Update — aber es ist ein anderes Update, als die verbreiteten Übersichten beschreiben. Das grosse React-Risiko ist entfallen. Geblieben ist eine Änderung, die technisch unspektakulär klingt und trotzdem genau dort zuschlägt, wo Websites individuell gebaut wurden: im Editor. Wer eigene Blöcke betreibt, hat bis zum 19. August ein offenes Testfenster. Wer eine Standardinstallation fährt, kann entspannt bleiben und ein paar Tage abwarten. Der Unterschied zwischen beiden Fällen ist in zehn Minuten geklärt — und diese zehn Minuten sind gut investiert.

Einen Überblick über die Funktionen von 7.1 — responsive Stile, die neuen Blöcke Playlist und Tabs, den Medien-Editor — geben wir im Beitrag zum WordPress-7.1-Release. Warum sich der Editor überhaupt in diese Richtung entwickelt, ordnen wir in Block-Themes statt Page-Builder ein.

Häufig gestellte Fragen zu den Änderungen in WordPress 7.1

Quellen

• Make WordPress Core — React 19: punted beyond WordPress 7.1, experiment in Gutenberg (24. Juli 2026)
• Make WordPress Core — React 19 upgrade temporarily reverted in Gutenberg (5. Juni 2026)
• Make WordPress Core — Roadmap to 7.1 (19. Juni 2026)
• Make WordPress Core — Miscellaneous Editor Changes in WordPress 7.1 (4. August 2026)
• Make WordPress Core — Editor components updates in WordPress 7.1 (23. Juli 2026)
• Make WordPress Core — WordPress 7.1 Field Guide (5. August 2026)
• Make WordPress Core — Iframed Editor Changes in WordPress 7.1 (3. August 2026)
• Make WordPress Core — Post Editor iframing with meta boxes in WordPress 6.7 (18. Oktober 2024)
• Make WordPress Core — Iframed Editor Changes in WordPress 7.0 (24. Februar 2026)
• WordPress/gutenberg auf GitHub — Post editor: always iframe (#74042) (aufgenommen am 10. Juli 2026)
• Gutenberg Times — The post editor is going full iframe: what block developers need to know before WordPress 7.1 (2026)
• Make WordPress Test — Help Test WordPress 7.1 (15. Juli 2026)
• Make WordPress Core — Post Editor iframing with meta boxes in WordPress 6.7 (18. Oktober 2024)
• WordPress Developer Resources — Hook-Referenz enqueue_block_assets