На сайтах с Elementor часто возникает не проблема «как удалить Gutenberg совсем», а более приземлённая задача: редакторы путаются между двумя интерфейсами, часть контента создаётся в блоках, часть — в Elementor, а в итоге появляются разные шаблоны записи, лишние метабоксы и ошибки в процессе редактирования. В таких проектах обычно нужен не тотальный отказ от редактора блоков, а точечное ограничение: для записей и страниц оставить классический редактор, а Gutenberg не показывать там, где он не нужен.
Ниже — рабочая схема для WordPress с Elementor: как диагностировать конфликт, как отключить Gutenberg для нужных типов записей и ролей, как проверить результат и где чаще всего ломают админку.
Когда Gutenberg действительно мешает в Elementor
Сценарий обычно выглядит одинаково. На сайте уже есть страницы, собранные в Elementor, но редакторы продолжают открывать обычный редактор WordPress. В одном месте используется «Редактировать в Elementor», в другом — стандартный экран записи. Если при этом включены блоки, часть пользователей начинает случайно создавать контент не в том интерфейсе. Это особенно заметно на сайтах с несколькими авторами, где важна предсказуемость процесса.
Отключать Gutenberg имеет смысл, если:
- основной контент страниц собирается в Elementor;
- редакторы не должны видеть два разных способа редактирования одной и той же сущности;
- нужно убрать лишние панели и метабоксы в админке;
- для отдельных ролей нужно оставить только классический редактор;
- есть конфликт с плагинами, которые ожидают старый экран редактирования.
Если же вы активно используете блоки в записях, отключать Gutenberg глобально не стоит. В этом случае лучше ограничить его только для страниц, шаблонов или конкретных ролей.
Диагностика: что именно нужно отключить
Перед правкой кода проверьте, где именно возникает проблема. Это важно, потому что в WordPress есть несколько разных уровней, на которых можно вмешаться: редактор блоков, метабоксы, поддержку конкретного типа записи и доступ к интерфейсу по ролям.
Проверьте типы записей
Откройте экран редактирования страницы и записи. Если Gutenberg нужен только для постов, а страницы должны редактироваться в Elementor, задача уже понятна: отключаем блоковый редактор только для page. Если Elementor используется и для записей, тогда список типов будет шире.
Проверьте, не мешает ли шаблон темы
Иногда проблема не в Gutenberg как таковом, а в том, что тема или дочерняя тема добавляет свои метабоксы, которые конфликтуют с Elementor. В таком случае отключение редактора блоков лишь убирает часть шума, но не решает всё. Сначала стоит посмотреть, исчезает ли лишняя панель после отключения Gutenberg только для нужного типа записи.
Проверьте роли пользователей
Если редакторы должны работать только в Elementor, а администраторы — видеть оба режима, лучше ограничить отключение по ролям. Это безопаснее, чем рубить редактор целиком для всех.
Решение: отключаем Gutenberg точечно через код
Самый надёжный способ — использовать фильтр use_block_editor_for_post_type. Он позволяет отключить редактор блоков для конкретного типа записи без установки лишнего плагина.
Добавьте код в functions.php дочерней темы или в собственный мини-плагин:
<?php
add_filter( 'use_block_editor_for_post_type', 'wpelementor_disable_gutenberg_for_selected_types', 10, 2 );
function wpelementor_disable_gutenberg_for_selected_types( $use_block_editor, $post_type ) {
$disabled_post_types = array( 'page' );
if ( in_array( $post_type, $disabled_post_types, true ) ) {
return false;
}
return $use_block_editor;
}Этот вариант отключит Gutenberg только для страниц. Если нужно добавить записи или другой тип, расширьте массив $disabled_post_types.
Отключение только для отдельных ролей
Если редактор блоков должен остаться у администраторов, но исчезнуть у редакторов или авторов, можно добавить проверку роли. В WordPress роли хранятся в объекте пользователя, поэтому логика получается простой и прозрачной.
<?php
add_filter( 'use_block_editor_for_post_type', 'wpelementor_disable_gutenberg_for_roles', 10, 2 );
function wpelementor_disable_gutenberg_for_roles( $use_block_editor, $post_type ) {
if ( 'page' !== $post_type ) {
return $use_block_editor;
}
$user = wp_get_current_user();
if ( in_array( 'editor', (array) $user->roles, true ) || in_array( 'author', (array) $user->roles, true ) ) {
return false;
}
return $use_block_editor;
}Этот код лучше использовать только если у вас действительно есть понятная матрица ролей. Иначе проще отключить Gutenberg для типа записи целиком.
Альтернатива: плагин вместо кода
Если не хочется держать кастомный код в теме, можно использовать плагин, который отключает блоковый редактор для нужных сущностей. Но здесь есть компромисс: лишний плагин ради одной настройки увеличивает поверхность поддержки. Для небольших проектов код обычно проще и надёжнее.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код через фильтр | Без лишних зависимостей, точечный контроль | Нужно аккуратно хранить в дочерней теме или MU-плагине |
| Плагин для отключения редактора | Быстро включить без разработки | Дополнительный плагин, иногда слишком широкий набор настроек |
| Полное отключение Gutenberg | Максимально просто для редакторов | Теряете блоки там, где они могут быть полезны |
Если у вас уже используется набор инструментов для чистки WordPress, иногда удобнее держать это в одном месте. Например, в Clearfy Pro есть функции для удаления лишнего и упрощения админки, но сам принцип всё равно тот же: не отключать больше, чем нужно.
Как проверить, что всё сработало
После внедрения кода проверьте не только визуально, но и по факту загрузки редактора.
- Откройте страницу, для которой Gutenberg должен быть отключён.
- Убедитесь, что вместо блокового редактора открывается классический экран WordPress.
- Проверьте кнопку
Редактировать в Elementorи убедитесь, что она работает как раньше. - Откройте запись того типа, который не должен был измениться, и проверьте, что Gutenberg там остался.
- Зайдите под пользователем с другой ролью и повторите тест.
Если используется кэш админки или объектный кэш, иногда нужно выйти из аккаунта и войти снова, чтобы увидеть актуальное состояние интерфейса.
Частые ошибки и как их исправить
Код добавили в родительскую тему
Если правка внесена в functions.php родительской темы, она может исчезнуть после обновления. Для такого кода лучше использовать дочернюю тему или отдельный mu-plugin.
Отключили Gutenberg глобально, хотя он нужен для записей
Это частая ошибка на контентных сайтах. В результате редакторы теряют удобный интерфейс для постов, а вы получаете лишние обращения в поддержку. Сначала определите список типов записей, потом отключайте.
Сломали кастомный тип записи
Некоторые CPT в Elementor-сайтах уже настроены под блоковый редактор или под свои метабоксы. Если после отключения редактора пропали нужные поля, проверьте поддержку типа записи и не убирайте Gutenberg там, где он реально используется.
Проверяли только под администратором
У администратора и редактора могут быть разные права и разный набор доступных экранов. Если ограничение завязано на роль, тестировать нужно минимум под двумя пользователями.
Безопасность и поддержка: как не создать себе лишнюю проблему
Если вы вносите такой код на рабочем сайте, не редактируйте его напрямую в активной теме без резервной копии. Лучше сначала проверить на staging-окружении. Для небольших правок безопаснее держать код в отдельном мини-плагине: так он не исчезнет при смене темы и не смешается с версткой.
Ещё один практический момент: если на сайте есть несколько разработчиков, зафиксируйте правило, какие типы записей редактируются в Elementor, а какие — в блоках. Иначе через месяц вы снова получите смешанный контент и хаос в админке.
Когда лучше не отключать Gutenberg
Если команда уже пишет контент в блоках, а Elementor используется только для лендингов и отдельных шаблонов, отключение редактора блоков создаст больше проблем, чем решит. В таком случае лучше ограничить использование Elementor организационно: через инструкции, права доступа или шаблоны страниц, а не через полное отключение.
Для сайтов, где нужен более жёсткий контроль интерфейса редактора, иногда удобнее комбинировать Elementor с точечной чисткой админки и ограничением метабоксов. Но сам принцип остаётся прежним: сначала выясняем, что именно мешает, потом отключаем только это.