Как использовать классический редактор в WordPress: установка, настройка и когда это действительно имеет смысл
WordPress Classic Editor — это WYSIWYG-редактор контента на основе TinyMCE, который предшествовал блочной системе Gutenberg, введённой в WordPress 5.0. Он представляет собой единый линейный холст для редактирования — визуально похожий на Microsoft Word — где текст, медиафайлы и HTML сосуществуют в одном непрерывном поле, а не в виде отдельных, складываемых блоков. Для пользователей, которым нужно установить его сегодня, краткий ответ таков: установите официальный плагин Classic Editor из репозитория плагинов WordPress, активируйте его и настройте редактор по умолчанию в разделе Настройки > Написание.
Этот ответ из двух предложений охватывает основной вопрос. Остальная часть этого руководства посвящена архитектурным различиям между двумя редакторами, обоснованным техническим причинам выбора одного из них, крайним случаям конфигурации и сценариям, в которых принудительное использование Classic Editor создаёт больше проблем, чем решает.
Classic Editor и блочный редактор Gutenberg: техническое сравнение
Прежде чем менять какие-либо настройки, стоит понять, между чем именно вы переключаетесь. Это решение не является чисто косметическим.
| Параметр | Classic Editor (TinyMCE) | Блочный редактор Gutenberg |
|---|---|---|
| — | — | — |
| **Базовая технология** | TinyMCE 4.x WYSIWYG на основе iframe | Дерево компонентов React.js |
| **Хранение контента** | Чистый HTML в `post_content` | HTML с комментариями блочной грамматики (`<!– wp:paragraph –>`) |
| **Зависимость от REST API** | Минимальная — работает без REST API | Требует REST API для полноценной работы |
| **Поддержка пользовательских мета-блоков** | Полная, нативная поддержка | Частичная — устаревшие мета-блоки отображаются в слое совместимости |
| **Совместимость с конструкторами страниц** | Высокая (Elementor Classic, WPBakery и др.) | Варьируется — зависит от версии конструктора |
| **Различия в ревизиях** | Diff всего HTML поста | Diff на уровне блоков (более детальный) |
| **Производительность (загрузка редактора)** | Легче — нет бандла React | Тяжёлая начальная JS-нагрузка (~400 КБ+ в сжатом виде) |
| **Доступность** | Зрелая, хорошо протестированная | Активно улучшается, но исторически непоследовательная |
| **Долгосрочная поддержка** | Поддерживается через плагин; новых функций нет | Активная разработка, основное направление WordPress core |
| **Обработка шорткодов** | Встроенный рендеринг на вкладке «Визуально» | Специальный блок шорткода |
Наиболее операционно значимое различие — хранение контента. 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 не имеет такой зависимости и будет нормально функционировать в этих условиях.
Управление редактором в Multisite и на основе ролей
В установках WordPress Multisite сетевые администраторы иногда вынуждены обеспечивать единообразный опыт редактирования на всех подсайтах — особенно когда задействованы нетехнические редакторы. Плагин Classic Editor поддерживает опцию Settings > Writing для запрета переключения редактора отдельными пользователями, фиксируя всех пользователей в Classic Editor независимо от их личных предпочтений. Gutenberg не предлагает аналогичного механизма принудительного применения на уровне сети без написания пользовательского кода.
Скорость работы с текстовым контентом
Для издателей, производящих большие объёмы текстового контента — новостных статей, документации, юридических материалов — модель единого холста Classic Editor действительно быстрее. Нет необходимости вставлять новый блок, выбирать тип блока или переходить между панелями настроек блока. Вы нажимаете Enter и продолжаете писать. Для редакторов, работающих с клавиатурой и использующих горячие клавиши вкладки HTML, это имеет значение.
Как установить плагин Classic Editor
Classic Editor не входит в состав WordPress core. Он поддерживается как официальный плагин командой WordPress Contributors и доступен в репозитории плагинов WordPress.org.
Способ 1: Установка через панель управления WordPress
- Войдите в панель администратора WordPress (
/wp-admin). - Перейдите в раздел Плагины > Добавить новый плагин.
- В поле поиска введите
Classic Editor. - Найдите плагин, автором которого является WordPress Contributors — проверьте автора, так как существуют плагины-имитаторы с похожими названиями.
- Нажмите Установить, затем Активировать.
Способ 2: Установка через WP-CLI
Если вы управляете WordPress из командной строки — что является стандартной практикой в любой среде VPS Хостинга — WP-CLI значительно быстрее, чем UI панели управления:
wp plugin install classic-editor --activateДля установки на всю сеть в установке Multisite:
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
Вкладка «Визуально» (режим WYSIWYG)
Вкладка «Визуально» отображает ваш контент через предварительный просмотр TinyMCE на основе iframe. Панель инструментов предоставляет:
- Форматирование текста: Жирный (
Ctrl+B), Курсив (Ctrl+I), Зачёркнутый, Подчёркнутый - Стили абзацев: Заголовок 1 — Заголовок 6, Форматированный, Цитата
- Списки: Нумерованные и маркированные, с элементами управления отступами
- Ссылки: Вставка/редактирование гиперссылок с атрибутами target и title
- Вставка медиафайлов: Открывает медиатеку WordPress для изображений, видео, аудио и документов
- Вставка из Word: Удаляет проприетарную HTML-разметку Microsoft Word при вставке
- Режим письма без отвлечений: Переключение в полноэкранный режим, скрывающий весь UI администратора
Панель инструментов имеет две строки. Если вы видите только одну строку, нажмите кнопку Переключить панель инструментов (последний значок в первой строке), чтобы открыть вторую строку, которая включает селектор стиля абзаца, цвет текста, карту символов и отмену/повтор действий.
Вкладка «Текст» (режим чистого HTML)
Вкладка «Текст» открывает доступ к чистому HTML, хранящемуся в post_content. Это не полноценный редактор кода — в нём отсутствует подсветка синтаксиса и нумерация строк — но он даёт прямой доступ к разметке. Полезные сценарии:
- Вставка встраиваемых элементов
<iframe>, которые TinyMCE мог бы удалить или экранировать - Добавление пользовательских HTML-атрибутов, которые UI вкладки «Визуально» не предоставляет
- Отладка проблем рендеринга, вызванных автоматической очисткой тегов в TinyMCE
Важное поведение, которое необходимо понимать: TinyMCE выполняет санитизацию HTML при переключении с вкладки «Текст» обратно на вкладку «Визуально». Он закроет незакрытые теги, удалит определённые элементы (например, <script> в некоторых конфигурациях) и нормализует пробелы. Если вы пишете чистый HTML на вкладке «Текст», всегда проверяйте, что он сохраняется при переключении обратно на «Визуально» перед публикацией.
Мета-блоки «Цитата», «Произвольные поля» и «Обсуждение»
Под основным холстом редактора Classic Editor отображает полный набор нативных мета-блоков WordPress в их исходном макете:
- Цитата: Текстовое резюме, используемое темами и SEO-плагинами для мета-описаний
- Произвольные поля: Пары ключ-значение, хранящиеся в
wp_postmeta— доступны напрямую без переключения на боковую панель - Обсуждение: Настройки комментариев и обратных ссылок для каждой записи
- Ярлык: Редактируемое поле URL-ярлыка (также в блоке «Опубликовать»)
- Автор: Переназначение авторства записи без перехода на другую страницу
Эти мета-блоки всегда видны и занимают всю ширину в Classic Editor. В Gutenberg они либо скрыты в боковой панели, либо отображаются в iframe совместимости — значимое различие в UX для рабочих процессов, активно использующих произвольные поля.
Переключение между редакторами для отдельных записей
Если вы включили опцию «Разрешить пользователям переключаться», переключатель редактора для каждой записи работает следующим образом:
Из списка записей:
- Перейдите в раздел Записи > Все записи.
- Наведите курсор на заголовок записи.
- Нажмите Изменить (Classic Editor) или Изменить (Блочный редактор) по необходимости.
Из самого редактора:
В Gutenberg ссылка Переключиться на Classic Editor появляется в меню с тремя точками (вверху справа). В Classic Editor ссылка Переключиться на блочный редактор появляется в верхней части экрана.
Предупреждение: Переключение записи, созданной в Gutenberg, на Classic Editor — и последующее её сохранение — сохранит комментарии блочной грамматики в чистом HTML. Эти комментарии безвредны для рендеринга на фронтенде, но будут отображаться как буквальный текст на вкладке «Текст» 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 для редактирования записей, но не затрагивает редактор сайта (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 по-прежнему будет работать для контента записей и страниц, но редактор сайта (/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()для клиентских проектов - Вы хотите использовать редактор сайта для полной настройки темы
Используйте оба (с включённым переключением для каждого пользователя), если:
- У вас смешанная команда, где одни редакторы предпочитают 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 передаёт аутентификационные куки, которые должны быть защищены HTTPS независимо от того, какой редактор вы используете.
Для команд, управляющих редакционными рабочими процессами, включающими email-уведомления, коммуникации с авторами или интеграции с рассылками, выделенный Email-хостинг обеспечивает надёжную доставку транзакционных email WordPress (сброс пароля, уведомления о комментариях, изменения статуса записей), а не маршрутизацию через стандартный sendmail общего сервера.
FAQ
Влияет ли плагин Classic Editor на рендеринг фронтенда или производительность сайта?
Нет. Плагин Classic Editor изменяет только интерфейс редактирования на стороне администратора. Он не оказывает никакого влияния на то, как WordPress отображает страницы посетителям. Производительность фронтенда определяется вашей темой, уровнем кэширования и конфигурацией сервера — а не тем, какой редактор использовался для написания контента.
Повредит ли переключение с Gutenberg на Classic Editor мой существующий контент на основе блоков?
Нет. Gutenberg хранит аннотации блоков в виде HTML-комментариев внутри post_content. Classic Editor отобразит этот чистый HTML на вкладке «Текст» и попытается отрендерить его на вкладке «Визуально». Контент не удаляется и не повреждается. Если вы сохраните запись 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.
