Знакомая история: купили готовое решение, подрядчик «допилил под себя», сайт заработал. Прошёл год, вышло критическое обновление безопасности — а обновиться нельзя, потому что тогда «всё развалится». Доработки лежат прямо в файлах решения и ядра, и любое обновление их затирает. Бизнес оказывается в ловушке: либо старая уязвимая версия, либо переделка половины сайта.
Эта статья — о том, как дорабатывать шаблон и готовое решение на 1С-Битрикс так, чтобы сохранить возможность обновлений. Разберём три уровня кастомизации, безопасные механизмы платформы — копии компонентов, свои шаблоны, init.php, события и собственный модуль — и правила, которые отличают поддерживаемый проект от тупика. Если сайт уже в таком тупике, начинать стоит с аудита и оптимизации решения на 1С.
Коротко
- Никогда не правьте файлы ядра и исходники готового решения напрямую — обновление их затрёт.
- Меняйте вёрстку через копию шаблона компонента, логику — через копию компонента в своём namespace.
- Свой PHP-код держите в init.php или, лучше, в собственном модуле; поведение меняйте событиями.
- Правильная кастомизация — та, после которой вы спокойно обновляете ядро на копии сайта.
Почему обновляемость важнее, чем кажется
Обновляемость — это не «приятная опция», а вопрос безопасности и живучести проекта. Ядро Битрикс регулярно закрывает уязвимости, а готовые решения — исправляют баги и добавляют функции. Сайт, который нельзя обновить, со временем накапливает дыры в безопасности и отстаёт по возможностям от того, что уже доступно из коробки.
Стоимость «необновляемости» проявляется не сразу, но всегда. Сначала это мелкое неудобство, потом — невозможность поставить нужный модуль из-за старой версии, а в худшем случае — взлом через известную уязвимость, которую давно закрыли в обновлении. Поэтому обновляемость закладывают в архитектуру с самого начала, а не «когда-нибудь потом».
Что ломается при прямой правке
Чтобы понять, как делать правильно, посмотрим, что именно ломается при неправильном подходе. Прямая правка означает изменение файлов, которые Битрикс считает «своими» и перезаписывает при обновлении.
- Файлы ядра (
/bitrix/modules/). Обновление ядра перезаписывает их целиком — любые правки исчезают. - Штатные компоненты (
bitrix:). Живут в ядре, обновляются вместе с ним; правки в оригинале теряются. - Исходники готового решения. Обновление решения из Маркетплейса перезаписывает свои файлы.
- Системные шаблоны и переводы. Тоже относятся к обновляемым областям.
Правило простое: всё, что лежит в /bitrix/ и принадлежит ядру или решению, — чужая территория. Ваши доработки должны жить в других местах, которые обновление не трогает.
Три уровня кастомизации
Кастомизацию удобно разложить по уровням — от самого лёгкого и безопасного к самому глубокому. Выбирайте минимально достаточный уровень для задачи.
| Уровень | Что меняем | Механизм | Риск для обновлений |
|---|---|---|---|
| 1. Вёрстка | Внешний вид, вывод | Копия шаблона компонента | Нет |
| 2. Поведение | Реакция на действия | События в init.php / модуле | Нет |
| 3. Логика | Работа компонента | Копия компонента в своём namespace | Минимальный |
Общий принцип: сначала пытаемся решить задачу шаблоном и событиями, и только если не выходит — копируем компонент или пишем модуль. Чем выше уровень, тем больше кода под вашим контролем и тем важнее его версионировать. О том, как выстроить безопасный процесс выкладки таких доработок, — в статье про CI/CD и деплой в Битрикс.
Доработка шаблона компонента
Самый частый и безопасный уровень — правка шаблона компонента. Штатный компонент вроде bitrix:catalog.section состоит из логики (component.php, class.php) и шаблонов (template.php, style.css, script.js). Чтобы изменить внешний вид и вывод, шаблон копируют в шаблон сайта и правят уже там.
Что это даёт:
- Обновления компонента подхватываются. Логика в ядре обновляется, ваш шаблон остаётся.
- Полный контроль над вёрсткой. HTML, стили, скрипты — ваши, меняйте как нужно.
- Доступ к данным компонента. В шаблоне доступен
$arResult— можно выводить что угодно из подготовленных данных. - Изоляция по сайтам. Свой шаблон компонента живёт в шаблоне сайта и не мешает другим.
Если данных в $arResult не хватает, есть result_modifier.php — файл рядом с шаблоном, который дорабатывает результат компонента перед выводом, не трогая его логику. Это промежуточный, тоже безопасный приём.
Копия компонента в свой namespace
Когда шаблоном задачу не решить и нужно менять саму логику работы компонента, его копируют в собственное пространство имён. Вместо bitrix:catalog.section появляется, например, custom:catalog.section, и правится уже копия. Обновление ядра меняет оригинал в bitrix:, а вашей копии не касается.
Копия компонента оправдана для нетривиальной логики каталога, оформления заказа или B2B-сценариев, где штатного поведения не хватает. Такие доработки — часть проектов по разработке модулей и компонентов под 1С-Битрикс, где важно не только скопировать, но и грамотно организовать код.
init.php и обработчики событий
Поведение системы меняют не правкой её кода, а событиями. Битрикс построен на событийной модели: сохранение заказа, добавление товара, оформление, авторизация — почти всё генерирует события, на которые можно повесить свой обработчик. Обработчики регистрируют в /bitrix/php_interface/init.php (или в шаблоне сайта) — это штатное место, которое обновления не трогают.
Через события решают массу задач: пересчитать цену по своей логике, дописать данные в заказ, отправить уведомление в мессенджер, синхронизировать что-то с внешней системой. Код лежит отдельно от ядра, а срабатывает в нужный момент. Событийную модель D7 и работу с ней мы подробно разбираем в материале про D7 и ORM в Битрикс.
Собственный модуль поверх решения
Для крупных и долгоживущих доработок лучший инструмент — собственный модуль. Это изолированный кусок функционала со своей структурой: обработчики событий, свои сущности ORM, вспомогательные классы, свои компоненты. Модуль версионируется, устанавливается и переносится между проектами как единое целое.
Плюсы собственного модуля:
- Изоляция. Весь ваш код в одном месте, а не размазан по init.php и шаблонам.
- Версионирование и установка. Модуль ставится и обновляется штатными средствами, откатывается при проблеме.
- Переносимость. Один раз написанный функционал переезжает на другой проект.
- Чистая архитектура. Классы, автозагрузка, ORM — код, который не стыдно поддерживать годами.
Модуль не конкурирует с готовым решением, а дополняет его поверх: расширяет логику через события, добавляет свои компоненты и сущности. Как устроен полноценный модуль и чем он отличается от решения для Маркетплейса, разбираем в статье про разработку модуля для Маркетплейса Битрикс.
Результирующие шаблоны и включаемые области
Кроме компонентов, у сайта есть общий шаблон (header, footer, обёртка страниц) и включаемые области. Их тоже кастомизируют, не ломая обновляемость: шаблон сайта — это ваша территория, он не относится к обновляемому ядру. Здесь настраивают вёрстку каркаса, подключают свои стили и скрипты, задают меню и хлебные крошки.
Включаемые области (#INCLUDE_AREA#, включаемые файлы) позволяют контент-менеджеру править куски страниц без разработчика и без риска задеть логику. Правильно спроектированный шаблон сайта разделяет каркас, редактируемый контент и логику компонентов — так каждый слой меняется независимо и безопасно.
Готовые решения из Маркетплейса
Готовое решение — не приговор для доработок, если подходить грамотно. Решение можно расширять всеми перечисленными способами: копировать его компоненты, делать свои шаблоны, вешать события, писать модуль поверх. Ключевое правило — не редактировать исходники решения напрямую.
Выбор между готовым решением, доработкой и разработкой с нуля — вопрос стратегии, а не только техники. Мы разбирали его в контексте выбора платформы: иногда правильнее взять решение и аккуратно расширить, иногда — строить своё. Подробнее в материале про интеграции через REST и вебхуки, когда решение нужно связать с внешними системами.
Как безопасно обновляться
Даже при правильной кастомизации обновление проводят по процессу, а не «в лоб на бою». Последовательность такая:
- Копия сайта. Разверните актуальную копию боевого сайта на тестовом окружении.
- Обновление на копии. Прогоните обновление ядра и решений сначала там.
- Проверка доработок. Убедитесь, что кастомный функционал работает: заказ, каталог, кабинет, интеграции.
- Сверка копий компонентов. Проверьте компоненты, которые копировали, — не разошлись ли они с оригиналом.
- Выкладка на бой. Только после успешной проверки на копии обновляйте боевой сайт.
- Контроль после. Последите за ошибками и ключевыми сценариями в первые часы после обновления.
Стабильная инфраструктура для такого процесса — отдельная тема: тестовое окружение, бэкапы, откат. Про фундамент под это писали в статье про хостинг и инфраструктуру на BitrixVM.
Частые ошибки
- Правка файлов ядра. Меняют
/bitrix/modules/напрямую — обновление всё затирает. - Редактирование исходников решения. Правят файлы готового решения вместо доработки поверх.
- Весь код в шаблоне. Сотни строк логики в
template.phpвместо модуля или событий. - Копируют компонент ради мелочи. Глубокая копия там, где хватило бы шаблона или
result_modifier.php. - Нет версионирования. Доработки не в git — при сбое их не откатить и не восстановить.
- Обновление сразу на бою. Без проверки на копии — и сайт падает в прайм-тайм.
- Отказ от обновлений навсегда. «Работает — не трогай», пока не приходит взлом через старую уязвимость.
Чек-лист кастомизации
- Ядро не тронуто. В
/bitrix/modules/и исходниках решения нет ваших правок. - Вёрстка — в шаблонах компонентов. Внешний вид меняется копиями шаблонов, не логикой.
- Поведение — событиями. Реакции на действия висят на обработчиках в init.php или модуле.
- Логика — в своём namespace. Глубокие правки компонентов сделаны на копиях, а не в оригинале.
- Крупные доработки — в модуле. Свой функционал изолирован, версионируется, переносим.
- Всё в git. Доработки под контролем версий, есть возможность отката.
- Обновление проверено на копии. Обновляемость подтверждена на тестовом окружении.
Вывод
Кастомизация на 1С-Битрикс без потери обновляемости — не магия, а дисциплина. Правило одно: не трогать чужую территорию — файлы ядра и исходники решения. Вёрстку меняем копиями шаблонов компонентов, поведение — событиями в init.php или модуле, глубокую логику — копиями компонентов в своём namespace, а крупные доработки собираем в собственный модуль.
Так вы получаете сайт, который делает ровно то, что нужно бизнесу, и при этом спокойно принимает обновления безопасности и функций. Если проект уже в тупике необновляемости — это лечится: правки переносят в безопасные механизмы, и сайту возвращают возможность развиваться. Обновляемость окупается каждый раз, когда выходит критический патч, — и не окупается только у тех, кто о ней не подумал.
