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

Сайт сломался после установки решения - разбор причин

Решение установлено, и сразу после этого витрина поехала или страница перестала открываться. Разбираем причины по убыванию частоты, начиная с самого решения.

С чего начать

Смотрим, что именно установилось и когда:

Окно терминала
ls -lt /home/bitrix/www/bitrix/modules/ | head -5
ls -lt /home/bitrix/www/bitrix/templates/ | head -5
ls -lt /home/bitrix/www/local/templates/ 2>/dev/null | head -5
# свежие каталоги называют и само решение, и его шаблоны
# каталог local смотрят отдельно: решения ставятся и туда, и в bitrix

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

Читаем журнал ошибок за время установки:

Окно терминала
tail -100 /var/log/php-fpm/bx0-error.log | grep -iE 'fatal|error'
grep -ri 'vendor.module' /home/bitrix/www/bitrix/modules/error.log | tail -5
grep -ri 'vendor' /home/bitrix/www/bitrix/php_interface/dbconn.php 2>/dev/null
# имя решения в ошибке снимает половину вопросов сразу

Смотрим обработчики, которые повесило решение:

$conn = \Bitrix\Main\Application::getConnection();
print_r($conn->query("SELECT FROM_MODULE_ID, MESSAGE_ID, TO_MODULE_ID, TO_CLASS, TO_METHOD
    FROM b_module_to_module WHERE TO_MODULE_ID LIKE 'vendor.%'")->fetchAll());
// обработчики решения выполняются на каждом запросе к сайту

Обработчики - самый частый источник поломки. Решение подписывается на события корзины, заказа или сохранения элемента, и его ошибка выглядит как поломка штатного механизма платформы.

Отключаем решение целиком на минуту:

\Bitrix\Main\ModuleManager::isModuleInstalled('vendor.module');   // проверка факта
print_r(\Bitrix\Main\ModuleManager::getInstalledModules());       // весь состав
// снятие модуля в административном разделе удаляет и его обработчики

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

Причины

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

    ПризнакОшибка появляется на любой странице сайта, включая административный раздел.

    ПроверкаСмотрим таблицу обработчиков и ищем среди них классы установленного решения.

    Что делатьСнимаем решение и обращаемся к его разработчику с текстом ошибки и версией платформы.

  2. Решение подменило шаблон компонента или стили витрины примерно 25% случаев

    ПризнакСайт работает, но вёрстка блока поехала или пропал привычный элемент страницы.

    ПроверкаСравниваем каталоги шаблонов по времени правки и смотрим подключённые файлы стилей.

    Что делатьВозвращаем свой шаблон компонента и подключаем стили решения адресно, а не на весь сайт.

  3. Решению не хватает модуля или версии платформы примерно 20% случаев

    ПризнакСтраница падает с сообщением о неизвестном классе или об отсутствующем методе.

    ПроверкаЧитаем требования решения и сверяем их с составом установленных на сайте модулей.

    Что делатьДоустанавливаем нужный модуль либо отказываемся от решения на этой редакции продукта.

  4. Решение положило свои файлы в каталог ядра примерно 15% случаев

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

    ПроверкаПроверяем каталог ядра на файлы решения и сверяем их с проверкой целостности.

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

  5. Агент решения грузит сервер и вешает страницы примерно 10% случаев

    ПризнакСайт стал заметно медленнее, а нагрузка растёт волнами без роста посещаемости.

    ПроверкаСмотрим список агентов и время их выполнения, отбирая появившиеся после установки.

    Что делатьОтключаем агент решения или переносим его запуск на ночь через задание по расписанию.

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

Как быстро понять, виновато ли решение?

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

Почему поломка появилась не сразу после установки?

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

Можно ли просто удалить каталог решения?

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

Что делать, если решение нужно, а оно ломает сайт?

Написать разработчику с текстом ошибки, версией платформы и шагами повтора. До ответа решение держат выключенным на боевом сайте.

Как проверять решения заранее?

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

Смежное

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