Содержание статьи
Отключите автоматическое сохранение конфигурации редактора через REST. Оно ломает нестандартные кастомизации. Добавьте фильтр:
add_filter(\'block_editor_settings_all\', \'__return_empty_array\');
Это исключит лишние параметры, мешающие работе сторонних расширений. Никаких конфликтов, если всё настроено вручную.
Используйте custom post type templates вместо жёсткой фиксации структуры через UI. Файл template-parts/ + register_block_pattern() – и вы контролируете разметку без лишней нагрузки на ядро.
Не надейтесь на UI-панели. Они не отслеживают пересекающиеся зависимости скриптов. Один конфликт – и всё рушится. Пример: включение wp_enqueue_script(\'wp-edit-post\') без предварительной регистрации зависимостей вызовет TypeError.
Важно: при использовании
wp_register_script()обязательно указывайте зависимости явно. Не надейтесь, что ядро всё сделает за вас.
Для точечной деактивации предустановленных компонентов используйте remove_theme_support(\'core-block-patterns\'). Это мгновенно отключает мусор из ядра, мешающий кастомной логике.
Хотите отключить панель конфигурации блоков? Пример:
add_filter(\'use_block_editor_for_post_type\', function($use, $type) {
if ($type === \'page\') return false;
return $use;
}, 10, 2);
Проверка перед каждым запросом. Гибко. Управляемо.
Убрать ненужные JSON-шаблоны можно так:
unregister_block_pattern(\'core/quote\');
Повторите для каждого системного элемента. Да, вручную. Автоматизации нет – ядро этого не позволяет.
Помните: любые необработанные JSON-структуры, загружаемые в редактор, могут вызвать непредсказуемые ошибки при обновлениях.
Не используйте theme.json для настройки поведения – он переопределяет всё и ломает кастомные скрипты. Лучше изолировать всё через functions.php или отдельные модули.
Файлы шаблонов и структура директорий обязаны соответствовать WP-контракту. Нарушите – получите WSOD при первом редактировании. Особенно важно для блоков внутри templates/.
Контроль структуры – не опция, а необходимость. Один лишний элемент, и интерфейс не загрузится. Будьте параноиком – проверяйте всё. Даже то, что, как кажется, \»работает\».
Как отключать ненужные блоки Gutenberg через functions.php без плагинов
Подключите хук allowed_block_types_all – и начинайте резать лишнее. Этот фильтр даёт полный контроль над тем, что видно в редакторе. Подходит для чистки под индивидуальные нужды, кастомные шаблоны, темы с жёсткой структурой.
add_filter(\'allowed_block_types_all\', function( $allowed_blocks, $editor_context ) {
if ( ! empty( $editor_context->post ) ) {
return [
\'core/paragraph\',
\'core/heading\',
\'core/image\',
// добавляйте нужное
];
}
return $allowed_blocks;
}, 10, 2);
Минимум блоков – меньше ошибок от контента. Контроль – это безопасность. Особенно на проектах с несколькими пользователями, где каждый может сломать макет одним заголовком третьего уровня в неподходящем месте.
Не хотите ручной список? Удалите только определённые элементы. Хук тот же:
add_filter(\'allowed_block_types_all\', function( $allowed_blocks ) {
return array_filter( $allowed_blocks, function( $block ) {
return ! in_array( $block, [
\'core/verse\',
\'core/quote\',
\'core/preformatted\',
] );
} );
} );
Удалили цитаты – меньше хаоса. Нет ненужных кнопок – нет соблазна их использовать.
Внимание! Убедитесь, что не режете кастомные блоки, если они нужны на фронтенде. Ошибка здесь может привести к пустому макету и панике.
Есть нюанс: фильтр не работает в классическом редакторе. Только в редакторе нового типа. В условиях многошаблонной структуры можно проверять $editor_context->post->post_type и отключать выборочно, по типу контента.
if ( $editor_context->post->post_type === \'page\' ) {
return [ \'core/paragraph\', \'core/image\' ];
}
Зачем отдавать редактор на волю случая, если можно держать всё под контролем? Удаляйте всё, что не соответствует задачам. Оставьте только то, что действительно нужно. В остальном – чистый список, никаких соблазнов.
Важно помнить: любые изменения через functions.php мгновенно отражаются на всех пользователях. Без теста – не коммить.
Проверяйте результат после каждой правки. Блоков меньше – риск меньше. А значит, контент стабильнее.
Настройка пользовательских ролей для ограничения доступа к определённым блокам
Ограничивайте отображение по ролям через фильтр allowed_block_types_all. Это ключ. Фильтр возвращает список доступных элементов для конкретного пользователя. Не применяйте его глобально – передавайте $editor_context, в котором доступна роль текущего юзера.
Пример:
add_filter(\'allowed_block_types_all\', function($allowed_blocks, $editor_context) {
if (!empty($editor_context->post) && current_user_can(\'editor\')) {
return [
\'core/paragraph\',
\'core/image\'
];
}
return $allowed_blocks;
}, 10, 2);
Работает только при редактировании записей. Для виджетов и шаблонов – другая логика. Не обобщайте.
Важно помнить: если плагин добавляет собственные блоки, они тоже будут скрыты – даже если используются в старом контенте. Контент может «сломаться» визуально. Проверяйте до релиза.
Создайте кастомную роль, если стандартных прав недостаточно. Используйте add_role(), но не забудьте про capability edit_posts – без неё интерфейс редактора не откроется вообще.
Пример создания роли:
add_role(\'limited_editor\', \'Ограниченный редактор\', [
\'read\' => true,
\'edit_posts\' => true,
\'upload_files\' => false
]);
Хаос начинается, когда роли меняются динамически. Не добавляйте права на лету в хук init, если не знаете, зачем. Это не временное решение – это минное поле.
Внимание! Никогда не скрывайте элементы только через CSS или JavaScript. Это не ограничение, это иллюзия.
Проверку наличия блока можно провести при сохранении. Хук save_post и парсинг post_content через parse_blocks(). Ищите, что не должно быть – удаляйте или логируйте. Но не надейтесь на фильтрацию как на панацею – лучше не допускать, чем исправлять.
Функция current_user_can() возвращает true/false, но не забудьте, что роли можно комбинировать. Один пользователь – несколько капабилити. Ошибки на этом уровне приводят к нежеланным последствиям. Жёстко логируйте.
Контроль отображения на фронтенде – другая история. Если элемент спрятан в админке, это не значит, что он не отрендерится на сайте. Удаляйте его в render_block, если роль не совпадает.
Пример:
add_filter(\'render_block\', function($block_content, $block) {
if ($block[\'blockName\'] === \'core/image\' && !current_user_can(\'administrator\')) {
return \'\';
}
return $block_content;
}, 10, 2);
Способы предотвращения критических ошибок при регистрации кастомных блоков
Регистрируй блоки только после полной инициализации ядра. Используй хук init или enqueue_block_editor_assets. Преждевременный вызов register_block_type() приводит к фатальной ошибке. Ни раньше, ни позже.
add_action( \'init\', function() {
register_block_type( __DIR__ . \'/my-block/block.json\' );
});Не доверяй файлу block.json вслепую. Если указанный путь недоступен или структура некорректна – загрузка сорвется. Проверяй существование файла перед регистрацией:
if ( file_exists( __DIR__ . \'/my-block/block.json\' ) ) {
register_block_type( __DIR__ . \'/my-block/block.json\' );
}Всегда указывай корректный namespace. Пробелы, спецсимволы, кириллица – нет, нет и еще раз нет. Формат должен быть plugin-name/block-name.
Важно: Несовпадение между
nameв block.json и реальным namespace приведёт к неработоспособности на фронте и в редакторе!
Изолируй регистрацию от основной логики плагина или темы. Простейший способ – использовать отдельный класс или файл, загружаемый строго при наличии всех зависимостей:
// includes/blocks/register.php
if ( function_exists( \'register_block_type\' ) ) {
register_block_type( __DIR__ . \'/block.json\' );
}Следи за версиями скриптов и стилей. Несогласованность между версией в block.json и реально зарегистрированным ассетом вызовет сбои. Ядро не выдаст ошибку – просто блок исчезнет. Ты даже не заметишь.
{
\"editorScript\": \"file:./editor.js\",
\"editorStyle\": \"file:./editor.css\",
\"style\": \"file:./style.css\"
}Загрузи скрипты явно, если WordPress не может найти их автоматически.
wp_register_script( \'my-block-editor\', plugins_url( \'editor.js\', __FILE__ ), [ \'wp-blocks\', \'wp-element\' ] );
wp_register_style( \'my-block-style\', plugins_url( \'style.css\', __FILE__ ) );
register_block_type( \'plugin/block\', [
\'editor_script\' => \'my-block-editor\',
\'style\' => \'my-block-style\',
] );Помните: Ошибки регистрации редко видны в админке. Но они убивают рендеринг блоков молча. В консоли – тишина. В редакторе – пустота.
Отключай автозагрузку block.json, если используешь ручную регистрацию. Дублирование данных вызовет конфликт. Используй параметр render_callback вместо save, если нужен PHP-рендеринг:
register_block_type( \'plugin/block\', [
\'render_callback\' => \'render_my_block\',
] );Тестируй регистрацию на чистой установке без кэшей. Браузер может подгрузить старый ассет. Используй версионирование вручную:
wp_register_script( \'my-block-editor\', plugins_url( \'editor.js\', __FILE__ ), [], filemtime( __DIR__ . \'/editor.js\' ) );Работает – не трогай. Не работает – отключай всё и проверяй по одному.