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

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

White-label на Битрикс — это когда компания-разработчик создаёт продукт, который её клиенты продают под своим брендом. Агрегатор туров, платёжный шлюз, CRM-система, маркетплейс — всё это может быть построено как white-label: один код, десятки инсталляций с разным брендингом. Или одна инсталляция с мультитенантностью.

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

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

Мультисайтовость Битрикс (один инстанс, несколько сайтов). Битрикс поддерживает несколько сайтов в рамках одной установки. Каждый сайт — запись в b_lang, отдельный шаблон в /local/templates/{SITE_ID}/, свои настройки в b_option. Данные (товары, пользователи, заказы) могут быть общими или разделёнными по сайтам.

Подходит когда:

• Клиентов мало (до 20–30 сайтов)
• Данные частично общие (единый каталог, разные цены)
• Одна команда администрирует все сайты

Раздельные инсталляции. Каждый клиент получает независимую установку Битрикс. Общая кодовая база поставляется как модуль или через Git. Обновления раскатываются отдельно на каждый инстанс.

Подходит когда:

• Клиенты хотят независимость (свои данные, свои бэкапы)
• Разная конфигурация под каждого клиента
• Требования к изоляции данных (GDPR, медицина)

Мультитенантность в рамках одной инсталляции

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

• Таблица 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/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            # подключение автолоадера

Преимущество: модуль обновляется через стандартный механизм Битрикс (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 продукта должен управлять своим экземпляром. Это не стандартная админка Битрикс — она избыточна и небезопасна для внешних пользователей. Строится отдельный «личный кабинет партнёра»:

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

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

Обновление кодовой базы

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

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

При единой инсталляции обновление проще — один деплой.

Изоляция данных между тенантами

Критичный вопрос безопасности: данные тенанта A не должны быть видны тенанту B. Во всех запросах к инфоблокам добавляется обязательный фильтр по SITE_ID или по кастомному полю TENANT_ID:

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

Для критичных данных (платёжная информация, персональные данные) рекомендуется разделение баз данных между тенантами — каждый тенант работает со своей схемой PostgreSQL. Битрикс не поддерживает это из коробки, но через переключение $DB объекта в начале каждого запроса это реализуемо.

Сроки

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