Meta Box Conditional Logic - WordPress Plugin

Руководство по настройке Meta Box Conditional Logic для управляемых полей WordPress

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

Материал рассчитан на владельца сайта, вебмастера или разработчика, который уже работает с Meta Box, Meta Box Lite, MB Builder или Meta Box AIO и хочет показать редактору только те поля, которые нужны в конкретном сценарии. Мы не будем пересказывать карточку продукта. Вместо этого соберём практическую схему: от первого правила видимости до диагностики случаев, когда поле не появляется, правило срабатывает только после обновления страницы или условие внутри группы ведёт себя иначе, чем ожидалось.

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

Какую задачу решает условная логика в экосистеме Meta Box

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

Meta Box Conditional Logic добавляет к этому слою зависимость: поле, мета-бокс или даже отдельный элемент админ-панели показывается или скрывается в зависимости от значения другого поля, таксономии, шаблона страницы, формата записи, ID записи, родительской страницы или другого элемента. В интерфейсе MB Builder это выглядит как блок правил в разделе Conditional Logic. В коде та же идея выражается через параметры visible и hidden.

Важный практический вывод: расширение не решает задачу вывода данных в шаблоне автоматически. Оно управляет тем, что видит редактор в форме ввода. Если поле скрыто в админ-панели, это не значит, что тема перестанет выводить старое сохранённое значение. Для публичной части сайта нужно отдельно проверить шаблон, динамический блок, MB Views, page builder или PHP-код, который читает мета-значение.

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

• Карточка события переключается между online и offline, а редактор видит либо ссылку на трансляцию, либо адрес и карту.
• Каталог услуг показывает разные поля для консультации, пакета услуг и разового продукта.
• Редактор страницы выбирает шаблон, после чего появляются только поля, относящиеся к этому шаблону.
• В группе характеристик дополнительные поля открываются только внутри конкретного клона, чтобы один повторяемый блок не влиял на соседний.
• Некоторые вкладки MB Tabs или произвольные элементы админ-панели скрываются по CSS-селектору через rwmb_outside_conditions.

Сильная сторона продукта в том, что он работает не только с обычной парой "поле зависит от поля". Документация подтверждает поддержку операторов сравнения, составных условий, специальных значений для чекбоксов и медиа-полей, встроенных элементов WordPress и элементов за пределами field group. Именно эти детали и стоит разобрать, потому что они чаще всего отличают рабочую настройку от правила, которое выглядит правильным, но не срабатывает.

Кому расширение подходит, а где оно будет лишним

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

Подходящие сценарии

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

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

Когда лучше выбрать другой подход

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

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

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

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

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

Проверьте базовую связку Meta Box

Для работы нужна активная база Meta Box. Если вы используете визуальный интерфейс, убедитесь, что доступны Meta Box Lite, MB Builder или Meta Box AIO с нужными расширениями. Документация Meta Box AIO отдельно описывает страницу Meta Box -> Extensions, где расширения можно включать и отключать. В индивидуальной установке важно, чтобы сам Meta Box и расширение условной логики были активны одновременно.

Если сайт работает только на бесплатной библиотеке Meta Box без визуального интерфейса, настроить правила можно кодом. Это нормальный вариант для разработчика, но не для команды, которая ожидает настраивать правила через админ-панель. В таком случае стоит заранее решить, где будет жить схема полей: в MB Builder, в PHP-коде темы, в отдельном плагине или в экспортированном коде.

Приведите ID и значения к предсказуемому виду

Условие сравнивает значения. Поэтому ID поля, значения опций и тип поля важнее красивой подписи. Если поле называется "Тип события", его ID может быть event_type, а значения - online и offline. Не используйте случайные значения вроде 1 и 2, если через месяц никто не вспомнит, что они означают.

Для чекбоксов документация рекомендует проверять true, false, 1 или 0. Для медиа-полей вроде file_advanced и image_advanced расширение проверяет количество загруженных файлов, а не строковое значение. Это важный нюанс: условие "покажи поле, если изображение есть" обычно строится через сравнение количества с нулём.

Разделите правила расположения и правила поведения

В Meta Box есть несколько похожих по смыслу механизмов. Location решает, где вообще появляется field group. MB Include Exclude и похожие расширения помогают точнее ограничить область применения. MB Show Hide проще и ориентирован на переключение мета-бокса по условиям вроде шаблона или таксономии. Meta Box Conditional Logic шире: оно управляет полями, мета-боксами и элементами, зависящими от значений.

Не смешивайте всё в одно правило. Если поле относится только к типу записи event, задайте это на уровне расположения field group. Если внутри события поле "Адрес" нужно только для офлайн-событий, это уже задача условной логики. Такой подход облегчает диагностику: вы понимаете, какой слой отвечает за отсутствие поля.

Установка и первичная проверка в WordPress

Точные шаги установки зависят от того, используете ли вы индивидуальное расширение, Meta Box AIO или сборку Meta Box Lite. Но логика первичной проверки одинаковая: расширение должно быть активировано, поле-зависимость должно существовать, а правило должно срабатывать без перезагрузки страницы там, где оно рассчитано на JavaScript-переключение.

1. Убедитесь, что Meta Box или Meta Box Lite активны и ваши field group видны в админ-панели.
2. Активируйте Meta Box Conditional Logic как отдельное расширение или включите соответствующий модуль в Meta Box -> Extensions, если используете Meta Box AIO.
3. Откройте существующую field group или создайте тестовую группу с простым полем выбора и одним зависимым текстовым полем.
4. Добавьте правило: зависимое поле видно, если поле выбора имеет конкретное значение.
5. Откройте запись, страницу или пользовательский тип записи, где группа должна отображаться, и переключите исходное поле несколько раз.
6. Сохраните запись и откройте её заново, чтобы проверить не только моментальное переключение, но и состояние после загрузки формы.

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

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

Настройка через MB Builder: от простого правила к связной форме

В визуальном интерфейсе MB Builder условная логика находится в настройках конкретного поля или field group. Пользователь выбирает, показывать или скрывать элемент, задаёт зависимое поле, оператор и значение. Для большинства редакторских задач этого достаточно: не нужно писать код, если зависимость строится внутри одной группы полей и опирается на обычные значения.

Базовый сценарий: показать поле по выбранному типу

Представим поле event_type со значениями online и offline. Для онлайн-события нужен URL трансляции, для офлайн-события - адрес. В MB Builder это лучше строить как две простые зависимости, а не как один длинный набор исключений.

• Поле stream_url показывается, если event_type равно online.
• Поле venue_address показывается, если event_type равно offline.
• Подсказки рядом с полями объясняют редактору, что будет показано на сайте.
• Шаблон вывода отдельно проверяет, заполнено ли значение, чтобы не выводить пустой блок.

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

Логика "все условия" и "любое условие"

Для сложных форм важно понимать связь между условиями. Когда несколько условий должны выполниться одновременно, используется логика "все". Когда достаточно одного совпадения, используется отношение or. В интерфейсе это обычно выражается выбором режима для набора правил, а в коде - ключом relation внутри when.

Не злоупотребляйте условием "любое". Оно удобно, когда поле действительно допустимо в нескольких независимых случаях. Но если форма начинает превращаться в набор исключений, лучше пересмотреть модель данных: возможно, нужен отдельный тип записи, отдельная field group или более понятное поле выбора.

Какие настройки лучше не трогать без причины

Параметр toggle_type отвечает за способ переключения. По умолчанию элементы скрываются через поведение, похожее на display. В документации также описаны варианты visibility, slide и fade. Менять тип переключения стоит только тогда, когда это решает конкретную проблему: например, нужно сохранить место в сетке колонок или сделать появление менее резким.

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

Настройка кодом: параметры, операторы и безопасные примеры

Кодовый вариант нужен, если field group регистрируется через rwmb_meta_boxes, если нужно скрыть элемент вне группы или если проект хранит схему полей в репозитории. Документация описывает базовый синтаксис так: visible или hidden получают массив с ID поля, оператором и значением. Если оператор равен =, его можно опустить.

Ниже пример для события. Он показывает ссылку трансляции только при онлайн-формате и адрес только при офлайн-формате. Код лучше помещать в небольшой собственный плагин проекта или в безопасный сниппет, который легко отключить. Не редактируйте ядро WordPress, файлы Meta Box или файлы расширения.

add_filter( 'rwmb_meta_boxes', function( $meta_boxes ) {
    $meta_boxes[] = [
        'title'      => 'Event details',
        'id'         => 'event-details',
        'post_types' => ['event'],
        'fields'     => [
            [
                'name'    => 'Event type',
                'id'      => 'event_type',
                'type'    => 'select',
                'options' => [
                    'online'  => 'Online',
                    'offline' => 'Offline',
                ],
            ],
            [
                'name'    => 'Stream URL',
                'id'      => 'stream_url',
                'type'    => 'url',
                'visible' => ['event_type', 'online'],
            ],
            [
                'name'    => 'Venue address',
                'id'      => 'venue_address',
                'type'    => 'text',
                'visible' => ['event_type', 'offline'],
            ],
        ],
    ];

    return $meta_boxes;
} );

Проверка после вставки простая: откройте новую запись типа event, переключите Event type, убедитесь, что лишнее поле скрывается сразу, сохраните запись и проверьте состояние после повторного открытия. Если поле появляется только после сохранения, сначала проверьте, что зависимое поле и поле-источник находятся в поддерживаемой области и что в браузере нет ошибок JavaScript.

Операторы, которые стоит использовать осознанно

Обычные операторы = и != подходят для большинства переключателей. in удобен, когда значение может входить в список. contains помогает с множественным выбором, включая чекбокс-листы и некоторые таксономические поля. between подходит не только для чисел, но и для значений даты и времени, если они сохранены в сопоставимом формате. starts with, ends with и match лучше использовать осторожно: они гибкие, но хуже читаются командой.

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

Условия для элементов вне field group

Документация подтверждает, что условная логика может работать с элементами за пределами обычной группы полей через фильтр rwmb_outside_conditions. Это полезно для вкладок MB Tabs, вспомогательных блоков, HTML-элементов и других частей страницы редактирования, если у них есть понятный CSS-селектор.

add_filter( 'rwmb_outside_conditions', function( $conditions ) {
    $conditions['.rwmb-tab-extra-details'] = [
        'hidden' => ['post_format', 'aside'],
    ];

    return $conditions;
} );

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

Группы, повторяемые блоки и вкладки: где чаще всего ломается ожидание

Самые интересные проблемы начинаются там, где поле больше не живёт в простой плоской форме. Meta Box поддерживает группы, клонируемые группы и вкладки. Meta Box Conditional Logic может с ними работать, но правила отличаются. Если пропустить этот нюанс, условие будет выглядеть правильным и всё равно не сработает.

Неповторяемая группа и формат ID

В неповторяемой группе подполе получает фактический ID в формате groupID_fieldID. Документация прямо указывает, что условие для подполей такой группы нужно строить с учётом этого формата. Например, если группа имеет ID details, а поле внутри неё имеет ID brand, зависимость может проверять details_brand.

Это один из самых частых источников ошибки: разработчик смотрит на подпись или внутреннее имя подполя и пишет условие по короткому ID. В результате JavaScript не находит нужное поле в текущем DOM-контексте. Если условие внутри группы не работает, первым делом проверьте реальный ID зависимости.

Клонируемая группа и область действия правила

Для клонируемых групп логика работает внутри конкретного клона. Это удобно: выбор в первом повторяемом блоке не должен менять поля во втором блоке. Но есть ограничение: правило не должно ссылаться на поле вне текущего клона, если зависимое поле находится внутри клонируемой группы. Иначе вы получите поведение, которое трудно объяснить редактору.

Проектируйте повторяемые блоки как автономные мини-формы. Если у каждого блока "Комиссия" есть переключатель "Нужна рамка" и вложенные поля рамки, оба элемента должны быть внутри одного клона. Тогда редактор меняет переключатель в конкретном блоке и видит изменение только там.

Вкладки MB Tabs и элементы DOM

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

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

Практический пример: форма события с онлайн- и офлайн-сценарием

Теперь соберём предметный сценарий. Допустим, у сайта есть тип записи event. Редактор создаёт мероприятие и выбирает формат: онлайн, офлайн или смешанный. От выбора зависят поля, которые нужно заполнить. Цель - сделать форму короткой, но не потерять важные данные.

Цель и подготовка

Нужно получить такую форму:

• При выборе online показываются ссылка на трансляцию и инструкция для участника.
• При выборе offline показываются адрес, карта или поле локации, а также заметка для посетителя.
• При выборе hybrid показываются оба набора, но редактор видит подсказки, какие поля обязательны для публичной страницы.

Перед настройкой создайте поле выбора event_format с понятными значениями online, offline и hybrid. Затем создайте четыре зависимых поля: stream_url, online_note, venue_address и visitor_note. Если используется карта, убедитесь, что поле карты корректно работает само по себе, без условия.

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

1. Откройте field group события в MB Builder или коде, где уже есть поле event_format.
2. Для stream_url задайте видимость, когда event_format равно online или hybrid.
3. Для online_note повторите ту же логику, но добавьте подсказку, что текст будет виден участникам рядом со ссылкой.
4. Для venue_address задайте видимость, когда event_format равно offline или hybrid.
5. Для visitor_note задайте ту же офлайн-логику и используйте его для парковки, входа, пропусков или другой практической информации.
6. Сохраните field group и проверьте три варианта на новой тестовой записи.

Если вы настраиваете кодом, для двух значений удобно использовать in:

[
    'name'    => 'Stream URL',
    'id'      => 'stream_url',
    'type'    => 'url',
    'visible' => ['event_format', 'in', ['online', 'hybrid']],
],
[
    'name'    => 'Venue address',
    'id'      => 'venue_address',
    'type'    => 'text',
    'visible' => ['event_format', 'in', ['offline', 'hybrid']],
],

Проверка результата

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

Особое внимание уделите переходу из одного формата в другой. Если редактор сначала выбрал hybrid, заполнил адрес и ссылку, а затем переключил событие в online, адрес может остаться сохранённым в базе. Это нормально для многих сценариев условной видимости, но шаблон вывода должен учитывать текущее значение event_format, а не слепо выводить всё, что когда-либо было сохранено.

Нюанс, который часто упускают

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

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

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

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

Откройте новую запись, где нет старых значений. Переключите исходное поле и убедитесь, что зависимые поля появляются сразу. Затем откройте существующую запись, где значения уже были сохранены. Это разные ситуации. В существующей записи поле может быть скрыто, но значение в базе всё ещё есть. Если админ-панель ведёт себя по-разному для новой и старой записи, причина может быть в сохранённых данных, значениях по умолчанию или логике шаблона.

Проверка сохранения

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

Проверка публичного вывода

Откройте публичную страницу и проверьте, что тема или builder не выводит нерелевантные данные. Для примера с событиями: онлайн-событие не должно показывать пустой блок адреса, офлайн-событие не должно показывать пустую ссылку трансляции, гибридное событие должно показывать оба набора только если они заполнены.

Если вывод строится через PHP, используйте обычную проверку значения перед HTML-разметкой. Если вывод строится через MB Views или page builder, проверьте условия отображения в соответствующем инструменте. Meta Box Conditional Logic здесь служит сигналом для редакторской формы, но публичную страницу всё равно контролирует шаблон.

Производительность, SEO и безопасность: что меняется на самом деле

Условная логика работает в админ-панели и не должна сама по себе становиться SEO-инструментом. Она может косвенно улучшить качество страницы, если редактор заполняет правильные поля и не оставляет лишние данные. Но она не гарантирует рост позиций, не создаёт разметку автоматически и не исправляет шаблон вывода.

Производительность админ-панели

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

Сократите число условий там, где можно решить задачу расположением field group. Не используйте условную логику для каждого мелкого поля, если проще разделить форму на несколько групп. Проверяйте страницу редактирования с реальным объёмом данных, а не только на пустой тестовой записи.

SEO и структурированные данные

Для SEO полезно не само скрытие поля, а чистота данных. Например, редактор не заполнит адрес для онлайн-события и не создаст противоречивую страницу. Но schema-разметка, заголовки, канонические URL, сниппеты и индексируемый HTML зависят от темы, SEO-плагина, шаблона и вывода значений. Если поле скрыто, а шаблон всё равно выводит старое значение, поисковая система увидит именно публичный HTML.

Безопасность и права доступа

Скрывать поле в админ-панели - не то же самое, что запретить доступ к данным. Если задача связана с ролями, правами, приватными полями или чувствительной информацией, используйте проверки возможностей WordPress, настройки доступа и корректную серверную логику. Условная логика удобна для интерфейса, но не должна быть единственным механизмом защиты.

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

Почему правила не срабатывают и как провести диагностику

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

Поле не появляется при переключении значения

Симптом: зависимое поле остаётся скрытым, хотя поле-источник выбрано правильно. Возможная причина - неверный ID зависимости, неверное значение опции, правило находится не в том поле или расширение не активировано.

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

Условие внутри группы не работает

Симптом: правило работает в плоской форме, но не работает для подполя группы. Для неповторяемой группы проверьте формат groupID_fieldID. Для клонируемой группы проверьте, что поле-источник и зависимое поле находятся внутри одного клона.

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

Скрытое поле всё равно выводится на сайте

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

Проверьте шаблон, MB Views или builder-условие. Вывод должен учитывать не только наличие значения, но и текущее поле-источник. Для события это означает: сначала проверяем event_format, затем выводим соответствующие поля.

Правило срабатывает только после обновления записи

Симптом: поле меняет состояние после Update, но не сразу при переключении. Поддержка Meta Box подтверждает, что условная логика должна показывать и скрывать элементы через JavaScript, если элемент поддерживается и находится в подходящем контексте. Значит, стоит проверить, не управляет ли правило внешним элементом без правильного селектора, не находится ли оно в сложной клонируемой структуре и нет ли ошибок JavaScript.

Если правило относится к произвольному элементу, используйте rwmb_outside_conditions. Если значения изменяются кодом, а события изменения не срабатывают, документация описывает ручной запуск rwmb.runConditionalLogic( $scope ) для области, где нужно пересчитать условия. Не добавляйте такой вызов вслепую: сначала подтвердите, что причина именно в программном изменении значения.

Таксономии и категории ведут себя иначе, чем обычные поля

Симптом: условие по категории или пользовательской таксономии не совпадает с ожиданием. В документации для категории используется post_category, для тегов - tags, для пользовательской таксономии - формат tax_input[taxonomy_slug]. Также важно понимать, проверяются ли ID терминов или slug.

Исправление начинается с уточнения значения. Не пишите условие по названию термина, если документация для этого случая ожидает ID или slug с префиксом slug:. После изменения правила проверьте новую запись и существующую запись с уже выбранной таксономией.

Когда лучше откатить настройку

Откат нужен, если редакторы теряют доступ к важным полям, форма становится непредсказуемой или условие скрывает данные, которые нужно проверить перед публикацией. Безопасный откат - отключить конкретное правило, а не удалять field group. После отката сохраните тестовую запись и убедитесь, что все поля снова видны.

Практичные идеи применения без перегруза формы

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

Каталог услуг с разными типами карточек

Поле service_type может переключать блоки для консультации, пакета, курса или разовой услуги. Для консультации показываются длительность и формат связи, для курса - программа и число занятий, для пакета - состав и условия. Такая схема снижает риск, что редактор заполнит несвязанные поля и получит странную карточку на сайте.

Портфолио с медиа-типами

Если работа может быть изображением, видео или внешней ссылкой, условие по media_type показывает только нужный набор. Для изображения - медиа-поле, для видео - URL или embed-поле, для внешней ссылки - кнопка и подпись. Важно помнить о шаблоне: он должен проверять тот же тип перед выводом.

Страницы с разными секциями

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

Внутренняя модерация контента

Для редакторского процесса можно показывать поле "Причина доработки" только если статус внутренней проверки выбран как needs_revision. Но не используйте это как замену правам доступа или workflow-плагину, если процесс сложный. Условная логика помогает с интерфейсом, а не с полномочиями пользователей.

Точное видео по продукту

На странице продукта Meta Box размещён ролик Meta Box Conditional Logic Quick View. Он полезен как короткая визуальная проверка идеи: как условная логика управляет появлением элементов и почему этот подход удобнее ручного JavaScript для типовых редакторских форм. Видео закрывает intent "как пользоваться Meta Box Conditional Logic" на уровне быстрого знакомства, а детали настройки и диагностики лучше сверять с документацией.

Когда Meta Box Conditional Logic будет удачным выбором

Meta Box Conditional Logic стоит использовать, если у вашего сайта уже есть структурированные поля Meta Box и редакторская форма зависит от выбора пользователя. Расширение особенно полезно для событий, каталогов, страниц с вариантами секций, карточек услуг, сложных field group и проектов, где нужно поддерживать чистую админ-панель без самописного JavaScript на каждый случай.

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

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