{„cover“:“Professional landscape format (1536×1024) hero image with bold text overlay ‚WordPress Gutenberg Update Fehler‘ in crisp white sans-serif on a deep semi-transparent dark navy overlay panel, centered with 8% safe margins from every edge. Background: dramatic editorial shot of a modern developer workspace showing a large monitor with a WordPress block editor displaying broken, empty blocks and a red error notification, dark moody studio lighting with accent blue and orange highlights, sharp editorial magazine-cover aesthetic, high contrast, professional tech photography quality.“,“content“:[„Numbered step-by-step process flow diagram (1536×1024), clean white background with teal and dark blue palette. Four stages shown as connected horizontal arrows: Stage 1 labeled ‚Update auslösen‘, Stage 2 ‚Block-Fehler erscheint‘, Stage 3 ‚Konflikt identifizieren‘, Stage 4 ‚Editor wiederhergestellt‘. Each stage has a small icon above it and 3-4 short German bullet labels beneath (e.g., ‚Plugin-Konflikt‘, ‚JS-Fehler‘, ‚Leerer Editor‘). Thin callout lines point to annotated details. Editorial infographic style, crisp typography, no pricing or dollar amounts.“,“Split-screen comparison (1536×1024) in sharp editorial style: left half shows a WordPress block editor with visually empty grey placeholder blocks and a browser console open showing a red JavaScript TypeError message, labeled in German ‚Leere Blöcke, Plugin-Konflikt‘. Right half shows the same editor fully restored with colorful content blocks and a green success indicator, labeled ‚Editor wiederhergestellt‘. Center dividing line with a small contrast arrow. Dark background on left, bright clean background on right. Teal and orange accent colors, magazine quality.“,“Annotated mechanism diagram (1536×1024) showing the WordPress Gutenberg rollback process as a vertical flowchart on a light grey background. Five numbered steps with short German labels: ‚1 Backup erstellen‘, ‚2 Plugin deaktivieren‘, ‚3 WP Rollback nutzen‘, ‚4 Cache leeren‘, ‚5 Editor testen‘. Each step has a small flat icon and a thin callout line pointing to a brief 2-4 word German annotation explaining the action. Navy blue and amber color palette, clean sans-serif typography, editorial infographic quality.“,“Four-panel labelled comparison guide (1536×1024) on a clean white background with navy and green palette. Panel 1: ‚Classic Editor Plugin‘ with 3 German bullet labels (‚Schnelle Lösung‘, ‚Kein Datenverlust‘, ‚Temporär nutzbar‘). Panel 2: ‚Gutenberg deaktivieren‘ with labels (‚Plugin-basiert‘, ‚Sofort wirksam‘, ‚Flexible Rückkehr‘). Panel 3: ‚Theme wechseln‘ with labels (‚Block-kompatibel‘, ‚Layouts intakt‘, ‚Getestet‘). Panel 4: ‚Profi-Hilfe holen‘ with labels (‚Expertenanalyse‘, ‚Schnelle Behebung‘, ‚Garantie‘). Each panel separated by thin lines, small icons above each heading, editorial flat-design style.“,“Annotated documentary-style editorial photograph (1536×1024): a close-up overhead flat-lay of a desk showing a laptop screen with WordPress admin dashboard open displaying a Gutenberg editor crash screen. A printed checklist sheet is partially visible with German headings (‚Vor dem Reset‘, ‚Plugins prüfen‘, ‚Backup gesichert‘). A coffee mug and a USB drive sit nearby. Warm natural studio lighting, shallow depth of field on the screen. Three small floating callout labels in German point to: ‚Debug-Modus aktiv‘, ‚Backup vorhanden‘, ‚Plugin-Konflikt‘. Magazine editorial quality, warm amber tones.“]
Zuletzt aktualisiert: 20. Oktober 2026
Quick Answer: WordPress Gutenberg Update Fehler wie leere Blöcke, kaputte Layouts und Editor-Abstürze entstehen fast immer durch JavaScript-Konflikte zwischen dem Block-Editor und einem Plugin oder Theme, die Inhalte in der Datenbank sind dabei in der Regel unversehrt. Der schnellste Weg zur Wiederherstellung: zuerst alle nicht zwingend nötigen Plugins deaktivieren, dann den Verursacher isolieren und entweder zurückrollen oder durch eine kompatible Version ersetzen. Ein vollständiges Datenbank-Backup ist vor jedem Eingriff Pflicht.
Key Takeaways
- Leere Blöcke bedeuten keinen Datenverlust, die Inhalte liegen weiterhin in der Datenbank, nur der Editor-UI zeigt sie nicht an [1][2]
- Die häufigste Ursache sind Plugin-Konflikte (z. B. Yoast SEO, Page-Builder-Plugins), nicht fehlerhafter WordPress-Core [2]
- Vor jedem Zurücksetzen unbedingt ein vollständiges Backup erstellen, am besten über ein Backup-Plugin oder per Hosting-Panel
- Das WP Rollback Plugin erlaubt das gezielte Zurücksetzen einzelner Plugins oder Themes, ohne die Datenbank anzufassen [3]
- Wer den Gutenberg-Editor vorübergehend abschalten will, kann Plugins wie Disable Gutenberg oder Relive Classic nutzen [4]
- Theme-Konflikte können genauso kritisch sein wie Plugin-Konflikte, insbesondere wenn
remove_theme_support('block-templates')gesetzt ist [5] - Ein JavaScript-Fehler im Browser-Konsolenfenster liefert den schnellsten Hinweis auf den eigentlichen Verursacher
- Gutenberg 24.2 (Oktober 2026) enthält aktive Stabilitätsfixes für Editor-Abstürze bei fehlenden Block-Selektoren [6]
- Bei hartnäckigen Fehlern lohnt sich der Wechsel auf ein Gutenberg-kompatibles Theme wie Twenty Twenty-Five
- Professionelle Hilfe ist bei Shop-Seiten oder komplexen Layouts oft die zeitsparendste Option
Warum werden meine Gutenberg-Blöcke nach einem Update plötzlich leer?
Leere Blöcke im WordPress-Editor sind nach einem Update fast immer ein UI-seitiges JavaScript-Problem, keine echte Datenpanne. Die Blockinhalte liegen sicher in der Datenbank, nur der Editor kann sie gerade nicht korrekt rendern.
Die typischsten Auslöser:
- Plugin-Konflikte: Ein Plugin lädt JavaScript, das mit der neuen Gutenberg-Version kollidiert. Ein bekanntes Beispiel aus der Community: Yoast SEO Premium 21.7 erzeugte in Kombination mit Gutenberg 17.3-17.4 einen
TypeError: e.replace is not a function, der den Editor komplett leer wirken ließ [2] - Theme-Konflikte: Themes, die
remove_theme_support('block-templates')verwenden, können nach einem Gutenberg-Update dazu führen, dass der gesamte Block-Editor leer erscheint, andere Post-Typen funktionieren dabei weiterhin normal [5] - Veraltete Block-API-Versionen: Plugins, die noch die alte
apiVersion: 1verwenden, aber in einem Iframe-basierten Editor mitapiVersion: 3laufen, können zu fatalen JS-Abstürzen führen [7] - Deprecated APIs: Seit neueren Gutenberg-Versionen wurden APIs wie
wp.blocks.isValidBlockContententfernt; Plugins, die diese noch nutzen, erzeugen ungültige oder „leere“ Block-Inhalte [8]
Wichtig: Einfach im Classic Editor oder direkt in der Datenbank prüfen, ob die Inhalte noch da sind, das beruhigt sofort [1].
Was verursacht Gutenberg-Editor-Abstürze und das Einfrieren?
Gutenberg-Abstürze passieren, wenn JavaScript-Ausnahmen im Editor nicht abgefangen werden. Das Ergebnis: der Editor friert ein, zeigt eine weiße Fläche oder meldet einen kritischen Fehler.
Ein konkretes Beispiel aus Oktober 2026: Ein bestätigter Bug ließ den Editor abstürzen, sobald kein Block ausgewählt war, der Pull Request „Style states: fix exception when there’s no selected block“ (Gutenberg 24.2) behebt genau diesen Fall [6]. Solche Bugs entstehen, weil der Editor intern mit clientId arbeitet und bei einem undefinierten Wert eine Ausnahme wirft.
Häufige Absturz-Ursachen auf einen Blick:
| Ursache | Symptom | Schnelltest |
|---|---|---|
| Plugin-JS-Konflikt | Weißer Editor, keine Blöcke | Plugins deaktivieren |
| Veraltete Block-API | Blöcke fehlen, Konsolen-Fehler | Browser-Konsole prüfen |
| Content Security Policy | Iframe-basierter Editor lädt nicht | Netzwerk-Tab im Browser |
| PHP-Speicherlimit | Editor lädt nicht, 500-Fehler | Debug-Log prüfen |
| Theme-Konflikt | Nur bestimmte Post-Typen betroffen | Standard-Theme aktivieren |
Wer einen WordPress Fehler 500 nach einem Core-Update erlebt, sollte zusätzlich die PHP-Kompatibilität prüfen.
Was sollte ich tun, bevor ich den Gutenberg-Editor zurücksetze?
Vor jedem Zurücksetzen gilt: Backup first, fix second. Wer diese Reihenfolge umdreht, riskiert im schlimmsten Fall, dass ein Wiederherstellungsversuch die Situation verschlimmert.
Checkliste vor dem Zurücksetzen:
- ✅ Vollständiges Backup erstellen, Datenbank und Dateien, am besten mit einem WordPress Backup-Plugin oder direkt über das Hosting-Panel
- ✅ Browser-Konsole öffnen (F12) und nach JavaScript-Fehlern suchen, der Fehlertext nennt meistens das verursachende Plugin
- ✅ Prüfen, ob das Frontend noch korrekt angezeigt wird, wenn ja, ist nur der Editor betroffen, keine Panik nötig
- ✅ WordPress-Version, PHP-Version und alle Plugin-Versionen notieren, das erleichtert die Fehlersuche enorm
- ✅ Staging-Umgebung nutzen, wenn vorhanden, alle Fixes zuerst dort testen
Wer noch kein Notfall-Backup hat, findet hier eine Anleitung: WordPress Notfall-Backup vor Fehler 500.
Wie setze ich den Gutenberg-Editor sicher zurück, ohne Inhalte zu verlieren?
Das Zurücksetzen des Gutenberg-Editors bedeutet in den meisten Fällen nicht, die gesamte WordPress-Installation neu aufzusetzen. Die Inhalte bleiben unangetastet, es geht darum, die fehlerhafte Komponente (Plugin, Theme oder Gutenberg-Plugin selbst) auf einen stabilen Stand zurückzubringen [3].
Schritt-für-Schritt-Rollback:
- Alle nicht zwingend nötigen Plugins deaktivieren, direkt im WordPress-Backend oder via FTP durch Umbenennen des Plugin-Ordners
- Editor neu laden, funktioniert er jetzt? Wenn ja, Plugins einzeln wieder aktivieren, bis der Fehler wieder auftritt
- Verursacher gefunden? Das WP Rollback Plugin nutzen, um die letzte funktionierende Version des Plugins wiederherzustellen [3]
- Gutenberg-Plugin selbst zurückrollen, falls das standalone Gutenberg-Plugin installiert ist, es deaktivieren und mit der im WordPress-Core enthaltenen Version testen
- Content-Revisionen nutzen, bei beschädigten Seiteninhalten bietet WordPress die eingebaute Revisions-Funktion; über „Seite bearbeiten → Revisionen“ lassen sich ältere Versionen eines Beitrags wiederherstellen [3]
💡 Wichtig: Das WP Rollback Plugin erlaubt das gezielte Zurücksetzen auf eine frühere Plugin- oder Theme-Version direkt aus dem Dashboard, ohne Datenbankänderungen [3].
Wer sich beim Thema WordPress Update fehlgeschlagen befindet, findet dort weitere Hilfe.
Wie behebe ich kaputte Seiten-Layouts im Block-Editor?
Kaputte Layouts entstehen oft, wenn ein Plugin-Update die Block-Registrierung ändert oder CSS-Dateien nicht mehr korrekt geladen werden. Das Frontend sieht dann falsch aus, obwohl der Editor scheinbar funktioniert.
Bewährte Vorgehensweise nach Pixelgrade [9]:
- Den genauen Plugin- oder Theme-Namen identifizieren, der das Layout zerstört hat
- Dieses Plugin neu installieren (ältere Version via WP Rollback)
- Alle Caching-Schichten leeren, Server-Cache, CDN-Cache, Browser-Cache
- Einen harten Browser-Refresh durchführen (Strg + Shift + R)
- Erst dann weitertesten, bevor WordPress-Core oder die Datenbank angefasst wird
Bei Theme-bedingten Layout-Fehlern hilft dieser Leitfaden: WordPress Theme Fehler reparieren: Darstellungsprobleme nach Updates.
Spezialfall blockbasierte Layouts für Shops: Wenn ein WooCommerce-Shop nach einem Gutenberg-Update fehlerhafte Produktseiten zeigt, liegt das häufig an inkompatiblen Block-Templates. Hier hilft ein Elementor Plugin Update fehlgeschlagen-Fix analog für Gutenberg-basierte Shops.
Kann ich zum Classic Editor wechseln, wenn Gutenberg immer wieder abstürzt?
Ja, und oft ist das die schnellste Lösung, um Redaktionen und Shops wieder arbeitsfähig zu machen, während das eigentliche Problem in Ruhe analysiert wird. Der Wechsel zum Classic Editor löscht keine Inhalte.
Drei Optionen im Überblick:
- Classic Editor Plugin (offiziell von WordPress): Ersetzt Gutenberg komplett durch den alten Editor. Einfach im Plugin-Verzeichnis suchen und installieren.
- Disable Gutenberg [4]: Deaktiviert den Block-Editor seitenweise oder komplett, lässt sich feingranular konfigurieren
- Relive Classic: Ähnlich wie Disable Gutenberg, gute Alternative mit aktivem Support
Wann ist der Classic-Editor-Wechsel sinnvoll?
- Redaktion muss sofort weiterarbeiten können
- Das Problem lässt sich nicht innerhalb von 30 Minuten isolieren
- Shop läuft, aber der Editor ist unbrauchbar
Wann lieber nicht?
- Das Theme ist ein Full-Site-Editing-Theme (z. B. Twenty Twenty-Four/Five), dann funktionieren viele Design-Elemente nur mit Gutenberg korrekt
- Komplexe Gutenberg-Block-Layouts würden im Classic Editor als Rohcode erscheinen
Ist das ein WordPress-Versions-Kompatibilitätsproblem mit Gutenberg?
Manchmal ja, besonders dann, wenn eine neue WordPress-Hauptversion und ein Gutenberg-Plugin-Update gleichzeitig eingespielt wurden. Die Kombination aus neuer Core-Version, neuem Gutenberg-Plugin und einem nicht aktualisierten Theme ist eine klassische Fehler-Dreiecks-Situation.
Wann ist Kompatibilität der wahrscheinliche Schuldige?
- Fehler trat unmittelbar nach einem Core-Update auf, nicht nach einem Plugin-Update
- Mehrere verschiedene Plugins zeigen gleichzeitig Probleme
- Das Theme stammt aus einer Zeit vor der Full-Site-Editing-Ära (vor WordPress 5.9)
PHP-Versionskonflikte können den Gutenberg-Editor ebenfalls beeinträchtigen, mehr dazu unter WordPress Fehler 500 nach PHP 8.3/8.4 Update.
Welche Plugins helfen bei Gutenberg-Fehlern, leeren Blöcken und Abstürzen?
Für die meisten Gutenberg-Probleme gibt es bewährte Plugin-Werkzeuge, ohne dass man Code anfassen muss.
Empfohlene Plugins für die Fehlerbehebung:
- WP Rollback, Zurücksetzen von Plugins und Themes auf frühere Versionen direkt aus dem Dashboard [3]
- Disable Gutenberg [4], Block-Editor komplett oder selektiv deaktivieren
- Health Check & Troubleshooting (offiziell von WordPress), Aktiviert einen sicheren Fehlerbehebungs-Modus, der Plugins nur für den eingeloggten Admin deaktiviert; der Rest der Website läuft normal weiter
- Query Monitor, Zeigt JavaScript-Fehler, PHP-Warnungen und langsame Datenbankabfragen, die den Editor beeinflussen können
- Classic Editor, Offizielles Plugin für die vollständige Rückkehr zum klassischen Editor
Wähle X, wenn…
- Du schnell wieder arbeiten musst → Disable Gutenberg + Classic Editor
- Du den Verursacher isolieren willst → Health Check & Troubleshooting
- Du eine frühere Plugin-Version brauchst → WP Rollback
Muss ich ein Backup wiederherstellen, um Gutenberg-Fehler zu beheben?
In den meisten Fällen nein. Da leere Blöcke und Editor-Abstürze UI-seitige JavaScript-Probleme sind, bleiben die Daten in der Datenbank intakt, ein vollständiges Backup-Restore wäre übertrieben und riskant [1][2][9].
Wann ein Backup-Restore sinnvoll ist:
- Die Datenbank wurde durch ein fehlerhaftes Migrations-Script beschädigt
- Ein Theme-Update hat Block-Templates überschrieben und alle Seiteninhalte verändert
- Der Fehler tritt auf dem Frontend auf und lässt sich nicht durch Plugin-Deaktivierung beheben
- Alle anderen Methoden wurden ohne Erfolg versucht
Für komplexere Datenbankprobleme: WordPress Datenbankfehler beheben.
Gibt es WordPress-Themes, die besser mit Gutenberg funktionieren?
Ja, und der Theme-Wahl kommt 2026 mehr Bedeutung zu als je zuvor, weil Full-Site-Editing-Themes komplett auf Gutenberg-Blöcke setzen.
Themes mit sehr guter Gutenberg-Kompatibilität:
- Twenty Twenty-Five / Twenty Twenty-Four (WordPress-Standardthemes): Vollständig blockbasiert, immer mit dem aktuellen Core kompatibel
- Kadence und GeneratePress: Aktiv gepflegte Themes mit regelmäßigen Gutenberg-Kompatibilitätsupdates
- Blocksy: Modernes Block-Theme mit nativer FSE-Unterstützung
Themes, die häufig Probleme verursachen:
- Ältere Page-Builder-Themes (Divi, Avada in alten Versionen), die ihren eigenen Editor mitbringen und mit Gutenberg kollidieren
- Themes, die
remove_theme_support('block-templates')verwenden, ohne es für neue Gutenberg-Versionen anzupassen [5]
Wie lange dauert es, Gutenberg-Abstürze zu beheben?
Die Behebungszeit hängt stark von der Ursache ab. Einfache Plugin-Konflikte lassen sich in 15-30 Minuten isolieren und beheben. Komplexere Fälle mit mehreren Konflikten, Custom-Block-Plugins oder beschädigten Datenbankinhalten können mehrere Stunden in Anspruch nehmen.
Typische Zeitrahmen:
- Plugin-Konflikt identifiziert und deaktiviert: 10-20 Minuten
- WP Rollback auf frühere Plugin-Version: 5-15 Minuten
- Classic Editor als Workaround aktivieren: 2-5 Minuten
- Vollständige Ursachenanalyse bei unbekanntem Auslöser: 1-3 Stunden
- Professionelle Reparatur durch einen WordPress-Experten: durchschnittlich 3 Stunden (laut WP-Repair-Erfahrungswerten)
Häufige Fehler beim Beheben von Gutenberg-Problemen
Viele Seitenbetreiber verlängern das Problem unbeabsichtigt durch folgende Aktionen:
- ❌ Sofort das komplette Backup wiederherstellen, ohne zu prüfen, ob die Daten noch intakt sind
- ❌ Alle Plugins auf einmal aktivieren, nachdem der Fehler behoben schien, so weiß man nicht, welches Plugin schuld war
- ❌ WordPress-Core manuell überschreiben, obwohl das Problem am Plugin lag
- ❌ Kein Backup vor dem Eingriff erstellen
- ❌ Cache nicht leeren nach dem Rollback, das lässt den Fehler scheinbar bestehen, obwohl er schon behoben ist
- ❌ Theme-Konflikt ignorieren und nur Plugins testen
Wer sich beim Thema Es gab einen kritischen Fehler in WordPress wiederfindet, sollte denselben methodischen Ansatz verfolgen.
FAQ
Löscht das Zurücksetzen von Gutenberg meine veröffentlichten Seiten? Nein. Das Zurücksetzen betrifft nur den Editor und seine Komponenten, die Seiteninhalte liegen in der Datenbank und bleiben unberührt [1][9].
Warum erscheinen Blöcke im Editor leer, aber auf dem Frontend sind sie sichtbar? Das ist ein klassisches Zeichen für einen JavaScript-Fehler im Editor-UI. Die Daten existieren, der Editor kann sie nur nicht rendern, meist wegen eines Plugin-Konflikts [2].
Kann ein PHP-Update Gutenberg-Fehler auslösen? Ja. PHP 8.x-Updates können Inkompatibilitäten in Plugins oder Themes erzeugen, die dann den Editor zum Absturz bringen. Mehr dazu: PHP Update WordPress: Was schiefgeht.
Was bedeutet „Block enthält unerwarteten oder ungültigen Inhalt“? Diese Meldung erscheint, wenn die gespeicherte Block-Struktur nicht mehr mit der aktuellen Block-Definition übereinstimmt, oft nach einem Plugin-Update, das die Block-API geändert hat. Der „Wiederherstellen“-Button versucht, die Inhalte zu retten; alternativ auf „In klassischem Editor bearbeiten“ klicken.
Wie erkenne ich, welches Plugin den Gutenberg-Fehler verursacht? Browser-Konsole öffnen (F12 → Console-Tab). JavaScript-Fehlermeldungen enthalten meistens den Dateinamen des verursachenden Plugins. Alternativ das „Health Check & Troubleshooting“-Plugin nutzen.
Ist es sicher, das standalone Gutenberg-Plugin zu deaktivieren? Ja. WordPress Core enthält eine eigene stabile Gutenberg-Version. Das standalone Plugin bietet nur experimentelle Features früher an, Deaktivierung schadet nichts.
Was tun, wenn auch der Classic Editor leere Seiten zeigt? Dann liegt das Problem tiefer, wahrscheinlich in der Datenbank oder einem serverseitigen Fehler. Jetzt ein Backup wiederherstellen oder professionelle Hilfe in Anspruch nehmen.
Funktioniert WP Rollback auch für das Gutenberg-Plugin selbst? Ja. WP Rollback funktioniert für alle Plugins und Themes aus dem offiziellen WordPress.org-Verzeichnis, inklusive des Gutenberg-Plugins [3].
Wie verhindere ich solche Fehler in Zukunft? Regelmäßige Backups, Updates erst auf einer Staging-Umgebung testen und ein WordPress Wartungsvertrag für automatisierte Überwachung.
Fazit: Schritt für Schritt zurück zum funktionierenden Editor
WordPress Gutenberg Update Fehler, leere Blöcke, kaputte Layouts und Editor-Abstürze, klingen dramatisch, sind aber in den allermeisten Fällen lösbar, ohne dass ein einziges Byte an Content verloren geht. Der Schlüssel liegt darin, ruhig und methodisch vorzugehen:
- Backup sichern, immer zuerst
- Browser-Konsole prüfen, den eigentlichen Fehler lesen
- Plugins isolieren, den Verursacher finden
- Gezielt zurückrollen, WP Rollback oder Classic Editor nutzen
- Cache leeren, und nochmals testen
Wer keine Zeit hat, sich durch diese Schritte zu arbeiten, oder wessen Shop-Seite gerade offline ist: Kay Jaeger und das WP-Repair-Team beheben solche Probleme im Schnitt in unter drei Stunden, kostenlose Ersteinschätzung hier anfordern. Die Anfrage ist völlig unverbindlich, und wenn der Fehler nicht behoben werden kann, fällt nur eine Aufwandspauschale von 49 EUR an.
Referenzen
[10] Restore Classic Editor – https://wordpress.com/plugins/restore-classic-editor [3] How To Undo Changes – https://www.liquidweb.com/wordpress/build/how-to-undo-changes/ [6] GitHub, PR #84140 – https://github.com/WordPress/gutenberg/pull/84140 [5] GitHub, Issue #67875 – https://github.com/WordPress/gutenberg/issues/67875 [4] Disable Gutenberg – https://de.wordpress.org/plugins/disable-gutenberg/ [1] Block Errors And Editor Troubleshooting (Listable) – https://pixelgrade.com/docs/listable/troubleshooting/block-errors-and-editor-troubleshooting/ [2] Gutenberg Editor Issues – https://wordpress.org/support/topic/gutenberg-editor-issues/ [9] Block Errors And Editor Troubleshooting (Jason) – https://pixelgrade.com/docs/jason/troubleshooting/block-errors-and-editor-troubleshooting/
References
- Block Errors and Editor Troubleshooting. pixelgrade.com.
- Gutenberg Editor Issues. wordpress.org.
- How to Undo Changes. liquidweb.com.
- Disable Gutenberg. de.wordpress.org.
- Issues. github.com.
- Pull. github.com.
- Javascript Gutenberg Conflict. wordpress.org.
- Deprecations. developer.wordpress.org.
- Block Errors and Editor Troubleshooting. pixelgrade.com.
- Restore Classic Editor. wordpress.com.