Когда на сайте уже есть рабочая редакционная схема, лишние блоки в Gutenberg начинают мешать быстрее, чем кажется. Кто-то случайно вставляет Verse, кто-то использует Cover вместо обычного изображения, а потом верстка плывёт, стили конфликтуют, и в контенте появляются элементы, которые вы не планировали поддерживать. В таких случаях разумнее не «обучать всех быть аккуратнее», а ограничить набор доступных блоков.
Ниже — рабочий сценарий: как отключить отдельные блоки в WordPress, где это делать безопаснее, как проверить, что ограничение реально сработало, и какие ошибки чаще всего ломают редактор.
Когда отключение блоков действительно нужно
Эта задача полезна не для «красоты админки», а для контроля контента. Обычно к ней приходят в четырёх ситуациях:
- редакторы используют слишком много разных блоков, и шаблоны страниц перестают быть единообразными;
- на сайте есть блоки, которые конфликтуют с темой или кастомными стилями;
- нужно убрать редкие блоки, чтобы не путать авторов;
- вы хотите сократить поверхность ошибок в редакторе и не давать вставлять элементы, которые потом сложно поддерживать.
Важно понимать: отключение блока в редакторе не всегда удаляет уже вставленный контент. Если блок уже есть в записи, он может остаться в старом материале, а новый контент просто перестанет его предлагать. Это нормальное поведение, и на него нужно рассчитывать заранее.
Диагностика: что именно нужно ограничить
Перед правкой кода проверьте, где блоки используются сейчас. Это помогает не отключить то, что уже активно в старых записях.
Что посмотреть в первую очередь
- какие блоки реально встречаются в опубликованных материалах;
- используются ли блоки в шаблонах сайта или только в ручных записях;
- есть ли у редакторов привычка вставлять блоки из сторонних плагинов;
- не завязаны ли на блоки какие-то внутренние инструкции или шаблоны.
Если у вас есть доступ к базе, можно быстро поискать названия блоков в содержимом записей. Для классического Gutenberg это обычно строки вида wp:paragraph, wp:image, wp:quote и так далее. Но не пытайтесь удалять блоки из базы массово без теста на копии сайта: это уже отдельная операция, и она нужна не всегда.
Способ 1. Отключить блоки через код темы или mu-plugin
Это самый предсказуемый вариант, если вам нужен контроль без лишних зависимостей. Подходит для сайта, где вы готовы поддерживать небольшой фрагмент кода.
WordPress даёт фильтр allowed_block_types_all. Через него можно задать список разрешённых блоков или убрать конкретные. Ниже пример, где мы оставляем только нужные базовые блоки и несколько часто используемых элементов.
<?php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
if ( ! empty( $editor_context->post ) ) {
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/list',
'core/quote',
'core/separator',
'core/buttons',
'core/button',
);
}
return $allowed_blocks;
}, 10, 2 );Если нужно не ограничивать всё подряд, а убрать только несколько блоков, удобнее собрать список запрещённых и отфильтровать доступные блоки динамически. Так проще сопровождать код, когда набор меняется.
<?php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
$blocked = array(
'core/verse',
'core/code',
'core/freeform',
'core/html',
'core/cover',
);
if ( is_array( $allowed_blocks ) ) {
return array_values( array_diff( $allowed_blocks, $blocked ) );
}
return $allowed_blocks;
}, 10, 2 );Код лучше класть не в functions.php активной темы, а в небольшой mu-plugin, если сайт живой и тема может меняться. Это снижает риск потерять настройку после обновления или смены шаблона.
Пример mu-plugin
<?php
/**
* Plugin Name: Block Restrictions
*/
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
$blocked = array( 'core/verse', 'core/html', 'core/freeform' );
if ( is_array( $allowed_blocks ) ) {
return array_values( array_diff( $allowed_blocks, $blocked ) );
}
return $allowed_blocks;
}, 10, 2 );Файл можно положить в wp-content/mu-plugins/block-restrictions.php. Если папки mu-plugins нет, её можно создать вручную.
Способ 2. Ограничить блоки через плагин
Если не хочется держать код в репозитории или на хостинге нет удобного деплоя, можно использовать плагин для управления блоками. Это практично для небольших проектов, где админка обслуживается не разработчиком, а контент-менеджером.
Из реальных вариантов обычно выбирают плагины, которые умеют отключать блоки, чистить интерфейс редактора и убирать лишние элементы. Например, Clearfy Pro подходит, если вам нужно не только отключение блоков, но и более широкая чистка сайта и редактора. Это не замена точечному коду, а удобный вариант, когда важна админская управляемость без правок в теме.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код через allowed_block_types_all | Точно, прозрачно, без лишних зависимостей | Нужно поддерживать фрагмент кода | Есть разработчик или доступ к репозиторию |
| mu-plugin | Не зависит от темы, легко переносится | Нужен доступ к файловой системе | Сайт уже живёт и должен быть стабильным |
| Плагин для управления блоками | Быстро включить, удобно для админов | Дополнительная зависимость | Нужна настройка без разработки |
Как проверить, что блоки реально отключились
Проверка нужна не только в редакторе. Иногда блок исчезает из панели, но остаётся доступным через вставку из старого шаблона, паттерна или стороннего плагина.
Минимальный чек-лист
- откройте новую запись и проверьте список блоков в inserter;
- попробуйте найти отключённый блок через поиск по блокам;
- проверьте редактирование уже существующей записи, где блок раньше использовался;
- посмотрите, не появился ли блок через паттерн или шаблон темы;
- очистите кэш, если на сайте стоит кэширование админки или объектов;
- проверьте работу под ролью редактора, а не только администратора.
Если блок всё ещё виден, причина часто не в фильтре, а в другом месте: плагин может добавлять свой набор блоков, тема может регистрировать шаблоны, а кэш браузера или плагина — показывать старый интерфейс.
Частые ошибки и как их исправить
Ошибка 1. Код добавили в тему, а потом сменили шаблон
Такой способ работает до первой смены темы. После этого ограничение исчезает, и редактор снова показывает лишние блоки. Если настройка важна для сайта, переносите её в mu-plugin или отдельный мини-плагин.
Ошибка 2. Слишком жёсткий список разрешённых блоков
Когда вы оставляете только пару базовых блоков, редакторы могут потерять нужные элементы для нормальной работы. Особенно это заметно, если на сайте уже используются кнопки, галереи, таблицы или блоки плагинов. Перед ограничением проверьте реальные сценарии публикации.
Ошибка 3. Убрали блок, который уже есть в старых записях
Старый контент может открываться с предупреждением о недоступном блоке или с упрощённым отображением. Это не всегда критично, но такие записи нужно просмотреть вручную. Если блок важен для архива, не удаляйте его без миграции контента.
Ошибка 4. Не проверили права пользователей
У разных ролей может быть разный набор доступных функций. Иногда проблема проявляется только у редакторов или авторов, а администратор видит всё и считает, что настройка не сработала. Тестируйте под той ролью, для которой вы и вводили ограничение.
Что делать, если нужно убрать блок только для части сайта
Иногда ограничение нужно не глобально, а только для определённого типа записей. Например, на страницах блока можно оставить больше свободы, а в новостях — только базовые элементы. Для этого в фильтре можно проверить тип записи и вернуть разные наборы блоков.
<?php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
$post_type = '';
if ( ! empty( $editor_context->post ) ) {
$post_type = $editor_context->post->post_type;
}
if ( 'post' === $post_type ) {
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/list',
);
}
if ( 'page' === $post_type ) {
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/list',
'core/buttons',
'core/button',
'core/columns',
);
}
return $allowed_blocks;
}, 10, 2 );Такой подход удобнее, чем один общий список на весь сайт. Он позволяет не ломать редактор там, где блоки действительно нужны, и одновременно держать под контролем проблемные разделы.
Практические советы по безопасности и производительности
Отключение блоков само по себе не нагружает сайт, но плохая реализация может создать лишние проблемы. Не встраивайте логику в случайные места и не размножайте одинаковые фильтры в нескольких файлах. Один источник правды проще проверять и сопровождать.
- держите ограничения в одном mu-plugin или отдельном плагине;
- не редактируйте ядро и не правьте файлы плагинов вручную;
- перед выкладкой на прод тестируйте на копии сайта;
- если используете кэширование, очищайте кэш после изменения списка блоков;
- не отключайте блоки, которые используются в шаблонах темы или в паттернах, если не готовы мигрировать контент.
Если задача шире, чем просто скрыть блоки, иногда выгоднее взять инструмент, который закрывает сразу несколько технических проблем редактора и разметки. В таких случаях можно посмотреть на Clearfy Pro, но только если вам действительно нужны дополнительные функции чистки и оптимизации, а не одна точечная правка.
Проверка результата после внедрения
После изменения кода откройте несколько сценариев:
- новая запись;
- редактирование старой записи;
- страница с другим типом контента;
- пользовательская роль без прав администратора.
Если нужный блок исчез из inserter, не появляется через поиск и не ломает старые записи, настройка работает. Если блок всё ещё доступен, проверьте, не подключает ли его сторонний плагин, и не остался ли старый кэш интерфейса.
Для контроля удобно вести короткий список: какой блок убрали, где именно, под какой ролью проверяли и что увидели в редакторе. Это экономит время, когда через месяц кто-то спросит, почему в админке пропал конкретный элемент.