WordPress 7.1: Was am 19. August auf Ihrer Website bricht

WordPress 7.1 erscheint am 19. August 2026 — und zwei der meistgenannten Punkte zu diesem Update stimmen nicht mehr. 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 an den Editor-Komponenten

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.

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.

Zwei enger gefasste Punkte bleiben laut der offiziellen Dev-Note 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

Sie brauchen dafür weder die Beta noch den Release Candidate. Das Gutenberg-Plugin erzwingt den iframe bereits ab Version 22.6 — damit lässt sich der Zustand nach dem Update auf einer Testkopie vorwegnehmen.

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 der 19. August 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.

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 — Notes, responsives Styling, neue Blöcke — 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 — Editor components updates in WordPress 7.1 (23. Juli 2026)
• 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