Оновлення версії ядра 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/ оновлюється легше, ніж сайт з правками в ядрі та кастомними модулями п'ятирічної давності.