UF-поля профиля пользователя в 1С-Битрикс

Штатных полей профиля пользователя — имя, email, телефон — хватает не всегда: интернет-магазину может понадобиться дата рождения для персональных акций, B2B-порталу — название компании и ИНН. Разберём, как добавить пользовательские поля профиля в 1С-Битрикс и вывести их на форме регистрации и личного кабинета.

Создание UF-поля через админку

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

Вывод поля на форме регистрации

Штатная форма регистрации (компонент bitrix:system.auth.form или отдельная страница регистрации) автоматически подхватывает UF-поля, если они помечены как обязательные для заполнения при регистрации, — но для тонкой настройки расположения, подписей и порядка полей часто требуется правка шаблона компонента, поскольку автоматический вывод ограничен базовым набором стилевых решений.

Нужна помощь с Битрикс?

Программное чтение и запись UF-полей

<?php

$user = CUser::GetByID($userId)->Fetch();
echo $user['UF_BIRTHDAY'];

$U = new CUser;
$U->Update($userId, [
    'UF_BIRTHDAY' => '1990-05-15',
    'UF_COMPANY_NAME' => 'ООО Ромашка',
]);

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

Вывод на странице личного кабинета

Для отображения дополнительных полей в личном кабинете (например, компонент bitrix:main.profile) может потребоваться доработка шаблона компонента, если поле было создано уже после первоначальной установки шаблона, — штатный шаблон профиля рассчитан на набор полей, известный на момент его создания, и не подхватывает новые UF-поля автоматически без явной правки.

Валидация значений UF-полей

Для полей типа "Список" значения ограничены заранее заданным набором вариантов автоматически, но для строковых и числовых полей валидация формата (например, корректность ИНН) требует дополнительной проверки — либо через обработчик события OnBeforeUserUpdate, либо на уровне самой формы до отправки данных на сервер.

<?php

use Bitrix\Main\EventManager;

EventManager::getInstance()->addEventHandler(
    'main',
    'OnBeforeUserUpdate',
    function (&$fields) {
        if (isset($fields['UF_INN']) && !preg_match('/^\d{10,12}$/', $fields['UF_INN'])) {
            global $APPLICATION;
            $APPLICATION->ThrowException('Некорректный формат ИНН');
        }
    }
);

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

Не каждое UF-поле должно быть видно другим пользователям на публичной части сайта (например, в комментариях или на форуме, если профиль показывается публично) — стоит явно продумать, какие поля выводятся везде, а какие остаются доступны только самому пользователю и администратору, а не полагаться на то, что настройка видимости происходит автоматически при создании поля.

Миграция и перенос UF-полей между окружениями

UF-поля, созданные через админку на одном окружении, не переносятся автоматически при обычном переносе кода — они хранятся в базе данных, а не в файлах. Для переноса между dev- и боевым окружением нужен либо перенос соответствующих таблиц базы, либо программное создание полей через API в обработчике установки модуля, если поля относятся к собственному функционалу проекта.

Частые ошибки

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

Итог

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

Теги: Пользователи Разработка