Поэтому обновления лучше вести в рамках регулярной технической поддержки сайта, а не как разовую аварийную работу.
Обновления нужны не ради версии в админке. Они нужны, чтобы сайт оставался безопасным и готовым к развитию. Если не обновляться годами, новая задача становится дороже: сначала приходится разбирать технический долг, чинить совместимость, проверять бэкапы и только потом делать то, ради чего клиент обратился.
Эта статья для владельцев сайтов и начинающих разработчиков. Первым она поможет понять смысл обновлений. Вторым покажет, почему обновление начинается не с кнопки, а с диагностики.
Если сайт на Битрикс давно не обновлялся, начните с диагностики. WEB-AiM занимается поддержкой и развитием сайтов на 1С-Битрикс и помогает определить безопасный порядок работ: что обновить штатно, что вынести на dev-копию, а где сначала нужен серверный переезд.
Что именно обновляется
В обновлении есть несколько слоёв.
Первый слой — ядро
Ядро 1С-Битрикс или коробочного Битрикс24. В нём выходят исправления безопасности, поддержка новых версий PHP, доработки магазина, CRM и админки.
Второй слой — модули
Это стандартные модули Битрикс, решения из Marketplace, оплата, доставка, обмен с 1С.
Третий слой — шаблон и кастомные доработки
Если готовый шаблон несколько лет меняли под клиента, в нём могут быть особая карточка товара, региональные телефоны, склады, доставка, корзина, письма и фильтры. Такое нельзя обновлять вслепую.
Четвёртый слой — серверное окружение
PHP, MariaDB или MySQL, nginx, почта, cron, BitrixVM, SSL, место на диске, права, резервное копирование. Иногда сайт невозможно обновить, пока он работает на старом PHP или устаревшей виртуальной машине Битрикс.
Почему владельцу сайта лучше не откладывать
Главная причина — безопасность. Старые версии ядра, модулей и PHP чаще содержат известные уязвимости. Популярные CMS постоянно сканируются ботами, поэтому проблема может проявиться не из-за особого интереса к сайту, а из-за массовой проверки.
Вторая причина — стоимость развития. Когда проект не обновлялся несколько лет, разработчик сначала тратит время на перенос на новый PHP, обновление модулей, восстановление бэкапов и исправление старых ошибок. Клиент платит не только за новую возможность, но и за возвращение проекта в рабочее техническое состояние.
Третья причина — стабильность интеграций. У интернет-магазинов часто есть обмен с 1С, CRM, доставка, онлайн-оплата, email-уведомления и выгрузки. Любое изменение у внешнего сервиса может проявить старую проблему.
Четвёртая причина — бэкапы. Перед обновлением мы всегда проверяем резервное копирование. Иногда выясняется, что бэкапы давно не уходят в облако или на диске мало места.
Как выглядит безопасный процесс
Сначала проводится диагностика: версия ядра, модули, PHP, сервер, лицензия, ошибки Монитора качества, бэкапы, свободное место и критичные сценарии.
Для интернет-магазина это:
- главная страница;
- каталог;
- карточка товара;
- корзина;
- оформление заказа;
- оплата;
- доставка;
- формы;
- личный кабинет;
- админка;
- обмены.
Затем делается свежий бэкап. Если проект сложный, разворачивается копия на dev-сервере. На копии можно переключить PHP, поставить обновления, увидеть ошибки и составить список правок.
После этого важна последовательность. Иногда сначала нужно поставить доступные обновления на текущем PHP, потом переключить PHP и только затем применить правки из git. Если поменять порядок, можно получить нерабочий сайт.
Финальный этап — проверка. Для разработчика это логи, админка, инфоблоки, почтовые события, cron, формы, заказы, сделки, REST, обмены и бэкапы.
Для владельца важнее результат: покупатель оформляет заказ, менеджер видит заявку, письма уходят, цены и остатки обновляются.
Кастомизированные шаблоны: отдельная зона риска
Кастомизированный шаблон часто выглядит как готовое решение, но внутри уже стал индивидуальной разработкой. За годы там могли изменить карточку товара, региональность, фильтр, корзину, письма, доставку и вывод складов.
Если обновить такой шаблон автоматически, можно потерять доработки. Поэтому сначала нужно понять, какие файлы менялись, что вынесено в /local, что осталось в /bitrix/templates, есть ли история в git и где находится бизнес-логика.
После этого принимается решение: обновлять шаблон полностью, переносить изменения вручную, применять патчер безопасности поставщика или не трогать шаблон, если лицензия закончилась и риск выше пользы.
В одном из проектов WEB-AiM два сайта на одной лицензии нужно было перевести на PHP 8 и обновить Битрикс. Оба сайта работали на кастомных шаблонах и находились на стороннем хостинге. Работы делали через тестовый контур. После обновления исправили неработающие элементы, сайты заработали на PHP 8.2, обновления были установлены.
На проекте OOO-MVB.ru обновление затрагивало не только сайт, но и CRM-сценарии. Проверяли главную, каталог, формы, pop-up, админку, создание сделок, выбор товаров, прохождение сделки по этапам. Это хороший пример: после обновления нельзя ограничиваться главной страницей.
Серверные обновления: PHP, BitrixVM, почта и бэкапы
Серверное обновление не ограничивается установкой свежего PHP. Для Битрикс-проекта сервер влияет на производительность, почту, бэкапы, обмены, cron, загрузку файлов, SSL и стабильность админки.
Типовая ситуация: проект работает на старой PHP и старой BitrixVM. Битрикс уже не позволяет ставить часть обновлений, Монитор качества показывает предупреждения, а разработчики не могут внедрять новые функции без риска.
Тогда безопаснее развернуть новый сервер, настроить актуальную BitrixVM, перенести сайт, отдельно перенести upload, проверить cron, почту, права, SSL, редиректы и мониторинг.
На gk-lynx.ru использовалась коробочная версия Битрикс24 в связке интернет-магазина и CRM. Перед обновлением сделали копию на dev, подключили проект к git, обновили ядро и проверили работоспособность. После переноса на боевой контур проект перевели на PHP 8, диагностика стала зелёной, письма приходили, CRM работала, автоматическая проверка страниц не нашла проблем.
На AGSX накопилось много неустановленных обновлений, а портал оставался на PHP 7. В итоге обновили виртуальную машину, поставили обновления Битрикс, перевели PHP на 8.2 и прошли тесты без ошибок.
На saintbor задача включала PHP, обновление проекта и перенос на новый сервер. Это типичный старый проект, который страшно трогать, но нужно поддерживать. Если заранее собрать пошаговый план, проверить бэкапы, окружение и порядок переключения, даже старый проект можно обновлять управляемо.
Что важно начинающему разработчику
- Не начинайте с кнопки обновления. Сначала зафиксируйте исходное состояние: версии, список модулей, PHP, ошибки, ветку git, дату бэкапа, свободное место и сценарии проверки.
- Не обновляйте боевой сайт без копии, если проект сложный или давно не обслуживался. Dev-контур экономит время, потому что большая часть ошибок проявится до переключения.
- Не доверяйте только визуальной проверке главной страницы. В Битриксе часто ломается то, что не видно сразу: почтовые шаблоны, события, REST, обмен с 1С, обработчики заказов, права, кеш и агенты.
- Не смешивайте обновление ядра, шаблона, серверный переезд и новые доработки в одну бесконтрольную работу. Лучше разделить этапы: подготовка, копия, обновление, исправления, боевой перенос, финальная проверка.
- Ведите изменения в git. Если обновление затёрло часть кастомизации, история помогает понять, что именно изменилось и что нужно вернуть. Без git разработчик часто вынужден угадывать.
- Пишите чек-лист под конкретный проект. У интернет-магазина с оплатой и доставкой один набор проверок. У коробочного Битрикс24 другой: сделки, лиды, задачи, почта, бизнес-процессы, REST, права, роботы и интеграции.
Если у вас коробочный портал или CRM с доработками, полезно отдельно смотреть техподдержку CRM/Битрикс24: обновления могут затрагивать сделки, роботов, почту, права и интеграции.
Когда пора обновляться
Есть несколько явных признаков:
- Битрикс ругается на старый PHP;
- обновления давно не ставились;
- лицензия активна, но система не обновляется;
- не проходят бэкапы;
- появились ошибки в Мониторе качества;
- интеграции работают нестабильно;
- разработчики говорят, что сначала нужно обновить платформу.
Владелец сайта может воспринимать обновление как расход без видимого результата. На практике это техническая страховка бизнеса. Обновление снижает риск взлома, упрощает поддержку и помогает избежать ситуации, когда срочную задачу невозможно сделать из-за устаревшего окружения.
Хорошее обновление незаметно для покупателей. Сайт работает, заказы приходят, менеджеры продолжают работать в CRM. Но за этой незаметностью стоит подготовка: диагностика, резервные копии, тестовый контур, аккуратная работа с шаблоном, правильная последовательность обновлений и проверка реальных сценариев.
Если проект давно не обновлялся, лучший первый шаг — провести аудит. Нужно понять, что обновляется штатно, что требует dev-копии, где есть риск по шаблону, нужен ли переезд сервера и какие сценарии проверить после работ. Так обновление перестаёт быть лотереей.
Если не уверены, в каком состоянии проект на 1С-Битрикс или Битрикс24, начните с короткого аудита. WEB-AiM проверит ядро, модули, PHP, сервер, шаблон, бэкапы и критичные сценарии, а затем предложит безопасный порядок работ в рамках поддержки и развития проекта.