Як використовувати класичний редактор у WordPress: встановлення, налаштування та коли це справді має сенс

Редактор WordPress Classic Editor — це WYSIWYG-редактор контенту на основі TinyMCE, що передував блоковій системі Gutenberg, введеній у WordPress 5.0. Він являє собою єдине лінійне полотно для редагування — візуально схоже на Microsoft Word — де текст, медіа та HTML співіснують в одному безперервному полі, а не у вигляді окремих блоків, що можна складати. Для тих, хто хоче встановити його сьогодні, коротка відповідь така: встановіть офіційний плагін Classic Editor з репозиторію плагінів WordPress, активуйте його та налаштуйте редактор за замовчуванням у розділі Параметри > Написання.

Ця відповідь із двох речень охоплює основний запит. Решта цього посібника стосується архітектурних відмінностей між двома редакторами, обґрунтованих технічних причин для вибору одного з них, граничних випадків конфігурації та сценаріїв, де примусове використання Classic Editor насправді створює більше проблем, ніж вирішує.

Classic Editor проти блокового редактора Gutenberg: технічне порівняння

Перш ніж торкатися будь-яких налаштувань, варто зрозуміти, між чим саме ви перемикаєтесь. Це рішення не є суто косметичним.

Найбільш операційно значуща відмінність — це зберігання контенту. Classic Editor зберігає чистий HTML. Gutenberg обгортає кожну одиницю контенту в HTML-коментарі, що слугують роздільниками блоків. Якщо вам коли-небудь доведеться переносити контент між системами — до headless CMS, генератора статичних сайтів або платформи, відмінної від WordPress — вихідні дані Classic Editor значно легше аналізувати та переносити. Блокова граматика Gutenberg є власністю парсера WordPress.

Чому розробники та власники сайтів досі обирають Classic Editor

Сумісність зі застарілими плагінами та темами

Багато комерційних плагінів — зокрема старіші конструктори форм, розширення для електронної комерції та плагіни для власних типів записів — реєструють мета-блоки, що вставляють поля безпосередньо на екран редагування запису. У Gutenberg ці мета-блоки переміщуються до згортуваної бічної панелі, що відображається всередині iframe-шиму сумісності. Цей шим не завжди працює коректно: виникають конфлікти JavaScript, умовна логіка ламається, а деякі UI-фреймворки мета-блоків (наприклад, діалоги jQuery UI) не ініціалізуються належним чином у контексті вкладеного документа.

Якщо ваш сайт використовує плагіни з add_meta_box() зі складними UI, що залежать від JavaScript, Classic Editor повністю усуває цей клас проблем.

Обмеження REST API

Редактор Gutenberg постійно надсилає фонові запити до WordPress REST API — для отримання шаблонів блоків, автозбереження чернеток, перевірки статусу блокування запису та перевірки прав користувача. У захищених серверних середовищах, де REST API навмисно обмежений (через add_filter('rest_authentication_errors', ...) або правила на рівні сервера, що блокують /wp-json/), Gutenberg частково або повністю не завантажуватиметься. Classic Editor не має такої залежності та нормально функціонуватиме за цих обмежень.

Мультисайт і контроль редактора на основі ролей

На мультисайтових інсталяціях WordPress мережеві адміністратори іноді потребують забезпечення єдиного досвіду редагування на всіх підсайтах — особливо коли залучені нетехнічні редактори. Плагін Classic Editor підтримує параметр Settings > Writing для заборони перемикання редактора окремими користувачами, фіксуючи всіх користувачів у Classic Editor незалежно від їхніх індивідуальних уподобань. Gutenberg не пропонує еквівалентного механізму примусового застосування на рівні мережі без власного коду.

Швидкість роботи з текстовим контентом

Для видавців, що виробляють великі обсяги текстового контенту — новинні статті, документацію, юридичні документи — модель єдиного полотна Classic Editor є справді швидшою. Немає потреби вставляти новий блок, вибирати тип блоку або переміщатися між панелями налаштувань блоку. Ви натискаєте Enter і продовжуєте писати. Для редакторів, що активно використовують клавіатуру та ярлики вкладки HTML, це має значення.

Як встановити плагін Classic Editor

Classic Editor не входить до складу WordPress core. Він підтримується як офіційний плагін командою WordPress Contributors і доступний у репозиторії плагінів WordPress.org.

Спосіб 1: Встановлення через панель керування WordPress

1. Увійдіть до адміністративної панелі WordPress (/wp-admin).
2. Перейдіть до Плагіни > Додати новий плагін.
3. У полі пошуку введіть Classic Editor.
4. Знайдіть плагін, автором якого є WordPress Contributors — перевірте автора, оскільки існують плагіни-імітатори зі схожими назвами.
5. Натисніть Встановити зараз, потім Активувати.

Спосіб 2: Встановлення через WP-CLI

Якщо ви керуєте WordPress з командного рядка — що є стандартною практикою в будь-якому середовищі VPS Хостингу — WP-CLI значно швидший за UI панелі керування:

wp plugin install classic-editor --activate

Щоб встановити його на всю мережу на мультисайтовій інсталяції:

wp plugin install classic-editor --activate-network

Спосіб 3: Ручне завантаження

Завантажте ZIP-архів плагіна з wordpress.org/plugins/classic-editor, потім завантажте його через Плагіни > Додати новий плагін > Завантажити плагін, або розпакуйте його безпосередньо на сервер:

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

Після розпакування активуйте через WP-CLI або панель керування.

Налаштування параметрів Classic Editor

Після активації плагін відкриває два параметри конфігурації в розділі Параметри > Написання.

Редактор за замовчуванням для всіх користувачів

Перший параметр встановлює загальносайтове значення за замовчуванням. Ви можете вибрати між Classic Editor та Блоковим редактором. Встановлення цього параметра на Classic Editor означає, що кожен новий запис і сторінка відкриватимуться в TinyMCE за замовчуванням.

Дозволити користувачам перемикати редактори

Другий параметр контролює, чи можуть окремі користувачі перевизначати загальносайтове значення за замовчуванням для кожного запису окремо. Коли увімкнено, наведення курсора на запис у списку Записи > Всі записи відображає два посилання для дій: Редагувати (відкривається в загальносайтовому редакторі за замовчуванням) та Редагувати (Classic Editor) або Редагувати (Блоковий редактор) залежно від поточного значення за замовчуванням.

Рекомендована конфігурація для більшості застарілих сайтів:

• Редактор за замовчуванням: Classic Editor
• Дозволити користувачам перемикати: Ні

Це запобігає випадковому відкриттю контенту редакторами в Gutenberg та ненавмисному вставленню коментарів блокової граматики в записи, що були написані в Classic Editor — суміш, яка може спричинити аномалії відображення в деяких темах.

Використання інтерфейсу Classic Editor

Вкладка Visual (режим WYSIWYG)

Вкладка Visual відображає ваш контент через попередній перегляд TinyMCE на основі iframe. Панель інструментів надає:

• Форматування тексту: Жирний (Ctrl+B), Курсив (Ctrl+I), Закреслений, Підкреслений
• Стилі абзаців: Заголовок 1 — Заголовок 6, Попередньо відформатований, Цитата
• Списки: Нумеровані та ненумеровані, з елементами керування відступами
• Посилання: Вставка/редагування гіперпосилань з атрибутами target та title
• Вставка медіа: Відкриває медіатеку WordPress для зображень, відео, аудіо та документів
• Вставка з Word: Видаляє власну HTML-розмітку Microsoft Word при вставці
• Режим письма без відволікань: Перемикач повноекранного режиму, що приховує весь UI адміністратора

Панель інструментів має два рядки. Якщо ви бачите лише один рядок, натисніть кнопку Перемикач панелі інструментів (остання іконка в першому рядку), щоб відкрити другий рядок, який містить селектор стилю абзацу, колір тексту, таблицю символів та скасування/повторення.

Вкладка Text (режим чистого HTML)

Вкладка Text відкриває чистий HTML, що зберігається в post_content. Це не повноцінний редактор коду — він не має підсвічування синтаксису та нумерації рядків — але надає прямий доступ до розмітки. Корисні сценарії:

• Вставка вбудованих елементів <iframe>, які TinyMCE видалив би або екранував
• Додавання власних HTML-атрибутів, які UI вкладки Visual не відображає
• Налагодження проблем відображення, спричинених автоматичним очищенням тегів TinyMCE

Критична поведінка для розуміння: TinyMCE виконує санітизацію HTML при переключенні з вкладки Text назад на вкладку Visual. Він закриє незакриті теги, видалить певні елементи (наприклад, <script> у деяких конфігураціях) та нормалізує пробіли. Якщо ви пишете чистий HTML у вкладці Text, завжди перевіряйте, що він зберігається після переходу назад до Visual перед публікацією.

Мета-блоки Excerpt, Custom Fields та Discussion

Під основним полотном редактора Classic Editor відображає повний набір нативних мета-блоків WordPress у їхньому оригінальному вигляді:

• Excerpt: Текстовий підсумок, що використовується темами та SEO-плагінами для мета-описів
• Custom Fields: Пари ключ-значення, що зберігаються в wp_postmeta — доступні безпосередньо без переходу до бічної панелі
• Discussion: Налаштування коментарів та зворотних посилань для кожного запису
• Slug: Поле редагованого URL-слагу (також у блоці Publish)
• Author: Перепризначення авторства запису без переходу на іншу сторінку

Ці мета-блоки завжди видимі та на всю ширину в Classic Editor. У Gutenberg вони або приховані в бічній панелі, або відображаються в iframe сумісності — суттєва відмінність UX для робочих процесів, що значною мірою покладаються на власні поля.

Перемикання між редакторами для кожного запису

Якщо ви увімкнули параметр «Дозволити користувачам перемикати», перемикач редактора для кожного запису працює наступним чином:

Зі списку записів:

1. Перейдіть до Записи > Всі записи.
2. Наведіть курсор на заголовок запису.
3. Натисніть Редагувати (Classic Editor) або Редагувати (Блоковий редактор) за потреби.

Зсередини редактора:

У Gutenberg посилання Перейти до Classic Editor з’являється в меню з трьома крапками (верхній правий кут). У Classic Editor посилання Перейти до блокового редактора з’являється у верхній частині екрана.

Попередження: Перемикання запису, написаного в Gutenberg, до Classic Editor — і подальше його збереження — збереже коментарі блокової граматики в чистому HTML. Ці коментарі нешкідливі для відображення на фронтенді, але відображатимуться як буквальний текст у вкладці Text Classic Editor, що може бути незрозумілим. Перемикання назад до Gutenberg правильно їх перепарсить. Зворотний сценарій (контент Classic Editor, відкритий у Gutenberg) є чистим, оскільки Gutenberg автоматично обгортає нерозпізнаний HTML у блок Classic.

Вимкнення Classic Editor без плагіна

Якщо ви хочете примусово використовувати Gutenberg і запобігти використанню Classic Editor — або якщо ви хочете вимкнути Gutenberg без встановлення плагіна — WordPress надає хук-фільтр:

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

Це досягає того ж ефекту, що й плагін Classic Editor для редагування записів, але не впливає на Site Editor (Full Site Editing). Для повного вимкнення Gutenberg, включаючи FSE:

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

Цей підхід є кращим у середовищах, де встановлення додаткових плагінів обмежено політикою, або де ви хочете, щоб логіка вимкнення контролювалася версіями у вашій темі або плагіні, а не залежала від стану активації стороннього плагіна.

Classic Editor та середовища хостингу WordPress

Сам плагін Classic Editor є легким і не висуває жодних суттєвих вимог на стороні сервера. Однак ширший контекст вашого хостингового середовища впливає на досвід редагування способами, що варті уваги.

На тарифах спільного хостингу адміністративна панель WordPress може здаватися повільною, оскільки виконання PHP та запити до бази даних конкурують з іншими орендарями на тому ж сервері. Classic Editor помітно легший за Gutenberg у цьому контексті — менше викликів REST API, відсутність накладних витрат на рендеринг React та менший обсяг JavaScript означають швидше завантаження сторінок в адміністративній частині. Якщо ви користуєтесь тарифом Спільного веб-хостингу і вважаєте блоковий редактор повільним, Classic Editor є практичною оптимізацією.

На VPS з cPanel ви маєте повний контроль над лімітами пам’яті PHP, конфігурацією OPcache та кешуванням запитів MySQL. У цьому середовищі обидва редактори працюють добре, і вибір стає суто питанням робочого процесу, а не необхідністю продуктивності.

Для високонавантажених інсталяцій WordPress на Виділених серверах вибір редактора практично не впливає на продуктивність фронтенду — інтерфейс редагування завантажується лише автентифікованими адміністраторами, і саме опублікований HTML-вивід має значення для швидкості сторінки.

Поширені підводні камені та граничні випадки

TinyMCE видаляє валідний HTML: Конфігурація valid_elements та extended_valid_elements TinyMCE контролює, які HTML-теги та атрибути дозволені у візуальному редакторі. За замовчуванням він видаляє теги на кшталт <article>, <section>, <figure> (у старіших конфігураціях) та будь-які власні атрибути даних. Якщо ваш контент потребує їх, ви повинні розширити дозволені елементи TinyMCE через фільтр tiny_mce_before_init:

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

Конфлікти автозбереження: Classic Editor використовує старішу функцію JavaScript wp_autosave(), яка надсилає POST-запити до wp-admin/post.php з action=autosave. Якщо ваш сервер має агресивне обмеження частоти запитів або правило WAF, що блокує повторні POST-запити до wp-admin, автозбереження мовчки не виконуватиметься. Відстежуйте журнали помилок сервера, якщо виникає втрата контенту.

Classic Editor та теми Full Site Editing (FSE): Якщо ваша активна тема є FSE-темою (тією, що оголошує "blockTemplates": true у theme.json), Classic Editor все одно працюватиме для контенту записів і сторінок, але Site Editor (/wp-admin/site-editor.php) повністю базується на Gutenberg і не залежить від плагіна Classic Editor. Ви не можете використовувати Classic Editor для редагування шаблонів FSE-теми.

Поведінка при деактивації плагіна: Деактивація плагіна Classic Editor не конвертує ваш контент. Записи, написані в Classic Editor, залишаються чистим HTML. Записи, написані в Gutenberg, зберігають свою блокову граматику. Gutenberg правильно парсить обидва варіанти. Деактивація плагіна не несе ризику втрати даних.

Матриця рішень: який редактор використовувати?

Використовуйте Classic Editor, якщо:

• Ваш сайт використовує плагіни зі складними UI мета-блоків, що ламаються в шарі сумісності Gutenberg
• Ваш сервер обмежує WordPress REST API
• Ви переносите контент на платформу, відмінну від WordPress, і потребуєте чистого, портативного HTML
• Ваша редакційна команда велика, нетехнічна та навчена на робочому процесі Classic Editor
• Ви запускаєте WordPress на ресурсно обмеженому середовищі спільного хостингу

Використовуйте Gutenberg, якщо:

• Ви створюєте нові сайти без залежностей від застарілих плагінів
• Ваша тема базується на блоках або сумісна з FSE
• Вам потрібні багаторазові блоки, шаблони блоків або складні багатоколонкові макети без конструктора сторінок
• Ви створюєте власні блоки з register_block_type() для клієнтських проектів
• Ви хочете використовувати Site Editor для повного налаштування теми

Використовуйте обидва (з увімкненим перемиканням для кожного користувача), якщо:

• У вас змішана команда, де одні редактори надають перевагу Classic, а інші — Gutenberg
• Ви перебуваєте в перехідному періоді міграції застарілого сайту до блокової архітектури
• Різні типи записів на вашому сайті мають різні вимоги до складності

Практичний технічний контрольний список

Перш ніж перемикати робочий сайт на Classic Editor, перевірте наступне:

• ] Переконайтеся, що версія плагіна Classic Editor актуальна (перевірте [wordpress.org/plugins/classic-editor для останнього випуску)
• [ ] Протестуйте UI мета-блоків усіх активних плагінів у Classic Editor на тестовому середовищі перед розгортанням на продакшн
• [ ] Перегляньте ваші фільтри tiny_mce_before_init, якщо у вас є власні конфігурації TinyMCE, що можуть конфліктувати зі значеннями за замовчуванням плагіна
• [ ] Визначте політику «дозволити перемикання» та задокументуйте її для вашої редакційної команди
• [ ] Якщо використовуєте WP-CLI, підтвердіть, що плагін активовано за допомогою wp plugin list --status=active
• [ ] Перевірте, що ваша тема не покладається на специфічні для Gutenberg стилі блоків (CSS-класи wp-block-*) для відображення на фронтенді
• [ ] Зробіть резервну копію бази даних перед будь-якими змінами перемикання редактора на сайті з наявним контентом Gutenberg
• [ ] Якщо ви в мережі Multisite, вирішіть, чи активувати на рівні мережі або для кожного сайту окремо, та застосуйте через Settings > Writing на рівні мережі

Поєднайте налаштування WordPress із належно захищеним доменом, переконавшись, що ваші SSL-сертифікати дійсні та автоматично оновлюються — адміністративна панель WordPress передає файли cookie автентифікації, які повинні бути захищені HTTPS незалежно від того, який редактор ви використовуєте.

Для команд, що керують редакційними робочими процесами, які включають сповіщення електронною поштою, комунікацію з авторами або інтеграцію з розсилками, виділений Хостинг електронної пошти забезпечує надійну доставку транзакційних листів WordPress (скидання паролів, сповіщення про коментарі, зміни статусу записів), а не їх маршрутизацію через стандартний sendmail спільного сервера.

FAQ

Чи впливає плагін Classic Editor на відображення фронтенду або продуктивність сайту?

Ні. Плагін Classic Editor лише змінює інтерфейс редагування на стороні адміністратора. Він не має жодного впливу на те, як WordPress відображає сторінки для відвідувачів. Продуктивність фронтенду визначається вашою темою, шаром кешування та конфігурацією сервера — а не тим, який редактор використовувався для написання контенту.

Чи пошкодить перемикання з Gutenberg на Classic Editor мій наявний контент на основі блоків?

Ні. Gutenberg зберігає анотації блоків як HTML-коментарі всередині post_content. Classic Editor відображатиме цей чистий HTML у вкладці Text та намагатиметься відобразити його у вкладці Visual. Контент не видаляється і не пошкоджується. Якщо ви зберігаєте запис Gutenberg у Classic Editor без редагування, анотації блоків зберігаються. Якщо ви редагуєте та зберігаєте, TinyMCE може нормалізувати деякі пробіли, але не видалятиме коментарі-анотації.

Чи можу я використовувати Classic Editor для одних типів записів, а Gutenberg — для інших?

Так, але не через UI налаштувань плагіна Classic Editor. Вам потрібно використовувати фільтр use_block_editor_for_post_type у коді:

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

Чи буде плагін Classic Editor підтримуватися постійно?

WordPress.org взяв на себе зобов’язання підтримувати плагін Classic Editor оновленнями безпеки та сумісності щонайменше до 2024 року, і він продовжує отримувати оновлення після цього зобов’язання. Однак він не отримує нових функцій — він перебуває в режимі обслуговування. Для довгострокових нових проектів Gutenberg є стратегічним напрямком WordPress core.

Чи працює Classic Editor з WooCommerce?

Так. Редактор товарів WooCommerce історично будувався на мета-блоках Classic Editor. Останні версії WooCommerce (8.x+) представили новий редактор товарів на основі блоків, але застаріла форма редагування товарів на основі Classic Editor залишається доступною і є стандартною для більшості інсталяцій. Плагін Classic Editor не заважає екранам редагування товарів WooCommerce.