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

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

Готове рішення з маркетплейса закриває 70–80% потреб. Решта 20–30% — специфіка бізнесу: інша логіка розрахунку вартості доставки, нестандартні поля у формі замовлення, кастомний зовнішній вигляд під фірмовий стиль, інтеграція з внутрішньою системою обліку. Завдання кастомізації — додати цю специфіку, не зламавши оновлювальність готового рішення.

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

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

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

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

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

Копіювання шаблону для кастомізації:

Оригінал: /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/ не торкається — кастомний шаблон залишається. Bitrix при рендерингу спочатку шукає шаблон в /local/, потім в /bitrix/.

Це працює для template.php, style.css, script.js шаблонів компонентів. Логіка компонента (component.php, class.php) залишається оригінальною.

Кастомізація логіки через події

Для зміни бізнес-логіки без правки файлів модуля використовується система подій Bitrix. Подієва архітектура дозволяє підписатися на дію та модифікувати дані до або після неї.

Приклад: готовий модуль доставки розраховує вартість через подію 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);
    }
}

І реєструєте його замість оригіналу через параметри модуля або через відповідний обробник подій.

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

Частина поведінки готових рішень керується через параметри в b_option (таблиця параметрів Bitrix). Параметри читаються через 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 редиректів
• Статичні методи без подій

У таких випадках залишається або домовитися з вендором про офіційні хуки, або прийняти, що ця частина буде перезаписана при оновленні і описати процедуру відновлення кастомізації.

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