ACF-Blöcke plötzlich in der Sidebar? Das steckt hinter dem WordPress-7.1-Problem und so lösen Sie es

Veröffentlicht: 01.09.2026 · Letzte Aktualisierung: 01.09.2026

Seit dem Update auf WordPress 7.1 melden viele Website-Betreiber dasselbe Phänomen: Eigene ACF-Blöcke zeigen ihre Eingabefelder nicht mehr im Block selbst, sondern schieben sie in die schmale rechte Sidebar des Editors. In manchen Konstellationen gehen Eingaben beim Speichern sogar verloren. Wer daraufhin das Theme debuggt oder Advanced Custom Fields aktualisiert, sucht an der falschen Stelle. Die Ursache liegt in WordPress selbst.

Dieser Beitrag erklärt, was in WordPress 7.1 geändert wurde, warum ausgerechnet ACF-Blöcke betroffen sind und wie Sie in wenigen Sekunden prüfen, ob Ihre Website das Problem hat. Danach folgen die Lösungswege, von der schnellen Übergangslösung bis zur sauberen Migration auf ACF Blocks V3.

Das Symptom: ACF-Felder wandern in die Sidebar

So äußert sich das Problem im Alltag: Sie fügen einen Ihrer eigenen ACF-Blöcke in einen Beitrag oder eine Seite ein. Statt der gewohnten Eingabefelder im Block erscheint im Canvas nur eine Vorschau. Die Felder tauchen stattdessen im Block-Tab der rechten Sidebar auf. Bei etwa 280 Pixeln Breite ist die Sidebar für komplexe Feldgruppen mit Repeatern oder Flexible Content praktisch unbenutzbar.

Auf manchen Installationen zeigt sich eine tückischere Variante. Die Felder nehmen Eingaben scheinbar an und zeigen sie auch an, beim Speichern gehen die Werte jedoch verloren. Der Beitrag bekommt ein neues Änderungsdatum, die Block-Attribute bleiben unverändert. Für Redakteurinnen und Redakteure sieht das aus, als wäre das Backend vom Frontend abgekoppelt. Ein Zustand, der sich kaum sinnvoll als Bugreport formulieren lässt.

Besonders verwirrend: Häufig ist nur der erste Block auf der Seite betroffen. Fügen Sie denselben Block-Typ ein zweites Mal ein, verhält sich dieser zweite Block normal. Die Asymmetrie führt fast zwangsläufig zur falschen Diagnose „Bug im eigenen Block-Code“, dabei ist der eigene Code fehlerfrei. Warum das so ist, klärt weiter unten der Abschnitt zu ACFs mode-Attribut.

Wer betroffen ist und wer nicht

Der Schaden ist enger begrenzt, als die Symptome vermuten lassen. Das macht die Fehlersuche nicht leichter, sondern schwerer, weil das meiste auf der Website normal weiterläuft:

• Nicht betroffen: alle Core-Blöcke von WordPress (Absatz, Überschrift, Bild, Galerie und so weiter).
• Nicht betroffen: native Custom Blocks mit eigener React-edit-Komponente. Sie wurden von vornherein für den iframe-Canvas gebaut.
• Nicht betroffen: klassische ACF-Feldgruppen an Seiten, Beiträgen oder Custom Post Types. Sie rendern als Metaboxen außerhalb des Canvas, der iframe erreicht sie gar nicht.
• Betroffen: ausschließlich eigene ACF-Blöcke, die mit Block-Version 1 oder 2 registriert sind. Und hier liegt der entscheidende Punkt: Version 2 ist der Standard, wenn Ihre block.json weder apiVersion noch acf.blockVersion angibt. Also genau die minimale Konfiguration, die praktisch jedes ACF-Tutorial zeigt.

Registriert Ihre Website keine eigenen ACF-Blöcke, betrifft Sie das Thema nicht. Aktualisieren Sie WordPress dann ganz normal.

Die Ursache: WordPress 7.1 erzwingt den iframe-Canvas

Bis einschließlich WordPress 7.0.2 entschied der Editor pro Beitrag, ob der Canvas, also die eigentliche Bearbeitungsfläche, in einem iframe gerendert wird oder direkt im Admin-Dokument. Die Logik dafür steckte in einem internen Hook namens useShouldIframe. Eine der Bedingungen lautete sinngemäß: Der Canvas wird nur dann geiframed, wenn alle im Beitrag vorhandenen Blöcke mindestens API-Version 3 deklarieren, also als iframe-kompatibel markiert sind.

Ein einziger Block mit API-Version 2 irgendwo im Beitrag genügte, ein ACF-Block zum Beispiel, und der gesamte Canvas blieb un-geiframed. Auf dieser Ausnahmeregel standen klassische Themes mit ACF-Blöcken jahrelang, die meisten ohne es zu wissen. Im Quellcode des Editors stand übrigens seit langem ein Kommentar mit der Ankündigung, dass der iframe künftig verpflichtend wird. Allerdings nur im kompilierten JavaScript-Bundle, das in der Praxis niemand liest.

Was WordPress 7.1 konkret entfernt hat

Mit WordPress 7.1, erschienen am 19. August 2026, ist diese bedingte Logik komplett verschwunden. Der Hook useShouldIframe existiert im 7.1-Build nicht mehr, ebenso wenig der Selektor hasV3BlocksOnly und die Eigenschaft disableIframe. Stattdessen übergibt der Editor dem Canvas einen fest verdrahteten Wert: shouldIframe: true. Es gibt keinen Filter, keine Konstante und keine Einstellung, um das abzuschalten, weder auf PHP- noch auf JavaScript-Seite.

Das Ziel der Änderung ist nachvollziehbar. Der iframe isoliert den Canvas vom WordPress-Admin: Nur die Skripte und Styles des Themes werden darin geladen, nichts aus wp-admin gelangt mehr in die Vorschau. Der Editor zeigt dadurch präziser, wie die Seite im Frontend aussieht. Für block-native Entwicklung ist das ein Fortschritt. Für alles, was auf wp-admin-Skripte im Canvas angewiesen war, ist es das Ende einer stillschweigenden Duldung.

Warum ACF-Blöcke der Version 2 im iframe scheitern

Ein ACF-Block der Version 1 oder 2 rendert sein Bearbeitungsformular als gewöhnliches Markup, angetrieben von ACFs jQuery-basierter Feldlogik, im selben Dokument wie der Rest des Admins. Dazu gehören auch WordPress-Bibliotheken wie der klassische WYSIWYG-Editor oder jQuery-UI-Datepicker. Ein geiframter Canvas ist aber ein separates Dokument. Diese Bibliotheken sind dort schlicht nicht vorhanden, ACFs Feld-Maschinerie findet keinen Ankerpunkt.

ACFs dokumentierter Fallback für diesen Fall: Die Felder werden in die InspectorControls gerendert, also in die rechte Sidebar. Was Sie sehen, ist kein Absturz. Es ist ein Fallback, der genau das tut, wofür er geschrieben wurde, nur in einer Situation, für die ihn niemand vorgesehen hatte. ACF formuliert es in der Ankündigung zu Version 6.8.9 offen: Der V2-Edit-Modus, der Admin-Skripte in die Vorschaufläche injizierte, stand schon immer im Widerspruch zur Richtung, in die sich der Block-Editor entwickelt. WordPress 7.1 ist der Punkt, an dem dieser Widerspruch nicht mehr auflösbar war.

Die zweite Ursache: ACF setzt den Modus auf „preview“ zurück

Unabhängig vom iframe gibt es ein zweites, älteres Verhalten. Es vervollständigt das Bild und löst zugleich das Rätsel „Warum nur der erste Block?“. ACF liest den Anzeigemodus eines Blocks (edit oder preview) zur Laufzeit nicht aus der block.json. Stattdessen schreibt ACF ein mode-Attribut in jede Block-Instanz und speichert es im Beitragsinhalt. Verliert ein Block den Fokus, weil Sie woanders hinklicken, etwa um einen zweiten Block einzufügen, kann dieser Wert auf preview kippen und bleibt dann dauerhaft im gespeicherten Inhalt stehen.

Deshalb wirkt der zuerst eingefügte Block „kaputt“ und der zuletzt eingefügte normal: Der erste hat als erster den Fokus verloren. Mit dem Block-Typ hat das nichts zu tun, nur mit der Einfüge-Reihenfolge. Der übliche Rat, den Modus per Stift-Symbol in der Block-Toolbar zurückzuschalten, hilft oft nicht weiter. Die verbreitete und an sich sinnvolle Einstellung "supports": { "mode": false } entfernt genau diesen Umschalter.

In zehn Sekunden prüfen, ob Ihre Website betroffen ist

Zwei Kommandos im WordPress-Root genügen. Beide lesen nur Core-Dateien und ändern nichts:

grep -c "shouldIframe" wp-includes/js/dist/editor.js
grep -rl "disableIframe" wp-includes/js/dist/

Auf WordPress 7.0.2 listet das zweite Kommando vier Dateien. Auf 7.1 listet es keine einzige, weil disableIframe in den Editor-Bundles nicht mehr existiert. Kein Treffer plus ACF-Blöcke der Version 1/2 im Einsatz bedeutet: Sie haben exakt das hier beschriebene Problem.

Der Praxistest im Editor: Legen Sie einen Testbeitrag an und fügen Sie denselben ACF-Block dreimal ein. Wechseln Sie den Fokus zwischen den Blöcken und heben Sie die Auswahl auf. Bleiben alle Felder inline im Block und erscheint nirgends die Klasse acf-block-preview, ist Ihre Konfiguration in Ordnung. Wandern Felder in die Sidebar oder kippt ein Block in die Vorschau, sind Sie betroffen.

Die Lösungswege im Überblick

Wichtig vorab: Ein ACF-Update auf 6.8.8 oder älter ändert nichts, denn der Standardwert für die Block-Version (2) ist dort identisch. Erst mit ACF PRO 6.8.9, erschienen am 27. August 2026, hat der Hersteller reagiert. Damit gibt es vier gangbare Wege, sortiert von „empfohlen“ bis „Notnagel“.

Weg A (empfohlen): ACF PRO auf 6.8.9 aktualisieren

Seit ACF PRO 6.8.9 gilt: Jeder ACF-Block, der keine explizite Version deklariert, wird auf WordPress 7.1 und neuer automatisch als V3-Block registriert. V3 ist für den iframe-Canvas gebaut und funktioniert dort korrekt. Für die Mehrheit der Installationen, nämlich alle mit dem unveränderten Standard, löst das Update das Problem ohne eine Zeile eigenen Code.

Was sich dadurch ändert, ist die Bearbeitungs-Erfahrung. V3-Blöcke zeigen im Canvas standardmäßig eine Vorschau, ein Klick auf das Stift-Symbol öffnet den Expanded Editor: ein großzügiges Panel neben der Block-Vorschau, deutlich komfortabler als die schmale Sidebar, gerade bei Repeatern und Flexible Content. Optional lässt sich zusätzlich Inline-Editing aktivieren (ab ACF PRO 6.7). Textfelder werden dann direkt in der Block-Vorschau editierbar.

Zwei Details aus 6.8.9 sind für Umsteiger wichtig:

• Blöcke mit dem alten Muster "mode": "edit" plus "supports": { "mode": false }, also dauerhaft gesperrter Bearbeitungsmodus, zeigen als V3 automatisch einen sauberen Platzhalter mit Block-Titel und „Bearbeiten“-Button statt einer möglicherweise kaputten Vorschau.
• Für neue Blöcke gibt es die offiziell unterstützte Eigenschaft "acf": { "renderPreview": false } in der block.json. Der Block springt dann direkt in den Expanded Editor. Das ist der zukunftssichere Ersatz für den alten Formular-Workflow.

Achtung: Blöcke, die explizit acf.blockVersion: 1 oder 2 deklarieren, bleiben auch unter 6.8.9 auf V2 und damit im Sidebar-Problem. Diese Blöcke müssen einzeln migriert werden, siehe Weg D.

Weg B (Übergang): das offizielle Kompatibilitäts-Plugin

Wer mehr Zeit für die Migration braucht, etwa Agenturen mit dutzenden Kundenprojekten und geschulten Redaktionen, bekommt von ACF eine offizielle Brücke: das Plugin acf-blocks-v2-iframe-compatibility auf GitHub. Es stellt das V2-Bearbeitungsverhalten unter WordPress 7.1 wieder her. Alternativ hält der Filter acf/blocks/default_block_version den bisherigen Standard global fest.

ACF sagt dazu selbst sehr deutlich: Das ist eine temporäre Brücke, kein Dauerzustand. Einzelne Funktionen können unsauber laufen, und mit künftigen Core-Versionen kann der Ansatz ganz aufhören zu funktionieren. Planen Sie die V3-Migration also parallel. Das Plugin kauft Zeit, gelöst ist damit nichts.

Weg C (Notnagel): WordPress auf 7.0.2 zurückrollen

Der viel geteilte englischsprachige Erfahrungsbericht zu diesem Thema empfiehlt, den Core per wp core update --version=7.0.2 --force auf die Vorversion zu pinnen und Auto-Updates zu deaktivieren, kombiniert mit einem kleinen Editor-Skript, das das mode-Attribut der eigenen Blöcke dauerhaft auf edit zwingt. Technisch funktioniert das. Als Akut-Maßnahme auf einer Live-Site, deren Redaktion sofort weiterarbeiten muss, ist es legitim. Vorher zwingend: Datenbank-Export und Core-Backup, denn einen offiziellen Weg, das Datenbankschema rückwärts zu migrieren, gibt es nicht.

Aus Wartungs- und Sicherheitssicht raten wir davon ab, diesen Zustand stehen zu lassen. Eine gepinnte Core-Version erhält keine Sicherheitsupdates mehr, und bei der Angriffsfrequenz auf WordPress-Installationen ist das ein reales Risiko, das mit jeder Woche wächst. Ende August war der Rollback die einzige Option. Seit ACF 6.8.9 mit V3-Default und Kompatibilitäts-Plugin gibt es bessere. Wenn Sie aktuell auf 7.0.2 gepinnt sind: Nutzen Sie die gewonnene Zeit für Weg A oder B und heben Sie den Pin danach wieder auf.

Weg D (Ziel): saubere Migration auf ACF Blocks V3

Mittelfristig führt kein Weg an V3 vorbei. Laut ACF ist es die einzige Bearbeitungs-Architektur, die im iframe-Editor korrekt funktioniert und mit der weiteren Core-Entwicklung funktionieren wird. Die Migration im Kern:

• In der block.json jedes Blocks "acf": { "blockVersion": 3 } setzen, bei PHP-Registrierung entsprechend acf_block_version. Voraussetzung ist ACF PRO 6.6 oder neuer.
• Für viele Blöcke auf einmal genügt ein Filter im Theme oder Plugin:

  add_filter( 'acf/blocks/default_block_version', function() {
      return 3;
  } );

  Blöcke mit explizit gesetzter Version bleiben davon unberührt und brauchen ein individuelles Update.

• Danach im Editor testen: Vorschau-Rendering prüfen, Expanded Editor durchklicken, bei Formular-Blöcken renderPreview: false erwägen, Redaktion über den neuen Workflow informieren.

Den vollständigen Migrationsleitfaden pflegt ACF in der offiziellen Blocks-V3-Dokumentation.

Was nachweislich nicht hilft

• ACF auf 6.8.8 oder älter aktualisieren. Der Block-Version-Default (2) ist bis einschließlich 6.8.8 unverändert, das Problem bleibt identisch bestehen.
• Den eigenen Block-Code debuggen. Der Code ist nicht defekt. Betroffene und funktionierende Blöcke können byte-identisch konfiguriert sein. Der Unterschied liegt im gespeicherten mode-Attribut und in der WordPress-Version.
• Den Modus-Umschalter in der Toolbar klicken. Bei "supports": { "mode": false } existiert der Umschalter nicht, und genau diese Einstellung ist in Formular-Blöcken die Regel.
• Auf einen Opt-out-Filter in WordPress hoffen. Es gibt keinen. Weder PHP noch JavaScript bieten in 7.1 eine Möglichkeit, den iframe abzuschalten.
• Das Classic-Editor-Plugin als Dauerlösung. Es umgeht den Block-Editor komplett. Damit verlieren Sie die Blöcke als Bearbeitungskonzept, statt sie zu reparieren.

Was das für Redaktionen bedeutet

Der technische Fix ist die eine Hälfte, der Workflow Ihrer Redaktion die andere. Der V2-Edit-Modus war beliebt, weil er Content-Teams eine klassische Formular-Erfahrung gab: Felder ausfüllen, speichern, fertig, ohne über das Frontend-Aussehen nachzudenken. Viele Agenturen haben hunderte Kunden genau darauf geschult.

Mit V3 ändert sich das Modell: Vorschau im Canvas, Bearbeitung im Expanded Editor oder inline direkt im Block. Nach kurzer Eingewöhnung ist das Panel bei komplexen Feldgruppen komfortabler als die alten Inline-Felder. Die Umstellung ist trotzdem real, denn Redaktionshandbücher wollen aktualisiert und Teams eingewiesen werden. Planen Sie das als Teil der Migration ein, nicht als Nachgedanken. Für Blöcke, bei denen die Vorschau keinen Mehrwert hat, etwa reine Daten-Blöcke, ist renderPreview: false die richtige Wahl. Die Redaktion landet dann direkt im Formular, wie früher.

Einordnung: kein Bug, sondern eine Weichenstellung

So ärgerlich der Moment ist, in dem die eigenen Blöcke „kaputt“ wirken: Hier ist nichts kaputtgegangen. WordPress hat eine lange angekündigte Architektur-Entscheidung vollzogen, und ACF hat innerhalb einer guten Woche mit einem neuen Default, einem Kompatibilitäts-Plugin und einer klaren Migrationsempfehlung reagiert. Die eigentliche Lehre für Betreiber liegt woanders. Der stillschweigende Standard „keine Version angeben“ stand jahrelang auf einer Ausnahmeregel im Core, von der kaum jemand wusste. Explizite Versionsdeklarationen in der block.json und ein Testlauf auf einer Staging-Umgebung vor jedem Major-Update hätten das Problem sichtbar gemacht, bevor es die Live-Site trifft.

Genau dafür gibt es gemanagte WordPress-Wartung: Major-Updates auf Staging testen, Inkompatibilitäten erkennen, bevor Redaktionen sie erleben, und Migrationspfade planen statt Feuerwehr zu spielen. Wenn Ihre Website eigene ACF-Blöcke einsetzt und Sie unsicher sind, ob Sie betroffen sind: Im Rahmen unserer WordPress-Wartung prüfen wir Ihre Blöcke, spielen die passende Lösung ein und begleiten die V3-Migration.

Häufige Fragen (FAQ)

Warum sind meine ACF-Felder plötzlich in der Sidebar?

WordPress 7.1 rendert den Editor-Canvas immer in einem iframe. ACF-Blöcke der Version 1/2 können ihr Bearbeitungsformular dort nicht darstellen und weichen als dokumentierten Fallback auf die rechte Sidebar aus. Ursache ist die Core-Änderung, nicht Ihr Theme und nicht ACF.

Ist das ein Bug in ACF oder in meinem Theme?

Nein. Weder ACF noch Ihr Block-Code haben sich geändert. WordPress 7.1 hat die bedingte iframe-Logik (useShouldIframe) entfernt und erzwingt den iframe ausnahmslos. ACF-V2-Blöcke verhalten sich darin exakt so, wie ihr Fallback es vorsieht.

Reicht es, ACF zu aktualisieren?

Ja, aber erst ab ACF PRO 6.8.9 vom 27.08.2026. Diese Version registriert Blöcke ohne explizite Versionsangabe auf WordPress 7.1 und neuer automatisch als iframe-kompatible V3-Blöcke. Updates auf 6.8.8 oder älter ändern nichts am Problem. Blöcke mit explizit gesetzter Version 1/2 müssen zusätzlich manuell migriert werden.

Kann ich WordPress gefahrlos auf 7.0.2 zurückrollen?

Als Akut-Maßnahme mit vorherigem Datenbank-Export und Core-Backup: ja. Als Dauerzustand: nein, denn eine gepinnte Core-Version erhält keine Sicherheitsupdates. Seit ACF 6.8.9 gibt es mit dem V3-Default und dem offiziellen Kompatibilitäts-Plugin bessere Optionen.

Was ist ACF Blocks V3?

Die aktuelle Block-Architektur von ACF ab Version 6.6, gebaut für den iframe-Editor. Statt Inline-Feldern im Canvas bietet V3 eine Block-Vorschau plus einen großzügigen Expanded Editor. Optional sind Inline-Editing ab 6.7 und ein Vorschau-freier Formular-Modus per renderPreview: false ab 6.8.9 verfügbar.

Sind normale ACF-Felder an Seiten und Beiträgen auch betroffen?

Nein. Klassische Feldgruppen rendern als Metaboxen außerhalb des Editor-Canvas und funktionieren unter WordPress 7.1 unverändert. Betroffen sind ausschließlich als Block registrierte ACF-Feldgruppen der Version 1/2.

Quellen: make.wordpress.org, Iframed editor changes in WordPress 7.1 · ACF PRO 6.8.9 Release Notes · ACF Blocks V3 Dokumentation · Fallstudie maxsoskind.org vom 20.08.2026 · Gutenberg Times, Full-iframe Walkthrough