Ситуация типовая: сайт уже работает, часть контента удобно редактировать в классическом редакторе, а для других типов записей нужен Gutenberg. Полностью выключать блоковый редактор на всём сайте обычно не стоит — это ломает привычный рабочий процесс и мешает новым шаблонам. Гораздо полезнее отключить его точечно: только для нужных post type, только для отдельных ролей или только там, где есть старые метабоксы и тяжёлые поля.
Ниже — рабочие способы, как сделать это без лишних побочных эффектов, как проверить результат и где чаще всего ошибаются.
Когда отключение Gutenberg действительно нужно
Не каждый конфликт с редактором решается его полным отключением. Обычно точечное отключение нужно в таких сценариях:
- старый тип записей использует метабоксы, которые плохо живут в блоковом интерфейсе;
- кастомный post type редактируется через ACF или похожие поля, а редактор нужен только как контейнер для текста;
- контент-редакторы работают по старому процессу и не готовы к блокам на части разделов;
- в админке есть плагины, которые добавляют сложные метабоксы и визуально конфликтуют с Gutenberg;
- нужно оставить блоки для страниц, но вернуть классический редактор для новостей, обзоров или записей другого типа.
Если задача именно в производительности админки, сначала проверьте, не мешают ли тяжелые плагины, автосохранение или лишние метабоксы. Сам по себе Gutenberg не всегда является источником проблемы.
Диагностика: что именно надо отключить
Перед правкой кода важно понять, где редактор включён сейчас. В WordPress это зависит от поддержки editor у типа записи и от фильтров, которые добавляют плагины или тема.
Проверьте тип записи
Если проблема только в одном custom post type, не трогайте весь сайт. Посмотрите, как он зарегистрирован: есть ли у него поддержка редактора, и не отключает ли её тема через remove_post_type_support().
Проверьте плагины, которые вмешиваются в редактор
Часто Gutenberg отключают не кодом темы, а плагином для классического редактора или набором оптимизаций. Если на сайте уже есть такой плагин, не дублируйте логику в functions.php. Иначе получите ситуацию, когда один инструмент включает редактор, а другой тут же его выключает.
Проверьте, не нужен ли блоковый редактор для шаблонов
Если сайт использует шаблоны блоков, паттерны или редактор сайта, отключение Gutenberg на страницах может затронуть не только контент, но и рабочий процесс команды. В таком случае лучше ограничиться конкретными типами записей, а не всем интерфейсом.
Способ 1: отключить Gutenberg для конкретного типа записей через фильтр
Самый предсказуемый вариант — использовать фильтр use_block_editor_for_post_type. Он позволяет оставить Gutenberg там, где он нужен, и выключить его только для выбранных post type.
<?php
add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
$disabled_post_types = array( 'post', 'news', 'portfolio' );
if ( in_array( $post_type, $disabled_post_types, true ) ) {
return false;
}
return $use_block_editor;
}, 10, 2 );В этом примере Gutenberg отключается для обычных записей post, а также для двух кастомных типов: news и portfolio. Для остальных типов редактор остаётся включённым.
Если вам нужно убрать блоковый редактор только для одного типа, список можно сократить до одного значения. Это лучше, чем писать отдельные условия в нескольких местах.
Способ 2: отключить поддержку редактора у кастомного типа
Если тип записи регистрируете вы сами, проще сразу не добавлять поддержку редактора. Это удобно, когда контент редактируется через метабоксы, ACF-поля или собственную форму.
<?php
register_post_type( 'catalog_item', array(
'label' => 'Каталог',
'public' => true,
'show_ui' => true,
'supports' => array( 'title', 'thumbnail' ),
'has_archive' => true,
) );Здесь у типа catalog_item нет поддержки editor, поэтому блоковый редактор не будет показан. Это не фильтр, а настройка регистрации. Такой подход лучше, если вы проектируете тип записи с нуля.
Если тип уже существует, а код регистрации менять неудобно, используйте фильтр из предыдущего раздела. Не пытайтесь одновременно убрать поддержку в регистрации и ещё раз отключать редактор фильтром без необходимости.
Способ 3: вернуть классический редактор только для части ролей
Иногда проблема не в типе записи, а в том, что редактор нужен только редакторам контента, а администраторам — нет. Тогда отключение по post type не помогает. В таком случае можно завязаться на роль пользователя, но делать это аккуратно: WordPress не даёт готового фильтра именно по роли в use_block_editor_for_post_type, поэтому условие придётся строить через текущего пользователя.
<?php
add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
if ( 'post' !== $post_type ) {
return $use_block_editor;
}
$user = wp_get_current_user();
if ( in_array( 'author', (array) $user->roles, true ) ) {
return false;
}
return $use_block_editor;
}, 10, 2 );Этот вариант полезен, если редакторы работают по старому процессу, а администраторы тестируют блоки. Но как правило лучше не завязывать интерфейс на роль без крайней необходимости: поддержка такого условия усложняет сопровождение.
Сравнение подходов
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
Фильтр use_block_editor_for_post_type | Нужно отключить Gutenberg для отдельных типов | Точечно, просто откатить | Надо знать slug типа записи |
Убрать поддержку editor при регистрации | Вы сами пишете post type | Чистая архитектура | Не подходит для уже существующих типов |
| Отключение по роли | Разные команды работают по-разному | Гибко | Сложнее поддерживать и тестировать |
Проверка результата после внедрения
После изменения кода не ограничивайтесь визуальной проверкой одной записи. Нужно убедиться, что редактор отключён именно там, где вы планировали, и не задел другие типы.
- Откройте запись нужного типа в админке и проверьте, что интерфейс стал классическим.
- Создайте новую запись другого типа и убедитесь, что Gutenberg там остался.
- Проверьте, не пропали ли метабоксы и не сломалась ли загрузка медиафайлов.
- Если используется ACF или другой плагин полей, проверьте сохранение значений.
- Очистите кеш, если на сайте есть плагин кеширования админки или object cache, и повторите тест.
Если изменения не видны сразу, проверьте, не подключён ли плагин Classic Editor или аналогичный. Он может перебивать ваш код и создавать ложное ощущение, что фильтр не работает.
Частые ошибки и как их исправить
Отключают Gutenberg через весь сайт, хотя нужен только один тип
Это самая частая ошибка. В результате страдают страницы, шаблоны и редакторы, которые уже привыкли к блокам. Исправление простое: ограничьте условие массивом конкретных post type.
Путают slug типа записи
В коде нужен не ярлык из админки, а системный slug. Например, news, а не «Новости». Если slug указан неверно, фильтр просто не сработает.
Правят тему, а потом теряют изменения
Если код добавлен в functions.php активной темы, при обновлении или смене темы он может исчезнуть. Для стабильного решения лучше вынести логику в мини-плагин или mu-plugin.
Оставляют конфликтующие плагины включёнными
Если одновременно работает плагин для классического редактора и собственный фильтр, результат может быть непредсказуемым. Сначала проверьте, кто именно управляет редактором, и оставьте один источник истины.
Безопасность и поддержка: как не создать лишнюю проблему
Отключение Gutenberg — это не только про удобство. Если код написан неаккуратно, можно случайно скрыть редактор там, где он нужен для SEO-блоков, FAQ, разметки или шаблонов контента. Поэтому лучше придерживаться нескольких правил:
- не отключайте редактор глобально без причины;
- храните код отдельно от темы, если он критичен для процесса редактирования;
- после обновления плагинов проверяйте, не изменились ли slug типов записей;
- если на сайте несколько редакторов контента, документируйте, где Gutenberg выключен и почему;
- не смешивайте отключение редактора с оптимизацией фронтенда — это разные задачи.
Если вам нужен более широкий набор технических настроек для чистки админки и управления лишними функциями WordPress, иногда удобнее собрать их в одном инструменте, чем держать россыпь разрозненных сниппетов. Но даже в этом случае точечную логику лучше оставлять в коде, чтобы было понятно, что именно и зачем отключено.
Когда задача сводится к управлению несколькими техническими опциями сайта, полезно сначала зафиксировать, какие типы записей и роли должны видеть блоковый редактор, а какие — нет. Тогда любое последующее изменение можно проверить за пару минут, а не искать причину по всей админке.