Viele Unternehmenswebsites laufen seit Jahren mit dem Plugin Classic Editor, weil Redakteure sich an die alte Oberfläche gewöhnt haben oder weil Seiten mit Shortcodes und eigenem HTML gebaut wurden. Das Plugin wird weiter gepflegt, aber neue Funktionen von WordPress entstehen nur noch für den Block-Editor. Ein Umstieg ist deshalb eher eine Frage des Zeitpunkts als des Ob. Wer ihn plant, statt alle Inhalte auf einmal umzuwandeln, vermeidet kaputte Layouts und Frust in der Redaktion. Diese Anleitung zeigt, wie Sie den Bestand erfassen, beide Editoren eine Zeit lang parallel betreiben, einzelne Beiträge kontrolliert umwandeln und zum Schluss das Plugin entfernen. Alle Schritte haben wir in einer Testinstanz mit WordPress 7.1.2 und Classic Editor 1.7.0 durchgespielt.

Voraussetzungen

WordPress: eine aktuelle Version, getestet mit 7.1.2.
PHP: mindestens 7.4, wie von WordPress empfohlen.
Plugin: Classic Editor ist installiert und aktiv (sonst ist der Umstieg bereits vollzogen).
Zugriff: Administrator im Backend; für die Bestandsaufnahme SSH mit WP-CLI oder Zugriff auf die Datenbank, etwa über phpMyAdmin.
Testumgebung: eine Kopie der Website für Probeumwandlungen, siehe WordPress-Staging-Umgebung mit WP-CLI einrichten.
Backup: eine aktuelle Sicherung der Datenbank. Umgewandelte Inhalte lassen sich über Revisionen zurückholen, aber nur, solange Revisionen nicht abgeschaltet oder bereinigt wurden.

Schritt 1: Bestand erfassen

Der Block-Editor erkennt Blöcke an HTML-Kommentaren der Form  im Beitragsinhalt. Beiträge ohne solche Kommentare stammen aus dem klassischen Editor. Die folgende Abfrage zählt beide Gruppen getrennt nach Beiträgen und Seiten (Tabellenpräfix wp_ bei Bedarf anpassen):

wp db query "SELECT post_type, SUM(post_content NOT LIKE '%<!-- wp:%') AS klassisch, SUM(post_content LIKE '%<!-- wp:%') AS bloecke FROM wp_posts WHERE post_status IN ('publish','draft','private','future') AND post_type IN ('post','page') GROUP BY post_type"

In unserer Testinstanz ergab das:

post_type  klassisch  bloecke
page       0          2
post       1          2

Die Liste der klassischen Beiträge mit Titel liefert die WordPress-Funktion has_blocks():

wp eval 'foreach ( get_posts( array( "post_type" => array( "post", "page" ), "numberposts" => -1, "post_status" => "any" ) ) as $p ) { if ( ! has_blocks( $p ) ) echo $p->ID, "\t", $p->post_type, "\t", $p->post_title, "\n"; }'

Für die Planung wichtiger als die Zahl ist die Art der Inhalte. Suchen Sie nach Shortcodes und nach eigenem HTML wie <div class="…">. Welche Shortcodes auf Ihrer Website registriert sind, zeigt:

wp eval 'global $shortcode_tags; echo implode( " ", array_keys( $shortcode_tags ) ), "\n";'

In der Testinstanz ohne Zusatz-Plugins waren das wp_caption caption gallery playlist audio video embed. Jeder weitere Eintrag stammt von einem Plugin oder dem Theme und verdient einen eigenen Test.

Verifizieren: Sie haben eine Liste der klassischen Beiträge und Seiten, sortiert nach Bedeutung (Startseite, Leistungsseiten, meistbesuchte Beiträge zuerst), und wissen, welche Shortcodes vorkommen.

Schritt 2: Abhängigkeiten von Plugins und Theme prüfen

Laut Plugin-Beschreibung existiert Classic Editor vor allem für Plugins, die die alte Bearbeitungsseite erweitern oder alte Meta-Boxen hinzufügen. Prüfen Sie deshalb in der Testumgebung jedes Plugin, das im Editor eigene Felder zeigt: SEO-Plugins, Felder-Plugins, Seitenbaukästen, Shop-Erweiterungen. Die meisten aktuellen Plugins unterstützen den Block-Editor; Meta-Boxen erscheinen dort in einem Bereich unterhalb des Inhalts.

Zum Theme: Die FAQ des Plugins sagt klar, dass Classic Editor mit Block-Themes und dem Website-Editor nicht funktioniert, weil diese auf Blöcken beruhen. In unserer Testinstanz mit dem Block-Theme Twenty Twenty-Five öffnete das Plugin einzelne Beiträge trotzdem im klassischen Editor; Vorlagen und Navigation bearbeiten Sie dort aber nur mit Blöcken. Wer ohnehin einen Theme-Wechsel plant, sollte ihn nicht mit dem Editor-Umstieg bündeln, sonst lassen sich Fehler nicht mehr einer Ursache zuordnen.

Verifizieren: Für jedes Plugin mit Editor-Funktionen ist notiert, ob es im Block-Editor funktioniert. Kritische Plugins ohne Block-Unterstützung haben einen Ersatzkandidaten; wie Sie Plugins bewerten, zeigt WordPress-Plugins auswählen.

Schritt 3: Parallelbetrieb einrichten

Classic Editor kann beide Editoren nebeneinander anbieten. Öffnen Sie Einstellungen > Schreiben. Das Plugin ergänzt dort zwei Einstellungen:

„Standard-Editor für alle Benutzer“: Stellen Sie Block-Editor ein. Neue Beiträge entstehen damit bereits als Blöcke.
„Benutzern erlauben, den Editor zu wechseln“: Stellen Sie Ja ein. So kann die Redaktion bei Problemen ausweichen.

Per WP-CLI lauten die Optionen:

wp option update classic-editor-replace block
wp option update classic-editor-allow-users allow

Nach der Umstellung zeigte die Beitragsliste in der Testinstanz unter jedem Beitrag die Links Bearbeiten [Block-Editor] und Bearbeiten [Classic Editor]. Laut Plugin-Beschreibung öffnet jeder Beitrag danach in dem Editor, mit dem er zuletzt bearbeitet wurde, unabhängig davon, wer ihn bearbeitet hat. Das verhindert, dass zwei Personen denselben Beitrag abwechselnd in unterschiedlichen Editoren speichern.

Planen Sie für den Parallelbetrieb einen festen Zeitraum, etwa vier bis acht Wochen, und eine kurze Einweisung der Redaktion. Legen Sie das Enddatum vorab fest und teilen Sie es der Redaktion mit.

Verifizieren: Ein neuer Beitrag unter Beiträge > Beitrag hinzufügen öffnet im Block-Editor, und die Beitragsliste zeigt beide Bearbeiten-Links.

Schritt 4: Beiträge kontrolliert umwandeln

Öffnen Sie einen klassischen Beitrag über Bearbeiten [Block-Editor]. Der gesamte alte Inhalt steht dann in einem einzigen Block „Klassisch“. Das ist noch keine Umwandlung: Der Beitrag sieht im Frontend aus wie vorher und lässt sich so auch weiter bearbeiten. Klicken Sie auf den Block; die Werkzeugleiste zeigt in der Testinstanz die Schaltflächen Klassisch, In Blöcke umwandeln, Bearbeiten und Optionen.

Mit In Blöcke umwandeln zerlegt WordPress den Inhalt in einzelne Blöcke. Unser Testbeitrag enthielt eine Überschrift, einen Absatz mit Fettdruck, den Shortcode [gallery], eine Tabelle und einen <div>-Kasten mit eigener CSS-Klasse. Daraus wurden:

Alter Inhalt	Neuer Block
`<h2>`	Überschrift
Absatz mit `<strong>`	Absatz, Fettdruck erhalten
`[gallery ids="1"]`	Galerie mit Bild-Block
`<table>`	Tabelle
`<div class="alt-box">`	Individuelles HTML

Eigenes HTML landet also im Block „Individuelles HTML“ und bleibt unverändert, lässt sich aber nicht mehr bequem bearbeiten. Solche Stellen ersetzen Sie nach und nach durch passende Blöcke, etwa „Gruppe“ mit einer zusätzlichen CSS-Klasse. Shortcodes von Plugins, für die es keinen Block-Umwandler gibt, landen je nach Plugin im Shortcode-Block oder im Absatz; das prüfen Sie in der Testkopie.

Vergleichen Sie nach dem Umwandeln die Vorschau mit der Live-Seite und speichern Sie erst dann. Beim Speichern legte WordPress im Test eine Revision an. Über den Link Revisionen in der Seitenleiste des Editors holen Sie den alten Zustand zurück, falls etwas nicht stimmt. Mehr zu Revisionen und Wiederherstellung beschreibt Einzelne WordPress-Beiträge und Medien aus dem Backup wiederherstellen.

Wandeln Sie nicht alle Beiträge auf Vorrat um. Ältere Beiträge, die niemand mehr bearbeitet, können im Block „Klassisch“ bleiben; WordPress stellt sie weiter korrekt dar. Konzentrieren Sie sich auf Seiten, die regelmäßig geändert werden.

Verifizieren: Nach dem Speichern zeigt wp post get ID --field=post_content Blockkommentare wie , und die Seite sieht im Frontend aus wie vorher.

Schritt 5: Plugin entfernen und Ergebnis prüfen

Wenn der Zeitraum für den Parallelbetrieb abgelaufen ist, die Redaktion ohne klassischen Editor arbeitet und keine Plugins mehr davon abhängen, stellen Sie in der Testkopie Benutzern erlauben, den Editor zu wechseln auf Nein, arbeiten einige Tage so und deaktivieren dann das Plugin auf der Live-Website unter Plugins > Installierte Plugins. Nicht umgewandelte Beiträge öffnen danach im Block-Editor mit dem Block „Klassisch“; Inhalte gehen nicht verloren, weil das Plugin nur die Oberfläche steuert. Zurück bleibt je bearbeitetem Beitrag das Metafeld classic-editor-remember, in dem das Plugin den zuletzt genutzten Editor vermerkt; es stört nicht. Löschen Sie das Plugin anschließend, statt es deaktiviert liegen zu lassen.

Ein Editor-Umstieg zeigt oft, wie viele Plugins und Anpassungen sich über die Jahre angesammelt haben. Damit wächst auch der laufende Aufwand für Updates und Kontrolle. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: wp plugin list enthält kein classic-editor mehr, neue und bestehende Beiträge öffnen im Block-Editor, und die wichtigsten Seiten sehen im Frontend unverändert aus.

Typische Fehler

Alle Beiträge in einem Durchgang umwandeln: Fehler fallen dann erst auf, wenn Besucher sie melden. Wandeln Sie einzeln und mit Vorschau um.
Umwandlung mit Speichern verwechseln: Das Öffnen im Block-Editor ändert noch nichts. Erst „In Blöcke umwandeln“ und Speichern schreiben den neuen Inhalt.
Revisionen abgeschaltet: Ist in der wp-config.php WP_POST_REVISIONS auf false gesetzt, fehlt der einfache Rückweg. Dann ist das Datenbank-Backup die einzige Absicherung.
Eigenes HTML im Block „Individuelles HTML“ bearbeitet: Redakteure ohne HTML-Kenntnisse beschädigen dort leicht die Struktur. Ersetzen Sie solche Blöcke auf wichtigen Seiten durch normale Blöcke.
Theme-Wechsel und Editor-Umstieg gleichzeitig: Fehler lassen sich nicht mehr zuordnen. Trennen Sie beide Projekte zeitlich.

Häufige Fragen

Wie lange wird Classic Editor noch gepflegt?

Die Plugin-Seite nennt Unterstützung „bis 2024 oder so lange wie nötig“. Am 30.09.2026 lag die letzte Aktualisierung auf den 28.05.2026 (Version 1.7.0, getestet bis 7.0.6). Ein festes Enddatum gibt es nicht; planen Sie den Umstieg trotzdem.

Gehen beim Deaktivieren des Plugins Inhalte verloren?

Nein. Das Plugin speichert Inhalte nicht in eigenem Format. Nicht umgewandelte Beiträge erscheinen im Block-Editor als Block „Klassisch“.

Kann ich einzelnen Benutzern den klassischen Editor lassen?

Ja, solange das Plugin aktiv ist und der Wechsel erlaubt ist, wählt jeder Benutzer in seinem Profil den Standard-Editor. Das verlängert allerdings den Parallelbetrieb.

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4, Theme Twenty Twenty-Five und Classic Editor 1.7.0 mit deutscher Sprachdatei: Bestandsabfragen per SQL und has_blocks(), Shortcode-Liste, Einstellungen unter „Schreiben“ im Browser und per WP-CLI, Bearbeiten-Links in der Beitragsliste, Umwandlung eines klassischen Testbeitrags mit Überschrift, Galerie-Shortcode, Tabelle und eigenem HTML, Speichern mit Revision. Nicht getestet: Seitenbaukästen, Plugins mit eigenen Meta-Boxen, Multisite.

Fazit

Der Umstieg vom Classic Editor gelingt am sichersten schrittweise: Bestand erfassen, Plugins prüfen, beide Editoren befristet parallel anbieten, wichtige Seiten einzeln umwandeln und das Plugin zum Schluss entfernen. Ältere, unveränderte Beiträge dürfen im Block „Klassisch“ bleiben. Wenn Sie die Updates, die ein solcher Umbau nach sich zieht, nicht selbst übernehmen möchten, finden Sie dafür die WordPress-Wartung.

Weiterführende Anleitungen und Quellen

Quellen: