WordPress 7.1 Update: Breaking Changes

Einordnung

WordPress 7.1 ist am 19. August 2026 erschienen, drei Monate nach dem großen 7.0-Release. Wer den Sprung von 6.x auf 7.0 noch vor sich hat, findet die Anforderungen und die Vorbereitungsschritte in der Checkliste zum 7.0-Update. Dieser Artikel setzt eine laufende 7.0-Installation voraus und behandelt nur, was in 7.1 dazugekommen ist.

Der Vorfall rund um WP Rocket hat dem Release zusätzliche Aufmerksamkeit verschafft, allerdings nicht die erfreuliche Sorte. Dazu weiter unten mehr.

Die wichtigsten Änderungen

Erzwungener iframed Editor, auch für Legacy-Metaboxen

Bisher fiel der Block-Editor auf eine nicht-iframed Darstellung zurück, sobald klassische Metaboxen registriert waren. Dieser Fallback entfällt. Der Editor läuft künftig immer in einem iframe.

Das ist die Änderung mit dem größten Bruchpotenzial. Betroffen ist jedes Plugin und jedes Theme, dessen JavaScript oder CSS davon ausgeht, im selben Dokument wie der Editor zu laufen. Typische Symptome: Skripte finden ihre Zielelemente nicht mehr, Styles greifen nicht, jQuery-Selektoren laufen ins Leere.

Konkret zu prüfen:

Alles, was document.querySelector auf Editor-Elemente anwendet
Styles, die über admin_enqueue_scripts statt über enqueue_block_assets eingebunden werden
ACF-Felder mit eigenem JavaScript
Custom Metaboxen mit Farbwählern, Datepickern oder Media-Uploadern

Styles korrekt einbinden

Der Unterschied zwischen den beiden Hooks entscheidet darüber, ob deine Styles im iframe ankommen. admin_enqueue_scripts lädt in das Admin-Dokument, also außerhalb des iframes. enqueue_block_assets lädt im Block-Editor in das iframe-Dokument selbst und im Frontend zusätzlich auf der Seite:

<?php
// Falsch ab WordPress 7.1: landet im Admin-Dokument, nicht im Editor-iframe
add_action( 'admin_enqueue_scripts', function () {
    wp_enqueue_style( 'devslab-editor', get_theme_file_uri( 'assets/editor.css' ), [], '1.0' );
} );

// Richtig: wird im Editor-iframe und im Frontend geladen
add_action( 'enqueue_block_assets', function () {
    wp_enqueue_style( 'devslab-blocks', get_theme_file_uri( 'assets/blocks.css' ), [], '1.0' );
} );

// Nur im Editor, nicht im Frontend: läuft weiterhin im Admin-Dokument.
// Für reine Editor-UI (Sidebar-Panels, Toolbar) ist das genau richtig,
// für Block-Darstellung im Canvas nicht.
add_action( 'enqueue_block_editor_assets', function () {
    wp_enqueue_script(
        'devslab-editor-ui',
        get_theme_file_uri( 'assets/editor-ui.js' ),
        [ 'wp-plugins', 'wp-edit-post', 'wp-element' ],
        '1.0',
        true
    );
} );

Als Faustregel: Alles, was aussehen soll wie im Frontend, gehört in enqueue_block_assets. Alles, was die Editor-Oberfläche drumherum betrifft, bleibt in enqueue_block_editor_assets.

Aus dem iframe heraus auf das richtige Dokument zugreifen

Der zweite Stolperstein ist JavaScript, das mit document arbeitet. Innerhalb des Editor-iframes zeigt document weiterhin auf das Admin-Dokument, wenn das Skript dort geladen wurde. Der Canvas liegt in einem anderen Dokument:

// Brüchig: findet den Block nicht mehr, sobald der Editor iframed läuft
const block = document.querySelector( '.wp-block-devslab-teaser' );

// Robust: erst das Canvas-Dokument bestimmen, dann darin suchen
function getEditorDocument() {
  const canvas = document.querySelector( 'iframe[name="editor-canvas"]' );
  return canvas?.contentDocument ?? document;
}

const editorDoc = getEditorDocument();
const block = editorDoc.querySelector( '.wp-block-devslab-teaser' );

// Aus einem Skript, das bereits im iframe läuft, zurück ins Admin-Dokument:
const adminDoc = window.parent.document;

Wichtig ist das Timing: Das iframe existiert nicht sofort beim Laden der Seite. Wer beim Initialisieren danach sucht, bekommt null. Entweder auf ein Editor-Ereignis warten oder das Skript gleich über enqueue_block_assets in das iframe laden lassen, dann entfällt der ganze Umweg.

Geänderte Hook-ID-Generierung

Die interne ID, die WordPress für registrierte Hooks vergibt, kam bei Closures bis 7.0 aus spl_object_hash() und war damit immer ein 32 Zeichen langer Hex-String. 7.1 stellt auf spl_object_id() um, das eine kleine Zahl liefert. Weil PHP rein numerische Strings als Array-Schlüssel automatisch zu Integer castet, steht in $wp_filter ab 7.1 ein Integer statt eines Strings.

Das klingt nach einem Detail, das niemanden interessiert, und für die allermeisten Projekte stimmt das auch. Relevant wird es überall dort, wo Code über $wp_filter iteriert und die Keys als Strings behandelt. Unter PHP 8 mit declare(strict_types=1) führt das zu einem TypeError statt zu einem stillen Type-Cast.

<?php
// Riskant unter WordPress 7.1
foreach ( $wp_filter[ $hook ]->callbacks[ $priority ] as $key => $cb ) {
    if ( substr( $key, 0, 8 ) === 'devslab_' ) { /* ... */ }
}

// Robust
foreach ( $wp_filter[ $hook ]->callbacks[ $priority ] as $key => $cb ) {
    if ( str_starts_with( (string) $key, 'devslab_' ) ) { /* ... */ }
}

Genau dieser Fall hat WP Rocket getroffen und tausende Websites lahmgelegt. Wenn du eigenen Code hast, der $wp_filter durchläuft, prüf ihn. Die Details und die Soforthilfe für betroffene Seiten stehen in WP Rocket Fatal Error nach WordPress 7.1.

Neue Block-Supports

Background Gradients als Block-Support, nicht mehr nur über eigene Styles
Minimum Width als Dimension-Support
Bearbeitbare Blöcke innerhalb des Custom HTML Blocks

Für Theme-Entwickler bedeutet das: Einige Dinge, die bisher über eigene Attribute und Render-Callbacks gelöst wurden, lassen sich jetzt deklarativ in der block.json abbilden.

Was das für ein Timber/Twig-Setup bedeutet

In einem Setup mit Custom Gutenberg Blocks mit Timber und Twig wandert damit Konfiguration aus dem PHP-Render-Callback in die block.json:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "devslab/teaser",
  "title": "Teaser",
  "category": "devslab",
  "supports": {
    "color": {
      "background": true,
      "gradients": true
    },
    "dimensions": {
      "minHeight": true,
      "minWidth": true
    }
  }
}

Im Twig-Template ändert sich dadurch weniger, als man erwartet: WordPress liefert die generierten Klassen und Inline-Styles über get_block_wrapper_attributes(), und das Template muss sie nur durchreichen. Wer die Wrapper-Attribute bisher von Hand zusammengebaut hat, verliert genau hier die neuen Supports:

<?php
// Render-Callback: Wrapper-Attribute an Twig übergeben, nicht selbst bauen
$context = Timber::context();
$context['attributes'] = $attributes;
$context['wrapper']    = get_block_wrapper_attributes( [ 'class' => 'teaser' ] );

Timber::render( 'blocks/teaser.twig', $context );

{# blocks/teaser.twig #}
<article {{ wrapper|raw }}>
  <h2 class="teaser__title">{{ attributes.title|e }}</h2>
</article>

Der Filter |raw ist hier bewusst gesetzt, weil get_block_wrapper_attributes() bereits fertig escaptes Markup liefert. Für den eigentlichen Inhalt bleibt es bei |e.

Globale Styles: Responsive Variationen

Style-Variationen lassen sich jetzt responsive definieren, mit konfigurierbaren Viewports. Zusätzlich gibt es Unterstützung für Text-Shadow.

Abilities API erweitert

Die in 7.0 eingeführte Abilities API wurde um bessere Discovery, Validierung und Integration externer Clients erweitert, inklusive Vorbereitung auf JSON-Schema. Für Projekte, die WordPress als Backend für externe Anwendungen nutzen, lohnt hier ein genauerer Blick.

20 neue Hooks

19 Filter und eine Action sind dazugekommen. Die vollständige Liste steht im Field Guide, der unten verlinkt ist. Für den Update-Test relevanter als die neuen Hooks ist die Frage, ob bestehende Hooks in deinem Code weiterhin greifen.

jQuery UI auf 1.14.2

Betrifft alles, was auf jQuery UI aufbaut, insbesondere ältere Plugins mit Datepickern und Sortable-Listen. In der Regel unproblematisch, aber ein Punkt für die Testliste.

Block-Styles werden bedarfsabhängig geladen

Gut für die Performance, potenziell problematisch dort, wo Inhalte per AJAX oder aus externen Quellen nachgeladen werden und die zugehörigen Styles dann fehlen.

Update-Checkliste für 7.1

Auf Staging updaten, nie direkt auf Produktion.
Alle Plugins mit eigenem Editor-JavaScript öffnen und den Editor tatsächlich benutzen, nicht nur laden.
Eigenen Code auf $wp_filter-Iterationen durchsuchen.
Custom Metaboxen im Editor prüfen, besonders mit Media-Upload und Datepicker.
Frontend-Ansicht auf fehlende Block-Styles prüfen, vor allem bei nachgeladenen Inhalten.
WP Rocket auf mindestens 3.23.2.2 aktualisieren, falls im Einsatz.
Eine Testseite mit jedem selbst gebauten Block durchklicken.
Erst dann auf Produktion ausrollen.

Der vollständige Ablauf dahinter, von der Inventur bis zum Rollback-Plan, steht in WordPress-Updates sicher ausrollen. Zum Abhaken während des Rollouts gibt es die druckbare Update-Checkliste.

Fazit

7.1 ist technisch ein ruhiges Release mit einer unruhigen Nebenwirkung. Der erzwungene iframed Editor ist die Änderung, die am ehesten etwas kaputt macht, und sie betrifft ausgerechnet die Plugins, die mit Custom Fields und eigenen Metaboxen arbeiten, also genau die in professionellen Projekten üblichen.

WordPress 7.1: Was sich ändert und worauf Entwickler achten müssen