Розробка white-label рішення на 1С-Бітрікс

Розробка white-label рішення на 1С-Bitrix

White-label на Bitrix — це коли компанія-розробник створює продукт, який її клієнти продають під своїм брендом. Агрегатор турів, платіжний шлюз, CRM-система, маркетплейс — усе це може бути побудовано як white-label: один код, десятки інсталяцій з різним брендингом. Або одна інсталяція з мультитенантністю.

Ключове технічне питання на старті: одна кодова база для всіх клієнтів чи окремий інстанс для кожного?

Дві архітектурні моделі

Мультисайтовість Bitrix (один інстанс, кілька сайтів). Bitrix підтримує кілька сайтів у рамках однієї установки. Кожен сайт — запис у b_lang, окремий шаблон у /local/templates/{SITE_ID}/, власні налаштування в b_option. Дані (товари, користувачі, замовлення) можуть бути спільними або розділеними за сайтами.

Підходить коли:

• Клієнтів мало (до 20–30 сайтів)
• Дані частково спільні (єдиний каталог, різні ціни)
• Одна команда адмініструє всі сайти

Окремі інсталяції. Кожен клієнт отримує незалежну установку Bitrix. Спільна кодова база постачається як модуль або через Git. Оновлення розкочуються окремо на кожен інстанс.

Підходить коли:

• Клієнти хочуть незалежності (власні дані, власні бекапи)
• Різна конфігурація під кожного клієнта
• Вимоги до ізоляції даних (GDPR, медицина)

Мультитенантність у рамках однієї інсталяції

Для агрегаторів і SaaS-продуктів на Bitrix будується мультитенантна архітектура:

• Таблиця b_lang — кожен сайт (тенант) з унікальним LID
• Шаблони — спільний базовий шаблон (/local/templates/base/) + перевизначення в /local/templates/{TENANT_ID}/
• Налаштування тенанта — кастомна таблиця b_tenant_settings з парами TENANT_ID / KEY / VALUE
• Користувачі — спільна таблиця b_user, розділення за групами та за SITE_ID

Брендування кожного тенанта:

// В init.php або в header шаблону
$tenantId   = SITE_ID; // LID поточного сайту
$tenantConf = TenantSettingsTable::getByTenantId($tenantId);

define('TENANT_PRIMARY_COLOR', $tenantConf['PRIMARY_COLOR'] ?? '#0052cc');
define('TENANT_LOGO_URL',      $tenantConf['LOGO_URL'] ?? '/logo.svg');
define('TENANT_DOMAIN',        $tenantConf['DOMAIN']);

CSS-змінні генеруються динамічно через PHP, кешуються на рівні сторінки:

// Динамічний CSS із кольорами тенанта
$css = ":root { --primary: " . TENANT_PRIMARY_COLOR . "; --brand-font: " . $tenantConf['FONT'] . "; }";

Розробка ядра продукту як Bitrix-модуля

Якщо код продукту постачається кільком клієнтам, його краще оформити як модуль Bitrix. Модуль встановлюється через /bitrix/admin/partner_modules.php, реєструється в b_module:

/local/modules/vendor.whitelabel/
├── install/
│   ├── index.php          # встановлювач модуля
│   └── db/install.sql     # створення кастомних таблиць
├── lib/
│   ├── TenantManager.php
│   ├── BrandingService.php
│   └── ...
├── options.php            # налаштування модуля в адмінці
└── include.php            # підключення автолоадера

Перевага: модуль оновлюється через стандартний механізм Bitrix (ModuleManager::isModuleInstalled(), ModuleManager::install()), аналогічно стандартним модулям.

Розмежування функціональності за тарифами

White-label часто передбачає тарифні плани: базовий, стандарт, преміум. Кожен тарифний план відкриває/закриває частину функціоналу.

Перевірка доступності фічі:

// TenantLicenseManager.php
public static function hasFeature(string $feature, string $tenantId = SITE_ID): bool {
    $plan = self::getTenantPlan($tenantId); // 'basic' | 'standard' | 'premium'
    $features = self::PLAN_FEATURES[$plan] ?? [];
    return in_array($feature, $features, true);
}

// У коді компонента або контролера
if (!TenantLicenseManager::hasFeature('advanced_analytics')) {
    // Показуємо заглушку або редирект на сторінку апгрейду
}

Матриця фіч зберігається в коді (константа-масив) або в БД. Зміни тарифу застосовуються без деплою — тільки оновлення запису в b_tenant_settings.

Адміністративний інтерфейс для клієнтів

Клієнт white-label продукту повинен керувати своїм екземпляром. Це не стандартна адмінка Bitrix — вона надлишкова й небезпечна для зовнішніх користувачів. Будується окремий «особистий кабінет партнера»:

• Управління брендингом (завантаження логотипу, вибір кольорів)
• Управління користувачами свого тенанта
• Перегляд статистики та аналітики
• Налаштування сповіщень та інтеграцій

Реалізація — окремий розділ сайту з авторизацією за групою користувачів TENANT_ADMIN. Компоненти в /local/components/vendor.whitelabel/tenant.admin.*.

Оновлення кодової бази

Підтримка кількох інсталяцій — найскладніше операційне завдання. При окремих інстансах потрібна система автоматичного деплою оновлень:

• Git-репозиторій із кодом модуля/шаблонів
• CI/CD (GitLab CI, GitHub Actions) з розкочуванням на кожен сервер через SSH або Ansible
• Версіонування: модуль має VERSION в install/index.php; перед оновленням перевіряється сумісність із версією Bitrix на сервері клієнта

При єдиній інсталяції оновлення простіше — один деплой.

Ізоляція даних між тенантами

Критичне питання безпеки: дані тенанта A не повинні бути видимі тенанту B. У всіх запитах до інфоблоків додається обов'язковий фільтр за SITE_ID або за кастомним полем TENANT_ID:

// Базова вибірка з обов'язковою фільтрацією за тенантом
$filter = array_merge($userFilter, ['=PROPERTY.TENANT_ID' => CURRENT_TENANT_ID]);
$res = CIBlockElement::GetList([], $filter, ...);

Для критичних даних (платіжна інформація, персональні дані) рекомендується розділення баз даних між тенантами — кожен тенант працює зі своєю схемою PostgreSQL. Bitrix не підтримує це «з коробки», але через перемикання об'єкта $DB на початку кожного запиту це реалізовується.

Терміни

White-label на Bitrix — нестандартне застосування платформи, що вимагає глибокого розуміння її архітектури. При правильному проєктуванні система масштабується від 5 до 500 клієнтів без переписування ядра.