Обновление 1С-Битрикс: как обновить ядро и модули и не сломать сайт

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

Статья для владельца сайта на 1С-Битрикс и его разработчика. Разберём, почему обновления ломают сайт, как подготовиться, в каком порядке обновлять ядро и модули, что делать с требованиями к PHP и MySQL, что проверять после и как откатиться, если что-то пошло не так. Что такое сама платформа и чем отличаются редакции — в отдельной статье о 1С-Битрикс.

Почему обновление 1С-Битрикс ломает сайт

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

Правки прямо в ядре /bitrix

Самая частая причина. Разработчику нужно было быстро поменять поведение модуля или стандартного компонента — он открыл файл в /bitrix/modules/ или /bitrix/components/bitrix/ и поправил. Система обновлений считает эти файлы своими и перезаписывает их. Правка исчезает молча: сайт открывается, но скидка перестаёт считаться, письмо не уходит, поле пропадает из заказа.

Кастомизация, перемешанная с системными файлами

Шаблоны компонентов, скопированные и переделанные внутри /bitrix/templates/, свой init.php в /bitrix/php_interface/, собственные модули рядом со штатными. Сами по себе эти файлы обновление не затирает, но когда своё и вендорское лежит вперемешку, невозможно быстро понять, что меняли вы, а что пришло с дистрибутивом. Для доработок у Битрикса есть отдельная папка /local, о ней ниже.

Устаревшее окружение и сторонние решения

Новые версии модулей рассчитаны на свежий PHP и MySQL. Старый код шаблонов и init.php, написанный под PHP 5.6 или 7.x, на PHP 8 падает с фатальными ошибками: удалённые функции, строгая типизация, изменившееся поведение сравнений. Отдельный риск — решения из Маркетплейса (у них в коде модуля есть точка, например vendor.module): если партнёр давно не выпускал обновлений, модуль может просто не работать с новым ядром.

Подготовка к обновлению: бэкап, тестовая копия, аудит ядра

Резервная копия файлов и базы

Нужен полный бэкап: файлы и база данных. Штатный инструмент — «Настройки → Инструменты → Резервное копирование», но на больших сайтах надёжнее снимать копию средствами сервера: архив файлов плюс дамп БД через mysqldump. Копию храните вне сервера сайта и проверьте, что она разворачивается. Бэкап, который ни разу не восстанавливали, — это надежда, а не страховка.

Тестовая копия с тем же окружением

Обновлять сразу на боевом сайте — главная ошибка. Разверните копию на поддомене или отдельном сервере с теми же версиями PHP, MySQL и настройками веб-сервера. Закройте её от индексации и отключите на ней реальные интеграции: оплату, отправку писем клиентам, выгрузку в 1С, иначе тестовые заказы уйдут в учёт.

Проверка целостности ядра

Прежде чем обновлять, выясните, правили ли ядро. Если на сайте установлен модуль «Проактивная защита», используйте «Контроль целостности»: он сравнивает системные файлы с эталоном и показывает изменённые. Если модуля нет, разработчик сравнивает /bitrix/modules и /bitrix/components/bitrix с чистым дистрибутивом той же версии через diff. Каждое найденное изменение надо разобрать: перенести в /local, переписать через события или отказаться от него.

Отдельно запустите «Проверку системы» («Настройки → Инструменты → Проверка системы»): она показывает, соответствует ли сервер требованиям, и находит ошибки в структуре базы. Исправьте ошибки до обновления, а не после.

Как обновить Битрикс: порядок действий

Если тестовая копия готова и ядро проверено, порядок такой.

1. Проверьте лицензию. Обновления устанавливаются только при активном периоде обновлений. Если он истёк, «Обновление платформы» выдаст ошибку или не покажет обновлений — сначала продлите лицензию.
2. Остановите фоновые процессы. На время обновления приостановите запуск агентов по cron, отключите обмен с 1С и импорты, чтобы они не писали в базу, пока меняется её структура.
3. Обновите систему обновлений. Раздел «Настройки → Marketplace → Обновление платформы». Если система сообщает, что сначала нужно обновить её саму, соглашайтесь: это отдельный короткий шаг.
4. Установите обновления платформы. Сначала ядро (модуль main), затем остальные модули. Нажатие «Установить рекомендуемые обновления» делает это по порядку. Бета-версии на рабочем сайте не ставьте — они отключаются в настройках системы обновлений.
5. Повторите, пока обновления не закончатся. Установка идёт порциями: после одного прохода часто появляется следующий. Запускайте, пока система не сообщит, что обновлений нет.
6. Обновите решения Маркетплейса. Раздел «Настройки → Marketplace → Обновление решений» — модули партнёров и готовые шаблоны. Их обновляют после платформы, потому что новые версии часто требуют свежее ядро.
7. Сбросьте кэш и проверьте сайт. Очистите кеш («Настройки → Настройки продукта → Автокеширование», вкладка «Очистка файлов кеша»), включите фоновые процессы и пройдите проверку из раздела ниже.

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

Если разрыв в версиях большой

Сайт, который не обновлялся три-пять лет, за один подход не обновить. Действуйте по частям: сначала поднимите ядро до версии, которая ещё работает на вашем текущем PHP, затем обновите PHP, затем продолжайте обновлять модули. Между этапами проверяйте работоспособность копии и фиксируйте состояние в бэкапе или git. Если установка обрывается по тайм-ауту, увеличьте max_execution_time и memory_limit на время работ.

Ошибка связи с сервером обновлений

Сообщения вида «не удалось соединиться с сервером обновлений» обычно вызваны не Битриксом, а сервером сайта: исходящие соединения закрыты файрволом, устарели корневые сертификаты или не работает DNS. Второй частый вариант — истекший период обновлений. Для старых модулей партнёров бывает ошибка описания модуля после перехода на PHP 8: в install/index.php конструктор объявлен в старом стиле PHP 4 и должен быть переименован в __construct.

Переход на PHP 8.2 и MySQL 8: требования вендора

У обновлений платформы есть требования к окружению, и в 2026 году они ужесточились.

• PHP. С 1 февраля 2026 года вендор ограничил поддержку PHP ниже 8.2: пока сервер работает на PHP 8.1 или более старой версии, обновления коробочных продуктов не устанавливаются. Вендор рекомендует PHP 8.3 и выше.
• MySQL. С 1 сентября 2026 года ограничена поддержка MySQL ниже 8.0, рекомендуется 8.4. Сайт на MySQL 5.7 продолжит работать, но вендор предупреждает об ограничении поддержки — переход стоит запланировать, чтобы не остаться без обновлений.

Порядок перехода вендор описывает так: бэкап → обновить ядро и все модули на текущем PHP → обновить решения Маркетплейса → только потом повышать версию PHP. Если сразу поднять PHP на сайте со старыми модулями, получите ошибки, и лечится это откатом PHP и повторением шагов в правильном порядке.

Что обычно чинить в своём коде при переходе на PHP 8

• Удалённая настройка mbstring.func_overload: старые сайты в UTF-8 опирались на неё, в PHP 8 её нет.
• Удалённые функции: each(), create_function(), старые mysql_* в самописных скриптах.
• Фатальные ошибки там, где раньше было предупреждение: count() от не-массива, арифметика с нечисловыми строками, неверные типы аргументов встроенных функций.
• Динамические свойства классов в PHP 8.2 выдают предупреждения об устаревании — не критично, но засоряет логи.

Обновление MySQL 5.7 до 8 на Битриксе

Переход на MySQL 8 требует дампа и восстановления базы на новом сервере, проверки кодировки и сортировки таблиц, режима sql_mode и прямых SQL-запросов в своём коде: в MySQL 8 появились новые зарезервированные слова (например, rank, groups), и запросы, где так названы поля без кавычек, перестают работать. Делайте это на тестовой копии и замеряйте скорость тяжёлых страниц до и после.

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

«Главная открылась» — не проверка. Пройдите сценарии, которые приносят деньги, и служебные процессы, которые не видны глазом.

Отдельно проверьте, что поисковый робот видит сайт как раньше: не пропали мета-теги, не поменялись адреса страниц, sitemap и robots.txt на месте.

Откат: план Б на случай неудачного обновления

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

Заранее решите, в какой момент откатываетесь, а не чините на ходу. Разумное правило: если за оговорённое окно (например, 30–60 минут) критичную функцию — оплату, оформление, обмен — не удалось восстановить, сайт возвращается к исходной копии, а проблема разбирается на тестовой. Заказы и заявки, пришедшие между бэкапом и откатом, нужно выгрузить заранее, чтобы не потерять.

Как вынести правки из ядра в /local

Папка /local — штатное место для всего, что разработчик делает под проект. Система обновлений её не трогает, а Битрикс ищет в ней файлы раньше, чем в /bitrix.

• /local/templates/ — шаблоны сайта и переопределённые шаблоны стандартных компонентов.
• /local/components/ — собственные компоненты, в том числе копии штатных, если их нужно доработать.
• /local/modules/ — собственные модули.
• /local/php_interface/init.php — обработчики событий, константы, подключение своих классов.

Перенос правок из ядра — это не копирование файлов. Изменение внутри модуля sale нужно переписать через обработчик события или собственный класс, а правку в стандартном компоненте — через копию компонента в /local/components или переопределённый шаблон. Заодно имеет смысл положить /local в git: тогда любая доработка видна и откатывается одной командой.

На запущенном проекте такая «расчистка» занимает от нескольких дней до пары недель и по сути является доработкой сайта на Битриксе с разбором чужого кода. Зато после неё обновление снова становится рутиной.

Как часто обновлять Битрикс и при чём здесь безопасность

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

• обновления безопасности — в течение нескольких дней после выхода, через тестовую копию;
• плановое обновление всех модулей — раз в месяц или раз в квартал;
• проверка окружения (PHP, MySQL, сертификаты сервера) — раз в полгода с оглядкой на требования вендора.

Откладывать обновления опасно не абстрактно. Волны массовых взломов сайтов на Битриксе использовали уязвимости, которые вендор закрыл в обновлениях задолго до атак: пострадали прежде всего сайты, которые годами не обновлялись. Подробности и выводы — в разборе массовых взломов Битрикс 2022–2025.

Обратная сторона: обновления без тестовой копии и без контроля правок ядра ломают сайт. Поэтому регулярность и регламент идут вместе.

Когда обновлять самим, а когда звать подрядчика

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

Внешняя команда оправдана, если:

• сайт не обновлялся больше года и работает на PHP 7.x или MySQL 5.7;
• контроль целостности показывает изменённые файлы ядра, а документации нет;
• на сайте интернет-магазин с обменом с 1С, и простой в несколько часов стоит заметных денег;
• прежний разработчик ушёл, и никто не знает, что на сайте дописано.

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

Чек-лист безопасного обновления Битрикс

• Период обновлений лицензии активен
• Снят полный бэкап файлов и базы, восстановление проверено
• Развёрнута тестовая копия с тем же PHP и MySQL, закрыта от индексации, интеграции отключены
• Проверена целостность ядра, найденные правки разобраны или перенесены в /local
• «Проверка системы» и проверка базы пройдены без ошибок
• Замерена производительность до обновления
• Обновления сначала установлены и проверены на копии
• На рабочем сайте: свежий бэкап, остановлены обмен с 1С и импорты
• Порядок: система обновлений → ядро → модули → решения Маркетплейса → кэш
• Проверены заказ, формы, обмен с 1С, агенты, логи, производительность
• PHP переведён на 8.2+ (вендор рекомендует 8.3+), MySQL — на 8.0+, после обновления модулей
• Заранее определены критерий и окно отката

Итог

Битрикс ломается не от обновлений, а от того, что их ставят на сайт с правленым ядром, без тестовой копии и без плана отката. Вынесите доработки в /local, держите окружение в рамках требований вендора — сейчас это PHP 8.2+ и MySQL 8.0+, — обновляйте регулярно и через копию. Тогда обновление 1С-Битрикс занимает часы, а не превращается в аварийный проект раз в несколько лет.