So verwenden Sie den Classic Editor in WordPress: Installation, Konfiguration und wann es tatsächlich sinnvoll ist

Der WordPress Classic Editor ist ein auf TinyMCE basierender WYSIWYG-Inhaltseditor, der dem in WordPress 5.0 eingeführten Gutenberg-Blocksystem vorausgeht. Er bietet eine einzige, lineare Bearbeitungsoberfläche – optisch ähnlich wie Microsoft Word –, in der Text, Medien und HTML in einem kontinuierlichen Feld koexistieren, anstatt in diskreten, stapelbaren Blöcken. Für Benutzer, die ihn heute installieren möchten, lautet die kurze Antwort: Installieren Sie das offizielle Classic Editor-Plugin aus dem WordPress-Plugin-Repository, aktivieren Sie es und konfigurieren Sie den Standard-Editor unter Einstellungen > Schreiben.

Diese zwei Sätze decken die Kernfrage ab. Der Rest dieses Leitfadens behandelt die architektonischen Unterschiede zwischen den beiden Editoren, die legitimen technischen Gründe für die Wahl des einen oder anderen, Konfigurationsrandfälle und die Szenarien, in denen die Erzwingung des Classic Editors tatsächlich mehr Probleme schafft als löst.

Classic Editor vs. Gutenberg Block Editor: Ein technischer Vergleich

Bevor Sie irgendwelche Einstellungen ändern, lohnt es sich zu verstehen, zwischen was Sie eigentlich wechseln. Die Entscheidung ist nicht rein kosmetischer Natur.

Der betrieblich bedeutsamste Unterschied ist die Inhaltsspeicherung. Der Classic Editor speichert sauberes HTML. Gutenberg umschließt jede Inhaltseinheit mit HTML-Kommentar-Annotationen, die als Block-Begrenzer fungieren. Wenn Sie jemals Inhalte zwischen Systemen migrieren — zu einem Headless-CMS, einem Static-Site-Generator oder einer Nicht-WordPress-Plattform — ist die Classic-Editor-Ausgabe wesentlich einfacher zu parsen und zu portieren. Gutenbergs Block-Grammatik ist proprietär für den WordPress-Parser.

Warum Entwickler und Website-Betreiber weiterhin den Classic Editor wählen

Kompatibilität mit Legacy-Plugins und -Themes

Viele kommerzielle Plugins — insbesondere ältere Formular-Builder, E-Commerce-Erweiterungen und benutzerdefinierte Beitragstyp-Plugins — registrieren Meta-Boxen, die Felder direkt in den Beitragsbearbeitungsbildschirm einfügen. In Gutenberg werden diese Meta-Boxen in ein ausklappbares Seitenleisten-Panel verbannt, das innerhalb eines iframe-Kompatibilitäts-Shims gerendert wird. Dieser Shim verhält sich nicht immer korrekt: JavaScript-Konflikte entstehen, bedingte Logik bricht zusammen, und einige Meta-Box-UI-Frameworks (z. B. jQuery UI-Dialoge) initialisieren sich im verschachtelten Dokumentkontext nicht korrekt.

Wenn Ihre Website auf Plugins angewiesen ist, die add_meta_box() mit komplexen JavaScript-abhängigen UIs verwenden, beseitigt der Classic Editor diese gesamte Problemklasse.

REST API-Einschränkungen

Gutenbergs Editor stellt kontinuierliche Hintergrundanfragen an die WordPress REST API — um Block-Muster abzurufen, Entwürfe automatisch zu speichern, den Post-Sperrstatus abzurufen und Benutzerberechtigungen zu validieren. In gehärteten Serverumgebungen, in denen die REST API absichtlich eingeschränkt ist (über add_filter('rest_authentication_errors', ...) oder serverseitige Regeln, die /wp-json/ blockieren), wird Gutenberg teilweise oder vollständig nicht laden. Der Classic Editor hat keine solche Abhängigkeit und funktioniert unter diesen Einschränkungen normal.

Multisite- und rollenbasierte Editor-Kontrolle

Bei WordPress-Multisite-Installationen müssen Netzwerkadministratoren manchmal eine konsistente Bearbeitungserfahrung über alle Subsites hinweg durchsetzen — insbesondere wenn nicht-technische Redakteure beteiligt sind. Das Classic-Editor-Plugin unterstützt eine Settings > Writing-Option, um das benutzerspezifische Editor-Wechseln zu deaktivieren und alle Benutzer unabhängig von ihren individuellen Präferenzen an den Classic Editor zu binden. Gutenberg bietet keinen gleichwertigen Netzwerk-Durchsetzungsmechanismus ohne benutzerdefinierten Code.

Workflow-Geschwindigkeit für textlastige Inhalte

Für Verlage, die große Mengen an Textinhalten produzieren — Nachrichtenartikel, Dokumentationen, Rechtsdokumente — ist das Einzelleinwand-Modell des Classic Editors tatsächlich schneller. Es ist nicht notwendig, einen neuen Block einzufügen, einen Block-Typ auszuwählen oder zwischen Block-Einstellungspanels zu navigieren. Sie drücken Enter und schreiben weiter. Für Redakteure, die mit der Tastatur arbeiten und HTML-Tab-Shortcuts verwenden, ist das relevant.

So installieren Sie das Classic Editor-Plugin

Der Classic Editor ist nicht im WordPress-Core enthalten. Er wird als offizielles Plugin vom WordPress-Contributors-Team gepflegt und ist im WordPress.org-Plugin-Repository verfügbar.

Methode 1: Installation über das WordPress-Dashboard

1. Melden Sie sich in Ihrem WordPress-Adminbereich an (/wp-admin).
2. Navigieren Sie zu Plugins > Neues Plugin hinzufügen.
3. Geben Sie im Suchfeld Classic Editor ein.
4. Suchen Sie das Plugin, das von WordPress Contributors erstellt wurde — überprüfen Sie den Autor, da es Nachahmerplugins mit ähnlichen Namen gibt.
5. Klicken Sie auf Jetzt installieren und dann auf Aktivieren.

Methode 2: Installation über WP-CLI

Wenn Sie WordPress über die Befehlszeile verwalten — was auf jeder VPS-Hosting-Umgebung gängige Praxis ist — ist WP-CLI deutlich schneller als die Dashboard-Benutzeroberfläche:

wp plugin install classic-editor --activate

Um es netzwerkweit auf einer Multisite-Installation zu installieren:

wp plugin install classic-editor --activate-network

Methode 3: Manueller Upload

Laden Sie das Plugin-ZIP von wordpress.org/plugins/classic-editor herunter und laden Sie es über Plugins > Neues Plugin hinzufügen > Plugin hochladen hoch, oder entpacken Sie es direkt auf Ihrem Server:

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

Nach dem Entpacken über WP-CLI oder das Dashboard aktivieren.

Classic-Editor-Einstellungen konfigurieren

Nach der Aktivierung stellt das Plugin zwei Konfigurationsoptionen unter Einstellungen > Schreiben bereit.

Standard-Editor für alle Benutzer

Die erste Option legt den seitenweiten Standard fest. Sie können zwischen Classic Editor und Block Editor wählen. Wenn Sie dies auf Classic Editor setzen, wird jeder neue Beitrag und jede neue Seite standardmäßig in TinyMCE geöffnet.

Benutzern erlauben, Editoren zu wechseln

Die zweite Option steuert, ob einzelne Benutzer den Seitenstandard auf Beitragsbasis überschreiben können. Wenn aktiviert, werden beim Hovern über einen Beitrag in der Liste Beiträge > Alle Beiträge zwei Aktionslinks angezeigt: Bearbeiten (öffnet im Seitenstandard) und Bearbeiten (Classic Editor) oder Bearbeiten (Block Editor), abhängig vom aktuellen Standard.

Empfohlene Konfiguration für die meisten Legacy-Sites:

• Standard-Editor: Classic Editor
• Benutzern das Wechseln erlauben: Nein

Dies verhindert, dass Redakteure versehentlich Inhalte in Gutenberg öffnen und unbeabsichtigt Block-Grammatik-Kommentare in Beiträge einfügen, die im Classic Editor verfasst wurden — eine Mischung, die bei einigen Themes zu Rendering-Anomalien führen kann.

Die Classic-Editor-Oberfläche verwenden

Der Visual-Tab (WYSIWYG-Modus)

Der Visual-Tab rendert Ihre Inhalte über TinyMCEs iframe-basierte Vorschau. Die Symbolleiste bietet:

• Textformatierung: Fett (Ctrl+B), Kursiv (Ctrl+I), Durchgestrichen, Unterstrichen
• Absatzstile: Überschrift 1 bis Überschrift 6, Vorformatiert, Blockzitat
• Listen: Geordnet und ungeordnet, mit Einzug/Ausrücken-Steuerelementen
• Links: Hyperlinks einfügen/bearbeiten mit Ziel- und Titelattributen
• Medieneinfügung: Öffnet die WordPress-Mediathek für Bilder, Videos, Audio und Dokumente
• Aus Word einfügen: Entfernt beim Einfügen die proprietären HTML-Markierungen von Microsoft Word
• Ablenkungsfreier Schreibmodus: Vollbild-Umschalter, der alle Admin-UI ausblendet

Die Symbolleiste hat zwei Reihen. Wenn Sie nur eine Reihe sehen, klicken Sie auf die Schaltfläche Symbolleiste umschalten (das letzte Symbol in der ersten Reihe), um die zweite Reihe anzuzeigen, die den Absatzstil-Selektor, Textfarbe, Zeichentabelle und Rückgängig/Wiederholen enthält.

Der Text-Tab (Roh-HTML-Modus)

Der Text-Tab zeigt das in post_content gespeicherte rohe HTML an. Dies ist kein vollständiger Code-Editor — er verfügt weder über Syntaxhervorhebung noch über Zeilennummerierung — gibt Ihnen aber direkten Zugriff auf das Markup. Nützliche Szenarien:

• Einfügen von rohen <iframe>-Einbettungen, die TinyMCE entfernen oder maskieren würde
• Hinzufügen benutzerdefinierter HTML-Attribute, die die UI des Visual-Tabs nicht bereitstellt
• Debuggen von Rendering-Problemen, die durch TinyMCEs automatische Tag-Bereinigung verursacht werden

Wichtiges Verhalten zum Verstehen: TinyMCE führt eine HTML-Bereinigung durch, wenn Sie vom Text-Tab zurück zum Visual-Tab wechseln. Es schließt nicht geschlossene Tags, entfernt bestimmte Elemente (wie <script> in einigen Konfigurationen) und normalisiert Leerzeichen. Wenn Sie rohes HTML im Text-Tab schreiben, überprüfen Sie immer, ob es einen Hin- und Rückweg zum Visual-Tab übersteht, bevor Sie veröffentlichen.

Die Meta-Boxen für Auszug, benutzerdefinierte Felder und Diskussion

Unterhalb der Haupteditor-Leinwand zeigt der Classic Editor den vollständigen Satz nativer WordPress-Meta-Boxen in ihrem ursprünglichen Layout:

• Auszug: Nur-Text-Zusammenfassung, die von Themes und SEO-Plugins für Meta-Beschreibungen verwendet wird
• Benutzerdefinierte Felder: Schlüssel-Wert-Paare, die in wp_postmeta gespeichert sind — direkt zugänglich, ohne zu einem Seitenleisten-Panel wechseln zu müssen
• Diskussion: Beitragsspezifische Kommentar- und Trackback-Einstellungen
• Slug: Bearbeitbares URL-Slug-Feld (auch in der Veröffentlichen-Box)
• Autor: Beitragsautorenschaft neu zuweisen, ohne die Seite zu verlassen

Diese Meta-Boxen sind im Classic Editor immer sichtbar und in voller Breite. In Gutenberg sind sie entweder in der Seitenleiste verborgen oder werden im Kompatibilitäts-iframe gerendert — ein bedeutender UX-Unterschied für Workflows, die stark auf benutzerdefinierte Felder angewiesen sind.

Zwischen Editoren pro Beitrag wechseln

Wenn Sie die Option „Benutzern das Wechseln erlauben” aktiviert haben, funktioniert der beitragsspezifische Editor-Umschalter wie folgt:

Aus der Beitragsliste:

1. Gehen Sie zu Beiträge > Alle Beiträge.
2. Hovern Sie über den Beitragstitel.
3. Klicken Sie nach Bedarf auf Bearbeiten (Classic Editor) oder Bearbeiten (Block Editor).

Aus dem Editor heraus:

In Gutenberg erscheint ein Link mit der Aufschrift Zum Classic Editor wechseln im Drei-Punkte-Optionsmenü (oben rechts). Im Classic Editor erscheint ein Link mit der Aufschrift Zum Block Editor wechseln oben auf dem Bildschirm.

Warnung: Wenn Sie einen in Gutenberg verfassten Beitrag zum Classic Editor wechseln — und ihn dann speichern — werden die Block-Grammatik-Kommentar-Annotationen im rohen HTML beibehalten. Diese Kommentare sind für das Frontend-Rendering harmlos, erscheinen aber als wörtlicher Text im Text-Tab des Classic Editors, was verwirrend sein kann. Das Zurückwechseln zu Gutenberg wird sie korrekt neu parsen. Das umgekehrte Szenario (Classic-Editor-Inhalte in Gutenberg geöffnet) ist sauber, da Gutenberg nicht erkanntes HTML automatisch in einen Classic-Block einschließt.

Classic Editor ohne Plugin deaktivieren

Wenn Sie Gutenberg erzwingen und die Verwendung des Classic Editors verhindern möchten — oder wenn Sie Gutenberg ohne Installation eines Plugins deaktivieren möchten — bietet WordPress einen Filter-Hook:

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

Dies erzielt denselben Effekt wie das Classic-Editor-Plugin für die Beitragsbearbeitung, betrifft jedoch nicht den Site-Editor (Full Site Editing). Für eine vollständige Gutenberg-Deaktivierung einschließlich FSE:

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

Dieser Ansatz ist in Umgebungen vorzuziehen, in denen die Installation zusätzlicher Plugins durch Richtlinien eingeschränkt ist, oder wenn Sie die Deaktivierungslogik versionskontrolliert in Ihrem Theme oder Plugin haben möchten, anstatt vom Aktivierungsstatus eines Drittanbieter-Plugins abhängig zu sein.

Classic Editor und WordPress-Hosting-Umgebungen

Das Classic-Editor-Plugin selbst ist leichtgewichtig und stellt keine nennenswerten serverseitigen Anforderungen. Der breitere Kontext Ihrer Hosting-Umgebung beeinflusst jedoch die Bearbeitungserfahrung auf eine Weise, die es wert ist, beachtet zu werden.

Bei Shared-Hosting-Plänen kann das WordPress-Adminpanel träge wirken, da PHP-Ausführung und Datenbankabfragen mit anderen Mietern auf demselben Server konkurrieren. Der Classic Editor ist in diesem Kontext messbar leichter als Gutenberg — weniger REST-API-Aufrufe, kein React-Rendering-Overhead und eine kleinere JavaScript-Nutzlast bedeuten schnellere Seitenladevorgänge im Admin. Wenn Sie einen Shared-Web-Hosting-Plan haben und den Block-Editor als langsam empfinden, ist der Classic Editor eine praktische Optimierung.

Auf einem VPS mit cPanel haben Sie die volle Kontrolle über PHP-Speicherlimits, OPcache-Konfiguration und MySQL-Abfrage-Caching. In dieser Umgebung funktionieren beide Editoren gut, und die Wahl wird rein zur Workflow-Präferenz statt zur Leistungsnotwendigkeit.

Bei stark frequentierten WordPress-Installationen auf Dedizierten Servern hat die Editor-Wahl praktisch keinen Einfluss auf die Frontend-Leistung — die Bearbeitungsoberfläche wird nur von authentifizierten Admin-Benutzern geladen, und der veröffentlichte HTML-Output ist das, was für die Seitengeschwindigkeit zählt.

Häufige Fallstricke und Randfälle

TinyMCE entfernt gültiges HTML: TinyMCEs valid_elements– und extended_valid_elements-Konfiguration steuert, welche HTML-Tags und -Attribute im Visual-Editor erlaubt sind. Standardmäßig entfernt es Tags wie <article>, <section>, <figure> (in älteren Konfigurationen) und alle benutzerdefinierten Datenattribute. Wenn Ihre Inhalte diese erfordern, müssen Sie TinyMCEs erlaubte Elemente über den tiny_mce_before_init-Filter erweitern:

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Autosave-Konflikte: Der Classic Editor verwendet die ältere wp_autosave()-JavaScript-Funktion, die POST-Anfragen an wp-admin/post.php mit action=autosave sendet. Wenn Ihr Server aggressives Rate-Limiting oder eine WAF-Regel hat, die wiederholte POST-Anfragen an wp-admin blockiert, werden Autosaves stillschweigend fehlschlagen. Überwachen Sie Ihre Server-Fehlerprotokolle, wenn Inhaltsverluste auftreten.

Classic Editor und Full Site Editing (FSE)-Themes: Wenn Ihr aktives Theme ein FSE-Theme ist (eines, das "blockTemplates": true in theme.json deklariert), funktioniert der Classic Editor weiterhin für Beitrags- und Seiteninhalte, aber der Site-Editor (/wp-admin/site-editor.php) basiert vollständig auf Gutenberg und wird vom Classic-Editor-Plugin nicht beeinflusst. Sie können den Classic Editor nicht verwenden, um FSE-Theme-Templates zu bearbeiten.

Verhalten bei Plugin-Deaktivierung: Das Deaktivieren des Classic-Editor-Plugins konvertiert Ihre Inhalte nicht. Im Classic Editor verfasste Beiträge bleiben als sauberes HTML erhalten. In Gutenberg verfasste Beiträge behalten ihre Block-Grammatik. Gutenberg wird beides korrekt parsen. Es besteht kein Datenverlustrisiko durch das Deaktivieren des Plugins.

Entscheidungsmatrix: Welchen Editor sollten Sie verwenden?

Verwenden Sie den Classic Editor, wenn:

• Ihre Website Plugins mit komplexen Meta-Box-UIs verwendet, die in Gutenbergs Kompatibilitätsschicht nicht funktionieren
• Ihr Server die WordPress REST API einschränkt
• Sie Inhalte auf eine Nicht-WordPress-Plattform migrieren und sauberes, portables HTML benötigen
• Ihr Redaktionsteam groß, nicht-technisch und auf den Classic-Editor-Workflow geschult ist
• Sie WordPress in einer ressourcenbeschränkten Shared-Hosting-Umgebung betreiben

Verwenden Sie Gutenberg, wenn:

• Sie neue Websites ohne Legacy-Plugin-Abhängigkeiten erstellen
• Ihr Theme blockbasiert oder FSE-kompatibel ist
• Sie wiederverwendbare Blöcke, Block-Muster oder komplexe mehrspaltigen Layouts ohne einen Page-Builder benötigen
• Sie benutzerdefinierte Blöcke mit register_block_type() für Kundenprojekte erstellen
• Sie den Site-Editor für die vollständige Theme-Anpassung nutzen möchten

Verwenden Sie beide (mit aktiviertem benutzerspezifischem Wechseln), wenn:

• Sie ein gemischtes Team haben, bei dem einige Redakteure Classic und andere Gutenberg bevorzugen
• Sie sich in einer Übergangsphase befinden, in der Sie eine Legacy-Site auf eine blockbasierte Architektur migrieren
• Verschiedene Beitragstypen auf Ihrer Website unterschiedliche Komplexitätsanforderungen haben

Praktische technische Checkliste

Bevor Sie Ihre Produktionssite auf den Classic Editor umstellen, überprüfen Sie Folgendes:

• ] Bestätigen Sie, dass die Classic-Editor-Plugin-Version aktuell ist (prüfen Sie [wordpress.org/plugins/classic-editor für die neueste Version)
• [ ] Testen Sie alle aktiven Plugin-Meta-Box-UIs im Classic Editor in einer Staging-Umgebung, bevor Sie in die Produktion deployen
• [ ] Überprüfen Sie Ihre tiny_mce_before_init-Filter, wenn Sie benutzerdefinierte TinyMCE-Konfigurationen haben, die möglicherweise mit den Standardeinstellungen des Plugins in Konflikt geraten
• [ ] Entscheiden Sie sich für die „Wechseln erlauben”-Richtlinie und dokumentieren Sie sie für Ihr Redaktionsteam
• [ ] Wenn Sie WP-CLI verwenden, bestätigen Sie, dass das Plugin mit wp plugin list --status=active aktiviert ist
• [ ] Überprüfen Sie, ob Ihr Theme nicht auf Gutenberg-spezifische Block-Stile (wp-block-*-CSS-Klassen) für das Frontend-Rendering angewiesen ist
• [ ] Sichern Sie Ihre Datenbank, bevor Sie Editor-Wechsel-Änderungen auf einer Site mit vorhandenen Gutenberg-Inhalten vornehmen
• [ ] Wenn Sie ein Multisite-Netzwerk betreiben, entscheiden Sie, ob Sie netzwerkweit oder pro Site aktivieren und über Settings > Writing auf Netzwerkebene durchsetzen möchten

Ergänzen Sie Ihr WordPress-Setup mit einer ordnungsgemäß gesicherten Domain, indem Sie sicherstellen, dass Ihre SSL-Zertifikate gültig sind und sich automatisch erneuern — das WordPress-Adminpanel überträgt Authentifizierungs-Cookies, die unabhängig vom verwendeten Editor durch HTTPS geschützt werden müssen.

Für Teams, die redaktionelle Workflows verwalten, die E-Mail-Benachrichtigungen, Autoren-Kommunikation oder Newsletter-Integrationen umfassen, stellt ein dediziertes E-Mail-Hosting-Setup sicher, dass transaktionale WordPress-E-Mails (Passwort-Zurücksetzungen, Kommentar-Benachrichtigungen, Beitragsstatus-Änderungen) zuverlässig zugestellt werden, anstatt über das Standard-sendmail eines Shared Servers geleitet zu werden.

FAQ

Beeinflusst das Classic-Editor-Plugin das Frontend-Rendering oder die Website-Leistung?

Nein. Das Classic-Editor-Plugin modifiziert nur die adminseite Bearbeitungsoberfläche. Es hat keinen Einfluss darauf, wie WordPress Seiten für Besucher rendert. Die Frontend-Leistung wird durch Ihr Theme, die Caching-Schicht und die Serverkonfiguration bestimmt — nicht davon, welcher Editor zum Schreiben der Inhalte verwendet wurde.

Werden meine bestehenden blockbasierten Inhalte beschädigt, wenn ich von Gutenberg zum Classic Editor wechsle?

Nein. Gutenberg speichert Block-Annotationen als HTML-Kommentare in post_content. Der Classic Editor zeigt dieses rohe HTML in seinem Text-Tab an und versucht, es im Visual-Tab zu rendern. Die Inhalte werden weder gelöscht noch beschädigt. Wenn Sie einen Gutenberg-Beitrag im Classic Editor speichern, ohne ihn zu bearbeiten, bleiben die Block-Annotationen erhalten. Wenn Sie bearbeiten und speichern, kann TinyMCE einige Leerzeichen normalisieren, wird aber die Kommentar-Annotationen nicht entfernen.

Kann ich den Classic Editor für einige Beitragstypen und Gutenberg für andere verwenden?

Ja, aber nicht über die Einstellungs-UI des Classic-Editor-Plugins. Sie müssen den use_block_editor_for_post_type-Filter im Code verwenden:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

Wird das Classic-Editor-Plugin dauerhaft gepflegt?

WordPress.org hat sich verpflichtet, das Classic-Editor-Plugin mit Sicherheits- und Kompatibilitätsupdates mindestens bis 2024 zu pflegen, und es erhält auch über diese Verpflichtung hinaus Updates. Es erhält jedoch keine neuen Funktionen — es befindet sich im Wartungsmodus. Für langfristige neue Projekte ist Gutenberg die strategische Richtung des WordPress-Cores.

Funktioniert der Classic Editor mit WooCommerce?

Ja. WooCommerces Produkteditor wurde historisch auf Classic-Editor-Meta-Boxen aufgebaut. Neuere WooCommerce-Versionen (8.x+) haben einen neuen, auf Blöcken basierenden Produkteditor eingeführt, aber das Legacy-Classic-Editor-basierte Produktformular bleibt verfügbar und ist für die meisten Installationen der Standard. Das Classic-Editor-Plugin stört WooCommerces Produktbearbeitungsbildschirme nicht.