Кастомизация компонентов 1С-Битрикс без правки ядра: шаблон, result_modifier и component_epilog
Одна из самых дорогих ошибок в поддержке 1С-Битрикс — менять стандартный компонент или файл ядра ради небольшой доработки. Пока проект не обновляется, всё выглядит нормально. После очередного обновления правка исчезает или конфликтует с новой версией платформы.
Большинство изменений публичной части можно сделать без вмешательства в ядро: через собственный шаблон компонента, result_modifier.php, component_epilog.php или отдельный компонент проекта.
Что должно оставаться в template.php
Шаблон отвечает прежде всего за представление: HTML-разметку и минимальную логику вывода. Если внутри шаблона появляются большие запросы к базе, сложные вычисления и изменение данных, поддерживать компонент становится труднее.
Хороший шаблон получает уже подготовленный $arResult и превращает его в интерфейс. Это особенно важно, когда один и тот же компонент используется в нескольких местах с разными шаблонами.
Для чего нужен result_modifier.php
result_modifier.php выполняется перед шаблоном и подходит для подготовки результата: добавить вычисляемое поле, нормализовать массив, получить связанные данные одним запросом или подготовить URL. Благодаря этому HTML остаётся читаемым.
Но здесь важно помнить о кешировании компонента. Если модификатор делает тяжёлый запрос, нужно понимать, когда этот код выполняется и что именно попадает в кеш.
Когда нужен component_epilog.php
component_epilog.php выполняется после шаблона и может использоваться для действий, которые должны происходить после вывода, в том числе при работе компонента с кешем. Чтобы нужные значения были доступны, их заранее добавляют в ключи кеша результата.
Этот механизм полезен, например, когда после формирования компонента нужно установить свойства страницы или выполнить дополнительную логику, которая не должна находиться внутри HTML-шаблона.
Почему копия шаблона безопаснее правки системного
Стандартный шаблон можно скопировать в шаблон сайта и менять уже локальную версию. Тогда обновление платформы не перезапишет файл. При этом разработчик всегда может сравнить локальную копию с актуальным стандартным шаблоном и вручную перенести полезные изменения после крупного обновления.
Когда шаблона уже недостаточно
Если нужно изменить сам алгоритм выборки, добавить новую бизнес-логику или полностью поменять контракт данных, лучше сделать собственный компонент в /local/components/. Попытка решить такую задачу десятками условий в шаблоне обычно заканчивается трудно поддерживаемым кодом.
Что не стоит делать
- редактировать файлы внутри
/bitrix/components/; - выполнять запрос к базе для каждого элемента прямо в цикле шаблона;
- размещать бизнес-логику в HTML;
- копировать огромный стандартный компонент ради изменения одной строки без анализа;
- забывать о кешировании после добавления новых данных в результат.
Практическая структура доработки
- Определите, меняется только отображение или логика получения данных.
- Для отображения создайте собственный шаблон компонента.
- Подготовку данных вынесите в
result_modifier.php. - Пост-обработку, связанную с кешем и страницей, разместите в
component_epilog.php. - Если меняется бизнес-логика компонента — создайте собственный компонент в
/local/. - После изменений проверьте работу с включённым кешем и после очистки кеша.
Чем меньше проект зависит от изменений внутри ядра, тем спокойнее проходят обновления и тем проще передавать сайт другому разработчику.
Перед крупным обновлением полезно отдельно проверить все локальные шаблоны и компоненты. Подробнее о самом процессе обновления — в статье как безопасно обновлять 1С-Битрикс.
Если проект содержит много старых доработок и непонятно, что можно обновлять без риска, поможет технический аудит и поддержка сайта.