Когда в редакторе Gutenberg слишком много лишних блоков, это обычно не вопрос «удобства», а вопрос контроля. На сайте появляются блоки, которые редакторы случайно вставляют в контент, а потом приходится чистить разметку, править стили и разбираться, почему в шаблоне внезапно появился нестандартный HTML. В WordPress это решается точечно: можно скрыть только те блоки, которые реально не нужны вашей редакции.
Ниже — рабочие варианты для темы, плагина или дочерней темы: через фильтр allowed_block_types_all, через редакторский плагин и через проверку результата после внедрения. Сразу оговорюсь: речь не о полном отключении Gutenberg, а именно о сокращении набора доступных блоков.
Когда это действительно нужно
Чаще всего проблема проявляется в трёх сценариях. Первый — сайт ведут несколько авторов, и часть из них вставляет блоки, которые ломают единый стиль: колонки, нестандартные кнопки, обложки, медиа-группы. Второй — у проекта есть строгий дизайн-системный набор блоков, и всё лишнее только мешает. Третий — на старом сайте после обновления WordPress в редакторе появились новые блоки, а команда не хочет, чтобы они использовались без согласования.
Если задача именно в этом, не стоит отключать Gutenberg целиком или ставить тяжёлые «анти-блоковые» плагины без необходимости. Обычно достаточно ограничить список доступных блоков на уровне кода или настроек.
Диагностика: что именно мешает
Перед изменениями проверьте, какие блоки реально используются на сайте. Это важно, потому что отключение блока не удаляет уже вставленный контент, но может создать проблемы при редактировании существующих записей. Если блок уже есть в статьях, его лучше не скрывать до анализа архива.
Что проверить в первую очередь
- Какие блоки используются в старых и новых записях.
- Есть ли кастомные блоки от темы или плагинов.
- Используют ли редакторы шаблонные блоки, которые вы хотите убрать.
- Нет ли блоков, завязанных на шорткоды или виджеты, которые потом сложно заменить.
Если у вас есть staging-копия, тестируйте изменения там. Это особенно важно, когда на сайте подключены плагины с собственными блоками: после фильтра они могут исчезнуть из панели, но остаться в старом контенте как «неизвестный блок».
Решение через код: ограничить список доступных блоков
Самый предсказуемый способ — использовать фильтр allowed_block_types_all. Он работает в современном WordPress и позволяет задать белый список блоков для редактора. Это лучше, чем пытаться отключать всё подряд через CSS или правки в админке.
Пример: оставим только базовые блоки и уберём всё лишнее. Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'allowed_block_types_all', function( $allowed_block_types, $editor_context ) {
if ( ! empty( $editor_context->post ) ) {
return array(
'core/paragraph',
'core/heading',
'core/list',
'core/image',
'core/gallery',
'core/quote',
'core/table',
'core/columns',
'core/button',
'core/separator',
'core/spacer',
'core/embed',
);
}
return $allowed_block_types;
}, 10, 2 );Если нужно убрать только несколько блоков, а не строить полный белый список, лучше сделать это через список исключений и вернуть все остальные. Но на практике белый список надёжнее: он не пропускает новые блоки, которые WordPress может добавить в будущем.
Как ограничить блоки только для определённого типа записей
Это полезно, если, например, в статьях нужен один набор блоков, а в страницах — другой. Ниже пример для записей типа post. Для страниц и других типов можно задать отдельные правила.
<?php
add_filter( 'allowed_block_types_all', function( $allowed_block_types, $editor_context ) {
if ( empty( $editor_context->post ) ) {
return $allowed_block_types;
}
if ( 'post' === $editor_context->post->post_type ) {
return array(
'core/paragraph',
'core/heading',
'core/list',
'core/image',
'core/quote',
'core/table',
'core/button',
);
}
if ( 'page' === $editor_context->post->post_type ) {
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/columns',
'core/button',
);
}
return $allowed_block_types;
}, 10, 2 );Такой подход удобен, когда редакционная политика отличается для разных разделов сайта. Например, в блоге можно оставить больше гибкости, а на посадочных страницах — только минимальный набор.
Решение через плагин: когда код трогать не хочется
Если на проекте нет разработчика под рукой или изменения должны вноситься через интерфейс, можно использовать плагин, который управляет доступностью блоков и чистит лишние элементы редактора. Важно только не путать это с плагинами, которые полностью заменяют редактор: вам нужен именно инструмент для контроля блоков, а не тяжёлая надстройка.
Для сайтов, где параллельно нужно чистить админку, отключать лишние функции и убирать дубли, часто используют Clearfy Pro. Но даже в этом случае я бы не полагался только на интерфейс: критичные ограничения лучше фиксировать кодом, чтобы они не зависели от настроек в админке.
| Подход | Плюсы | Минусы |
|---|---|---|
Код через allowed_block_types_all | Точно, прозрачно, не зависит от плагинов | Нужен доступ к теме или mu-plugin |
| Плагин для управления блоками | Быстро включить без разработки | Зависимость от стороннего кода и настроек |
| CSS/скрытие в интерфейсе | Просто сделать | Не решает проблему, блок остаётся доступным |
Проверка результата после внедрения
После изменения откройте редактор записи и убедитесь, что лишние блоки исчезли из панели вставки. Но этого недостаточно: нужно проверить ещё три вещи.
- Откройте старую запись, где уже использовался скрытый блок.
- Проверьте, не стал ли блок отображаться как «неизвестный» или «несовместимый».
- Сохраните запись и убедитесь, что контент не изменился в HTML-выводе.
Если блок был уже вставлен в контент, WordPress обычно не удаляет его автоматически. Он может остаться в разметке и продолжить отображаться на фронтенде. Проблемы начинаются тогда, когда редактор пытается отредактировать такой блок после его отключения. Поэтому сначала анализируйте архив, потом ограничивайте набор.
Как быстро проверить на фронтенде
Откройте страницу в браузере и сравните HTML до и после. Если блок был частью шаблона или паттерна, убедитесь, что стили не сломались. Особенно это касается колонок, кнопок и обложек: они часто тянут за собой дополнительные классы и отступы.
Частые ошибки и как их исправить
- Скрыли блок, который уже используется в старых записях. Сначала найдите все записи с этим блоком и замените его на альтернативу.
- Использовали CSS вместо фильтра. Блок остаётся доступным через поиск и вставку, проблема не решается.
- Сделали слишком жёсткий белый список. Редакторы теряют нужные блоки для обычной работы. Начинайте с минимального набора ограничений.
- Добавили код в родительскую тему. После обновления темы изменения могут пропасть. Для таких правок лучше использовать дочернюю тему или mu-plugin.
- Не учли блоки от плагинов. Если на сайте есть ACF Blocks, Kadence Blocks или аналогичные расширения, их тоже нужно отдельно проверить перед ограничением.
Практические советы по безопасности и производительности
Ограничение блоков само по себе не ускоряет сайт заметно, но помогает снизить риск редакторских ошибок и лишней разметки. Это косвенно полезно для производительности: меньше случайных тяжёлых блоков, меньше встроенных медиа и меньше мусора в контенте.
С точки зрения безопасности важно другое: не давайте редакторам доступ к блокам, которые позволяют вставлять произвольный HTML без необходимости. Если на проекте есть отдельные роли, проверьте их права и не смешивайте задачу управления блоками с отключением редакторских ограничений. Это разные уровни контроля.
Если нужен более широкий набор инструментов для технической чистки WordPress, имеет смысл смотреть на решения, которые закрывают сразу несколько задач: удаление дублей, отключение лишнего, настройку SEO-элементов и упрощение админки. Но даже в таком случае ограничения блоков лучше держать в коде, а не только в интерфейсе плагина.
Когда лучше не отключать блоки вообще
Если сайт активно живёт на паттернах, шаблонах и reusable blocks, жёсткое ограничение может создать больше проблем, чем пользы. В таком случае лучше не убирать блоки из редактора, а выстроить редакционную политику: какие блоки можно использовать, какие — только через шаблоны, а какие — только разработчикам.
То же самое относится к проектам, где контент часто мигрирует между сайтами. Если вы регулярно импортируете записи, слишком узкий список доступных блоков может мешать поддержке старого контента. В таких случаях сначала тестируйте на копии и фиксируйте правила для команды, а уже потом включайте ограничения на боевом сайте.