Личный кабинет — это не одна страница, а раздел из нескольких компонентов: профиль, история заказов, адреса доставки, подписки. В 1С-Битрикс большая часть этого есть в готовом виде, и собирается кабинет в основном из штатных компонентов.
Разберём структуру раздела, какие компоненты за что отвечают, как ограничить доступ и что стоит добавить сверх стандартной поставки.
Что должно быть в кабинете
Набор зависит от типа сайта:
| Раздел | Корпоративный сайт | Интернет-магазин |
|---|---|---|
| Профиль | Да | Да |
| Смена пароля | Да | Да |
| История заказов | — | Да |
| Адреса доставки | — | Да |
| Корзина и отложенные | — | Да |
| Подписки на рассылки | Да | Да |
| Документы и счета | Иногда | Для юрлиц |
Начинать разумно с минимума: профиль, смена пароля и заказы. Остальное добавляется тогда, когда становится понятно, чем люди реально пользуются.
Структура раздела
Стандартное расположение — папка /personal/ в корне сайта:
/personal/
index.php главная кабинета
profile/ профиль
orders/ история заказов
address/ адреса доставки
subscribe/ подписки
.section.php свойства раздела
Раздел удобно оформить собственным шаблоном сайта: у кабинета обычно другая навигация и нет лишних маркетинговых блоков. Как это настроить, описано в статье Свой шаблон для конкретного раздела сайта.
Нужна помощь с Битрикс?
Ограничение доступа
Кабинет должен быть закрыт для неавторизованных. Самый простой способ — проверка в начале страницы:
<?php
require($_SERVER['DOCUMENT_ROOT'] . '/bitrix/header.php');
global $USER;
if (!$USER->IsAuthorized()) {
LocalRedirect('/auth/?backurl=' . urlencode($APPLICATION->GetCurPageParam()));
}
?>
Параметр backurl важен для удобства: после входа человек попадёт
туда, куда шёл, а не на главную.
Более правильный путь — настроить права доступа на раздел через структуру сайта: тогда проверка не дублируется на каждой странице. Механика описана в статье Права доступа в Битрикс.
Готовые компоненты
Комплексный компонент кабинета
Самый быстрый вариант для магазина — комплексный компонент
bitrix:sale.personal.section. Он разворачивает сразу весь набор страниц
с собственной навигацией:
<?$APPLICATION->IncludeComponent(
'bitrix:sale.personal.section',
'main',
[
'SEF_MODE' => 'Y',
'SEF_FOLDER' => '/personal/',
'SHOW_ORDERS' => 'Y',
'SHOW_ACCOUNT' => 'N',
'SHOW_PROFILE' => 'Y',
'SHOW_SUBSCRIBE' => 'Y',
'SHOW_PRIVATE' => 'Y',
]
)?>
Плюс — всё работает сразу. Минус — меньше контроля над версткой и структурой URL.
Отдельные компоненты
Гибче собрать кабинет из частей:
| Компонент | Назначение |
|---|---|
bitrix:main.profile | Редактирование профиля |
bitrix:sale.personal.order.list | Список заказов |
bitrix:sale.personal.order.detail | Карточка заказа |
bitrix:sale.personal.address | Адреса доставки |
bitrix:subscribe.edit | Управление подписками |
bitrix:system.auth.changepasswd | Смена пароля |
Профиль пользователя
Компонент профиля выводит и стандартные поля, и пользовательские:
<?$APPLICATION->IncludeComponent(
'bitrix:main.profile',
'main',
[
'SET_TITLE' => 'Y',
'SEND_INFO' => 'N',
'CHECK_RIGHTS' => 'Y',
'USER_PROPERTY' => ['UF_PHONE', 'UF_COMPANY'],
]
)?>
Про добавление своих полей есть отдельный материал Пользовательские поля UF_ в Битрикс.
Важный момент: не выводите в профиле поля, которые пользователь не должен менять. Скидка, статус клиента, внутренние отметки менеджера — всё это должно быть скрыто, иначе человек изменит их сам.
История заказов
Для магазина это главный экран кабинета. Что стоит показывать в списке: номер, дату, сумму, статус и, отдельно, статус оплаты.
Что обычно приходится доделывать:
- Понятные названия статусов. Системные формулировки вроде «Принят, ожидается оплата» стоит заменить на человеческие.
- Повтор заказа. Кнопка «Заказать снова» заметно увеличивает повторные покупки.
- Ссылка на оплату для неоплаченных заказов.
- Отслеживание доставки — номер накладной со ссылкой на перевозчика.
Смена пароля и безопасность
Кабинет — это персональные данные, и минимальные требования такие:
- раздел работает только по HTTPS;
- смена пароля требует ввода текущего;
- при смене адреса почты отправляется подтверждение;
- сессия завершается по неактивности;
- пользователь видит только свои заказы — проверка на стороне сервера.
Последний пункт критичен. Если карточка заказа открывается по идентификатору из адресной строки без проверки владельца, любой авторизованный пользователь сможет посмотреть чужие заказы, подставив другой номер. Штатные компоненты проверку делают, а вот самописные страницы — далеко не всегда.
Проверка перед запуском
- Кабинет недоступен без авторизации — проверьте в режиме инкогнито.
- После входа происходит возврат на нужную страницу.
- Профиль сохраняется, изменения применяются.
- Заказы отображаются, и только свои.
- Попробуйте открыть чужой заказ по идентификатору — должно быть отказано.
- Смена пароля работает и требует текущий.
- Кабинет удобен на мобильном.
- Выход завершает сессию.
Пятый пункт стоит проверить обязательно, даже если используются штатные компоненты, — это самая дорогая из возможных ошибок в кабинете.
Частые ошибки
- Нет проверки владельца заказа. Чужие заказы открываются подстановкой идентификатора.
- Служебные поля доступны для редактирования. Пользователь меняет себе скидку.
- После входа переброс на главную. Человек не понимает, куда делась нужная страница.
- Кабинет работает по HTTP. Персональные данные передаются открыто.
- Системные статусы заказов без расшифровки. Покупатель звонит менеджеру, чтобы понять, что происходит.
- Кабинет не адаптирован. Половина посетителей заходит с телефона.
Итог
Личный кабинет в 1С-Битрикс собирается из штатных компонентов: комплексного
sale.personal.section для быстрого старта или отдельных компонентов
профиля, заказов и адресов — когда нужен контроль над вёрсткой и адресами.
Технически кабинет несложен, и основное внимание стоит уделить двум вещам: проверке, что пользователь видит только свои данные, и понятности интерфейса — прежде всего человеческим названиям статусов заказа.
