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