Компоненты, модули и шаблоны 1С-Битрикс: как дорабатывать, не ломая обновления

Главная проблема старых сайтов на Битриксе — правки прямо в ядре и в системных шаблонах. Такие сайты нельзя обновить: каждое обновление стирает доработки или конфликтует с ними, и сайт годами живёт без исправлений безопасности. Между тем Битрикс даёт понятные механизмы, чтобы дорабатывать что угодно, не трогая ядро. Разберу их с примерами.

Главное правило: /bitrix/ не трогаем

Папка /bitrix/ — это ядро и системные файлы. Всё, что в ней лежит, может быть перезаписано обновлением. Для доработок существует папка /local/ в корне сайта. Битрикс ищет файлы сначала в /local/, потом в /bitrix/:

• /local/templates/ — шаблоны сайта;
• /local/components/ — собственные компоненты и копии шаблонов компонентов;
• /local/modules/ — собственные модули;
• /local/php_interface/init.php — обработчики событий и общие функции;
• /local/php_interface/ — прочий код, подключаемый через init.php.

Если на старом сайте всё лежит в /bitrix/templates/ и /bitrix/php_interface/, первым шагом переносите это в /local/.

Шаблоны компонентов

Стандартный компонент, например bitrix:catalog.element, выводит данные через шаблон. Чтобы изменить вывод:

1. Скопируйте шаблон компонента в свой шаблон сайта. В режиме правки это делается через меню компонента — «Копировать шаблон компонента», или вручную в папку /local/templates/ваш_шаблон/components/bitrix/catalog.element/.default/.
2. Правьте копию.
3. Укажите в вызове компонента нужный шаблон.

Системный шаблон в /bitrix/components/ остаётся нетронутым и спокойно обновляется.

result_modifier.php: изменить данные до вывода

Если нужно не только поменять вёрстку, но и подготовить данные — добавить поле, пересчитать цену, подтянуть связанные элементы, — используйте файл result_modifier.php в папке шаблона компонента. Он выполняется после компонента, но до шаблона, и работает с массивом $arResult.

<?php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die();
foreach ($arResult['ITEMS'] as &$item) {
    $item['SHORT_NAME'] = TruncateText($item['NAME'], 60);
}
unset($item);

Так шаблон получает готовые данные, а логика не размазывается по вёрстке.

component_epilog.php: код, который выполняется всегда

Шаблон компонента кэшируется, и код внутри него при кэше не выполняется. Если нужно установить заголовок страницы, мета-теги, добавить элемент в «просмотренные» или подключить скрипт при каждом показе — используйте component_epilog.php. Чтобы передать в него данные из кэшируемого результата, перечислите ключи в $component->SetResultCacheKeys() в result_modifier.php.

Собственные компоненты

Если стандартного компонента нет или его логика сильно отличается, пишите свой в /local/components/ваше_пространство/имя.компонента/. Структура:

• .description.php — описание для визуального редактора;
• .parameters.php — параметры;
• component.php или class.php — логика;
• templates/.default/template.php — шаблон.

Современный вариант — class.php с классом-наследником CBitrixComponent: код понятнее и тестируемее.

init.php и события

Многие задачи решаются обработчиками событий, а не правкой модулей. Например, изменить данные заказа при оформлении или отправить заявку в CRM при добавлении элемента инфоблока.

<?php
use Bitrix\Main\EventManager;
EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnAfterIBlockElementAdd',
    ['\\Local\\Handlers\\Iblock', 'onAfterAdd']
);

Сам обработчик лучше вынести в отдельный класс в /local/php_interface/ или в свой модуль, а init.php оставить коротким.

Собственные модули

Если доработка большая — интеграция с внешним сервисом, своя админка, агенты — оформляйте её модулем в /local/modules/. Модуль устанавливается и удаляется штатно, его легко перенести на другой сайт, и он не смешивается с остальным кодом.

Готовые решения Marketplace

С решениями вроде Аспро действуют те же правила:

• не правьте файлы решения в его папке — обновление их перезапишет;
• копируйте нужные шаблоны компонентов в /local/templates/;
• используйте настройки решения и его собственные механизмы расширения, если они есть;
• ведите список изменений.

Как найти правки в ядре на старом сайте

1. Сравните файлы /bitrix/ с чистым дистрибутивом той же версии. Инструмент «Проверка системы» и монитор качества частично помогают, но надёжнее — сравнение файлов.
2. Посмотрите даты изменения файлов в /bitrix/modules/ и /bitrix/components/bitrix/ — файлы с датами, отличающимися от даты обновлений, подозрительны.
3. Если сайт в git — история покажет всё.

Найденные правки переносите в /local/: в шаблоны компонентов, обработчики событий или свои компоненты. Только после этого можно обновлять платформу. Порядок обновления — в статье как обновить Битрикс без поломок.

Кэш при доработках

• После изменения шаблона компонента сбросьте кэш, иначе изменения не будут видны.
• Не отключайте кэш компонентов ради удобства разработки на рабочем сайте.
• Если в шаблоне используются данные, зависящие от пользователя, учтите это в параметрах кэша или вынесите в component_epilog.php.

Контроль версий

Держите /local/ в git. Тогда видно, кто и что менял, легко откатить неудачную правку и развернуть изменения на тестовом сайте. Ядро в репозиторий класть не нужно — оно обновляется штатно.

Пример: доработка карточки товара

Задача: в карточке товара нужно показать срок доставки, зависящий от наличия на складе, и вывести блок «С этим товаром покупают» из связанного свойства инфоблока.

Правильный порядок:

1. Скопировать шаблон компонента catalog.element в /local/templates/ваш_шаблон/components/bitrix/catalog.element/.default/.
2. В result_modifier.php получить связанные товары по свойству и добавить их в $arResult, а также вычислить срок доставки по остатку.
3. В template.php вывести новые блоки, не трогая остальную вёрстку.
4. Если блок должен меняться без сброса кэша (например, зависит от города покупателя), вынести его вывод в component_epilog.php или подгружать AJAX-запросом.
5. Сбросить кэш, проверить карточку для товаров в наличии и под заказ.

Ни одного изменения в /bitrix/ — а значит, обновление платформы и решения пройдёт без потери доработки.

Как оценивать доработки

Перед оценкой я смотрю, где сейчас лежит код: в /local/ или в /bitrix/, есть ли готовое решение Marketplace, как настроен кэш, есть ли тестовая копия. Правильная структура проекта заметно удешевляет каждую следующую задачу.

Тестовая копия

Любые доработки на Битриксе сначала делаются на копии. Для этого удобно держать тестовый поддомен с отдельной базой, закрытый от индексации и посторонних паролем.

Короткий итог

Всё своё — в /local/, данные — в result_modifier.php, некэшируемое — в component_epilog.php, логика — в компонентах и модулях, события — в коротком init.php. При таком подходе сайт на Битриксе годами обновляется без потерь, а любой новый разработчик быстро понимает, где что лежит. Если на вашем сайте правки разбросаны по /bitrix/, первым шагом поддержки будет их перенос — это окупается при первом же обновлении.

Стоимость поддержки

Сайт на Битриксе с правильной структурой дешевле обслуживать: обновления занимают меньше времени, а доработки не требуют разбора чужих правок в ядре.

Чек-лист правильной доработки

1. Никаких правок в /bitrix/.
2. Шаблоны сайта и компонентов — в /local/templates/.
3. Подготовка данных — в result_modifier.php.
4. Некэшируемый код — в component_epilog.php.
5. Логика — в своих компонентах и модулях в /local/.
6. События — короткий init.php и классы-обработчики.
7. /local/ в git.
8. Сброс кэша после изменений.

Частые вопросы