Meta Box Show Hide - WordPress Plugin

Руководство по настройке Meta Box Show Hide для условных meta boxes в WordPress

Meta Box Show Hide нужен там, где редактору WordPress не должны мешать лишние блоки полей. В этом руководстве разберём не общую рекламу расширения, а рабочую схему: что проверить до установки, как подключить условия show и hide, как выбрать между шаблоном, форматом записи, рубрикой, таксономией, родительской страницей и значением поля, а затем как убедиться, что meta box появляется только в нужном контексте.

Расширение особенно полезно разработчикам, которые уже используют Meta Box для собственных полей и хотят сделать экран редактирования чище. Если у записи есть десятки настроек, но часть из них относится только к шаблону страницы, рубрике, формату записи или выбранному переключателю, скрытие лишнего блока снижает риск ошибки редактора и убирает интерфейсный шум.

Важная граница: Meta Box Show Hide управляет видимостью целых meta boxes. Для условий на уровне отдельного поля, вкладки, внешнего элемента или сложных операторов обычно нужен MB Conditional Logic. Для случаев, когда блок вообще не должен попадать в HTML редактора, логичнее смотреть на MB Include Exclude или фильтр rwmb_show. Ниже эти различия разобраны отдельно, потому что именно здесь чаще всего появляются неправильные ожидания.

Где расширение встраивается в рабочий процесс Meta Box

Meta Box как базовый плагин даёт разработчику каркас для custom fields, custom meta boxes и динамических данных в WordPress. Meta Box Show Hide добавляет к этому каркасу слой условной видимости: при регистрации meta box разработчик добавляет массив show или hide, а расширение отслеживает выбранный контекст в редакторе и показывает либо скрывает весь блок.

По официальной документации условия могут опираться на шаблон страницы, post format, рубрики, иерархические пользовательские таксономии, факт наличия родительской страницы и значения отдельных элементов интерфейса через CSS-селекторы. На практике это закрывает типовую задачу: не перегружать редактора настройками, которые нужны только в узком сценарии.

Представьте сайт с несколькими типами страниц. На обычной странице нужны только SEO-поля и короткие служебные заметки. На странице с шаблоном "Landing" появляются настройки первого экрана, кнопки, блока преимуществ и формы. На записи формата "Gallery" нужны поля галереи, а на обычной записи они только сбивают редактора. Meta Box Show Hide позволяет привязать такие блоки к контексту без написания отдельной логики показа для каждого экрана.

Главная практическая мысль: расширение не создаёт поля и не выводит их на сайте. Оно помогает управлять тем, какие группы полей видит редактор в админ-панели WordPress при редактировании конкретного материала.

Из-за JavaScript-подхода блок может появляться без перезагрузки страницы после изменения условия, например после выбора рубрики или значения в управляющем поле. Но у этого подхода есть следствие: скрытые поля всё равно существуют в разметке редактора и их значения могут быть отправлены при сохранении записи. Поэтому Meta Box Show Hide не стоит использовать как механизм безопасности, разграничения доступа или удаления данных из формы.

Кому подойдёт Meta Box Show Hide, а кому лучше выбрать другой подход

Расширение рассчитано прежде всего на разработчиков, вебмастеров и агентства, которые собирают сайты на Meta Box и контролируют структуру полей через код или через набор расширений Meta Box. Оно подходит, если нужно оставить одну модель данных, но сделать экран редактирования более контекстным.

Когда продукт будет удачным выбором

Meta Box Show Hide хорошо подходит для проектов, где разные типы контента используют часть общих полей, но не все поля должны быть видны постоянно. Это могут быть журнальные сайты, каталоги, лендинги внутри корпоративного сайта, базы событий, образовательные материалы или проекты с несколькими редакционными сценариями.

• Нужно показывать блок настроек только для конкретного шаблона страницы.
• Нужно скрывать meta box для отдельных рубрик или пользовательских таксономий.
• Нужно менять набор видимых блоков при выборе post format.
• Нужно показать дополнительный блок, если редактор выбрал значение в управляющем поле.
• Нужно сохранить работу и в классическом редакторе, и в редакторе блоков, если используемая версия расширения поддерживает оба режима.

Когда лучше не начинать с Show Hide

Если задача звучит как "показать отдельное поле, когда другое поле равно X", Show Hide может оказаться слишком грубым инструментом. Он работает на уровне группы, а не на уровне каждой строки формы. Для точечных зависимостей, сложных операторов, вкладок и внешних HTML-элементов ближе MB Conditional Logic.

Если задача связана с правами пользователей, безопасностью, удалением лишних полей из формы или запретом сохранения значений, JavaScript-скрытие не решает её полностью. В таком случае стоит смотреть на серверные проверки, роли WordPress, отдельные meta boxes, MB Include Exclude или собственный фильтр, который решает, показывать ли группу до вывода HTML. Это уже серверная логика, а не только удобство редактора.

Для визуального конструктора без кода расширение тоже не всегда будет самым простым стартом. Если команда хочет всё настраивать только через интерфейс, стоит заранее проверить, какие части конкретного набора Meta Box доступны через UI в установленной сборке. Базовый Meta Box часто используется как библиотека и предполагает работу с кодом, а расширения вроде MB Builder добавляют визуальный уровень.

Что проверить перед установкой и включением

Перед установкой важно понять не только "есть ли WordPress", а из какой системы собран экран редактирования. Meta Box Show Hide зависит от того, что meta boxes уже зарегистрированы через Meta Box и что выбранные условия действительно существуют в интерфейсе редактирования.

Зависимости и место установки

Для работы нужен базовый Meta Box. Если поля создаются через код, проверьте, где подключается фильтр rwmb_meta_boxes: в дочерней теме, в собственном мини-плагине или в mu-plugin. Для клиентских проектов чаще безопаснее держать такую конфигурацию в отдельном плагине, чтобы смена темы не выключила структуру данных.

Если используется Meta Box AIO или набор премиальных расширений, проверьте, включён ли нужный модуль. Для сайта с несколькими средами полезно сверить staging и production: иногда расширение включено на тестовом сайте, но отсутствует на рабочем, и правило show в коде не даёт ожидаемого поведения.

Контекст, по которому будет идти условие

До написания кода составьте короткую таблицу условий. Это экономит время на диагностике, потому что Show Hide чувствителен к тому, чем именно вы проверяете контекст: ID, имя, slug, CSS-селектор или формат post_type:template-file.php для шаблонов записей.

Если правило зависит от пользовательской таксономии, убедитесь, что она действительно доступна на экране редактирования нужного типа записи. Если редактор не видит этот блок или он заменён кастомным интерфейсом, условие может не сработать так, как ожидается.

План отката

Перед включением правил на рабочем сайте подготовьте простой откат: временно закомментировать массив show или hide, выключить расширение на staging, вернуть прежний файл мини-плагина из системы контроля версий. Не начинайте настройку на единственной рабочей копии без резервного плана, особенно если поля используются редакторами каждый день.

Установка и первичная проверка в админ-панели

Установка обычно выглядит как добавление расширения к уже работающему Meta Box. Не нужно создавать авторизацию внутри проекта или вводить какие-либо секреты в кодовые примеры. Для этой статьи достаточно понимать общий порядок: установить базовый Meta Box, добавить расширение, активировать его в WordPress и проверить, что регистрация meta boxes продолжают работать.

Базовый порядок действий

1. Проверьте, что базовый Meta Box активен и существующие поля отображаются в редакторе.
2. Установите расширение Meta Box Show Hide тем способом, который соответствует вашей сборке: отдельный ZIP, Meta Box AIO или другой официальный пакет.
3. Активируйте расширение через Plugins или через панель управления расширениями, если используете Meta Box AIO.
4. Откройте запись или страницу, где уже есть meta box, зарегистрированный через Meta Box.
5. Пока не добавляйте сложные правила. Сначала убедитесь, что старая конфигурация meta boxes не сломалась.

После установки не должно появиться магического нового экрана с единственной кнопкой "настроить всё". Большая часть работы остаётся в конфигурации meta boxes. Это нормально для экосистемы Meta Box: продукт ориентирован на разработчика и структуру данных, а не только на визуальные переключатели.

Минимальная проверка после активации

Откройте экран редактирования с уже существующим meta box и сохраните тестовую запись без изменений. Если на этом этапе появляются ошибки JavaScript, исчезают все блоки или редактор начинает работать нестабильно, сначала отключите сторонние плагины на тестовой копии и переключитесь на стандартную тему. Такой подход совпадает с типичной рекомендацией поддержки Meta Box: изолировать Meta Box, Meta Box AIO и стандартную тему, чтобы понять, конфликтует ли условная логика с окружением.

Мини-итог: первая проверка не про условия, а про стабильность. Если базовые поля Meta Box работают до и после активации расширения, можно переходить к правилам видимости.

Как устроены правила show и hide

В Meta Box Show Hide правило добавляется прямо в массив конфигурации meta box. Используется либо ключ show, либо ключ hide. Оба варианта принимают набор условий и необязательный параметр relation, который объединяет условия как AND или OR. По умолчанию применяется логика OR.

Разница между show и hide проста, но её стоит проговорить. show означает "покажи блок, если условия совпали". hide означает "скрой блок, если условия совпали". В одном проекте лучше договориться о стиле: либо большинство правил пишутся как включающие, либо как исключающие. Смешивание двух подходов без причины усложняет поддержку.

Логика OR и AND

Если условий несколько и используется OR, достаточно совпадения одного условия. Например, meta box может появляться для страницы с конкретным шаблоном или для записи в нужной рубрике. Если используется AND, должны совпасть все условия сразу: выбран нужный шаблон, запись относится к нужной рубрике и управляющий checkbox отмечен.

Для редакторского интерфейса часто безопаснее начинать с более узкой логики. Когда meta box появляется слишком часто, редактор видит лишние поля и может заполнить не тот блок. Когда правило слишком узкое, блок не появится, но это легче заметить на тесте с заранее составленным чек-листом условий.

Условия по шаблону страницы и post type template

Шаблон страницы - один из самых понятных сценариев. Если настройки нужны только для лендинга, укажите файл шаблона в template. Для шаблонов типов записей WordPress используется форма post_type:template-file.php. Если часть post_type: не указана, расширение воспринимает шаблон как шаблон страницы.

Это важный нюанс для сайтов, где шаблоны есть не только у страниц, но и у пользовательских типов записей. Если у типа event есть шаблон single-event.php, правило должно явно отражать тип записи. Иначе разработчик может долго искать ошибку в JavaScript, хотя проблема находится в формате значения.

Условия по рубрикам и пользовательским таксономиям

Для рубрик используется ключ category. В документации подчёркнуто, что для категорий ожидаются ID или имена, а не slug. Для пользовательской таксономии ключом становится slug таксономии, например location, а значениями - ID или имена терминов. Здесь особенно важно не смешивать человекочитаемое имя, slug и ID.

Если проект многоязычный или редакторы переименовывают рубрики, ID обычно стабильнее имени. Но ID хуже читается в коде, поэтому рядом уместен короткий комментарий. Такой комментарий не должен объяснять очевидное, но может сохранить контекст: какой термин скрывается за числом и почему именно он управляет блоком.

Условие input_value

input_value позволяет реагировать на значение конкретного элемента интерфейса. Это мощный, но более хрупкий вариант, потому что он зависит от CSS-селектора и фактической разметки редактора. Его удобно применять для собственного управляющего поля: например, checkbox "Use advanced layout" показывает meta box с дополнительными настройками.

Перед использованием input_value проверьте селектор в браузере и убедитесь, что он существует на экране редактирования в нужном режиме. Если один и тот же сайт использует классический редактор и редактор блоков, протестируйте оба. Для checkbox документация показывает подход, где значение true соответствует отмеченному состоянию.

Подробная настройка: от простого правила к поддерживаемой конфигурации

Самая полезная настройка Meta Box Show Hide - не в том, чтобы написать один массив, а в том, чтобы сделать правило понятным через месяц. Условная видимость обычно ломается не из-за сложности кода, а из-за неясной логики: неизвестно, почему блок скрыт, какое условие главное, какие термины используются и что должно произойти после выбора редактора.

Базовый пример для страницы с шаблоном

Ниже пример показывает meta box только для страниц с указанными шаблонами. Такой код уместно держать в мини-плагине проекта или в файле, где уже зарегистрированы Meta Box поля. Пример не меняет ядро WordPress и не требует правки файлов расширения.

add_filter( 'rwmb_meta_boxes', 'project_register_landing_meta_boxes' );

function project_register_landing_meta_boxes( $meta_boxes ) {
    $meta_boxes[] = array(
        'id'         => 'landing_controls',
        'title'      => 'Landing controls',
        'post_types' => array( 'page' ),
        'show'       => array(
            'relation' => 'OR',
            'template' => array( 'templates/landing.php', 'templates/campaign.php' ),
        ),
        'fields'     => array(
            array(
                'name' => 'Hero button label',
                'id'   => 'hero_button_label',
                'type' => 'text',
            ),
        ),
    );

    return $meta_boxes;
}

После сохранения откройте страницу с обычным шаблоном и страницу с указанным шаблоном. В первом случае meta box не должен мешать редактору. Во втором он должен появиться. Если блок не меняет состояние, проверьте точное имя файла шаблона, путь относительно темы и то, отображается ли selector шаблона в текущем редакторе.

Пример с рубрикой и пользовательской таксономией

Когда блок нужен для определённого типа редакционного материала, удобнее использовать таксономии. Например, настройки спонсорского блока могут появляться только у записей в рубрике "Partner" или у событий в регионе "USA". В таких правилах лучше не полагаться на один визуальный тест: проверьте запись без термина, с одним термином, с несколькими терминами и после снятия термина.

'show' => array(
    'relation' => 'OR',
    'category' => array( 12, 'Partner' ),
    'region'   => array( 'USA' ),
),

Если термин переименован, правило по имени может перестать совпадать. Поэтому для устойчивых проектов часто выбирают ID терминов и ведут рядом документацию. Это не обязательное правило, но для клиентского сайта с долгой поддержкой ID обычно безопаснее названия.

Когда использовать hide вместо show

hide удобен, когда meta box должен быть виден почти всегда, кроме нескольких исключений. Например, блок заметок редактора нужен на всех страницах, но не нужен на системных шаблонах, где контент собирается автоматически. В таком случае исключающее правило читается проще, чем длинный список разрешённых условий.

Но не превращайте hide в способ скрыть проблемы структуры. Если блок относится только к одному типу контента, лучше явно показать его через show. Чем меньше скрытой логики, тем проще объяснить редактору, почему он видит или не видит конкретный блок.

Безопасный откат спорной настройки

Если после внедрения правила редакторы жалуются, что блок исчез, не меняйте сразу несколько условий. Отключите только один слой: например, временно уберите input_value и оставьте template. Потом проверьте результат. Такой пошаговый откат помогает понять, что именно сломалось: неверный селектор, неправильный термин, несовместимость редактора или конфликт JavaScript.

Проверка после каждого изменения: открыть новую запись, открыть существующую запись, изменить условие, сохранить, перезагрузить экран и убедиться, что meta box остаётся в ожидаемом состоянии.

Практический пример: настройки события только для нужного шаблона и типа материала

Разберём предметный сценарий. На сайте есть пользовательский тип записи event. Для обычного события редактор заполняет дату, место и краткое описание. Для события с расширенной страницей нужен дополнительный meta box: фон первого экрана, текст кнопки, блок партнёров и отметка "Показывать карту". Этот блок должен появляться только у событий с шаблоном event:templates/event-landing.php и при выбранной таксономии event_type со значением "Conference".

Цель

Нужно, чтобы редактор видел расширенные настройки только там, где они реально влияют на страницу события. Для обычных событий эти поля не должны занимать место и не должны провоцировать заполнение данных, которые не выводятся на сайте.

Подготовка

Перед кодом проверьте четыре вещи: тип записи event зарегистрирован, шаблон доступен для этого типа записи, таксономия event_type выводится в редакторе, а meta box с расширенными полями уже описан через Meta Box. Если хотя бы один элемент отсутствует, правило видимости не сможет корректно проверить контекст.

Шаги настройки

1. Создайте или откройте meta box с расширенными настройками события.
2. Добавьте в конфигурацию ключ show.
3. Поставьте relation в AND, потому что должны совпасть оба условия.
4. Укажите шаблон в формате event:templates/event-landing.php.
5. Укажите таксономию event_type и стабильное значение термина.
6. Проверьте новое событие, существующее событие и событие, где выбран другой тип.

'show' => array(
    'relation' => 'AND',
    'template' => array( 'event:templates/event-landing.php' ),
    'event_type' => array( 'Conference' ),
),

Ожидаемый результат

Когда редактор выбирает нужный шаблон и термин события, meta box с расширенными настройками появляется в редакторе. Если выбран другой шаблон или другой термин, блок скрыт. При переключении условий блок должен реагировать без ручной перезагрузки там, где WordPress и окружение корректно передают изменения в интерфейсе.

Нюанс с уже сохранёнными значениями

Если поля были заполнены раньше, скрытие блока не означает автоматическое удаление значений. Это важная особенность JavaScript-видимости. Если сайт не должен выводить старые значения, проверяйте условие и на уровне шаблона вывода. Meta Box Show Hide улучшает админ-панель, но не заменяет серверную логику вывода на публичной части сайта.

Проверка для редактора

Попросите редактора пройти тот же сценарий без подсказок: создать событие, выбрать тип, выбрать шаблон, увидеть нужный блок, заполнить одно поле, сохранить и открыть запись снова. Если редактор понимает, почему блок появился, настройка сделана не только технически, но и эргономически.

Как проверить результат после настройки

Проверка результата должна быть шире, чем "я увидел блок один раз". Условная видимость зависит от состояния редактора, сохранённых значений, порядка загрузки скриптов и иногда от других плагинов. Поэтому хорошая проверка включает несколько контекстов.

Чек-лист для редактора блоков

• Создайте новую запись или страницу в нужном типе контента.
• Проверьте состояние meta box до выбора условия.
• Выберите шаблон, рубрику, формат или значение поля, которое должно показать блок.
• Сохраните запись и перезагрузите экран редактирования.
• Снимите условие и убедитесь, что блок скрывается обратно.
• Проверьте консоль браузера на JavaScript-ошибки, если блок не меняет состояние.

Чек-лист для классического редактора

Классический редактор всё ещё встречается на старых или специализированных проектах. Официальная страница расширения указывает поддержку classic editor и Gutenberg, но реальный сайт может добавлять свои скрипты, мета-блоки и плагины. Поэтому тестируйте режим отдельно.

• Убедитесь, что нужные блоки не выключены в Screen Options.
• Проверьте, что рубрики, таксономии и post format доступны на экране.
• Сохраните запись после смены условия и откройте её заново.
• Если блок ведёт себя нестабильно, временно отключите плагины, которые меняют экран редактирования.

Публичная часть сайта

Meta Box Show Hide не выводит данные на сайте, но после настройки полезно проверить публичную часть. Если поле скрыто в админ-панели, шаблон сайта всё равно может читать старое значение. Поэтому в шаблоне вывода стоит учитывать тот же бизнес-сценарий: если событие не использует расширенный шаблон, не показывать блок партнёров только потому, что данные когда-то были сохранены.

Такой подход разделяет две задачи: расширение управляет удобством редактора, а тема или собственный код управляет тем, что увидит посетитель. Это снижает риск, что скрытое поле случайно продолжит влиять на публичную страницу.

Практичные идеи применения на реальных сайтах

Meta Box Show Hide раскрывается лучше всего не в демонстрационном примере, а в ежедневной работе редакции. Ниже несколько сценариев, где условная видимость целого блока действительно уменьшает шум и помогает не ошибиться.

Лендинги внутри обычного сайта

Для страниц с шаблоном лендинга можно показывать блоки "Hero", "CTA", "Tracking note" и "Campaign settings", а на обычных страницах скрывать их. Редактор не будет думать, почему поле кнопки не влияет на стандартную страницу. Проверка простая: сменить шаблон страницы и убедиться, что набор meta boxes меняется.

Редакционные форматы записей

Для записей формата "Gallery" можно показывать meta box с настройками галереи, для формата "Video" - блок с URL и постером, а для стандартной записи оставить только обычные поля. Такой сценарий особенно полезен, если тема по-разному выводит материалы в архиве и на отдельной странице.

Каталог с пользовательскими таксономиями

В каталоге объектов разные таксономии могут требовать разные блоки данных. Например, для объектов типа "Apartment" нужны поля площади и этажа, для "Land" - кадастровая информация и ограничения участка. Show Hide помогает держать один интерфейс редактирования, но показывать редактору только контекстные группы.

Внутренние служебные блоки

Иногда meta box нужен не для вывода на сайте, а для процесса: редакторская отметка, статус проверки, внутренний комментарий. Если такой блок нужен только дочерним страницам или только материалам определённой рубрики, is_child и условия по таксономии помогут не показывать его везде.

Во всех сценариях правило одно: сначала опишите редакционный смысл блока, потом подберите техническое условие. Если начать с кода, легко получить красивый массив условий, который никто в команде не сможет объяснить.

Ограничения и выбор между Show Hide, Conditional Logic и Include Exclude

Официальная документация Meta Box прямо сравнивает три подхода: MB Include Exclude, MB Show Hide и MB Conditional Logic. Это сравнение критично для правильного выбора инструмента. Они похожи по словам "show" и "hide", но работают на разных уровнях.

Самое частое заблуждение - считать JavaScript-скрытие равноценным удалению поля из формы. Это не так. Документация подчёркивает, что при Show Hide и Conditional Logic HTML уже выведен, а inputs только скрываются. Значения могут сохраняться в базе при сохранении записи. Если это нежелательно, проверку нужно делать на уровне вывода, сохранения или серверной логики.

Второе заблуждение - пытаться решить все задачи через одно расширение. Если вам нужно поле "Видео URL" только при выбранном radio "Видео", удобнее Conditional Logic. Если вам нужен блок "Landing settings" только на шаблоне лендинга, Show Hide проще. Если блок не должен видеть неадминистратор, Show Hide не является защитой прав.

Третье заблуждение связано с производительностью. Скрытие лишних блоков улучшает восприятие редактора, но не превращает тяжёлый экран редактирования в лёгкий автоматически. Если meta box содержит тяжёлые поля, медленные запросы или сторонние скрипты, JavaScript-скрытие не всегда уберёт стоимость их подготовки. Для действительно тяжёлых блоков лучше рассмотреть серверное исключение или пересборку структуры.

Почему meta box не появляется или скрывается неправильно

Диагностика должна идти от простого к сложному: сначала проверить условие и экран редактора, затем окружение, затем JavaScript-конфликты. Ниже собраны симптомы, которые характерны для conditional visibility в Meta Box и для WordPress-редактора в целом.

Блок не появляется при выборе рубрики

Симптом: редактор выбирает нужную рубрику, но meta box остаётся скрытым. Возможная причина - в правило передан slug, а документация для category ожидает ID или имя. Также проверьте регистр имени, потому что для категорий условие чувствительно к регистру.

Что проверить: ID рубрики, точное имя, наличие рубрики в текущем типе записи, работу в новой и уже сохранённой записи. Исправление обычно сводится к переходу на ID или корректное имя. Если правило становится понятнее с ID, добавьте рядом комментарий в коде.

Условие по шаблону не работает для пользовательского типа записи

Симптом: meta box должен появляться для шаблона типа записи, но не появляется. Возможная причина - шаблон указан как обычный файл страницы, без префикса типа записи. Для post type templates используйте формат post_type:template-file.php.

Что проверить: поддерживает ли тип записи шаблоны, как называется файл, какой путь ожидает WordPress, не отличается ли путь в дочерней теме. Если шаблон доступен только в теме, проверьте, не изменилась ли структура после обновления или смены темы.

Скрытый блок всё равно сохраняет старые значения

Симптом: редактор больше не видит meta box, но на публичной странице остаются старые данные. Это не обязательно ошибка расширения. Show Hide скрывает блок в интерфейсе, но не является очисткой базы и не отменяет вывод в шаблоне.

Исправление зависит от задачи. Если старые значения не должны выводиться, добавьте проверку того же бизнес-условия в шаблон публичной части. Если значения нужно очистить, делайте это отдельной миграцией или аккуратной админской процедурой, а не через скрытие поля.

Правило с input_value работает нестабильно

Симптом: блок появляется после одного переключателя, но не реагирует после другого или перестаёт работать после обновления интерфейса. Возможная причина - CSS-селектор слишком хрупкий, элемент появляется позже, или другой скрипт меняет состояние без события, которое ждёт conditional logic.

Что проверить: существование элемента в разметке, точное значение, состояние checkbox, ошибки в консоли браузера. Если значение меняется программно, иногда для более сложной условной логики уместнее MB Conditional Logic и его ручной запуск условий через JavaScript, но для Show Hide лучше не усложнять без необходимости.

В классическом редакторе и редакторе блоков поведение разное

Симптом: в одном редакторе блок работает, а в другом нет. Сначала проверьте актуальность расширения и changelog: поддержка Gutenberg расширялась в истории продукта. Затем проверьте, не скрыт ли блок в Screen Options, и нет ли плагинов, которые перестраивают экран редактирования.

Если проблему не удаётся воспроизвести на стандартной теме с минимумом плагинов, причина, вероятно, в окружении. В таком случае лучше собрать минимальный пример meta box и постепенно возвращать плагины. Это быстрее, чем спорить с большим рабочим экраном, где одновременно действует десяток скриптов.

Нужно скрывать по роли пользователя

Симптом: команда пытается использовать Show Hide как механизм "администратор видит, редактор не видит". Для такой задачи лучше не опираться на визуальное скрытие. На форуме Meta Box похожие вопросы обычно направляют к Include Exclude, разделению meta boxes или другим решениям на уровне прав и серверной логики.

Если речь о безопасности или доступе к данным, используйте роли WordPress, capability checks, серверные фильтры и отдельные проверки сохранения. Show Hide может улучшить интерфейс, но не должен быть единственной защитой.

Видео по Meta Box Show Hide

На официальной странице продукта есть точный ролик Meta Box Show Hide Overview. Он полезен как быстрая визуальная проверка того, что расширение работает именно с meta boxes и условиями по шаблону, формату записи или рубрике. Используйте его как дополнение к этому руководству, если нужно увидеть общий принцип в движении, а не как замену тестированию на своём сайте.

Когда стоит использовать Meta Box Show Hide

Meta Box Show Hide будет удачным выбором, если сайт уже использует Meta Box, а задача состоит в том, чтобы сделать редактор WordPress более контекстным: показывать целые группы полей только для нужных шаблонов, форматов, рубрик, таксономий, дочерних страниц или значений управляющих элементов. В этом сценарии расширение даёт понятный способ убрать лишние блоки с экрана и не заставлять редактора каждый раз разбираться, какие поля относятся к текущему материалу.

Перед запуском на рабочем сайте проверьте зависимости, точные значения условий, поведение в нужном редакторе, сохранение после перезагрузки и публичный вывод старых значений. Если нужна логика на уровне отдельных полей, смотрите в сторону MB Conditional Logic. Если блок не должен выводиться в HTML или условие связано с правами, выбирайте серверный подход.

Когда тестовый сценарий пройден и вы понимаете, какие meta boxes должны появляться в каждом контексте, можно скачать установочный файл и проверить расширение на staging-копии сайта. Такой порядок безопаснее, чем сразу включать условную видимость на рабочем редакторском экране.