Как править решение Аспро, чтобы изменения не слетели при обновлении

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

Обновление решения — это не «кнопка, которая ломает сайт», а нормальная операция. Ломается она только на сайтах, где правки внесены прямо в файлы вендора. Ниже — правила, которые снимают проблему в источнике.

Правило 1. Не трогать оригинальные файлы решения

Обновление перезаписывает файлы решения своими версиями. Любая строка, дописанная внутри такого файла, исчезает. Отсюда простое разграничение:

Правило 2. CSS — только в custom.css

В решениях Аспро есть отдельный файл пользовательских стилей custom.css, который обновление не перезаписывает. Все визуальные правки — цвета, отступы, скрытие блоков, адаптив — вносите туда.

Практические моменты:

• Файл подключается последним, поэтому переопределение работает без !important в большинстве случаев. Если !important требуется на каждой строке — скорее всего, вы боретесь с более специфичным селектором, лучше уточнить свой.
• Держите в файле комментарии-разделители: /* === карточка товара === */. Через год это единственный способ понять, зачем нужна конкретная строка.
• Не редактируйте custom.css через админку на живом сайте: одна незакрытая скобка ломает вёрстку всех страниц сразу. Правьте локально, заливайте файлом.

Правило 3. Шаблон компонента — копировать, а не править

Если нужно поменять разметку конкретного блока, скопируйте шаблон компонента и правьте копию. В 1С-Битрикс это делается штатно: в режиме правки у компонента есть действие копирования шаблона — система сама создаёт копию в шаблоне сайта и переключает компонент на неё.

Что важно помнить:

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

Правило 4. Своя логика — в /local и init.php

Начиная с версии 14.0.1 главного модуля 1С-Битрикс файлы проекта выносятся из /bitrix в отдельную папку /local. Смысл ровно тот же: изолировать ваш код от кода продукта.

Что кладут в /local:

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

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

С версии 24.100.0 главного модуля в /local можно размещать и файлы настроек ядра .settings.php и .settings_extra.php.

Пример переноса логики в обработчик вместо правки файла решения:

// /local/php_interface/init.php
// вместо правки component.php решения вешаем обработчик события
AddEventHandler('iblock', 'OnAfterIBlockElementAdd', ['MyProject', 'onElementAdd']);

class MyProject
{
    public static function onElementAdd(&$arFields)
    {
        if ((int)$arFields['IBLOCK_ID'] !== 29) {
            return;
        }
        // ваша логика
    }
}

Такой код обновление не тронет: он лежит вне файлов решения.

Правило 5. Порядок работ вокруг обновления

1. Снимите резервную копию файлов и базы. Храните её вне вебрута — архив в корне сайта скачает кто угодно по прямой ссылке.
2. Разверните тестовую копию сайта и обновляйтесь сначала на ней. На проде «сразу» обновляют только сайты без правок.
3. Составьте список своих правок: файл — что изменено — зачем. Один текстовый файл в репозитории экономит дни.
4. Обновите решение на тесте, пройдите ключевые сценарии: главная, каталог, карточка, корзина, оформление заказа, формы, личный кабинет.
5. Сверьте свои копии шаблонов компонентов с новыми оригиналами, перенесите значимые изменения вендора.
6. Перенесите обновление на прод в наименее нагруженное время и сбросьте кэш.
7. Проверьте прод глазами: те же сценарии плюс мобильная версия.

Что делать, если правки уже внутри файлов решения

Ситуация типовая: сайт достался в наследство, правки внесены как попало. Порядок разбора:

1. Скачайте дистрибутив вашей версии решения и разверните рядом эталон.
2. Сравните каталог решения на сайте с эталоном (diff -r или любой визуальный сравниватель). Получите точный список изменённых файлов.
3. Разделите изменения на три группы: визуальные — переносятся в custom.css; разметочные — в копию шаблона компонента; логические — в обработчики в init.php или в собственный модуль.
4. Верните оригинальные файлы к эталонному состоянию.
5. Только после этого обновляйтесь.

Работа кажется избыточной ровно до первого обновления, после которого сайт остаётся рабочим, а правки — на месте. По опыту, на среднем сайте с историей доработок разбор занимает несколько дней, зато снимает проблему навсегда.