Как я использую события Bitrix, чтобы допиливать логику и не трогать ядро
В Bitrix почти любая «допилка» может быть сделана двумя способами: быстро и грязно (правим ядро, стандартные компоненты, модули) или через события. Первый вариант даёт быстрый эффект и долгую боль. Второй требует чуть больше дисциплины, но зато переживает обновления.
Зачем вообще нужны события
Событие — это точка, в которую Bitrix «зовёт» ваш код: перед сохранением элемента, после оформления заказа, при отправке почты, при авторизации и т.д. Вместо правки стандартного кода мы просто подписываемся на событие и меняем поведение.
В итоге ядро и модули можно спокойно обновлять, а вся кастомная логика живёт в отдельном месте — в /local и своих модулях.
Где я храню обработчики
Исторически люди лепили всё в /bitrix/php_interface/init.php. Я стараюсь от этого уходить:
- завожу свой модуль в /local/modules/ и регистрирую обработчики там
- либо, если проект поменьше, делаю отдельный класс-хранилище и подключаю его из init.php
Важно, чтобы код был не «рассыпан функциями», а собран в классы с адекватными именами. Тогда по логам/ошибкам сразу понятно, где искать поведение.
Базовая схема подключения
Пример для событий инфоблока:
use BitrixMainEventManager;
EventManager::getInstance()->addEventHandler( 'iblock', 'OnBeforeIBlockElementUpdate', ['\Local\Handlers\IBlock', 'onBeforeElementUpdate'] );
А в LocalHandlersIBlock:
class IBlock { public static function onBeforeElementUpdate(array &$fields): void { // ваша логика } }
Ключевой момент — аккуратно работать по ссылке с $fields, не забывать про проверки и не бросать исключения «во всё поле» без нужды.
Типичные кейсы, где события реально выручали Я чаще всего использую:
- события инфоблоков: дополнять/нормализовать данные перед сохранением, синхронизировать сущности
- OnSaleOrderSaved, OnBeforeOrderAdd: автоматическая установка свойств, статусов, прокидывание данных в внешние системы
- события пользователей: при регистрации создавать связанные сущности, отправлять дополнительные письма, проставлять роли
- почтовые события: логировать отправку важных писем, подставлять дополнительные поля
Всё это можно было бы «впихнуть» в шаблоны или модули, но события дают аккуратную точку вмешательства.
Типи**чные ошибки при работе с событиями
Гл**авные грабли:
- вешать тяжёлую логику прямо в событие: внутри OnBefore… гонять сложные запросы, HTTP-запросы, циклы
- регистрировать обработчики в /bitrix/modules, а не в /local
- не логировать ошибки, из-за чего сайт «ведёт себя странно», а причина — в упавшем обработчике
- плодить обработчики в разных местах, вместо одного централизованного модуля
Я стараюсь держать обработчики максимально лёгкими: если нужно что-то тяжёлое, лучше поставить флаг, записать задачу в свою таблицу и обработать её агентом или кроном.
Итог События в Bitrix — это нормальный, «правильный» способ вмешаться в работу системы, не трогая ядро и стандартные модули. Если вынести обработчики в /local, оформить их в модуль и следить за тем, чтобы они оставались лёгкими и предсказуемыми, проект переживает обновления и новые фичи без того самого ощущения, что любое изменение может всё сломать.
