Обновление ядра Битрикс: как не сломать кастомизации

Обновление ядра «1С-Битрикс: Управление сайтом» редко ломает сайт одной кнопкой. Обычно проблема появляется позже: обновлённый модуль меняет запрос к базе, шаблон перестаёт находить переопределённый компонент, а ручная правка в каталоге /bitrix исчезает после установки пакета. Ниже — рабочий процесс для версий 23.x и 24.x: сначала инвентаризация и копия, затем тест на стенде, обновление и проверка. На подготовленный проект обычно стоит закладывать от одного часа, а не десять минут из административной панели.

Главный риск — не само обновление, а место кастомизации

Штатный механизм обновления должен изменять файлы ядра и модулей, а не пользовательскую логику. Но в старых проектах разработчики часто правили файлы напрямую: шаблоны компонентов в /bitrix/templates, компоненты в /bitrix/components, классы модулей в /bitrix/modules. Такие изменения трудно отличить от поставляемых файлов, и пакет обновления может их заменить.

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

Правило для Битрикс простое: обновлять нужно не «файлы сайта», а контролируемый набор изменений, который можно сравнить, проверить и вернуть назад.

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

Что проверить до запуска обновления

Соберите карту изменений

Начните не с кнопки «Обновить», а с поиска ручных правок. Сравните файлы проекта с чистой поставкой той же редакции и версии, если она доступна, и просмотрите историю Git. Отдельно отметьте:

• изменения в /bitrix/modules, /bitrix/components и /bitrix/templates;
• переопределённые шаблоны компонентов, особенно каталог templates внутри шаблона сайта;
• обработчики событий, агенты, собственные модули и настройки в /local;
• правки в настройках PHP, веб-сервера, cron и правах на каталоги;
• интеграции с платёжными системами, CRM, почтой, складом и внешними API.

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

Проверьте совместимость окружения

Для каждой версии ядра смотрите требования именно в описании доступного обновления и документации вашей редакции. Сверьте версию PHP, СУБД, расширения PHP, веб-сервер и свободное место. Не меняйте PHP одновременно с ядром без необходимости: если сайт упадёт, вы не поймёте, какой шаг стал причиной.

Проверьте также доступ к административной панели, SSH или панели хостинга, базе данных и файлам. Если обновление прервётся из-за лимита времени выполнения PHP или нехватки места, повторный запуск поверх частично изменённого проекта усложнит диагностику.

Где обновлять: три варианта и их цена

Для сайта с оплатой, личными кабинетами или обменом с учётной системой выбирайте отдельный стенд. Копия должна использовать отдельную базу и отдельные очереди фоновых задач. Отправку писем, вебхуки и платёжные операции на стенде отключите или направьте в тестовый контур.

Пошаговый порядок обновления

1. Зафиксируйте исходное состояние. Запишите текущую версию ядра и модулей, версию PHP, дату последнего успешного обновления и список незакоммиченных изменений. Проверка: другой администратор может понять, что именно было установлено до начала работ.
2. Сделайте две независимые копии. Сохраните архив файлов и дамп базы в месте, не доступном из веба. Проверьте распаковку архива и восстановление дампа на тестовой базе. Проверка: из копии можно открыть главную страницу стенда и выполнить простой запрос к базе.
3. Воспроизведите обновление на копии. Используйте штатный раздел обновлений в административной панели, а не замену каталогов ядра архивом из интернета. Установите сначала доступные обновления в рекомендованном порядке, если такой порядок показывает панель. Проверка: панель сообщает об успешном завершении, а версия ядра и модулей изменилась ожидаемо.
4. Очистите кеш и проверьте критические сценарии. После обновления очистите кеш штатными средствами панели и протестируйте авторизацию, каталог, поиск, корзину, оформление заказа, оплату, обмены и письма. Проверка: сценарии проходят без ошибок в журнале и браузере.
5. Сравните кастомизации. Просмотрите изменения в Git или сравните контрольные копии файлов. Особое внимание уделите шаблонам компонентов, обработчикам событий и файлам, которые раньше лежали внутри /bitrix. Проверка: каждая пропавшая или изменённая строка имеет объяснение.
6. Повторите процедуру на боевом сайте. Выберите окно с низким трафиком, включите мониторинг ошибок и заранее подготовьте команду отката. Проверка: после обновления главная страница, административная панель и ключевой бизнес-сценарий работают с реальными данными.

Что ломается чаще всего

Шаблон компонента перестал работать

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

Код события вызывается дважды

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

Появился белый экран или ошибка 500

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

Фоновая задача запускает старый код

Веб-запрос может работать с очищенным кешем, а cron — использовать другую версию PHP, другой каталог проекта или старую копию файла. Проверьте команду cron, рабочий каталог, права и переменные окружения. Для обменов и агентов дополнительно смотрите время последнего успешного запуска.

Где этот подход ломается

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

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

Что делать дальше

После успешного обновления оставьте мониторинг ошибок включённым хотя бы на первые часы повышенного трафика. Проверьте долю ответов 5xx, время ответа каталога и оформления заказа, очереди cron, ошибки обмена и число неотправленных писем. В течение следующего цикла перенесите найденные правки из каталогов ядра в /local, добавьте проект в Git и оформите короткий регламент: кто обновляет, где лежит копия, как проверить восстановление и кто принимает решение об откате.

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