Сценарий знакомый: сайт уже живёт на классическом редакторе, в части разделов стоят старые метабоксы, а в одном-двух типах записей Gutenberg только мешает. Если отключить его грубо, можно сломать редактор, скрыть нужные поля или получить странное поведение в админке. Поэтому безопаснее выключать блочный редактор точечно — для конкретных post type, а не для всего сайта.
Когда это действительно нужно
Чаще всего проблема всплывает в таких случаях:
- кастомный тип записей завязан на метабоксы из
add_meta_box(); - контент собирается по старому шаблону и не должен редактироваться блоками;
- в редакторе появляются конфликты с ACF, Carbon Fields или самописными полями;
- нужно оставить Gutenberg для записей и страниц, но убрать его для новостей, кейсов, отзывов или каталога;
- редакторы путаются в блоках и ломают структуру контента там, где нужен строгий шаблон.
Диагностика: что именно ломается
Перед изменениями проверьте, что проблема именно в Gutenberg, а не в теме или плагине. Полезно быстро сравнить поведение в двух режимах:
- откройте нужный тип записи в админке и посмотрите, есть ли кнопка переключения на классический редактор;
- проверьте, исчезают ли метабоксы после загрузки страницы редактирования;
- временно отключите плагины, которые добавляют поля, и убедитесь, что конфликт не в них;
- посмотрите, не переопределяет ли тема поддержку редактора через
add_theme_support( 'editor-styles' )или связанные настройки.
Если метабоксы пропадают только в блочном редакторе, а в классическом всё на месте, значит задача именно в точечном отключении Gutenberg.
Пошаговое решение через код
Самый предсказуемый способ — фильтр use_block_editor_for_post_type. Он позволяет отключить блочный редактор для выбранных типов записей и не трогать остальные.
<?php
add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
$disabled_post_types = array( 'case', 'review', 'catalog_item' );
if ( in_array( $post_type, $disabled_post_types, true ) ) {
return false;
}
return $use_block_editor;
}, 10, 2 );Этот вариант удобен тем, что не зависит от конкретной темы и работает на уровне логики WordPress. Если потом понадобится вернуть Gutenberg для одного типа, достаточно убрать его из массива.
Если нужно отключить редактор только для одного типа
Можно сделать ещё проще:
<?php
add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
if ( 'news' === $post_type ) {
return false;
}
return $use_block_editor;
}, 10, 2 );Такой код лучше держать в дочерней теме или в небольшом mu-plugin, если настройка должна переживать обновления темы.
Альтернатива через поддержку типа записи
Если вы сами регистрируете post type, можно сразу отключить поддержку редактора в аргументах register_post_type(). Но этот способ подходит только тогда, когда код регистрации у вас под контролем.
<?php
register_post_type( 'case', array(
'label' => 'Кейсы',
'public' => true,
'show_ui' => true,
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
'show_in_rest' => false,
) );Здесь важный момент: show_in_rest не отключает Gutenberg сам по себе для всех сценариев, но для классического подхода к редактированию это часто часть общей настройки. Если тип записи уже используется в REST или блоках, меняйте его аккуратно и тестируйте на staging.
Сравнение подходов
| Способ | Где применять | Плюсы | Минусы |
|---|---|---|---|
Фильтр use_block_editor_for_post_type | Когда нужно отключить Gutenberg точечно | Гибко, безопасно, легко откатить | Нужно добавить код |
register_post_type() | Если тип записи создаёте сами | Настройка рядом с регистрацией | Не подходит для чужого кода и плагинов |
| Плагин для отключения редактора | Если нужен UI без правки кода | Быстро для контент-менеджера | Лишняя зависимость, не всегда удобно для точечной логики |
Если нужен не только этот сценарий, а ещё чистка лишних элементов редактора, дублей и технических хвостов, иногда удобнее держать это в одном инструменте вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpstart.ru&utm_medium=article&utm_campaign=otklyuchit-gutenberg-dlya-opredelennyh-tipov-zapisej-v-wordpress
Как проверить, что всё сработало
После внедрения не ограничивайтесь визуальной проверкой. Пройдитесь по короткому чек-листу:
- откройте нужный тип записи в админке и убедитесь, что загружается классический редактор;
- проверьте, что метабоксы отображаются и сохраняются;
- создайте тестовую запись и сохраните её без ошибок;
- убедитесь, что другие типы записей по-прежнему открываются в Gutenberg;
- посмотрите консоль браузера на наличие JS-ошибок в редакторе;
- если используется кэш админки или плагин оптимизации, очистите его и повторите проверку.
Хороший тест — открыть запись, заполнить несколько полей, сохранить, выйти и снова открыть её. Если значения не пропали и интерфейс не «прыгает», настройка отработала корректно.
Частые ошибки и как их исправить
Отключили Gutenberg глобально, хотя нужен только для одного типа
Такое часто делают через слишком общий фильтр или плагин с глобальной настройкой. Исправление простое: ограничьте список post type и проверьте, что в коде нет условий, которые возвращают false для всех типов записей.
Сломались метабоксы после отключения редактора
Причина обычно не в самом отключении, а в том, что метабоксы завязаны на REST, React-компоненты или блоковую разметку. В этом случае нужно проверить, не использует ли плагин поля, рассчитанные именно на Gutenberg. Иногда помогает обновление плагина, иногда — возврат к классическому редактору только для проблемного типа.
Редактор остался блочным, хотя фильтр добавлен
Проверьте приоритеты фильтров и место, где лежит код. Если код в теме, а активна не та тема, настройка не сработает. Если код в плагине, убедитесь, что он реально загружается на сайте, а не только в админке.
После обновления всё вернулось обратно
Это типичная история для правок в родительской теме. Решение — вынести код в дочернюю тему или mu-plugin. Для точечных административных настроек это надёжнее, чем править файлы темы напрямую.
Что учесть по безопасности и производительности
Само отключение Gutenberg почти не влияет на фронтенд, но влияет на поддержку сайта в долгую. Если вы оставляете классический редактор для части контента, зафиксируйте это в документации проекта: какие post type редактируются как раньше, какие — в блоках, и почему. Это экономит время при следующем обновлении темы или плагинов.
Ещё один практический момент: не складывайте такие правки в functions.php активной темы, если тема часто меняется. Для административной логики лучше использовать маленький mu-plugin или отдельный плагин проекта. Так вы не потеряете настройку при смене дизайна.
Если задача шире и нужно не только отключить редактор, но и убрать лишние элементы интерфейса, скрыть технические блоки и почистить админку, имеет смысл смотреть на комплексные инструменты. Но для одного-двух типов записей код обычно надёжнее и прозрачнее.