Как отключить Gutenberg для отдельных типов записей в WordPress без поломки редактора

Иногда проблема не в самом Gutenberg, а в том, что он нужен только для части сайта. Например, редакция работает с обычными записями в блоках, а для страниц, новостей или кастомного типа контента нужен старый классический интерфейс: метабоксы, ACF-поля, привычная верстка шаблонов. В таком случае отключать Gutenberg глобально — лишняя мера. Гораздо безопаснее убрать его точечно.

Ниже разберем рабочие варианты: через код, через плагин и через проверку совместимости темы и метабоксов. Это полезно, если после обновления WordPress редактор начал ломать старые шаблоны, поля съехали или контент-менеджеры жалуются на лишние клики.

Когда Gutenberg лучше отключать не полностью

Точечное отключение имеет смысл, если у вас один из таких сценариев:

• для page нужен классический редактор, а для post — блоки;
• кастомный тип записи использует сложные метабоксы и не дружит с блочной панелью;
• в теме есть старые шаблоны, которые завязаны на метаполя и не рассчитаны на блоковый контент;
• редакторам нужен привычный интерфейс только в административной части, без смены фронтенда.

Если же проблема в производительности или лишних скриптах на фронтенде, отключение Gutenberg не поможет: это уже другая задача. Здесь речь именно про редактор и его поведение в админке.

Диагностика: что именно ломается

Перед правкой кода стоит понять, где именно возникает конфликт. Это экономит время и помогает не отключить лишнее.

Проверьте тип записи

Откройте экран редактирования нужного контента и посмотрите, к какому post type он относится. Важно не путать обычные записи, страницы и кастомные типы. Для каждого типа можно задать отдельное поведение.

Проверьте, есть ли метабоксы и ACF-поля

Если на экране редактирования много метабоксов, Gutenberg может сдвигать их вниз или прятать за дополнительными вкладками. Это не всегда ошибка, но для редакторов часто выглядит как поломка. Если поля критичны для работы, классический редактор может быть удобнее.

Смотрите на поддержку темы и плагинов

Некоторые темы и плагины ожидают, что редактор будет классическим. Если в коде темы есть старые вызовы вроде the_content() без учета блоков, это не проблема само по себе. Но если шаблоны завязаны на метаполя и ручную разметку, блоковый редактор может мешать рабочему процессу.

Пошаговое решение через код

Самый надежный способ — отключить Gutenberg только для нужных типов записей через фильтр use_block_editor_for_post_type. Это штатный хук WordPress, он работает без сторонних плагинов.

<?php
add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
	$disabled_post_types = array( 'page', 'portfolio' );

	if ( in_array( $post_type, $disabled_post_types, true ) ) {
		return false;
	}

	return $use_block_editor;
}, 10, 2 );

В этом примере Gutenberg отключается для страниц и для кастомного типа portfolio. Для обычных записей редактор останется включенным.

Как добавить код безопасно

Лучше не вставлять такой код в случайный файл темы, который может перезаписаться при обновлении. Есть два нормальных варианта:

• дочерняя тема, если у вас уже есть стабильная тема;
• свой небольшой плагин для функционального кода.

Если код нужен только для одного сайта, я бы выбрал мини-плагин. Так проще отключать и переносить настройку между проектами.

<?php
/**
 * Plugin Name: Disable Gutenberg for selected post types
 */

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
	$disabled_post_types = array( 'page', 'portfolio' );

	return in_array( $post_type, $disabled_post_types, true ) ? false : $use_block_editor;
}, 10, 2 );

Если нужен плагин вместо кода

Если доступ к коду ограничен, можно использовать плагин, который умеет отключать блоковый редактор выборочно. Это удобнее для контент-менеджеров, но добавляет зависимость от стороннего решения. Для небольших сайтов это допустимо, для проектов с долгим жизненным циклом код обычно надежнее.

Если вам нужен не только контроль редактора, но и чистка лишнего в админке, иногда удобнее посмотреть в сторону комплексных решений вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и тут важно проверять, что именно отключается, а не включать все подряд.

Проверка результата после внедрения

После изменения кода не ограничивайтесь визуальной проверкой одного экрана. Нужно пройтись по нескольким сценариям.

• Откройте редактирование каждого нужного типа записи.
• Убедитесь, что вместо блокового редактора загружается классический интерфейс.
• Проверьте сохранение метаполей и произвольных полей.
• Откройте запись в предпросмотре и на фронтенде — контент должен отображаться как раньше.
• Если используется ACF, проверьте, что поля не пропали и не дублируются.

Если Gutenberg отключен только для части типов записей, остальные экраны должны остаться без изменений. Это хороший признак, что фильтр сработал именно точечно.

Частые ошибки и как их исправить

Отключили редактор глобально, хотя нужен был только для одного типа

Такое часто происходит, когда используют слишком общий фильтр или плагин с грубой настройкой. Решение простое: ограничьте список post type и проверьте, что в массиве нет лишних значений.

Код добавили в файл темы, а потом потеряли после обновления

Если код лежал в родительской теме, обновление могло его перезаписать. Перенесите настройку в дочернюю тему или мини-плагин.

Редактор отключился, но метабоксы стали отображаться странно

Это уже не проблема Gutenberg как такового, а конфликт верстки админки, метабоксов или стороннего плагина. Проверьте, нет ли у темы или плагина своих стилей для .edit-post-layout и похожих классов. Иногда конфликт вызывает именно старый CSS в админке.

Кастомный тип записи не попал под фильтр

Проверьте slug post type. В коде нужно использовать именно внутреннее имя типа записи, а не его ярлык в интерфейсе.

Что проверить на стороне темы и плагинов

Если вы работаете с темой, где много шаблонов и кастомных полей, полезно заранее проверить несколько вещей:

• поддерживает ли тема нужные типы записей в register_post_type();
• не завязан ли шаблон на блоки в контенте;
• не конфликтуют ли метабоксы с редактором сайдбара;
• не добавляет ли плагин свои стили и скрипты только для блокового редактора.

Если сайт строится на старой логике контента, иногда разумнее выбрать тему, где работа с классическим редактором не вызывает лишних переделок. Из практики это особенно важно для проектов с большим количеством шаблонов и редакторских полей, где стабильность важнее модного интерфейса. Для таких сценариев стоит смотреть и на тему, и на набор плагинов одновременно, а не только на сам WordPress-редактор.

Когда лучше не отключать Gutenberg

Если команда уже работает в блоках, а проблема только в одном метабоксе, лучше сначала попробовать адаптировать его под Gutenberg. Полное отключение редактора — это откат в удобстве, и он оправдан только тогда, когда экономит время и снижает число ошибок у редакторов. Если сайт активно развивается, а контент собирается из блоков, точечное отключение может создать больше ручной работы в будущем.

Практический ориентир простой: если тип записи живет на метаполях и старых шаблонах, отключайте Gutenberg точечно. Если контент уже блоковый, лучше чинить конкретный конфликт, а не возвращать весь сайт к классическому редактору.