Jak używać klasycznego edytora w WordPress: instalacja, konfiguracja i kiedy naprawdę ma to sens

WordPress Classic Editor to oparty na TinyMCE edytor treści WYSIWYG, który poprzedza system bloków Gutenberg wprowadzony w WordPress 5.0. Prezentuje pojedyncze, liniowe płótno edycji — wizualnie podobne do Microsoft Word — gdzie tekst, media i HTML współistnieją w jednym ciągłym polu, a nie w oddzielnych, układanych blokach. Dla użytkowników, którzy muszą go dziś zainstalować, krótka odpowiedź brzmi: zainstaluj oficjalną wtyczkę Classic Editor z repozytorium wtyczek WordPress, aktywuj ją i skonfiguruj domyślny edytor w Ustawienia > Pisanie.

Ta dwuzdaniowa odpowiedź obejmuje główne zapytanie. Reszta tego przewodnika dotyczy różnic architektonicznych między dwoma edytorami, uzasadnionych technicznych powodów wyboru jednego zamiast drugiego, przypadków brzegowych konfiguracji oraz scenariuszy, w których wymuszenie Classic Editor faktycznie stwarza więcej problemów niż rozwiązuje.

Classic Editor vs. Gutenberg Block Editor: Porównanie techniczne

Zanim zmienisz jakiekolwiek ustawienia, warto zrozumieć, między czym właściwie się przełączasz. Decyzja nie jest czysto kosmetyczna.

Najbardziej operacyjnie istotna różnica to przechowywanie treści. Classic Editor zapisuje czysty HTML. Gutenberg opakowuje każdą jednostkę treści w adnotacje komentarzy HTML działające jako ograniczniki bloków. Jeśli kiedykolwiek migrujesz treść między systemami — do headless CMS, generatora stron statycznych lub platformy innej niż WordPress — dane wyjściowe Classic Editor są znacznie łatwiejsze do parsowania i przenoszenia. Gramatyka bloków Gutenberg jest zastrzeżona dla parsera WordPress.

Dlaczego deweloperzy i właściciele stron nadal wybierają Classic Editor

Kompatybilność ze starszymi wtyczkami i motywami

Wiele komercyjnych wtyczek — szczególnie starsze kreatory formularzy, rozszerzenia e-commerce i wtyczki niestandardowych typów postów — rejestruje meta boxy, które wstrzykują pola bezpośrednio do ekranu edycji posta. W Gutenbergu te meta boxy są relegowane do zwijanego panelu bocznego renderowanego wewnątrz shima kompatybilności iframe. Ten shim nie zawsze działa poprawnie: pojawiają się konflikty JavaScript, logika warunkowa się psuje, a niektóre frameworki UI meta boxów (np. dialogi jQuery UI) nie inicjalizują się poprawnie w zagnieżdżonym kontekście dokumentu.

Jeśli Twoja strona opiera się na wtyczkach używających add_meta_box() ze złożonymi interfejsami zależnymi od JavaScript, Classic Editor eliminuje całą tę klasę problemów.

Ograniczenia REST API

Edytor Gutenberg wykonuje ciągłe żądania w tle do WordPress REST API — aby pobierać wzorce bloków, automatycznie zapisywać szkice, pobierać status blokady posta i weryfikować uprawnienia użytkownika. W zabezpieczonych środowiskach serwerowych, gdzie REST API jest celowo ograniczone (przez add_filter('rest_authentication_errors', ...) lub reguły na poziomie serwera blokujące /wp-json/), Gutenberg będzie częściowo lub całkowicie nie ładować się. Classic Editor nie ma takiej zależności i będzie działać normalnie w tych warunkach.

Multisite i kontrola edytora oparta na rolach

W instalacjach WordPress Multisite administratorzy sieci czasami muszą wymuszać spójne środowisko edycji we wszystkich podstronach — szczególnie gdy zaangażowani są redaktorzy nieposiadający wiedzy technicznej. Wtyczka Classic Editor obsługuje opcję Settings > Writing uniemożliwiającą przełączanie edytora przez poszczególnych użytkowników, blokując wszystkich użytkowników w Classic Editor niezależnie od ich indywidualnych preferencji. Gutenberg nie oferuje równoważnego mechanizmu egzekwowania na poziomie sieci bez niestandardowego kodu.

Szybkość pracy przy treściach tekstowych

Dla wydawców produkujących duże ilości treści tekstowych — artykułów informacyjnych, dokumentacji, pism prawnych — model pojedynczego płótna Classic Editor jest naprawdę szybszy. Nie ma potrzeby wstawiania nowego bloku, wybierania typu bloku ani nawigowania między panelami ustawień bloków. Naciskasz Enter i piszesz dalej. Dla redaktorów, którzy pracują na klawiaturze i używają skrótów zakładki HTML, ma to znaczenie.

Jak zainstalować wtyczkę Classic Editor

Classic Editor nie jest dołączony do rdzenia WordPress. Jest utrzymywany jako oficjalna wtyczka przez zespół WordPress Contributors i jest dostępny w repozytorium wtyczek WordPress.org.

Metoda 1: Instalacja przez panel WordPress

1. Zaloguj się do panelu administracyjnego WordPress (/wp-admin).
2. Przejdź do Wtyczki > Dodaj nową wtyczkę.
3. W polu wyszukiwania wpisz Classic Editor.
4. Znajdź wtyczkę autorstwa WordPress Contributors — zweryfikuj autora, ponieważ istnieją wtyczki imitatorów o podobnych nazwach.
5. Kliknij Zainstaluj teraz, a następnie Aktywuj.

Metoda 2: Instalacja przez WP-CLI

Jeśli zarządzasz WordPress z wiersza poleceń — co jest standardową praktyką w każdym środowisku Hostingu VPS — WP-CLI jest znacznie szybszy niż interfejs panelu:

wp plugin install classic-editor --activate

Aby zainstalować go w całej sieci w instalacji Multisite:

wp plugin install classic-editor --activate-network

Metoda 3: Ręczne przesłanie

Pobierz plik ZIP wtyczki z wordpress.org/plugins/classic-editor, a następnie prześlij go przez Wtyczki > Dodaj nową wtyczkę > Prześlij wtyczkę lub wypakuj go bezpośrednio na swój serwer:

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

Po wypakowaniu aktywuj przez WP-CLI lub panel.

Konfigurowanie ustawień Classic Editor

Po aktywacji wtyczka udostępnia dwie opcje konfiguracji w Ustawienia > Pisanie.

Domyślny edytor dla wszystkich użytkowników

Pierwsza opcja ustawia domyślny edytor dla całej witryny. Możesz wybrać między Classic Editor a Block Editor. Ustawienie tego na Classic Editor oznacza, że każdy nowy post i strona otwiera się domyślnie w TinyMCE.

Zezwól użytkownikom na przełączanie edytorów

Druga opcja kontroluje, czy poszczególni użytkownicy mogą nadpisać domyślne ustawienie witryny dla każdego posta osobno. Gdy jest włączona, najechanie kursorem na post na liście Posty > Wszystkie posty ujawnia dwa linki akcji: Edytuj (otwiera w domyślnym edytorze witryny) oraz Edytuj (Classic Editor) lub Edytuj (Block Editor) w zależności od aktualnego ustawienia domyślnego.

Zalecana konfiguracja dla większości starszych witryn:

• Domyślny edytor: Classic Editor
• Zezwól użytkownikom na przełączanie: Nie

Zapobiega to przypadkowemu otwieraniu treści przez redaktorów w Gutenbergu i nieumyślnemu wstrzykiwaniu komentarzy gramatyki bloków do postów napisanych w Classic Editor — mieszanina, która może powodować anomalie renderowania w niektórych motywach.

Korzystanie z interfejsu Classic Editor

Zakładka Visual (tryb WYSIWYG)

Zakładka Visual renderuje Twoją treść przez podgląd oparty na iframe TinyMCE. Pasek narzędzi zapewnia:

• Formatowanie tekstu: Pogrubienie (Ctrl+B), Kursywa (Ctrl+I), Przekreślenie, Podkreślenie
• Style akapitu: Nagłówek 1 do Nagłówka 6, Preformatowany, Cytat blokowy
• Listy: Numerowane i nienumerowane, z kontrolkami wcięcia/wysunięcia
• Linki: Wstawianie/edytowanie hiperłączy z atrybutami target i title
• Wstawianie mediów: Otwiera Bibliotekę mediów WordPress dla obrazów, wideo, audio i dokumentów
• Wklejanie z Worda: Usuwa zastrzeżone znaczniki HTML Microsoft Word przy wklejaniu
• Tryb pisania bez rozpraszaczy: Przełącznik pełnego ekranu ukrywający cały interfejs administracyjny

Pasek narzędzi ma dwa rzędy. Jeśli widzisz tylko jeden rząd, kliknij przycisk Przełącz pasek narzędzi (ostatnia ikona w pierwszym rzędzie), aby odsłonić drugi rząd, który zawiera selektor stylu akapitu, kolor tekstu, mapę znaków i cofnij/ponów.

Zakładka Text (tryb surowego HTML)

Zakładka Text udostępnia surowy HTML przechowywany w post_content. Nie jest to pełny edytor kodu — brakuje mu podświetlania składni i numerowania wierszy — ale daje bezpośredni dostęp do znaczników. Przydatne scenariusze:

• Wstawianie surowych osadzeń <iframe>, które TinyMCE by usunął lub zescapował
• Dodawanie niestandardowych atrybutów HTML, których interfejs zakładki Visual nie udostępnia
• Debugowanie problemów z renderowaniem spowodowanych automatycznym czyszczeniem tagów przez TinyMCE

Krytyczne zachowanie do zrozumienia: TinyMCE wykonuje sanityzację HTML podczas przełączania z zakładki Text z powrotem do zakładki Visual. Zamknie niezamknięte tagi, usunie pewne elementy (jak <script> w niektórych konfiguracjach) i znormalizuje białe znaki. Jeśli piszesz surowy HTML w zakładce Text, zawsze sprawdź, czy przeżyje przejście w obie strony do Visual przed publikacją.

Meta boxy Excerpt, Custom Fields i Discussion

Poniżej głównego płótna edytora Classic Editor wyświetla pełny zestaw natywnych meta boxów WordPress w ich oryginalnym układzie:

• Excerpt: Podsumowanie w postaci zwykłego tekstu używane przez motywy i wtyczki SEO do meta opisów
• Custom Fields: Pary klucz-wartość przechowywane w wp_postmeta — dostępne bezpośrednio bez przełączania do panelu bocznego
• Discussion: Ustawienia komentarzy i trackbacków dla poszczególnych postów
• Slug: Edytowalne pole slugu URL (również w polu Publikuj)
• Author: Zmiana autorstwa posta bez opuszczania strony

Te meta boxy są zawsze widoczne i pełnej szerokości w Classic Editor. W Gutenbergu są albo ukryte na pasku bocznym, albo renderowane w iframe kompatybilności — znacząca różnica UX dla przepływów pracy, które w dużym stopniu opierają się na polach niestandardowych.

Przełączanie między edytorami dla poszczególnych postów

Jeśli włączyłeś opcję „Zezwól użytkownikom na przełączanie”, przełącznik edytora dla poszczególnych postów działa następująco:

Z listy postów:

1. Przejdź do Posty > Wszystkie posty.
2. Najedź kursorem na tytuł posta.
3. Kliknij Edytuj (Classic Editor) lub Edytuj (Block Editor) według potrzeb.

Z wnętrza edytora:

W Gutenbergu link z napisem Przełącz na Classic Editor pojawia się w menu z trzema kropkami (prawy górny róg). W Classic Editor link z napisem Przełącz na Block Editor pojawia się w górnej części ekranu.

Ostrzeżenie: Przełączenie posta napisanego w Gutenbergu na Classic Editor — a następnie jego zapisanie — zachowa adnotacje komentarzy gramatyki bloków w surowym HTML. Te komentarze są nieszkodliwe dla renderowania front-endu, ale będą wyświetlać się jako dosłowny tekst w zakładce Text Classic Editor, co może być mylące. Przełączenie z powrotem na Gutenberg poprawnie je przeparsuje. Odwrotny scenariusz (treść Classic Editor otwarta w Gutenbergu) jest czysty, ponieważ Gutenberg automatycznie opakowuje nierozpoznany HTML w blok Classic.

Wyłączanie Classic Editor bez wtyczki

Jeśli chcesz wymusić Gutenberg i uniemożliwić korzystanie z Classic Editor — lub jeśli chcesz wyłączyć Gutenberg bez instalowania wtyczki — WordPress udostępnia hook filtra:

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

Osiąga to ten sam efekt co wtyczka Classic Editor dla edycji postów, ale nie wpływa na Site Editor (Full Site Editing). Aby całkowicie wyłączyć Gutenberg, w tym FSE:

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

To podejście jest preferowane w środowiskach, gdzie instalowanie dodatkowych wtyczek jest ograniczone przez politykę, lub gdzie chcesz mieć logikę wyłączania kontrolowaną przez wersje w swoim motywie lub wtyczce, a nie zależną od stanu aktywacji wtyczki zewnętrznej.

Classic Editor i środowiska hostingowe WordPress

Sama wtyczka Classic Editor jest lekka i nie nakłada żadnych znaczących wymagań po stronie serwera. Jednak szerszy kontekst środowiska hostingowego wpływa na doświadczenie edycji w sposób wart odnotowania.

Na planach hostingu współdzielonego panel administracyjny WordPress może działać wolno, ponieważ wykonywanie PHP i zapytania do bazy danych konkurują z innymi najemcami na tym samym serwerze. Classic Editor jest mierzalnie lżejszy niż Gutenberg w tym kontekście — mniej wywołań REST API, brak narzutu renderowania React i mniejszy ładunek JavaScript oznaczają szybsze ładowanie stron w panelu administracyjnym. Jeśli korzystasz z planu Hostingu Współdzielonego i uważasz, że edytor bloków jest wolny, Classic Editor jest praktyczną optymalizacją.

Na VPS z cPanel masz pełną kontrolę nad limitami pamięci PHP, konfiguracją OPcache i buforowaniem zapytań MySQL. W tym środowisku oba edytory działają dobrze, a wybór staje się czysto preferencją dotyczącą przepływu pracy, a nie koniecznością wydajnościową.

W przypadku instalacji WordPress o dużym ruchu na Serwerach Dedykowanych wybór edytora ma zasadniczo zerowy wpływ na wydajność front-endu — interfejs edycji jest ładowany tylko przez uwierzytelnionych użytkowników administracyjnych, a opublikowany wynik HTML jest tym, co ma znaczenie dla szybkości strony.

Typowe pułapki i przypadki brzegowe

TinyMCE usuwający prawidłowy HTML: Konfiguracja valid_elements i extended_valid_elements TinyMCE kontroluje, które tagi HTML i atrybuty są dozwolone w edytorze Visual. Domyślnie usuwa tagi takie jak <article>, <section>, <figure> (w starszych konfiguracjach) i wszelkie niestandardowe atrybuty data. Jeśli Twoja treść wymaga tych elementów, musisz rozszerzyć dozwolone elementy TinyMCE przez filtr tiny_mce_before_init:

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

Konflikty autozapisu: Classic Editor używa starszej funkcji JavaScript wp_autosave(), która wysyła żądania POST do wp-admin/post.php z action=autosave. Jeśli Twój serwer ma agresywne ograniczanie szybkości lub regułę WAF blokującą powtarzające się żądania POST do wp-admin, autozapisy będą cicho zawodzić. Monitoruj logi błędów serwera, jeśli dochodzi do utraty treści.

Classic Editor i motywy Full Site Editing (FSE): Jeśli Twój aktywny motyw jest motywem FSE (deklarującym "blockTemplates": true w theme.json), Classic Editor nadal będzie działać dla treści postów i stron, ale Site Editor (/wp-admin/site-editor.php) jest całkowicie oparty na Gutenbergu i nie jest dotknięty przez wtyczkę Classic Editor. Nie możesz używać Classic Editor do edycji szablonów motywu FSE.

Zachowanie przy dezaktywacji wtyczki: Dezaktywacja wtyczki Classic Editor nie konwertuje Twojej treści. Posty napisane w Classic Editor pozostają jako czysty HTML. Posty napisane w Gutenbergu zachowują swoją gramatykę bloków. Gutenberg poprawnie przeparsuje oba. Dezaktywacja wtyczki nie niesie ryzyka utraty danych.

Macierz decyzyjna: którego edytora powinieneś używać?

Użyj Classic Editor, jeśli:

• Twoja witryna używa wtyczek ze złożonymi interfejsami meta boxów, które psują się w warstwie kompatybilności Gutenberg
• Twój serwer ogranicza WordPress REST API
• Migrujesz treść na platformę inną niż WordPress i potrzebujesz czystego, przenośnego HTML
• Twój zespół redakcyjny jest duży, nieposiadający wiedzy technicznej i przeszkolony w przepływie pracy Classic Editor
• Uruchamiasz WordPress w środowisku hostingu współdzielonego z ograniczonymi zasobami

Użyj Gutenberg, jeśli:

• Budujesz nowe witryny bez zależności od starszych wtyczek
• Twój motyw jest oparty na blokach lub kompatybilny z FSE
• Potrzebujesz bloków wielokrotnego użytku, wzorców bloków lub złożonych układów wielokolumnowych bez page buildera
• Budujesz niestandardowe bloki z register_block_type() dla projektów klientów
• Chcesz wykorzystać Site Editor do pełnej personalizacji motywu

Używaj obu (z włączonym przełączaniem dla poszczególnych użytkowników), jeśli:

• Masz mieszany zespół, gdzie niektórzy redaktorzy preferują Classic, a inni Gutenberg
• Jesteś w okresie przejściowym migracji starszej witryny do architektury opartej na blokach
• Różne typy postów na Twojej witrynie mają różne wymagania dotyczące złożoności

Praktyczna lista kontrolna techniczna

Przed przełączeniem produkcyjnej witryny na Classic Editor zweryfikuj następujące kwestie:

• ] Potwierdź, że wersja wtyczki Classic Editor jest aktualna (sprawdź [wordpress.org/plugins/classic-editor dla najnowszego wydania)
• [ ] Przetestuj interfejsy meta boxów wszystkich aktywnych wtyczek w Classic Editor w środowisku testowym przed wdrożeniem na produkcję
• [ ] Przejrzyj swoje filtry tiny_mce_before_init, jeśli masz niestandardowe konfiguracje TinyMCE, które mogą kolidować z domyślnymi ustawieniami wtyczki
• [ ] Zdecyduj o polityce „zezwalania na przełączanie” i udokumentuj ją dla swojego zespołu redakcyjnego
• [ ] Jeśli używasz WP-CLI, potwierdź, że wtyczka jest aktywowana za pomocą wp plugin list --status=active
• [ ] Sprawdź, czy Twój motyw nie opiera się na stylach bloków specyficznych dla Gutenberg (klasy CSS wp-block-*) dla renderowania front-endu
• [ ] Wykonaj kopię zapasową bazy danych przed wprowadzeniem jakichkolwiek zmian przełączania edytora na witrynie z istniejącą treścią Gutenberg
• [ ] Jeśli korzystasz z sieci Multisite, zdecyduj, czy aktywować w całej sieci czy per-witryna i wymuś przez Settings > Writing na poziomie sieci

Sparuj swoją konfigurację WordPress z odpowiednio zabezpieczoną domeną, upewniając się, że Twoje Certyfikaty SSL są ważne i automatycznie odnawiane — panel administracyjny WordPress przesyła ciasteczka uwierzytelniające, które muszą być chronione przez HTTPS niezależnie od tego, którego edytora używasz.

Dla zespołów zarządzających przepływami pracy redakcyjnymi obejmującymi powiadomienia e-mail, komunikację z autorami lub integracje z newsletterami, dedykowana konfiguracja Hostingu Poczty E-mail zapewnia niezawodne dostarczanie transakcyjnych e-maili WordPress (resetowanie haseł, powiadomienia o komentarzach, zmiany statusu postów), a nie routing przez domyślny sendmail serwera współdzielonego.

FAQ

Czy wtyczka Classic Editor wpływa na renderowanie front-endu lub wydajność witryny?

Nie. Wtyczka Classic Editor modyfikuje tylko interfejs edycji po stronie administracyjnej. Nie ma żadnego wpływu na sposób, w jaki WordPress renderuje strony dla odwiedzających. Wydajność front-endu jest określana przez Twój motyw, warstwę buforowania i konfigurację serwera — nie przez to, który edytor był używany do pisania treści.

Czy przełączenie z Gutenberg na Classic Editor uszkodzi moją istniejącą treść opartą na blokach?

Nie. Gutenberg przechowuje adnotacje bloków jako komentarze HTML wewnątrz post_content. Classic Editor wyświetli ten surowy HTML w zakładce Text i spróbuje go wyrenderować w zakładce Visual. Treść nie jest usuwana ani uszkadzana. Jeśli zapiszesz post Gutenberg w Classic Editor bez jego edytowania, adnotacje bloków są zachowane. Jeśli edytujesz i zapiszesz, TinyMCE może znormalizować niektóre białe znaki, ale nie usunie adnotacji komentarzy.

Czy mogę używać Classic Editor dla niektórych typów postów, a Gutenberg dla innych?

Tak, ale nie przez interfejs ustawień wtyczki Classic Editor. Musisz użyć filtra use_block_editor_for_post_type w kodzie:

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 );

Czy wtyczka Classic Editor będzie trwale utrzymywana?

WordPress.org zobowiązał się do utrzymywania wtyczki Classic Editor z aktualizacjami bezpieczeństwa i kompatybilności co najmniej do 2024 roku i nadal otrzymuje aktualizacje po tym zobowiązaniu. Jednak nie otrzymuje żadnych nowych funkcji — jest w trybie konserwacji. W przypadku długoterminowych nowych projektów Gutenberg jest strategicznym kierunkiem rdzenia WordPress.

Czy Classic Editor działa z WooCommerce?

Tak. Edytor produktów WooCommerce był historycznie zbudowany na meta boxach Classic Editor. Nowsze wersje WooCommerce (8.x+) wprowadziły nowy edytor produktów zbudowany na blokach, ale starszy formularz produktu oparty na Classic Editor pozostaje dostępny i jest domyślny dla większości instalacji. Wtyczka Classic Editor nie zakłóca ekranów edycji produktów WooCommerce.