Обновления и перенос
После composer update сайт перестал запускаться
После composer update PHP-сайт перестал запускаться. Разберём, что изменилось в зависимостях и почему повторное обновление на рабочем сервере может ухудшить ситуацию.
Что происходит и с чего начать
Composer управляет библиотеками проекта. Обновление может выбрать новые версии в разрешённых пределах и изменить зафиксированный набор зависимостей. Поэтому нужно сравнить состояние до и после, а не считать команду обычной переустановкой прежних файлов. Важны composer.json, composer.lock и версия PHP. Если код ожидает старое поведение библиотеки, новый набор способен сломать запуск или отдельную функцию. Первым делом сохраните ошибку и изменения, чтобы восстановление опиралось на известную рабочую конфигурацию, а не очередной случайный подбор.
Что можно проверить самостоятельно
- Сохраните текст ошибки и изменения файлов зависимостей. Уточните, выполнялась ли команда на рабочем сервере и остался ли прежний composer.lock в системе контроля версий.
- Запишите версии PHP и окружение запуска. Веб-сервер и командная строка могут использовать разные конфигурации, поэтому успешный CLI-тест не гарантирует запуск сайта.
- Определите, сломан весь проект или отдельная операция. До нового обновления сохраните текущие данные и согласуйте возврат к рабочему набору либо адаптацию к новым версиям.
Как понять результаты проверки
Разработчик сравнивает зависимости и требования платформы, затем выбирает контролируемое восстановление. Установка по согласованному lock-файлу и поиск новых версий — разные задачи. Нельзя игнорировать требования платформы просто ради прохождения установки: приложение может упасть позже при выполнении. Также проверяют собственные изменения в библиотеках, если они были сделаны вне нормального процесса. Постоянное решение должно храниться в коде проекта и воспроизводиться при чистой установке, а не зависеть от ручной правки внутри каталога vendor.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Проверьте изменения composer.lock и первую ошибку приложения. Уточните, какие версии действительно установлены в рабочем релизе.
- Сверьте PHP и расширения с требованиями зависимостей. Не обходите проверку платформы без понимания, какая возможность нужна пакету.
- Проверьте автозагрузку и наличие production-зависимостей. Код приложения не должен рассчитывать на пакет, установленный только для разработки.
На что обратить внимание
Команда update пересчитывает версии в заданных ограничениях, а не просто восстанавливает прежний набор. Выполнение её напрямую на рабочем сервере может дать состояние, отличное от протестированного.
Как исправляют причину
Соберите согласованный релиз по проверенному lock-файлу и исправьте несовместимый код. Для воспроизводимого деплоя устанавливайте зафиксированные зависимости. Откат учитывает также миграции и изменённые форматы данных.
Как убедиться, что проблема решена
Проверьте запуск веба, консольных команд и очереди из одного релиза. Сохраните обновлённый lock-файл в репозитории после успешной проверки совместимости.
Проверьте запуск из чистого согласованного набора зависимостей и основные сценарии сайта. Если исправлялась совместимость, тест должен затрагивать конкретную библиотеку, вызвавшую отказ. Зафиксируйте изменённый lock-файл и порядок публикации. Итогом станет повторяемая рабочая установка, а не случайно заработавший сервер, состояние которого невозможно восстановить на другой машине или после следующего обновления.