Компонент main.profile Битрикс отвечает за страницу личного кабинета: форму с ФИО, e‑mail, телефоном, аватаром и сменой пароля. На большинстве сайтов на 1С-Битрикс он уже подключён в personal.php, который создаёт мастер сайта или разработчик шаблона, и в базовом виде работает без единой правки. Вопросы начинаются, когда нужно добавить своё поле, спрятать смену пароля для пользователей, авторизованных через соцсеть, или ограничить видимость профиля по группе. Ниже - как я обычно настраиваю main.profile на практике, какие параметры реально стоит трогать и на чём чаще всего спотыкаются при доработке.
Что делает компонент main.profile и когда с ним работают
main.profile входит в модуль main и выводит форму редактирования данных текущего авторизованного пользователя: имя, фамилию, отчество, e‑mail, телефон, дату рождения, пол, аватар, рабочую информацию (компания, должность) и блок смены логина с паролем. Отдельно он показывает уведомление, если e‑mail не подтверждён, и форму подтверждения, если в модуле включена такая проверка.
Компонент рассчитан на неавторизованных пользователей вернуться на форму входа - без сессии он просто не отдаёт данные для редактирования. Это стандартное поведение всей связки auth-компонентов main.profile, main.register и main.session_change_password, они используют общий набор параметров и одну логику проверки прав.
На практике с main.profile работают в трёх случаях: нужно добавить в форму собственное поле пользователя, нужно поменять состав видимых блоков (например, убрать смену пароля для клиентов, которые всегда заходят через Госуслуги или соцсеть), либо нужно перерисовать шаблон под дизайн личного кабинета, а не под стандартную бутстрап-вёрстку.
Где лежит компонент и как вывести его на странице профиля
Файлы компонента лежат в /bitrix/components/bitrix/main.profile/, шаблон по умолчанию - в подпапке templates/.default. Трогать эти файлы напрямую нельзя: любое обновление модуля main их перезапишет. Если нужно поменять вёрстку, шаблон копируют в /local/templates/имя_шаблона/components/bitrix/main.profile/.default/ и правят уже там - Битрикс сам подхватит переопределённый шаблон при следующем вызове компонента.
Подключение выглядит так же, как у любого другого компонента через CMain::IncludeComponent:
<?
$APPLICATION->IncludeComponent(
"bitrix:main.profile",
".default",
array(
"SET_TITLE" => "Y",
"CHECK_RIGHTS" => "Y",
"SEND_INFO" => "N",
"USE_PHONE_AUTH" => "N",
"AJAX_MODE" => "N",
"SEF_MODE" => "N",
)
);
?>
Этот вызов обычно уже стоит в personal.php, который генерирует установщик сайта или который приносит с собой купленный шаблон. Мне чаще приходится не создавать вызов заново, а находить его в существующем шаблоне и подстраивать параметры под задачу - искать стоит именно по строке bitrix:main.profile в файлах вашего шаблона сайта.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Параметры main.profile, которые реально нужны
У компонента параметров немного, и большинство сайтов работает на дефолтных значениях. На практике я трогаю обычно пять из них.
| Параметр | Что делает | Когда меняю |
|---|---|---|
| SET_TITLE | Подставляет заголовок страницы через API рабочей области | Отключаю (N), если заголовок уже задан в свойствах инфоблочной страницы |
| CHECK_RIGHTS | Проверяет, что редактировать профиль может только сам пользователь или админ | Оставляю Y почти всегда, отключение открывает чужие данные |
| SEND_INFO | Включает блок рабочей информации (компания, должность, доп. телефон) | Включаю для b2b-кабинетов, отключаю для розничного интернет-магазина |
| USE_PHONE_AUTH | Переключает форму на сценарий авторизации по номеру телефона | Включаю, если сайт использует вход по коду из СМС вместо логина и пароля |
| AJAX_MODE | Отправляет форму без перезагрузки страницы | Включаю, когда профиль встроен в одностраничный личный кабинет |
Параметры SEF_MODE, SEF_FOLDER и SEF_URL_TEMPLATES управляют ЧПУ у вложенных экранов компонента (смена пароля, подтверждение e‑mail). Их трогают редко - только если у сайта в принципе включён ЧПУ-режим и вложенные урлы профиля должны выглядеть человеко-читаемо, а не через GET-параметры.
Добавляем свои поля профиля через UF
Для нестандартных полей в профиле не нужно лезть в код компонента - в Битриксе для этого есть пользовательские свойства. Поле создаётся в административной панели: Настройки - Пользователи - Поля пользователей - Добавить поле. Код поля обязан начинаться с префикса UF_, например UF_TELEGRAM или UF_INN.
У нового поля в настройках есть флаг «Отображать в анкете пользователя» (или «показывать в профиле» в зависимости от редакции) - если он включён, main.profile сам подхватывает поле и рисует его в форме вместе со стандартными, без единой правки шаблона. Это касается текстовых, числовых полей, списков и полей типа «файл» - последнее удобно, если нужно собирать скан документа прямо в профиле.
Если поле нужно провалидировать перед сохранением (например, проверить формат ИНН или уникальность телеграм-ника), логику вешают на события модуля main - OnBeforeUserUpdate для проверки и блокировки сохранения при ошибке, OnAfterUserUpdate для действий уже после того, как данные записаны (отправить уведомление, синхронизировать с CRM). Обработчики регистрируются в init.php через AddEventHandler - это тот же механизм, что используется для любых других хуков модуля main, включая обработку заказов и авторизации.
Права доступа и проверка CHECK_RIGHTS
Параметр CHECK_RIGHTS не декоративный. Он не даёт пользователю А открыть чужой профиль, подставив чужой ID в GET-параметр URL. Отключать его стоит только на служебных страницах, куда и так не попадает никто, кроме администратора с уже проверенными правами - например, на внутренней странице редактирования сотрудников в закрытом разделе интранета.
Отдельно от CHECK_RIGHTS работают права на уровне групп пользователей. Если часть полей должна редактироваться только менеджером, а не самим клиентом (типичный случай - скидочный статус или привязанный к клиенту менеджер), это не параметр компонента, а логика уже вашего кастомного поля или отдельной формы в админке: пользовательское UF-поле можно вообще не выводить в профиле, а редактировать только через административный раздел «Пользователи», ограничив к нему доступ через стандартные права модуля.
Кастомизация шаблона и типичные ошибки
Самая частая ошибка - правки прямо в /bitrix/components/bitrix/main.profile/templates/.default/. Работает до первого обновления модуля main, после которого файлы стандартного шаблона перезаписываются и правки пропадают без следа. Второй по частоте случай - забытая проверка CHECK_RIGHTS после того, как компонент скопировали для кастомной страницы и на радостях отключили «чтобы не мешало» при отладке, а потом забыли включить обратно.
Третья ошибка - завязывать видимость полей на уровне вёрстки шаблона, просто скрывая блок стилями, а не на уровне параметров UF-поля или прав доступа. Такое поле по-прежнему приходит в форму и в POST-запросе, и его можно отправить в обход интерфейса напрямую - если поле не должно редактироваться пользователем, его нужно либо не выводить в профиле вообще, либо проверять в обработчике OnBeforeUserUpdate.
Если правки нужно делать регулярно - добавление полей под новые задачи бизнеса, синхронизация профиля с CRM, доработка формы под новый дизайн - удобнее не тратить время на разбор чужого шаблона самому, а отдать это на техническую поддержку сайта на Битрикс: там же обычно решаются смежные вопросы вроде миграции полей после обновления модуля или чистки конфликтующих обработчиков событий.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Чем main.profile отличается от main.register?
main.register выводит форму регистрации нового пользователя и создаёт запись в базе, а main.profile работает только с уже авторизованным пользователем и редактирует существующую запись. У обоих компонентов похожий набор параметров, потому что они построены на одной внутренней логике модуля main, но применяются на разных этапах: register до входа на сайт, profile после.
Как убрать блок смены пароля из формы профиля?
Готового параметра «скрыть смену пароля» у компонента нет, поэтому блок скрывают в переопределённом шаблоне (копия .default в /local/templates/) - там это просто удаление или условное скрытие соответствующего фрагмента вёрстки. Для пользователей, авторизованных только через внешний сервис, логичнее не показывать блок по условию, а не прятать его для всех.
Почему добавленное поле не появляется в форме профиля?
Чаще всего дело в невключённом флаге показа поля в анкете пользователя в настройках UF-поля, либо в закэшированном компоненте на странице - у main.profile может быть включено кэширование через общие настройки шаблона, и после добавления поля кэш нужно сбросить вручную через админку. Реже причина в том, что переопределённый шаблон в /local/templates/ старее актуального и не содержит вывод новых полей.
Можно ли вывести профиль без отдельной страницы личного кабинета?
Да, компонент можно встроить в любую существующую страницу или в блок другого раздела - он не привязан жёстко к personal.php, это просто соглашение, которое использует стандартный шаблон сайта. Достаточно вызвать IncludeComponent в нужном месте шаблона с параметрами CHECK_RIGHTS и AJAX_MODE под конкретный сценарий - например, во вкладке личного кабинета рядом с историей заказов.