В Gutenberg часто накапливается лишнее: блоки, которые редакторы не должны использовать, дублирующие возможности темы или просто тяжелые элементы, которые мешают поддерживать единый стиль контента. Самый безопасный сценарий — не отключать редактор целиком, а скрыть только конкретные блоки и проверить, что это не ломает уже созданные записи.
Ниже — рабочие варианты для WordPress: через PHP-фильтр, через ограничения по ролям и через плагин, если нужен более быстрый путь без правки темы.
Когда это действительно нужно
Отключение отдельных блоков полезно не ради «чистоты», а когда есть понятная причина:
- авторы вставляют блоки, которые не соответствуют дизайн-системе;
- на сайте есть собственные блоки темы или плагина, и стандартные блоки только мешают;
- нужно убрать опасные элементы для редакторов без прав администратора;
- в редакторе слишком много вариантов, и команда регулярно выбирает не тот блок;
- нужно сократить список доступных блоков на клиентском сайте, где контент ведут не разработчики.
Диагностика перед изменениями
Сначала проверьте, какие блоки реально используются в контенте. Если вы отключите блок, который уже стоит в старых записях, сами записи обычно не сломаются, но редактирование может стать неудобным: блок перейдет в режим «неизвестного» или будет отображаться как устаревший.
Что посмотреть в админке
- Какие блоки чаще всего вставляют редакторы.
- Есть ли в старых записях блоки из плагинов, которые вы планируете убрать.
- Используются ли повторно блоки, которые можно заменить шаблоном или паттерном.
- Есть ли роли, которым блоки точно не нужны: автор, редактор, контент-менеджер.
Если сомневаетесь, сначала ограничьте блоки только для части ролей, а не для всех пользователей.
Способ 1: отключить блоки через PHP-фильтр
Для большинства задач достаточно фильтра allowed_block_types_all. Он позволяет задать список разрешенных блоков или вернуть false для полного запрета, но в реальной работе удобнее именно белый список.
Добавьте код в functions.php дочерней темы или в собственный мини-плагин:
<?php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
if ( ! empty( $editor_context->post ) ) {
$post_type = get_post_type( $editor_context->post );
if ( 'post' === $post_type ) {
return array(
'core/paragraph',
'core/heading',
'core/list',
'core/image',
'core/gallery',
'core/quote',
'core/columns',
'core/button',
'core/separator',
);
}
}
return $allowed_blocks;
}, 10, 2 );Этот вариант оставляет только базовые блоки для записей. Для страниц или кастомных типов записей можно вернуть другой набор.
Как ограничить блоки только для одной роли
Если задача не в типе контента, а в правах, проверяйте пользователя через current_user_can(). Например, можно скрыть сложные блоки для авторов, но оставить их администраторам:
<?php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
if ( current_user_can( 'manage_options' ) ) {
return $allowed_blocks;
}
return array(
'core/paragraph',
'core/heading',
'core/list',
'core/image',
'core/button',
);
}, 10, 2 );Такой подход удобен, если редакторы должны работать в упрощенном интерфейсе, а разработчики — со всем набором блоков.
Способ 2: убрать блоки из панели через JavaScript
Иногда нужно не просто ограничить вставку, а убрать блоки из интерфейса выбора. Для этого используют фильтр blocks.registerBlockType или редакторские скрипты, но это уже более хрупкий путь: он зависит от загрузки скриптов и может ломаться при обновлениях.
Если задача простая, PHP-фильтра обычно достаточно. JS имеет смысл, когда вы работаете с собственным интерфейсом редактора или хотите точечно скрыть блоки в зависимости от контекста, который удобнее получить на клиенте.
Способ 3: использовать плагин для управления блоками
Если не хочется писать код, можно взять плагин для управления блоками. На практике это удобно для небольших сайтов, где разработчик не хочет поддерживать отдельный сниппет. Но у плагина есть минус: лишняя зависимость в админке и еще один слой настроек, который нужно документировать для команды.
| Подход | Плюсы | Минусы |
|---|---|---|
| PHP-фильтр | Прозрачно, быстро, без лишних зависимостей | Нужно править код и не забыть про обновления темы |
| JS-ограничение | Гибко для интерфейса редактора | Хрупче, сложнее поддерживать |
| Плагин | Быстро внедрить без разработки | Дополнительный плагин и зависимость от его настроек |
Пошаговое решение без лишнего риска
- Сделайте резервную копию или проверьте изменения на staging-копии.
- Определите список блоков, которые нужно оставить.
- Добавьте фильтр
allowed_block_types_allв дочернюю тему или мини-плагин. - Проверьте редактор под разными ролями.
- Откройте старые записи и убедитесь, что существующие блоки не стали «неизвестными».
- Если нужно, скорректируйте список разрешенных блоков для страниц, записей и кастомных типов.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте редактор и сделайте три вещи:
- попробуйте вставить блок, который вы отключили;
- откройте запись со старым содержимым и убедитесь, что блоки отображаются нормально;
- проверьте доступ под пользователем с другой ролью, если ограничение завязано на права.
Если блок исчез из списка, но старые записи перестали открываться корректно, значит вы отключили не тот тип блока или слишком агрессивно урезали список.
Частые ошибки и как их исправить
Отключили блок, который уже используется в контенте
Это самая частая проблема. Решение простое: сначала найдите записи с этим блоком, затем замените его на альтернативу или оставьте блок доступным хотя бы для редактирования старого контента.
Правили functions.php основной темы
После обновления темы изменения пропадут. Для таких задач лучше использовать дочернюю тему или отдельный мини-плагин.
Смешали ограничения по типу записи и по роли
Если в одном фильтре сразу проверять и пост-тип, и права, легко получить неожиданный результат. Разделяйте логику: сначала определяйте контекст, потом список блоков.
Скрыли блок через CSS, а не через разрешения
Это не решает проблему. Блок все равно может быть вставлен через копипасту, шаблон или API редактора. Если блок действительно запрещен, убирайте его на уровне разрешений.
Практика безопасности и поддержки
Если редакторами пользуются несколько человек, фиксируйте список разрешенных блоков в документации проекта. Это снижает риск, что кто-то случайно вернет лишний блок после обновления темы или плагина.
Для сайтов с жесткой редакционной политикой удобно хранить ограничения в небольшом собственном плагине. Так вы не привязываетесь к теме и не теряете настройки при смене дизайна.
Если нужен более широкий контроль над дублями, служебными блоками и чисткой интерфейса, можно посмотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для самой задачи отключения блоков кодовый фильтр обычно остается самым предсказуемым вариантом.
Главный критерий здесь простой: если блок не нужен редактору, убирайте его из доступных, но не ломайте уже опубликованный контент. Тогда редактор станет проще, а сопровождение — дешевле.