Заказчик просит «чуть поменять вывод каталога», и рука тянется открыть файл компонента прямо в /bitrix/components и поправить. Работает — до первого обновления платформы, которое молча затирает все ваши правки, и каталог возвращается к исходному виду. Правка ядра — это техдолг, который обязательно взорвётся: то при апдейте, то при переносе на другой стенд, то при попытке разобраться, почему сайт ведёт себя не так, как в документации.
Эта статья — практическое руководство по правильной кастомизации компонентов 1С-Битрикс через шаблоны, без единой правки ядра. Разберём копирование шаблона, result_modifier, component_epilog, свои параметры и наследование класса компонента. Такой подход мы применяем во всех проектах и закладываем в автоматизацию на 1С и доработку сайтов, чтобы код переживал обновления.
Коротко
- Никогда не правьте файлы в /bitrix — обновления их затрут; вся кастомизация живёт в /local.
- Для внешнего вида достаточно скопировать шаблон компонента и менять его.
- Данные готовьте в result_modifier.php, вёрстку держите в template.php, а код вне кэша — в component_epilog.php.
- Логику компонента меняйте наследованием class.php, а не правкой оригинала.
Почему правка ядра — это ловушка
Соблазн понятен: открыть системный файл и быстро поправить кажется самым коротким путём. Но у правки ядра три фатальных последствия. Первое — обновления. При апдейте платформы или модуля системные файлы перезаписываются, и ваши изменения исчезают без следа. Второе — хрупкость: правка в общем компоненте влияет на весь сайт, и ошибка ломает всё разом. Третье — непрозрачность: следующий разработчик не ожидает изменений в ядре и потратит часы, разбираясь, почему поведение отличается от документации.
1С-Битрикс с самого начала спроектирован так, чтобы кастомизация не требовала правки ядра. Есть штатные точки расширения — шаблоны, модификаторы результата, эпилоги, наследование классов, события. Задача разработчика — знать эти точки и использовать их, а не ломать систему обновлений ради минутной экономии.
Как устроен компонент и его шаблон
Чтобы кастомизировать грамотно, нужно понимать разделение ответственности внутри компонента. Компонент 1С-Битрикс — это две части: логика и представление.
- Логика (component.php / class.php). Получает данные, формирует массив
$arResult, управляет кэшированием. Это «мозг» компонента. - Шаблон (template.php и соседние файлы). Отвечает за то, как
$arResultпревращается в HTML. Это «внешность» компонента.
Ключевая идея: логику компонента менять нужно редко, а вот шаблон — почти всегда. Поэтому основной инструмент кастомизации — работа с шаблоном, где живут template.php, result_modifier.php, component_epilog.php, style.css, script.js и .parameters.php. Понимание этого разделения избавляет от лишнего копирования логики там, где достаточно поменять вывод.
Копирование шаблона в /local
Базовый приём кастомизации — не трогать системный шаблон, а сделать его копию в своей теме. Битрикс ищет шаблон компонента сначала в вашей теме, и если находит там — использует его вместо системного.
- Найдите системный шаблон. Он лежит в
/bitrix/components/…/templates/.default(или в шаблоне сайта). - Скопируйте его в /local. В
/local/templates/ваш_шаблон/components/…с тем же путём компонента. - Дайте своё имя шаблону. Не
.default, а осмысленное — напримерcatalog-custom. - Укажите шаблон в вызове компонента. В параметре
TEMPLATEпропишите своё имя. - Меняйте копию. Теперь правки идут в вашем файле, оригинал нетронут и переживёт обновления.
Каталог /local — принципиально важен: это ваша зона, которую обновления платформы не трогают. Всё кастомное — шаблоны, компоненты, модули, обработчики — держат именно там, отделяя свой код от системного и упрощая перенос между стендами.
result_modifier.php: подготовка данных
Первое, что осваивают при кастомизации шаблона, — файл result_modifier.php. Он выполняется до template.php и предназначен для того, чтобы дополнить или преобразовать массив $arResult перед выводом. Именно сюда выносят всю подготовку данных.
- Форматирование. Приведение цен, дат, единиц измерения к нужному виду.
- Дополнительные данные. Подтягивание свойств, остатков, связанных элементов, которых нет в базовом результате.
- Реструктуризация. Перестройка массива в удобную для вывода форму.
Смысл в разделении: result_modifier отвечает за «что выводим», template.php — за «как выводим». Когда логика подготовки данных вынесена из вёрстки, шаблон остаётся читаемым, а изменения данных не превращаются в поиск по HTML. Это чистый, поддерживаемый способ обогащать вывод компонента.
template.php: чистая вёрстка
Файл template.php должен содержать преимущественно разметку и минимум логики — только то, что напрямую связано с выводом: циклы по элементам, условия отображения, вставку подготовленных данных. Тяжёлые вычисления, запросы к базе и подготовку структур сюда тащить не нужно — для этого есть result_modifier.
Такое разделение окупается при поддержке: верстальщик правит внешний вид, не боясь задеть логику, а разработчик меняет данные, не копаясь в разметке. Чем чище template.php, тем дешевле дальнейшие изменения. Хорошая привычка — относиться к шаблону как к слою представления, куда данные приходят уже готовыми.
component_epilog.php: код вне кэша
Ключевой нюанс, на котором спотыкаются новички, — кэширование. Компонент кэшируется целиком, включая result_modifier и template.php. Это значит, что код в них выполняется только при пересборке кэша, а не на каждом хите. Для данных каталога это хорошо, но есть код, который должен работать всегда.
Для этого существует component_epilog.php — он выполняется после кэша, на каждом запросе. Сюда помещают то, что зависит от текущего момента и пользователя:
- Заголовок страницы и SEO. Установка title, description, хлебных крошек.
- Работа с текущим пользователем. Персональные данные, которые нельзя кэшировать на всех.
- Счётчики и аналитика. Код, который должен отрабатывать каждый визит.
result_modifier. Он закэшируется вместе с компонентом, и на всех страницах будет «застывший» title от первого закэшированного элемента. Такой код — только в component_epilog.php.
Свои параметры через .parameters.php
Иногда шаблону нужны собственные настройки, которые редактор сможет менять из административной панели без правки кода: количество выводимых элементов, режим отображения, включение блока. Для этого в шаблоне создают файл .parameters.php, где описывают дополнительные параметры.
Эти параметры появляются в настройках компонента рядом со стандартными и доступны в шаблоне через $arParams. Так вы делаете кастомизацию управляемой: контент-менеджер настраивает поведение блока через привычный интерфейс, а не зовёт разработчика ради каждой мелочи. Это особенно ценно для типовых блоков, которые ставятся на многих страницах с разными настройками.
Переопределение class.php наследованием
Всё вышеперечисленное меняет представление. Но иногда нужно изменить саму логику компонента — например, как он выбирает данные. Править class.php в ядре по-прежнему нельзя. Правильный путь — наследование: создают свой компонент, класс которого расширяет оригинальный, и переопределяют только нужные методы.
Так вы меняете конкретное поведение, оставляя остальное как в оригинале и сохраняя совместимость с обновлениями. Это более глубокая кастомизация, и применять её стоит осознанно — когда задачу действительно не решить через шаблон и модификатор результата. Похожие принципы наследования и расширения лежат в основе разработки собственных модулей; для сложной бизнес-логики нередко именно свой модуль оказывается чище, чем нагромождение наследников компонентов.
Стили, скрипты и ассеты шаблона
Шаблон компонента — это не только PHP, но и свои style.css и script.js. Битрикс автоматически подключает эти файлы, если они лежат в папке шаблона, и умеет собирать их в общий набор страницы. Держать стили и скрипты рядом с шаблоном — правильная практика: кастомизация становится самодостаточной.
- style.css. Стили конкретного шаблона подключаются автоматически.
- script.js. Поведение компонента — здесь, а не в глобальных файлах темы.
- Локальность. Всё, что нужно шаблону, лежит в его папке и переносится вместе с ним.
Кэширование при кастомизации
Кастомизация не должна ломать кэш — иначе вы улучшите вид, но обрушите скорость. Помните базовые правила: result_modifier и template.php кэшируются, component_epilog — нет. Если ваша доработка тянет тяжёлые запросы, держите их внутри кэшируемой части, а не в эпилоге, который выполняется на каждом хите.
При работе с персональными и часто меняющимися данными используют композитный кэш и отложенную загрузку динамики поверх статики. Как выстроить быструю выдачу и не потерять скорость при кастомизации, мы подробно разбираем в материалах про инфраструктуру на BitrixVM — окружение и кэш тесно связаны с тем, как ведёт себя кастомизированный компонент под нагрузкой.
Перенос и деплой кастомизаций
Кастомизация в /local хороша ещё и тем, что её удобно версионировать и переносить между стендами. Весь ваш код лежит в одном каталоге, отделённом от системного, и укладывается под систему контроля версий целиком. Обновление платформы меняет /bitrix, а ваш /local остаётся под вашим контролем.
На проектах с несколькими стендами (разработка, тест, боевой) это критично: кастомизации переносятся предсказуемо, без ручного копирования файлов из ядра. Как организовать надёжный перенос и автоматический деплой, мы описали в статье про CI/CD и деплой в Битрикс. Дисциплина «весь кастом в /local под git» превращает кастомизацию из источника хаоса в управляемый процесс.
Частые ошибки
- Правка файлов в /bitrix. Обновление затирает изменения, каталог возвращается к исходному виду.
- Логика в template.php. Тяжёлые запросы в вёрстке вместо result_modifier.
- Заголовок в result_modifier. Кэшируется и «застывает» на всех страницах.
- Копирование всего компонента ради вида. Достаточно скопировать шаблон, а не логику.
- Кастом в /bitrix/templates вместо /local. Смешивание своего и системного кода.
- Тяжёлый код в component_epilog. Выполняется на каждом хите и убивает скорость.
- Кастомизация вне контроля версий. Изменения непрозрачны и теряются при переносе.
Чек-лист кастомизации
- Ядро не тронуто. Ни одной правки в /bitrix/components и /bitrix/modules.
- Кастом в /local. Шаблоны, компоненты и обработчики лежат отдельно от системного кода.
- Данные в result_modifier. Подготовка вынесена из template.php.
- Некэшируемое в эпилоге. Заголовки, персонализация и счётчики — в component_epilog.
- Логика — наследованием. Изменения class.php через расширение, а не правку оригинала.
- Ассеты рядом с шаблоном. style.css и script.js в папке шаблона.
- Всё под git. /local версионируется и предсказуемо переносится между стендами.
Вывод
Кастомизация 1С-Битрикс без правки ядра — это не ограничение, а признак зрелой разработки. Платформа даёт полный набор точек расширения: копирование шаблона, result_modifier для данных, template.php для вёрстки, component_epilog для некэшируемого кода, .parameters.php для настроек и наследование class.php для логики. Всё это живёт в /local и переживает обновления.
Стоит один раз выстроить эту дисциплину — весь кастом в /local, разделение данных и вёрстки, версионирование — и сайт перестаёт «ломаться после обновлений». Кастомизация становится предсказуемой, переносимой и понятной следующему разработчику. Это дешевле в поддержке и надёжнее в эксплуатации, чем любая быстрая правка ядра.
