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

Мы столкнулись с ситуацией: клиент купил модуль расчёта доставки, но его логика не учитывала скидки по карте лояльности. Штатными средствами — никак. Прямая правка файлов? Обновление модуля уничтожит изменения. Задача кастомизации — добавить эту специфику, не сломав обновляемость готового решения. Подобные задачи составляют 30–40% всех запросов на доработку модулей.

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

Почему обновляемость — ключевой фактор?

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

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

Как кастомизировать шаблоны компонентов?

Большинство готовых решений выводит данные через стандартные компоненты Битрикс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) остаётся оригинальной. В 80% случаев достаточно копирования шаблона или подписки на событие.

Как кастомизировать логику без правки файлов?

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

Пример: готовый модуль доставки рассчитывает стоимость через событие 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.

Что такое D7-расширения и кастомные поля?

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

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

Кастомные поля Битрикс (UserTypeTable) позволяют добавить произвольные свойства к инфоблокам и HL-блокам без правки кода модуля. Это безопасный способ расширения.

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

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

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

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

Что входит в работу?

1. Анализ исходного кода модуля и выявление точек расширения.
2. Разработка кастомных обработчиков событий или переопределённых классов.
3. Тестирование на совместимость с текущей и будущими версиями модуля.
4. Документация изменений (какие файлы/события затронуты).
5. Передача доступов и инструкция по обновлению модуля.
6. Гарантийная поддержка 30 дней после сдачи.

Закажите кастомизацию с гарантией обновляемости — свяжитесь с нами для оценки вашего модуля. Готовая интеграция с 1С через CommerceML может потребовать доработки поведения модуля, и мы это тоже кастомизируем.

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

Если вы не уверены, что ваш модуль можно доработать без потери обновляемости, свяжитесь с нами — мы оценим и предложим решение. Получите консультацию — это бесплатно.