Meta Box User Meta - WordPress Plugin

Руководство по настройке и применению Meta Box User Meta

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

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

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

Какую задачу решает расширение для пользовательских полей

В стандартном профиле WordPress есть базовые данные: имя, email, сайт, описание и несколько служебных настроек. Этого хватает для блога с авторами, но быстро становится мало, если сайт работает как каталог специалистов, площадка с продавцами, закрытый портал, образовательный проект, база сотрудников или сервис с проверяемыми участниками.

Meta Box User Meta добавляет к объекту пользователя такие же управляемые поля, какие Meta Box обычно добавляет к записям, страницам и другим объектам. Отличие в целевом объекте: поле должно быть связано не с постом, а с пользователем. В коде это задается параметром type => user, а в визуальном конструкторе обычно выбирается расположение User или аналогичная настройка Location.

Главная польза расширения - не просто добавить еще одну строку в админку, а получить предсказуемую структуру пользовательских данных. У каждого поля есть ID, тип, подпись, возможные варианты значения и правила отображения. После сохранения данные попадают в user meta, поэтому их можно получать через штатные функции WordPress или через helper Meta Box.

Типовые задачи, где расширение действительно уместно:

• Профиль автора с телефоном, должностью, городом, фотографией, ссылками и профессиональным статусом.
• Каталог брокеров, преподавателей, врачей, консультантов или сотрудников, где у каждого пользователя есть дополнительные атрибуты.
• Служебная отметка для администратора: проверен ли пользователь, к какому отделу относится, какую роль в каталоге выполняет.
• Расширение профиля продавца или партнера, если эти данные нужны в шаблоне, карточке автора или интеграции.
• Хранение пользовательских параметров, которые должны оставаться совместимыми с WordPress user meta и доступны через код.

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

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

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

Расширение особенно удобно тем, кто уже использует Meta Box в проекте и хочет сохранить единый подход к полям. Если у сайта уже есть Meta Box, MB Builder, пользовательские типы записей или шаблоны, которые получают значения через rwmb_meta(), добавление user meta становится естественным продолжением архитектуры.

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

Когда расширение уместно

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

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

Когда стоит остановиться и пересмотреть задачу

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

Отдельно стоит отметить сценарий Users > Add New. В support-форуме Meta Box есть обсуждение, где пользователи спрашивали о выводе пользовательских полей прямо на экране создания нового пользователя. По ответу поддержки, эту возможность не стоит считать доступной по умолчанию. Поэтому рабочий процесс обычно такой: сначала создать пользователя стандартными средствами WordPress, затем открыть его профиль и заполнить дополнительные поля.

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

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

Составьте карту данных пользователя

Начните с простой таблицы вне WordPress. Для каждого будущего поля запишите: человекочитаемое название, технический ID, тип поля, кто заполняет, кто видит, где значение будет выводиться и можно ли оставить поле пустым. Для Meta Box это особенно важно, потому что ID станет meta key. Если вы позже будете получать значение через rwmb_meta(), dynamic tag или обычный get_user_meta(), именно ID поля будет главным ориентиром.

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

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

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

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

Решите, какие данные нельзя хранить или показывать

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

Безопасный принцип: в user meta храните только те данные, которые действительно нужны сайту. Для публичного вывода используйте белый список полей, а не "показать все, что есть в профиле".

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

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

1. Убедитесь, что основной Meta Box активен в Plugins.
2. Установите и активируйте Meta Box User Meta или пакет, где это расширение включено.
3. Если используете визуальный интерфейс, откройте раздел Meta Box или Custom Fields и проверьте, доступно ли создание field group.
4. Создайте тестового пользователя или выберите учетную запись, на которой безопасно проводить проверку.
5. Создайте минимальную field group с одним простым полем, например work_phone, и назначьте ее пользователям.
6. Откройте профиль пользователя в админке, заполните поле, сохраните профиль и убедитесь, что значение не пропало после перезагрузки страницы.

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

Что считается успешным первым запуском

Успешный запуск выглядит так: field group появляется на странице редактирования пользователя, поле имеет понятную подпись, значение сохраняется, а технический ID совпадает с тем, который вы записали в карту данных. Если поле не появилось, сначала проверьте Location или type => user, затем активность расширения, затем права текущего пользователя.

Если поле появилось, но значение не выводится на сайте, не меняйте настройки field group вслепую. Сохранение в админке и вывод в шаблоне - разные этапы. Следующий раздел как раз про это разделение.

Два способа создать поля пользователя: интерфейс и код

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

Настройка через MB Builder

Если в вашей установке доступен визуальный конструктор, рабочий путь обычно выглядит так: открыть Meta Box или Custom Fields, создать field group, добавить поля, перейти в Settings и выбрать Location для пользователей. В документации MB Builder этот Location описан как место, где группа полей относится к posts, terms, users, comments, blocks или settings pages, при этом для каждого типа объекта нужен соответствующий модуль.

Для типового сайта начните с группы "Profile details" или "Contact info". Не смешивайте публичные контактные данные и служебные флаги в одной большой группе. Если редактор видит двадцать разнородных полей, он быстро начинает заполнять их непоследовательно. Лучше создать 2-3 маленькие группы: контакты, статус проверки, медиа или дополнительные сведения.

Какие параметры проверить в интерфейсе

• Location: Должен быть выбран пользователь, иначе группа не появится в профиле.
• Field ID: Должен быть стабильным, коротким и понятным, например broker_phone, а не случайной фразой.
• Field type: Для телефона используйте tel, для города - список, для статуса - select или radio, для изображения - одиночное image-поле.
• Required: Делайте поле обязательным только там, где без него профиль нельзя использовать. Слишком много обязательных полей мешает массовому редактированию пользователей.
• Description: Добавьте короткую подсказку редактору, если значение должно быть в определенном формате.

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

Настройка через PHP

Кодовый вариант похож на создание обычной meta box, но в массиве группы указывается type со значением user. В официальной документации MB User Meta показан пример с контактными полями и кастомным аватаром. Ниже упрощенный фрагмент, который подходит как основа для child theme или небольшого проектного плагина.

add_action( 'rwmb_meta_boxes', function( $meta_boxes ) {
    $meta_boxes[] = [
        'title'  => 'Contact info',
        'type'   => 'user',
        'fields' => [
            [
                'name' => 'Work phone',
                'id'   => 'work_phone',
                'type' => 'tel',
            ],
            [
                'name'    => 'City',
                'id'      => 'city',
                'type'    => 'select_advanced',
                'options' => [
                    'ny' => 'New York',
                    'la' => 'Los Angeles',
                ],
            ],
        ],
    ];

    return $meta_boxes;
} );

Такой код лучше хранить не в файле родительской темы, а в child theme или небольшом site-specific плагине. Тогда обновление темы не сотрет структуру полей. После вставки кода проверьте админку: поле должно появиться в профиле пользователя, а значение должно сохраняться после Update User.

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

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

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

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

Как проектировать поля профиля без будущей путаницы

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

ID поля - главный договор между админкой и шаблоном

ID поля становится точкой связи между сохраненным значением и кодом вывода. Если поле называется "Work phone", а ID work_phone, то именно work_phone вы будете использовать в rwmb_meta(), shortcode, dynamic tag или собственном PHP. Field group ID - это не то же самое. В support-форуме Meta Box есть пример, где пользователь пытался вывести select-значение и путался между field ID и field group ID. Это типичная ошибка.

Правило простое: для вывода конкретного значения нужен ID конкретного поля. Field group ID нужен для группировки полей, форм и некоторых настроек, но он не заменяет meta key отдельного поля.

Выбирайте тип поля под будущий вывод

Если значение будет выводиться как текстовая строка, не усложняйте тип. Для телефона подойдет tel, для короткой должности - text, для биографии - textarea или WYSIWYG, если нужен форматированный текст. Для статуса лучше select или radio, чтобы редактор не писал "verified", "Verify", "проверен" и "ok" в разных профилях.

Для изображения профиля используйте одиночное image-поле и заранее проверьте формат возвращаемого значения. В официальном примере кастомного аватара используется rwmb_meta( 'custom_avatar', [ 'object_type' => 'user' ], $user_id ), а затем берется URL изображения. Но для своего проекта обязательно проверьте фактическую структуру возвращаемого значения, особенно если поле, настройки возврата или версия расширения отличаются.

Не смешивайте публичные и служебные поля

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

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

Где хранятся значения и как получить user meta в шаблоне

Документация MB User Meta подчеркивает, что расширение использует WordPress user meta API и хранит значения похожим образом на post meta. Это важно для совместимости: данные можно получать не только через Meta Box, но и через стандартные функции WordPress, если вы понимаете формат значения.

Получение значения через helper Meta Box

Для пользовательского объекта в rwmb_meta() нужно передать object_type со значением user и ID пользователя. Без этого helper может искать значение не там, где вы его сохранили. Базовый пример выглядит так:

$user_id = get_current_user_id();
$phone = rwmb_meta( 'work_phone', [ 'object_type' => 'user' ], $user_id );

if ( $phone ) {
    echo esc_html( $phone );
}

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

Текущий пользователь, автор записи и произвольный пользователь

• Текущий пользователь: Используйте get_current_user_id(), если выводите личные данные авторизованному человеку.
• Автор записи: Получите ID автора текущей записи и передайте его в helper, если строите авторский блок.
• Произвольный пользователь: Передавайте явный user ID из запроса, списка или административной логики.

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

Когда использовать стандартные функции WordPress

Если значение простое и вы точно знаете meta key, можно использовать get_user_meta(). Это особенно удобно, когда интеграция ожидает обычный WordPress meta key. Но Meta Box может возвращать сложные структуры для изображений, групп, cloneable-полей и некоторых advanced-типов. В таких случаях helper Meta Box часто удобнее, потому что учитывает формат поля.

Не смешивайте способы в одном шаблоне без причины. Если начали получать значение через rwmb_meta(), придерживайтесь этого подхода и документируйте параметры. Если используете get_user_meta(), отдельно проверьте, возвращается ли строка, массив, ID вложения или сериализованная структура.

Практический пример: карточка специалиста с контактами и статусом

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

Цель

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

Подготовка

Перед созданием полей создайте или выберите тестовую учетную запись. На staging-сайте назначьте ей обычную роль, близкую к реальному сценарию. Запишите будущие поля:

• work_phone - рабочий телефон, публичный вывод.
• city - город из заранее заданного списка.
• specialization - короткий текст, публичный вывод.
• verification_status - служебный статус, публично не показывается как сырое значение.

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

1. Создайте field group "Specialist profile".
2. Добавьте поля с понятными подписями и стабильными ID.
3. Для verification_status используйте select с ограниченными вариантами, например pending и verified.
4. В настройках группы выберите Location для пользователей или в коде укажите type => user.
5. Откройте профиль тестового специалиста, заполните поля и сохраните пользователя.
6. Обновите страницу профиля и убедитесь, что значения остались на месте.

После этого можно переходить к шаблону. Не выводите все поля сразу. Сначала сделайте простой диагностический блок в закрытом шаблоне или временно в staging: user ID, значение телефона, значение города, статус. Когда данные подтверждены, уберите диагностику и оформите публичную карточку.

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

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

Мини-итог: настройка считается рабочей только после двух проверок - значение сохраняется в профиле и выводится в нужном месте для правильного user ID.

Нюанс, который часто мешает

Если вы используете конструктор страниц или динамические теги, он может показывать не то значение, которое вы ожидаете. В support-теме Meta Box по выводу custom user meta обсуждалась ситуация, где пользователю пришлось разбираться, какой meta key указывать и чьи данные получает dynamic tag. Поэтому для диагностики держите под рукой простой PHP-проверочный вывод или временный shortcode. Он помогает отделить проблему хранения от проблемы интеграции с конструктором.

Практичные идеи применения на разных типах сайтов

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

Каталог авторов или экспертов

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

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

Площадка продавцов или партнеров

Для e-commerce-сценария user meta может хранить город продавца, контактный канал, статус проверки или служебную отметку "можно показывать в каталоге". Но не превращайте user meta в склад заказов, платежных реквизитов или договоров. Для таких данных нужны отдельные процессы, права доступа и аудит.

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

Закрытый портал или база сотрудников

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

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

Профиль с кастомным аватаром

Официальный tutorial Meta Box показывает сценарий с кастомным аватаром: создается поле изображения для пользователя, затем через код значение подставляется в avatar URL. Это уже не просто настройка поля, а связка user meta и фильтра WordPress. Такой сценарий полезен, если Gravatar не подходит или пользователям нужен локальный профильный снимок.

Но эта идея требует аккуратности: проверьте размер изображения, fallback на стандартный avatar, права загрузки файлов и поведение, если поле пустое. Не делайте аватар обязательным, пока не проверили процесс массового редактирования пользователей.

Проверка результата: админка, база данных, шаблон и кеш

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

Проверка в профиле пользователя

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

Проверка через временный вывод

На staging-сайте можно временно вывести значение в шаблоне или закрытом диагностическом блоке. Для простого поля достаточно получить user ID и значение через rwmb_meta(). Не оставляйте такой вывод на production, если он показывает персональные или служебные данные.

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

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

Проверка интеграций

Если значение выводится через Elementor, Bricks, MB Views или другой инструмент, сначала убедитесь, что само значение доступно через код. Потом проверяйте конкретную интеграцию. Так вы не будете менять field group из-за ошибки в dynamic tag или неверного контекста пользователя.

Безопасный вывод пользовательского поля в шаблоне

Meta Box User Meta часто используют разработчики, поэтому маленький практический snippet здесь уместен. Он не меняет ядро WordPress, не правит файлы расширения и основан на документированном принципе: для user meta в rwmb_meta() нужно передать object_type и user ID.

Пример ниже показывает рабочий телефон автора записи. Добавляйте его в шаблон child theme или в собственный проектный плагин, а не в файл плагина Meta Box. Перед использованием убедитесь, что поле work_phone создано и заполнено у автора.

$author_id = (int) get_the_author_meta( 'ID' );
$work_phone = rwmb_meta( 'work_phone', [ 'object_type' => 'user' ], $author_id );

if ( ! empty( $work_phone ) ) {
    echo '<p class="author-phone">';
    echo esc_html( $work_phone );
    echo '</p>';
}

Проверка: откройте запись тестового автора, заполните поле work_phone в его профиле, обновите страницу записи и убедитесь, что телефон появился только там, где вы вставили блок. Откат простой: удалите фрагмент из шаблона или отключите snippet в Code Snippets. Данные пользователя при этом останутся в профиле, потому что вывод и хранение разделены.

Если нужно добавить стили, используйте CSS вашей темы, например для класса author-phone. Не ориентируйтесь на внутренние классы админки Meta Box, потому что они не должны управлять публичным оформлением сайта.

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

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

Поле не появляется в профиле пользователя

Симптом: field group создана, но на странице редактирования пользователя ничего нового нет.

Возможная причина - группа привязана не к пользователю. В коде проверьте type => user. В интерфейсе проверьте Location. Также убедитесь, что активен именно модуль для user meta, а не только базовый Meta Box. Если вы работаете через визуальный конструктор, отсутствие варианта User часто указывает на недоступное или неактивное расширение.

Исправление: не создавайте дубль field group. Сначала исправьте Location, сохраните группу и обновите профиль пользователя. Если поле появилось, заполните одно значение и проверьте сохранение.

Поле видно, но после сохранения значение исчезает

Симптом: поле можно заполнить, но после Update User оно пустое.

Проверьте тип поля, обязательность, формат значения, права текущего администратора и возможные JavaScript-ошибки. Для advanced-полей с медиа также проверьте доступ к Media Library. Если проблема возникает только у сложного поля, временно создайте простое text-поле в той же группе. Если text сохраняется, проблема связана не с Location, а с конкретным типом поля или его настройками.

Значение не выводится на сайте

Симптом: в профиле значение сохранено, но в шаблоне пусто.

Самая вероятная причина - неверный user ID или пропущенный object_type. Для rwmb_meta() у user meta нужно передать [ 'object_type' => 'user' ] и ID пользователя. Если используете shortcode, support-форум Meta Box показывает похожую логику: нужны параметры object type и object ID.

Исправление: временно выведите ID пользователя, который передаете в helper, и сравните его с ID профиля, где заполнено поле. Если ID совпадает, проверьте field ID. Если ID не совпадает, исправляйте контекст: текущий пользователь, автор записи или пользователь из списка.

Вы перепутали field ID и field group ID

Симптом: редактор видит группу полей, но при выводе ничего не находится.

Field group ID нужен для группы. Field ID нужен для значения. Если поле applicant_status_mb находится внутри группы applicant-status-mb, выводить нужно ID поля. Это особенно важно для select-полей, где дополнительно нужно понимать, возвращается value или label.

Поле ожидают увидеть на экране добавления нового пользователя

Симптом: администратор хочет заполнить custom fields прямо в Users > Add New, но видит только стандартную форму WordPress.

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

Данные устарели из-за кеша или динамического конструктора

Симптом: в профиле уже новое значение, а публичная страница показывает старое.

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

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

Видео по сценарию с кастомным аватаром

У Meta Box есть точный tutorial по созданию пользовательского аватара через кастомное поле пользователя. Видео полезно, если вы хотите увидеть связку "создать поле изображения - назначить Location как User - получить значение через rwmb_meta() - подставить его в avatar URL". Это не заменяет всю настройку Meta Box User Meta, но хорошо закрывает практический intent по user meta и изображению профиля.

После просмотра проверьте у себя три момента: совпадает ли ID поля изображения, выбран ли объект User, и есть ли fallback, если аватар не загружен. Подробности кода лучше сверять с текстовой версией tutorial и документацией, потому что настройки сайта могут отличаться.

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

Meta Box User Meta будет удачным выбором, если вам нужен аккуратный способ добавить custom fields к пользователям WordPress, сохранить данные в native user meta и затем использовать их в шаблоне, каталоге, авторском блоке или служебной логике. Его сильная сторона - не готовая витрина профилей, а управляемая структура пользовательских данных внутри знакомой экосистемы Meta Box.

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

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