Розробка модуля особистого кабінету 1С-Бітрікс
У Бітріксі є готовий компонент system.auth.registration і сторінки особистого кабінету в поставці, але їх вистачає тільки для найпростішого випадку: змінити ім'я та переглянути замовлення. Як тільки з'являється задача «показати бонусні бали, історію нарахувань, прив'язані картки лояльності, кілька адрес доставки з картою та документи за B2B-договором» — стандартний кабінет стає відправною точкою для переробки, а не готовим рішенням. Ми розробляємо модуль особистого кабінету під ключ: аналізуємо бізнес-процеси, проектуємо архітектуру та реалізуємо всі секції з нуля. Наш досвід — 5+ років та 50+ проектів на Бітрікс, тому ми гарантуємо стабільну роботу навіть при високому навантаженні. Економія на масштабі — до 40% порівняно з погодинним доопрацюванням кожного компонента окремо.
Як розробити особистий кабінет на Бітрікс, який не гальмує?
Базовий кабінет у Бітріксі — набір розрізнених компонентів, кожен з яких звертається до БД самостійно, без загального шару даних. У результаті сторінка профілю може робити 15–20 SQL-запитів при завантаженні. Модуль особистого кабінету будується інакше: один агрегуючий сервіс збирає дані користувача при вході, кешує їх у сесії та віддає всім компонентам з єдиного джерела. Це знижує кількість запитів до 2–3 — різниця в 5–10 разів швидше порівняно зі стандартним підходом.
Архітектура: шари кабінету
Профільний сервіс (UserProfileService) — центральний клас, що інкапсулює всю логіку роботи з даними користувача:
class UserProfileService { private int $userId; private array $cache = []; public function getOrders(array $filter = [], int $page = 1): OrderCollection { return \Bitrix\Sale\OrderTable::getList([ 'filter' => array_merge(['=USER_ID' => $this->userId], $filter), 'order' => ['DATE_INSERT' => 'DESC'], 'limit' => 10, 'offset' => ($page - 1) * 10, ]); } public function getLoyaltyBalance(): int { if (!isset($this->cache['loyalty'])) { $this->cache['loyalty'] = LoyaltyTable::getBalanceForUser($this->userId); } return $this->cache['loyalty']; } } Компоненти кабінету отримують сервіс через DI-контейнер Bitrix\Main\DI\ServiceLocator. Кожен компонент відповідає за одну секцію: замовлення, адреси, налаштування сповіщень, документи.
Роутинг. Для кожної секції — окремий URL (/cabinet/orders/, /cabinet/addresses/, /cabinet/documents/). Реалізується через кастомний обробник у urlrewrite.php або через модуль main з реєстрацією правил через UrlRewriter::setRule.
Детально: керування адресами доставки
Штатно Бітрікс зберігає одну адресу в профілі користувача. Для кількох адрес потрібна власна таблиця:
CREATE TABLE myvendor_user_address ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, label VARCHAR(100), -- "Дім", "Робота" city VARCHAR(100), street VARCHAR(200), building VARCHAR(20), apartment VARCHAR(20), lat DECIMAL(10, 7), lng DECIMAL(10, 7), is_default BOOLEAN DEFAULT false, created_at TIMESTAMP DEFAULT NOW() ); Поля lat / lng заповнюються через Яндекс.Геокодер при збереженні адреси. При оформленні замовлення користувач вибирає адресу зі списку — дані підставляються в b_sale_order_props без ручного введення.
Секція документів для B2B
B2B-користувачі часто запитують рахунки, акти, УПД. Модуль пов'язує документи (генеровані модулем друкованих форм) з профілем користувача через таблицю myvendor_user_document. У кабінеті — фільтрація за типом документа, періодом, статусом, кнопка завантаження PDF. Права на перегляд документів перевіряються через групи користувачів.
Сповіщення
Користувач керує підписками на сповіщення: email, SMS, push. Кожен канал — окремий запис у myvendor_notification_pref. При відправленні сповіщення з бізнес-логіки додаток спочатку перевіряє вподобання користувача, і тільки потім вибирає канал доставки.
Чому модуль кабінету ефективніший за стандартні компоненти?
Стандартний підхід — кожен компонент сам тягне дані. Модуль — єдиний сервіс з кешуванням. Результат: швидкість завантаження сторінок зростає, навантаження на базу падає. Крім того, модуль легко розширювати новими секціями без правки існуючого коду. Порівняння наочно:
| Характеристика | Стандартний кабінет | Модуль кабінету |
|---|---|---|
| SQL-запитів на сторінку | 15–20 | 2–3 |
| Час завантаження (середній) | ~2 сек | ~0,4 сек |
| Підтримка кількох адрес | Ні | Так |
| B2B-документи | Тільки через доопрацювання | Вбудовано |
| Розширюваність | Складна | Проста (новий компонент + секція) |
Безпека кабінету
- Всі операції зміни даних (зміна email, пароля, адреси) вимагають підтвердження через код на email/SMS
- CSRF-захист через стандартний механізм Бітрікс (
bitrix_sessid) - Rate limiting на спроби зміни пароля через таблицю
myvendor_rate_limit - Маскування телефону у відображенні (показувати тільки останні 4 цифри)
Що входить у розробку модуля під ключ
Ми передаємо повний комплект: документацію з архітектури, вихідний код модуля, інструкцію з встановлення, навчання ваших менеджерів, гарантію на виправлення помилок протягом 30 днів. Після здачі надаємо 2 тижні безкоштовної підтримки. Зв'яжіться з нами, щоб оцінити ваш проект — ми надішлемо приблизний кошторис за 1–2 робочі дні. Бюджет формується після аудиту вимог і часто виявляється нижчим, ніж кастомізація стандартних компонентів силами штатного розробника.
Терміни розробки
| Масштаб | Склад | Термін |
|---|---|---|
| Базовий | Профіль + замовлення + кілька адрес | 3–4 тижні |
| Середній | + лояльність + документи + сповіщення | 6–8 тижнів |
| Повний | + B2B-функції + API для мобільного додатку | 10–14 тижнів |
Важливо зафіксувати список секцій кабінету до старту розробки — додавання нової великої секції (наприклад, програми лояльності) в середині проекту вимагає перегляду профільного сервісу та схеми даних. Отримайте консультацію — ми допоможемо скласти ТЗ і прикинути бюджет.
Для поглибленого вивчення архітектури Бітрікс рекомендуємо офіційну документацію та розділ REST API. Також корисно розуміння принципів REST для проектування API.
Розробка модуля особистого кабінету — це системна робота, що потребує досвіду з інфоблоками, HL-блоками та бізнес-процесами. Довірте її команді з сертифікатами 1С-Бітрікс.