Обновление версии ядра 1С-Битрикс

Обновление версии ядра 1С-Битрикс

Обновление ядра Битрикса ломает сайты чаще, чем признают. Не потому что ядро плохое, а потому что большинство кастомного кода написано с нарушением принципа «не трогай ядро»: правки в bitrix/modules/, вызовы устаревших функций напрямую, зависимость от внутренней структуры компонентов. Обновление обнаруживает этот долг.

Что именно обновляется

Ядро Битрикс — это каталог /bitrix/ на сервере. При обновлении через встроенный механизм (/bitrix/admin/update_system_partner.php) система:

1. Загружает пакет обновлений с серверов Битрикса
2. Распаковывает в /bitrix/updates/
3. Выполняет PHP-скрипты обновлений, которые вносят изменения в базу данных и файловую систему
4. Заменяет файлы ядра и модулей

Ваш код в local/ не трогается. Ваши шаблоны в local/templates/ — не трогаются. Файлы в /bitrix/ — заменяются.

Что ломается после обновления

Прямые правки файлов ядра. bitrix/modules/catalog/install/components/bitrix/catalog.element/templates/.default/template.php — отредактированный вручную. После обновления — перезаписан оригиналом. Всё что лежит внутри /bitrix/ и было изменено — потеряно.

Устаревшие функции. Каждые несколько версий Битрикс объявляет функции deprecated и в конечном счёте удаляет их. Вызов CIBlockElement::GetList() с неправильными параметрами в версии 22.x может вести себя иначе, чем в 18.x. Вызов удалённого метода — Fatal Error.

Изменения в API модулей. Модуль sale серьёзно переработан в версиях 17.x и далее: старый API (CSaleOrder::Add) сосуществует с новым (Bitrix\Sale\Order), но поведение при edge-кейсах может различаться.

Кастомные модули из Маркетплейс. Если разработчик модуля не обновлял его под новую версию ядра — после обновления модуль может не работать.

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

Шаг 1: Staging. Копия production-сайта на тестовом сервере. Обновление делается только здесь. Без staging обновлять продакшн — игра в русскую рулетку.

# Минимальный чеклист staging-окружения:
- Полная копия файлов сайта
- Дамп базы данных
- Идентичная версия PHP
- Отключены внешние интеграции (не слать письма клиентам, не синхронизировать с 1С)

Шаг 2: Аудит кастомного кода. Перед обновлением проверяем:

• Есть ли правки внутри /bitrix/ (через git diff если репозиторий есть, или через find /bitrix -newer /bitrix/bitrix_version.php -type f)
• Вызываются ли deprecated-функции (grep по кодовой базе на local/)
• Совместимы ли модули Маркетплейс с целевой версией — проверяем на странице модуля в магазине

Шаг 3: Обновление на staging. Запускаем обновление через панель управления или через консольный инструмент /bitrix/bin/console update. На большом сайте консольное обновление предпочтительнее — нет ограничения по времени выполнения PHP.

Шаг 4: Тестирование. Проходим по критическим сценариям: главная страница, каталог, карточка товара, корзина, оформление заказа, личный кабинет, административный интерфейс. Проверяем PHP error log на наличие новых ошибок.

Шаг 5: Обновление production. После успешного тестирования на staging. В maintenance mode (503 страница) на время обновления. После — снова проверка error log.

Особенности обновления через несколько мажорных версий

Если отставание 2+ лет — нельзя обновиться сразу до последней версии. Путь: 18.x → 20.x → 22.x → актуальная. Каждый промежуточный шаг — отдельное тестирование. Пропустить промежуточные версии нельзя: скрипты обновления базы данных выполняются последовательно.

Сроки

Основная переменная — объём кастомного кода, который нужно адаптировать. Сайт на стандартных компонентах с кодом в local/ обновляется легче, чем сайт с правками в ядре и кастомными модулями пятилетней давности.