Доработка шаблона Битрикс без потери при обновлении: как сохранить правки

Чтобы доработка шаблона Битрикс без потери при обновлении сохранилась, изменения размещают вне системных файлов: в отдельном шаблоне сайта, в собственном шаблоне компонента, в обработчике события или в конфигурационном файле, который обновление не перезаписывает. Прямое редактирование файлов ядра и системного шаблона приводит к тому, что очередной апдейт затирает правки. Ниже — разбор вариантов, таблица решений, учебный пример и проверяемый чек-лист.

Что именно считается доработкой шаблона и где границы задачи

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

Важно различать три слоя. Первый — системные файлы продукта: их обновление перезаписывает. Второй — пользовательские зоны, которые обновление не трогает: отдельный шаблон сайта, собственный шаблон компонента, файлы в пользовательской папке. Третий — конфигурационные файлы, которые платформа подключает, но не заменяет при апдейте. Задача сводится к тому, чтобы перенести нужное поведение из первого слоя во второй или третий.

Если правка касается только внешнего вида, часто достаточно собственного шаблона сайта или шаблона компонента. Если меняется логика вывода данных, подключают обработчики событий или модификаторы результата. Если нужно управлять поведением системного шаблона, используют конфигурационный файл, который размещается внутри шаблона и не перезаписывается обновлением. Каждый вариант имеет свою цену: где-то больше кода, где-то сложнее отладка, где-то ограничена совместимость с будущими версиями.

Границы услуги по доработке существующего проекта включают анализ кода и задачи, понятный результат, оценку, стенд, регрессию, релиз и план возврата. Это не скрытая перепродажа поддержки и не создание нового сайта. Заказчик получает предсказуемое изменение, которое переживёт обновление, и способ проверить это до выпуска на рабочий сайт.

Исходные данные, которые нужны до начала работ

Прежде чем выбирать способ, соберите входные данные. Без них любая оценка превращается в догадку, а риск потерять правки при обновлении растёт. Минимальный набор: версия продукта и модулей, список установленных обновлений, текущий шаблон сайта и его расположение, перечень компонентов, которые затрагивает задача, наличие собственных шаблонов компонентов, доступ к репозиторию и стенду.

Отдельно зафиксируйте, какие файлы уже правились вручную. Если в проекте есть изменённые системные файлы, их нужно найти до начала работ: иначе новая доработка ляжет поверх старой и усложнит обновление. Полезно сверить контрольные суммы или даты изменения файлов в системных папках с эталоном. Это не гарантирует полноту, но помогает выявить явные следы вмешательства.

Определите ответственных. Заказчик отвечает за доступы, тестовый стенд и приёмку. Исполнитель — за анализ, реализацию, проверку и документацию. Если в проекте несколько подрядчиков, заранее договоритесь, кто владеет шаблоном и кто вносит изменения. Иначе правки будут конфликтовать, а обновление покажет неожиданный результат.

Соберите требования к результату в проверяемом виде. Не «сделать красиво», а «на странице каталога выводится дополнительный блок с условиями доставки, который виден при определённом статусе заказа». Чем конкретнее формулировка, тем проще выбрать между шаблоном, компонентом и событием, а также построить приёмку.

Варианты размещения правок и критерии выбора

Основных вариантов четыре. Первый — правка в системном шаблоне сайта. Она переживёт обновление только в редких случаях и в целом считается рискованной. Второй — собственный шаблон сайта или дочерний шаблон, который наследует системный. Обновление его не затрагивает, но нужно следить за совместимостью с новыми версиями родителя. Третий — собственный шаблон компонента: копия системного шаблона размещается в пользовательской зоне, и обновление её не перезаписывает. Четвёртый — обработчик события или модификатор результата, который меняет данные до вывода, не трогая разметку.

Выбор зависит от того, что именно меняется. Если внешний вид — берите шаблон сайта или шаблон компонента. Если логика — обработчик события. Если нужно управлять поведением системного шаблона, который обновляется, — конфигурационный файл внутри шаблона. В документации по Сайтам24 описан конфигурационный файл .config.php, который размещается внутри системного шаблона. Он подключается и в редакторе, и на опубликованном сайте, а его ключи управляют набором скриптов, пространствами блоков и другими параметрами. Требуется проверка актуальности ключей для текущей версии платформы.

Критерии выбора: переживёт ли правка обновление, насколько сложно её сопровождать, есть ли риск конфликта с будущими версиями, как проверять результат. Если правка маленькая и касается только вывода, собственный шаблон компонента обычно проще. Если меняется поведение на нескольких страницах, обработчик события может оказаться компактнее. Если нужно тонко настроить системный шаблон, конфигурационный файл даёт предсказуемую точку входа. Выбор зависит от архитектуры проекта.

Не смешивайте варианты без необходимости. Одна задача — один основной способ. Комбинация допустима, когда часть работы делается в шаблоне, а часть — в обработчике, но тогда заранее опишите, что где лежит, чтобы при обновлении было понятно, что проверять.

Таблица решений: что переживёт обновление, а что нет

Таблица помогает принять решение до начала работ. Если выбран вариант, который обновление перезапишет, это должно быть осознанное временное решение с планом переноса. Если выбран пользовательский шаблон или обработчик, заранее определите, кто отвечает за его актуальность при обновлении продукта.

Предметная последовательность действий

Сначала зафиксируйте текущее состояние. Сделайте копию файлов и базы, отметьте версию продукта и модулей, сохраните список установленных обновлений. Это база для возврата, если что-то пойдёт не так. Работы ведите на стенде, а не на рабочем сайте.

Затем определите точку вмешательства. Найдите компонент или шаблон, который отвечает за нужный вывод. Проверьте, есть ли уже собственный шаблон компонента: если да, правка идёт в него, если нет — создайте копию системного шаблона в пользовательской зоне. Для изменений в оформлении сайта используйте собственный шаблон сайта, а не правку системного. Убедитесь, что путь к шаблону указан корректно.

После этого внесите изменение минимальным объёмом. Не переписывайте лишнее, не удаляйте системные вызовы, не меняйте структуру без необходимости. Если правка касается логики, добавьте обработчик события в пользовательской зоне и убедитесь, что он не дублирует существующее поведение и не конфликтует с другими модулями. Если нужно управлять системным шаблоном, используйте конфигурационный файл и проверьте, что его ключи соответствуют текущей версии.

Далее проверьте результат на стенде. Пройдите сценарии, которые затрагивает правка, и соседние сценарии, которые могут сломаться. Очистите кэш компонента и сайта, если это требуется. Убедитесь, что при обновлении продукта на стенде правка сохраняется. Для этого можно установить доступное обновление на стенде и повторить проверку. Зафиксируйте результаты тестирования.

В конце оформите документацию: что изменено, где лежит, почему выбран этот способ, как проверять после обновления. Это снижает риск, что следующая доработка снова уйдёт в системные файлы. Если в проекте несколько подрядчиков, документация помогает не конфликтовать.

Как проверить, что правка действительно переживёт обновление

Проверка строится на стенде. Сначала убедитесь, что правка работает до обновления. Затем установите доступное обновление продукта или модуля на стенде и повторите проверку. Если правка сохранилась, зафиксируйте это в документации. Если нет — найдите, какой файл был перезаписан, и перенесите изменение в пользовательскую зону.

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

Проверьте совместимость с текущей версией. Если вы используете конфигурационный файл, сверьте его ключи с актуальной документацией по API модуля Сайты24. Если вы наследуете системный шаблон, убедитесь, что новые версии родителя не конфликтуют с вашими правками. Если конфликт есть, опишите его и решите, как обновлять родительский шаблон дальше.

Наконец, проверьте возврат. Убедитесь, что у вас есть копия файлов и базы, а также понятный план отката. Если обновление на рабочем сайте приведёт к неожиданному результату, вы должны вернуть рабочее состояние без потери данных. Это часть приёмки, а не дополнительная опция.

Учебный пример: дополнительный блок в карточке товара

Учебный пример. Компания с интернет-магазином на 1С-Битрикс хочет вывести в карточке товара дополнительный блок с условиями доставки. Блок должен появляться только для товаров определённой категории. Сейчас карточка выводится системным шаблоном компонента, который обновляется вместе с продуктом. Прямая правка системного шаблона приведёт к потере блока при следующем обновлении. Пример учебный, не является готовым решением.

Входные условия: существующий проект, собственного шаблона компонента нет, стенд доступен, доступ к репозиторию есть. Задача — добавить блок так, чтобы обновление его не затёрло. Ограничение — не менять системный шаблон компонента и не переходить на новый шаблон сайта.

Действия. Создаём копию системного шаблона компонента в пользовательской зоне и даём ей понятное имя. В копии добавляем вывод блока с условием по категории. В вызове компонента указываем имя собственного шаблона. Проверяем на стенде: блок виден для нужной категории и не виден для остальных. Очищаем кэш компонента.

Проверка. Устанавливаем доступное обновление продукта на стенде. Повторяем проверку: блок на месте, условие работает, соседние элементы карточки не изменились. Если блок пропал, значит, правка ушла в системный файл или имя шаблона указано неверно. Возвращаемся к вызову компонента и проверяем привязку.

Наблюдаемый результат: блок сохраняется после обновления, потому что он находится в пользовательском шаблоне компонента. Ответственный за актуальность — исполнитель, который вносил правку; за приёмку — заказчик. Если в будущем системный шаблон компонента изменится, потребуется сверить копию с новой версией и при необходимости обновить её.

Чек-лист приёмки после обновления

• Сделана копия файлов и базы до начала работ, план возврата описан.
• Работы велись на стенде, а не на рабочем сайте.
• Правка размещена в пользовательской зоне: собственный шаблон сайта, шаблон компонента, обработчик события или конфигурационный файл.
• Системные файлы продукта не изменялись вручную.
• В вызове компонента указано правильное имя шаблона, кэш очищен, шаблон подключается корректно.
• Обработчик события зарегистрирован один раз, дублей нет.
• Конфигурационный файл соответствует текущей версии, ключи актуальны, поведение шаблона соответствует ожиданиям.
• На стенде установлено доступное обновление, правка сохранилась.
• Проверены соседние сценарии, которые могли сломаться.
• Результат зафиксирован в документации: что изменено, где лежит, как проверять.
• Определён ответственный за актуальность правки при будущих обновлениях.
• План возврата проверен: рабочее состояние восстанавливается без потери данных.

Ограничения, типичные ошибки и следующий шаг

Ограничения. Не все правки можно разместить в пользовательской зоне: иногда системный шаблон не предусматривает точки расширения, и тогда нужно оценить, стоит ли менять подход. Конфигурационный файл управляет поведением системного шаблона, но не заменяет его полностью. Собственный шаблон компонента требует сопровождения: при обновлении системного шаблона компонента нужно сверять копию с новой версией. Обработчик события может влиять на другие модули, если событие общее.

Типичные ошибки. Правка системного шаблона «на минуту», которая остаётся навсегда. Копия шаблона компонента без указания имени в вызове — правка есть, но не работает. Забытая очистка кэша — результат не виден, и кажется, что правка не применилась. Дублирование обработчика — двойной вывод или двойное действие. Отсутствие документации — следующая доработка снова уходит в системные файлы.

Следующий шаг. Если правок становится много, имеет смысл Приоритизация доработок сайта: как выбрать, что делать первым и заранее решить, какие из них требуют пользовательской зоны, а какие можно отложить. Перед выпуском на рабочий сайт полезно свериться с материалом о Релизы сайта Битрикс: как безопасно выпускать доработки. Если вы планируете передать работу подрядчику, поможет разбор того, Как проверить смету доработки сайта: разбор оценки по задачам. А если нужен исполнитель, который ведёт такие задачи от анализа до релиза, посмотрите доработка сайтов на 1с-битрикс.