Кастомизация готового решения из маркетплейса 1С-Битрикс

Кастомизация готового решения из маркетплейса 1С-Битрикс

Готовое решение из маркетплейса закрывает 70–80% потребностей. Остальные 20–30% — специфика бизнеса: другая логика расчёта стоимости доставки, нестандартные поля в форме заказа, кастомный внешний вид под фирменный стиль, интеграция с внутренней системой учёта. Задача кастомизации — добавить эту специфику, не сломав обновляемость готового решения.

Главная проблема: обновляемость vs кастомизация

Прямое изменение файлов в /bitrix/modules/vendor.modulename/ — самый быстрый способ добиться результата и самый деструктивный. При следующем обновлении модуля через маркетплейс все изменения перезаписываются. Через полгода разработчик модуля выпускает важное обновление безопасности, клиент обновляет — и кастомизация исчезает.

Правильный подход — кастомизация через механизмы расширения, которые Битрикс предоставляет специально для этого.

Кастомизация шаблонов компонентов

Большинство готовых решений выводит данные через стандартные компоненты Битрикс24. Визуальный слой — это шаблон компонента, который хранится отдельно от логики.

Копирование шаблона для кастомизации:

Оригинал: /bitrix/components/vendor/component.name/templates/.default/
Кастом:   /local/templates/SITE_TEMPLATE/components/vendor/component.name/CUSTOM_TEMPLATE/

Или в шаблоне сайта:

/local/templates/my_template/components/vendor/component.name/.default/

При обновлении модуля /local/ не трогается — кастомный шаблон остаётся. Битрикс при рендеринге сначала ищет шаблон в /local/, потом в /bitrix/.

Это работает для template.php, style.css, script.js шаблонов компонентов. Логика компонента (component.php, class.php) остаётся оригинальной.

Кастомизация логики через события

Для изменения бизнес-логики без правки файлов модуля используется система событий Битрикс. Событийная архитектура позволяет подписаться на действие и модифицировать данные до или после него.

Пример: готовый модуль доставки рассчитывает стоимость через событие OnDeliveryGetCost. Кастомный обработчик в /local/php_interface/init.php:

AddEventHandler('sale', 'OnDeliveryGetCost', function(&$arDelivery, &$arOrder, &$arOrderPrice) {
    // Модифицируем стоимость доставки под нашу логику
    if ($arOrder['REGION'] === 'CUSTOM_REGION') {
        $arDelivery['PRICE'] = 0;
    }
    return EventResult::SUCCESS;
});

Популярные события для кастомизации:

• OnBeforeOrderAdd / OnAfterOrderAdd — до и после создания заказа
• OnBeforeIBlockElementAdd / OnAfterIBlockElementUpdate — работа с элементами инфоблока
• OnBeforeUserLoginByHash — кастомная авторизация
• OnAfterUserAuthorize — действия после авторизации

Список доступных событий модуля смотрите в его документации или через grep -r "AddEventHandler\|RegisterModuleDependences" /bitrix/modules/vendor.modulename/.

Кастомизация через наследование классов

Многие современные модули используют ООП и позволяют переопределить классы. Если модуль объявляет класс VendorPaymentHandler extends \Bitrix\Sale\PaySystem\ServiceHandler, вы создаёте собственный класс в /local/:

// /local/lib/CustomPaymentHandler.php
namespace Custom;

class CustomPaymentHandler extends \Vendor\Module\PaymentHandler
{
    public function pay(array $payment): bool
    {
        // Добавляем свою логику до/после стандартной
        $this->logPaymentAttempt($payment);
        return parent::pay($payment);
    }
}

И регистрируете его вместо оригинального через настройки модуля или через соответствующий event handler.

Кастомизация конфигурации через параметры

Часть поведения готовых решений управляется через настройки в b_option (таблица параметров Битрикс). Параметры читаются через COption::GetOptionString('module.name', 'param_name'). Изменить их можно через административный интерфейс модуля или напрямую:

COption::SetOptionString('vendor.modulename', 'custom_param', 'value');

Это самый безопасный способ кастомизации — данные в БД, не затрагивают файлы. Но доступны только те параметры, которые модуль предусмотрел.

Кастомизация через D7-компоненты и маски

В D7-архитектуре (модули, использующие Bitrix\Main) для расширения поведения используются:

• ORM-расширения — добавление полей к существующим таблицам через UserTypeTable или через addCustomSelectFields в запросах
• Маски файлов (.settings.php) — переопределение настроек модуля на уровне сайта
• DI-контейнер (Bitrix\Main\DI\ServiceLocator) — подмена сервисов модуля своими реализациями

Что нельзя кастомизировать без правки ядра

Некоторые вещи в готовых решениях не поддаются кастомизации «правильным» способом:

• SQL-запросы внутри методов класса, которые нельзя переопределить
• Жёстко зашитые URL редиректов
• Статические методы без событий

В таких случаях остаётся либо договориться с вендором об официальных hook'ах, либо принять, что эта часть будет перезаписана при обновлении и описать процедуру восстановления кастомизации.

Сроки кастомизации