«Дорогая, я обновил твой Битрикс»: почему сайт ломается и как не стать заложником кнопки «Обновить»

Обновление платформы — это не магия, а жестокая необходимость. Это закрытые дыры в безопасности (за которые вас могут оштрафовать на 400 тысяч рублей по 152-ФЗ) и новые фичи, которых нет у конкурентов. Но нажатие заветной кнопки в админке часто оборачивается «белым экраном смерти» и нервным тиком.

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

Причина №1: «Я тут немного поправил ядро...» (фатальная ошибка)

Это классика жанра. Разработчик (или «гуру-самоучка») решил, что стандартная логика модуля iblock работает недостаточно быстро, и полез править файлы в папке /bitrix/modules/. Или, что еще хуже, в /bitrix/components/bitrix/.

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

Официальная позиция: «Изменение файлов ядра системы в папках /bitrix/modules/ и /bitrix/components/bitrix/ приведет к потере изменений при обновлении ». Более того, вас могут лишить технической поддержки за такие шаманства.

Как избежать: Запомните мантру — не трогайте ядро! Есть срочная потребность расширить функционал? Используйте [событийную модель (OnAfter*)] или создавайте свои модули. Для шаблонов компонентов используйте механизм переопределения через папку /local/ .

Причина №2: Святая война /bitrix/ vs /local/ (история с шаблонами)

Наиболее частая история, описанная в профильных блогах. Допустим, вы взяли готовое решение (например, комплексный компонент интернет-магазина) и, чтобы поменять верстку, полезли править шаблон прямо в /bitrix/templates/aspro_next/components/....

Что происходит: Решение обновляется из Маркетплейса. Папка /bitrix/ полностью перезаписывается актуальными файлами. Все ваши правки, сделанные внутри стандартного или стороннего компонента, безвозвратно теряются. В итоге на сайте либо пропадает верстка, либо, если вы правили PHP-логику, он сыпет ошибками.

«Классическая картина: обновился компонент в /bitrix/, а его кастомная версия в /local/ осталась прежней. В результате половина логики работает по-новому, половина — по-старому» .

Как избежать: Всегда копируйте шаблон компонента в папку /local/templates/Ваш_шаблон/components/bitrix/название_компонента/. Это буквально «золотое правило» Битрикса . Обновления не трогают папку /local/ . Да, на это уйдет на пару часов больше времени на старте, но это сэкономит вам недели дебага в будущем.

Причина №3: «А что, версию PHP тоже обновлять?!» (несостыковка окружения)

Однажды разработчики «Битрикса» решили жить в ногу со временем и перешли на D7 (современное ORM), а вместе с этим начали требовать PHP 8.1+ . Вы честно обновили платформу, нажав кнопку, а сайт упал с ошибкой Call to undefined function ....

Что происходит: Ваш старый хостинг работает на PHP 5.6 или 7.0. Новый код ядра использует функции, которых в старой версии PHP нет. Либо ваш старый кастомный код, написанный в 2015 году, вызывает депрекейтед функции, которые выпилили в новой версии PHP.

Реальный пример: В версии ядра 22.100 была обнаружена ошибка, из-за которой сайт падал в exception при добавлении параметра USER_FIELD_MANAGER=1 . Это баг, но он проявляется только при определенных условиях. Если же говорить про системные ошибки, то прямая дорога к проблемам лежит через игнорирование системных требований.

Как избежать: Перед обновлением платформы проверьте, поддерживает ли ваш сервер актуальную версию PHP и модули (например, mbstring, json). Используйте встроенную «Проверку системы» в админке. Она подсветит проблему сразу. И никогда не обновляйте PHP и Битрикс одновременно — делайте это поэтапно .

Причина №4: Обновление Аспро (или любого готового решения) — это квест

Разработчики готовых решений (Аспро, Интент, etc.) любят завязывать свои модули на огромное количество кастомных файлов. Обновление таких решений — это отдельный вид искусства.

«Обновление Аспро — это не просто нажать кнопку «Обновить», а полноценный квест. Оно всегда требует внимания и понимания, как работает связка /bitrix/ и /local/» .

Что происходит: Обновление из Маркетплейса затирает ваши доработки в шаблоне решения. Особенно часто страдают файлы в /bitrix/templates/aspro_* и кастомные компоненты /bitrix/components/aspro/. После обновления могут отвалиться: фильтры, карточка товара (слетает $arResult), корзина (API модуля Sale изменился) .

Как избежать:

1. Перед обновлением сделайте дамп базы и файлов.
2. Скопируйте все свои шаблоны в /local/ (если не сделали этого раньше).
3. Протестируйте обновление на тестовом стенде. Если у вас нет тестового стенда — устройте его. Это единственный способ увидеть проблемы до того, как их увидят клиенты .

Причина №5: Сломанная база данных и миграции (кнопка — зло)

Нажатие кнопки «Обновить» в админке — это «русская рулетка» для базы данных. Поскольку при обновлении меняется структура БД (добавляются поля, индексы, таблицы), процесс может прерваться на полпути. Если админка умерла, восстановить процесс штатно уже нельзя.

«В итоге либо получаем ошибку сразу (что не так плохо), либо система обновляется частично и процесс обновления прерывается. Повезет, если админка продолжит функционировать. А вот если админка умирает, то тут уже расчехляем бэкапы» .

Как избежать (профессиональный подход): Вместо нажатия кнопки на проде, используйте подход с миграциями. Схема:

1. Поднимаете дев-площадку.
2. Включаете логирование SQL-запросов ($DBDebugToFile = true в dbconn.php).
3. Нажимаете обновление на дев-площадке.
4. Анализируете лог SQL, удаляете мусор (SELECT, SHOW).
5. Превращаете оставшийся SQL в скрипты миграций (например, через модуль sprint.migration).
6. Запускаете эти миграции на проде по частям (чанками) в транзакциях .

Да, это сложно и долго. Но когда у вас проект, который не обновлялся 3 года, это единственный способ не остаться без продаж на неделю .

Чек-лист: Как не сломать сайт (или сломать, но контролируемо)

1. Бэкап — всему голова. Перед любым обновлением делайте бекап файлов и базы данных. Держите его на отдельном носителе. Проверяйте, что он восстанавливается .
2. Тестовый стенд. Если у вас нет копии сайта для тестирования — вы не профессионал. Это аксиома .
3. Читайте Changelog. Загляните на dev.1c-bitrix.ru и посмотрите, что именно поменялось в новом релизе. Это может спасти от неожиданностей .
4. Проверяйте файлы. Используйте find или встроенный поиск по дате модификации, чтобы понять, какие файлы перезаписались, и не потеряли ли вы критичные правки .
5. Следите за ошибками. Включите display_errors на время тестирования или смотрите в логи .

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