Обновление 1С-Битрикс - задача, которую откладывают месяцами, потому что «сайт и так работает». На практике это самая частая причина взлома через известные уязвимости и самая частая причина, почему интернет-магазин падает в разгар распродажи. Я веду поддержку нескольких проектов на Битрикс и вижу одну и ту же картину: клиент не обновлял ядро два года, потом просит «просто обновить», а после апдейта отваливается оплата, СДЭК и половина инфоблоков. Расскажу, почему тянуть с обновлением дороже, чем его делать вовремя, и как провести апдейт так, чтобы сайт не лёг.
Почему обновление 1С-Битрикс нельзя откладывать
Битрикс регулярно закрывает уязвимости в ядре и модулях - это видно по changelog модуля main, где почти в каждом релизе есть пункт «Устранена уязвимость». Пока сайт стоит на старой версии, эти дыры остаются открытыми, и сканеры ботов методично проверяют типовые CMS на известные CVE. Я разбирал взлом интернет-магазина, где через дыру в старом модуле catalog злоумышленники залили веб-шелл и рассылали спам с сервера - владелец узнал об этом только когда хостинг заблокировал аккаунт за исходящий спам.
Вторая причина - совместимость с PHP. Начиная с определённых сборок Битрикс требует PHP 8.1 и выше, а хостинги постепенно отключают поддержку PHP 7.4 на уровне инфраструктуры. Если ядро не обновлено, апгрейд PHP на сервере просто кладёт сайт белым экраном, и разбираться приходится в аварийном режиме, а не по плану.
Третья причина прозаичнее: чем больше версий сайт отстаёт от актуальной, тем длиннее и рискованнее становится сам процесс обновления 1С-Битрикс. Разработчики Битрикса пишут миграции между соседними версиями, а не между версией трёхлетней давности и текущей. Обновление через десяток промежуточных релизов почти гарантированно споткнётся на одном из них.
Что чаще всего ломается при апдейте Битрикс
За несколько лет сопровождения проектов на Битрикс я собрал список типовых поломок после обновления:
- Кастомные компоненты, скопированные в шаблон вместо переопределения через template_extension - при обновлении ядра перестают наследовать актуальную логику и начинают работать некорректно.
- Прямые правки файлов ядра «для скорости» - при накатывании обновления они либо затираются, либо конфликтуют с новыми файлами.
- Устаревшие обработчики событий (OnSaleOrderSaved, OnBeforeIBlockElementUpdate), написанные под старую сигнатуру метода - после обновления модуля sale или iblock начинают падать с фатальной ошибкой.
- Модули маркетплейса от сторонних разработчиков, которые не обновлялись синхронно с ядром - типичный случай для модулей доставки и эквайринга.
- Кастомизация визуального редактора и админки, завязанная на конкретные CSS-классы Bitrix Framework - при обновлении интерфейса админки классы меняются, и кастомная панель просто пропадает.
Отдельно стоит проблема совместимости с PHP-версией: если хостинг форсированно переключает PHP на новую мажорную версию, а часть кастомного кода использует устаревший синтаксис (например, create_function или динамические свойства без объявления), сайт падает не из-за обновления Битрикса, а из-за несовместимости окружения - но чинить приходится в комплексе.
Как подготовиться к обновлению 1С-Битрикс: бэкап и тестовый контур
Правило, которое я не нарушаю ни разу: обновление без свежего бэкапа и тестового контура - это не обновление, а эксперимент на боевом сайте. Порядок действий такой:
- Снимаю полный бэкап через встроенный модуль резервного копирования Битрикса или напрямую mysqldump + архив файлов - в зависимости от размера базы это занимает от нескольких минут до пары часов.
- Разворачиваю копию сайта на тестовом поддомене или локально через Docker с тем же окружением PHP и MySQL, что на проде.
- Прогоняю обновление на тестовой копии полностью, до последнего доступного релиза, и фиксирую все ошибки в логе.
- Проверяю ключевые сценарии руками: оформление заказа, оплату, работу личного кабинета, формирование заказа на доставку.
- Только после чистого прогона на тесте переношу обновление на боевой сервер в окно низкой нагрузки.
Вот пример команды для быстрого снятия бэкапа базы и файлов перед апдейтом, которую я обычно ставлю в cron перед плановым обновлением:
mysqldump -u root -p bitrix_db | gzip > /backup/db_$(date +%F).sql.gz
tar -czf /backup/files_$(date +%F).tar.gz /home/bitrix/wwwБез такого бэкапа откат после неудачного обновления превращается в восстановление сайта по кусочкам - иногда это дольше, чем само обновление.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Порядок обновления модулей Битрикс: ядро, компоненты, шаблон
Обновление 1С-Битрикс - это не одна кнопка, а последовательность шагов, и порядок здесь важен:
- Сначала обновляю модуль main (ядро) - все остальные модули зависят от его версии API.
- Затем обновляю системные модули: iblock, sale, catalog, currency - в порядке зависимостей, которые показывает панель обновлений.
- После системных модулей - модули маркетплейса: платёжные системы, службы доставки, модули аналитики.
- В последнюю очередь трогаю шаблон сайта и кастомные компоненты, потому что именно они чаще всего требуют ручной доработки после обновления API.
После каждого шага проверяю сайт на тестовом контуре, а не жду завершения всего цикла обновлений - так проще локализовать, какое именно обновление что-то сломало. Если модуль маркетплейса давно не обновлялся разработчиком (а такое сплошь и рядом с нишевыми модулями оплаты и логистики), иногда единственный вариант - переписать интеграцию через прямой API сервиса, не полагаясь на устаревший модуль.
Интеграции после обновления: эквайринг, СДЭК, внешние сервисы
Самая частая жалоба после обновления Битрикс - «оплата не проходит» или «заказы не уходят в доставку». Причина обычно в том, что модуль эквайринга или доставки использовал недокументированные хуки ядра, которые изменились в новой версии.
На практике я чинил интеграцию с эквайрингом Т‑Банка после обновления модуля sale - старая версия обработчика формировала запрос к API банка через устаревший метод, который перестал существовать после апдейта, и я переписывал вызов через актуальный SDK банка с сохранением всей истории транзакций. Похожая история с модулем СДЭК: после обновления каталога товаров у части заказов пропадали габариты и вес, потому что кастомные свойства инфоблока переопределялись стандартными полями Битрикса, и расчёт стоимости доставки начинал возвращать нули.
Перед обновлением стоит явно выписать список всех интеграций сайта - эквайринг, службы доставки, CRM, аналитику, внешние API - и после апдейта проверить каждую руками, а не полагаться на то, что «раз сайт открывается, значит всё работает». Именно в интеграциях чаще всего прячутся поломки, которые не видны на главной странице, но бьют по продажам в первый же день.
| Способ обновления | Кто делает | Риск простоя | Когда подходит |
|---|---|---|---|
| Автообновление через панель управления | Владелец сайта | Высокий | Простой сайт без кастомных доработок |
| Обновление через партнёра 1С-Битрикс | Партнёр по договору | Средний | Стандартные решения без глубокой кастомизации |
| Обновление с тестовым контуром через разработчика | Разработчик, знающий проект | Низкий | Магазин с интеграциями и кастомным кодом |
Если на сайте есть нестандартные доработки - кастомные обработчики событий, самописные компоненты, сложная интеграция с внешними сервисами - доверять автообновлению рискованно: оно не проверяет, переживёт ли конкретно ваш код изменение API. Для таких случаев логичнее заказывать разработку и сопровождение сложных интеграций после обновления, а не полагаться на автоматику.
Как часто обновлять Битрикс и кто должен этим заниматься
Оптимальная частота - раз в один-два месяца проверять наличие обновлений ядра и системных модулей, и ставить их в тестовом контуре сразу, как только вышел релиз, закрывающий уязвимость. Ждать «большого обновления» раз в год - рецепт для описанной выше ситуации с десятком промежуточных версий и лавиной несовместимостей.
Заниматься обновлением должен человек, который понимает структуру конкретного проекта: какие компоненты кастомные, какие интеграции критичны для бизнеса, где в коде есть прямые правки файлов ядра. Штатный контент-менеджер, который просто нажимает «обновить» в панели администратора, не проверит после апдейта работу оплаты и доставки - он даже не будет знать, что это нужно проверить.
Я веду для нескольких клиентов регулярную техподдержку именно в таком формате: раз в месяц смотрю доступные обновления, прогоняю их на тестовом контуре, чиню то, что ломается, и только потом переношу на прод. Это дешевле и предсказуемее, чем разовый аварийный вызов, когда сайт уже лежит после самостоятельного обновления через панель.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Можно ли обновить 1С-Битрикс самостоятельно, без разработчика?
Если сайт стандартный, без кастомных компонентов и сложных интеграций, автообновление через панель управления в большинстве случаев проходит гладко. Но если на сайте есть доработки под конкретный бизнес - оплата, доставка, кастомные инфоблоки - риск поломки высокий, и лучше сначала прогнать обновление на тестовой копии.
Что делать, если обновление уже сломало сайт?
Первым делом откатываюсь на бэкап, снятый перед обновлением, - если он есть, восстановление занимает от 15 минут до часа в зависимости от размера базы. Дальше разбираюсь на тестовом контуре, что именно вызвало ошибку, и накатываю обновление заново уже с исправлением конфликтующего кода.
Сколько стоит обновление 1С-Битрикс с проверкой интеграций?
Цена зависит от количества кастомных доработок и интеграций на сайте - чем их больше, тем дольше проверка после апдейта. Регулярное сопровождение с плановыми обновлениями я веду от 15 000 ₽/мес, разовую консультацию по оценке объёма работ можно взять от 3 000 ₽.
Как понять, что версия Битрикса устарела критично?
Смотрю три признака: версия PHP на хостинге скоро перестанет поддерживаться, в changelog модуля main за последний год есть записи об устранении уязвимостей, которые не установлены на сайте, и партнёрские модули (эквайринг, доставка) перестали получать обновления под текущую версию ядра. Если совпадают хотя бы два признака - обновление откладывать уже небезопасно.