Обновление Битрикс тянут до последнего почти всегда по одной причине: страшно, что после кнопки «обновить» сайт перестанет открываться, а разбираться с этим придётся вечером в пятницу. За практику поддержки чужих проектов на 1С-Битрикс я вижу одну и ту же картину: ядро и модули не трогали год или два, накопился десяток патчей безопасности, а новый функционал маркетплейса требует свежей версии API. Откладывать обновление дороже, чем один раз разобраться, как обновляться безопасно и без сюрпризов.
Зачем обновлять Битрикс и чем опасно затягивать
Битрикс регулярно закрывает найденные уязвимости патчами для ядра и модулей. Старая версия без этих патчей остаётся открытой для известных дыр, и заражения чаще всего залетают именно через давно не обновлявшиеся компоненты, а не через что-то экзотическое. Отдельная проблема - хостинг. Провайдеры периодически поднимают версию PHP на серверах, а старое ядро Битрикса с новым PHP работать откажется: сайт падает белым экраном без единой строчки в логе, понятной без разбора.
Есть и чисто практическая причина. Многие модули из маркетплейса (эквайринг, доставка, чат-боты) требуют минимальную версию главного модуля. Пока ядро старое, новую интеграцию просто не поставить, и приходится сначала тащить обновление, а потом уже саму доработку. Чем дольше сайт не обновляется, тем длиннее цепочка накопленных изменений и тем выше риск, что при обновлении что-то одно из десятка накопленных патчей конфликтует с локальными правками. Обновляться маленькими шагами почти всегда дешевле, чем один раз в три года прыгать через несколько версий подряд.
Подготовка к обновлению 1С-Битрикс
Перед любым обновлением я прохожу один и тот же чек-лист, и пропускать шаги здесь дороже, чем кажется на старте.
Бэкап базы и файлов
В панели управления есть штатный инструмент резервного копирования (раздел «Настройки» - «Резервное копирование»), который собирает архив базы и файлов в один пакет. Для сайтов с большой базой быстрее сделать это руками: mysqldump для базы и архив папки сайта отдельно. Главное правило - копия должна лежать не на том же диске, где крутится сайт, и её нужно хотя бы раз развернуть на тестовом окружении, чтобы убедиться, что архив реально восстанавливается, а не просто существует.
Тестовый сервер и локальные изменения
Обновление на боевом сайте без предварительной проверки на копии - это лотерея. В админке есть раздел «Проверка сайта» с пунктом «Изменённые файлы», который показывает, что в дистрибутиве было переписано руками. Если такие правки есть, до обновления решаю, что с ними делать: переносить логику в локальные шаблоны и обработчики событий или мириться с тем, что после обновления файл придётся восстанавливать вручную. Отдельно отключаю агенты (cron-задачи) на время обновления, чтобы фоновые скрипты не пытались отработать по старой логике во время смены версии модулей.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как проходит обновление: маркетплейс, ядро и модули
Стандартный путь - раздел «Маркетплейс» в админке, вкладка обновлений, где Битрикс показывает список доступных патчей для главного модуля и для каждого установленного модуля отдельно. Кнопка «обновить всё одним кликом» удобна для тестового сервера, но на боевом проекте я обновляю по частям: сначала главный модуль (ядро), проверяю, что сайт открывается и работает админка, потом остальные модули по очереди, с проверкой ключевых страниц после каждого шага.
| Способ обновления | Что нужно | Когда использую |
|---|---|---|
| Через маркетплейс в админке, одним кликом | Активная лицензия, доступ в панель управления | Плановое обновление после того, как та же версия уже проверена на копии сайта |
| Через SSH на тестовом сервере | Доступ по SSH, отдельная копия базы и файлов | Первая проверка обновления перед тем, как выпускать его на клиентский сайт |
| Точечное обновление одного модуля | Файлы модуля, резервная копия его таблиц в базе | Когда автообновление конфликтует с локальными правками в этом модуле |
После обновления смотрю вкладку мониторинга в разделе «Проверка сайта»: там видно ошибки PHP и предупреждения, которые не всегда всплывают на глаз при обычном просмотре сайта. Отдельно проверяю расписание агентов - после смены версии модуля порядок фоновых задач иногда сбивается, и часть из них перестаёт запускаться по расписанию.
Откат обновления Битрикс, если что-то пошло не так
В Битриксе нет кнопки «откатить обновление» - есть только восстановление из бэкапа, сделанного до начала обновления. Причём восстанавливать нужно и базу, и файлы вместе: если вернуть только файлы, а таблицы в базе уже успели поменяться под новую структуру модуля, получите ещё более странные ошибки, чем были до обновления. Поэтому бэкап «на всякий случай» из предыдущего раздела не формальность, а единственный рабочий путь назад.
На практике решение откатывать или чинить на месте я принимаю быстро: если после обновления не открывается ключевая функция сайта, например оформление заказа или личный кабинет, откатываюсь сразу и разбираюсь с причиной уже на тестовой копии, а не на боевом сайте с реальными покупателями. Если же ошибка локальная, например перестал работать один виджет в одном компоненте, часто быстрее временно отключить именно этот модуль или компонент, чем поднимать весь сайт из архива.
Что чаще всего ломается после обновления Битрикс
Три источника проблем повторяются из проекта в проект почти без вариаций.
Локальные правки в файлах ядра
Если в код ядра в своё время правили руками вместо использования локальных шаблонов и обработчиков событий, обновление либо перезатирает эти правки, либо конфликтует с новой версией того же файла. Старые проекты, которым лет пять и больше, почти всегда несут на себе такие правки, и перед обновлением я их выношу в нормальные точки расширения, чтобы обновление их больше не трогало.
Кастомные шаблоны и компоненты
Шаблоны компонентов, скопированные в локальную папку сайта, живут своей жизнью и не обновляются автоматически. Проблема начинается, когда сам компонент меняет сигнатуру метода или структуру возвращаемых данных - локальный шаблон продолжает обращаться к старому формату и падает с фатальной ошибкой прямо на публичной части сайта.
Сторонние модули и интеграции
Модули доставки, эквайринга и чат-ботов из маркетплейса обновляются отдельно от ядра и иногда меняют формат вебхука или логику расчёта. После любого обновления модуля доставки или платёжного модуля я отдельно прогоняю тестовый заказ с реальным расчётом стоимости, а не полагаюсь на то, что раз обновление прошло без ошибок в логе, значит и расчёты не изменились.
Если после обновления у клиента что-то отвалилось и нужно разобрать конфликт локальных правок с новой версией модуля, такую работу я оформляю как доработку и поддержку 1С-Битрикс - от 3 000 ₽/час. Плановое сопровождение, при котором обновления сначала тестируются на копии сайта и только потом идут в бой, обычно оформляют как техподдержку сайта - от 15 000 ₽/мес.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Как часто нужно обновлять Битрикс
Патчи безопасности для главного модуля стоит устанавливать по мере выхода, не дожидаясь накопления десятка версий. Крупные обновления с изменением структуры модулей я обычно ставлю на тестовую копию сразу после выхода, а на боевой сайт переношу после нескольких дней проверки, если для сайта не критична каждая минута простоя тестирования.
Можно ли обновлять Битрикс без бэкапа
Можно, но при первой же проблеме единственный путь назад закрыт. Панель Битрикса перед серьёзными обновлениями сама предлагает сделать бэкап, и пропускать это предложение смысла нет - создание архива занимает минуты, а восстановление сайта без него может занять дни.
Что делать, если сайт сломался после обновления
Сначала смотрю вкладку мониторинга в «Проверке сайта» и лог ошибок PHP - там обычно видно, какой модуль или файл вызывает фатальную ошибку. Если проблема в одном компоненте, отключаю его точечно. Если ошибка на уровне ядра или мешает ключевой функции сайта, восстанавливаюсь из бэкапа, сделанного перед обновлением, и разбираюсь с причиной уже на тестовой копии.
Нужно ли обновлять ядро и модули одновременно
Нет, и на боевом сайте я это специально разношу по шагам: сначала главный модуль, проверка, затем остальные модули по одному с проверкой сайта после каждого. Так проще понять, какое именно обновление вызвало проблему, вместо того чтобы разбирать сразу десять изменений одновременно.