Перейти к содержимому
BXWiki

После обновления отвалился функционал - разбор причин

Обновление платформы установилось до конца, сайт открывается, а часть функционала отвалилась: пропала фильтрация, перестали отправляться формы. Разбираем причины по убыванию частоты, начиная с того, чей код сломался.

С чего начать

Читаем журнал и смотрим путь упавшего файла:

Окно терминала
tail -n 80 /var/log/php-fpm/error.log | grep -iE 'fatal|undefined|error'
# /bitrix/modules/main/ и соседние каталоги - ядро платформы
# /bitrix/modules/vendor.solution/ - стороннее решение маркетплейса
# /local/ и /bitrix/templates/ - код самого проекта
# полный текст ошибки приходит в журнал, а не на страницу сайта

Путь упавшего файла делит причины пополам ещё до чтения кода. Файл ядра означает затёртую правку, а файл проекта - вызов, которого в новой версии больше нет.

Сверяем версии модулей, чей функционал отвалился:

Окно терминала
# версия каждого модуля лежит на диске, в install/version.php его каталога
grep -h '"VERSION"' /home/bitrix/www/bitrix/modules/{main,iblock,sale}/install/version.php
# в базе версий нет: система обновлений сравнивает именно эти файлы

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

Ищем правки, затёртые обновлением:

Окно терминала
# копию, снятую до обновления, сравниваем с чистым дистрибутивом той же версии
diff -rq /home/bitrix/dist/bitrix/modules /home/bitrix/backup/bitrix/modules | grep differ
# каталоги /local/ и шаблонов сайта в сравнении не участвуют: их обновление не трогает

Каталог /bitrix/ обновление считает своей собственностью и перезаписывает целиком. Сравнение с дистрибутивом называет файлы, которые правили руками.

Выполняем SQL-шаг, о котором просит админка:

-- текст запроса платформа печатает прямо в шапке админки, зелёной полосой
CREATE INDEX ix_iblock_element_prop_val
  ON b_iblock_element_property (VALUE(50), IBLOCK_PROPERTY_ID, IBLOCK_ELEMENT_ID);

Тяжёлые шаги обновление не выполняет само и оставляет их администратору сайта. Запрос прогоняют в разделе «Настройки - Инструменты - SQL-запрос».

Сбрасываем кэш опкода и файловый кэш:

Окно терминала
php -i | grep -E 'opcache.(enable|validate_timestamps)'   # 0 - файлы не перечитываются
systemctl restart php-fpm
# файловый кэш чистят из админки, а каталог managed_cache руками не трогают

Замена файлов на диске сама по себе не меняет картину мира внутри кэша опкода. Перезапуск обработчика PHP возвращает её в согласованное состояние за секунду.

Причины

  1. Обновление затёрло правки, внесённые прямо в каталог ядра примерно 30% случаев

    ПризнакОтвалилась ровно та доработка, которую когда-то делали под этот проект.

    ПроверкаСравниваем снятую до обновления копию с чистым дистрибутивом той же версии продукта.

    Что делатьПереносим правку в /local/ или в свой модуль: каталог /bitrix/ обновление перезаписывает целиком.

  2. Код зовёт метод, удалённый или переименованный в новой версии примерно 25% случаев

    ПризнакВ журнале стоит строка «Call to undefined method» с именем класса ядра.

    ПроверкаИщем этот вызов по коду проекта и по списку агентов, запускаемых по расписанию.

    Что делатьЗаменяем вызов действующим D7-аналогом либо дообновляем модуль, отставший от ядра платформы.

  3. Стороннее решение несовместимо с новой версией платформы примерно 20% случаев

    ПризнакПуть упавшего файла ведёт в каталог модуля с именем вида vendor.solution.

    ПроверкаСмотрим заявленную совместимость решения и дату последнего обновления самого модуля.

    Что делатьОбновляем решение отдельно от ядра, а до ответа автора отключаем его целиком.

  4. Не прогнаны SQL-шаги, которые обновление оставило вручную примерно 15% случаев

    ПризнакВ шапке админки висит зелёное сообщение с готовым текстом запроса к базе.

    ПроверкаЧитаем сообщение целиком: оно называет и таблицу, и нужный платформе индекс.

    Что делатьВыполняем запрос в консоли SQL и повторно открываем страницу с отвалившимся функционалом.

  5. Остался прежний кэш платформы и кэш опкода примерно 10% случаев

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

    ПроверкаСмотрим настройку проверки времени файлов в кэше опкода и дату файлов кэша.

    Что делатьПерезапускаем обработчик PHP и чистим файловый кэш из админки, а не руками.

Частые вопросы

Не работает часть функционала после обновления - с чего начинать?

С журнала ошибок и пути упавшего файла. Файл в /bitrix/ указывает на ядро и затёртые правки, файл в /local/ или в шаблоне - на код самого проекта.

Как убрать ошибку Call to undefined method после обновления?

Сначала проверить, что обновление доехало целиком: часто метод есть в свежем модуле, который просто не установился. Если модули на месте, вызов правят под новое API либо снимают агента, который его дёргает.

Пропали доработки, сделанные в файлах ядра. Их можно вернуть?

Только из копии, снятой до обновления: каталог /bitrix/ система обновлений перезаписывает целиком. Вернувшуюся правку сразу переносят в /local/, иначе следующее обновление затрёт её снова.

После обновления всплыло сообщение про SQL-запрос, что с ним делать?

Выполнить его в разделе «Настройки - Инструменты - SQL-запрос». Тяжёлые шаги вроде создания индекса обновление не делает само, а до их выполнения часть функционала работает медленно или не работает вовсе.

Можно ли откатить обновление, если функционал не вернулся?

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

Смежное

Первоисточник