Белая страница, ошибка 500 или сообщение «На сайте произошла критическая ошибка» сразу после смены версии PHP — очень частая ситуация. Паника и случайные изменения настроек только запутывают дело. На самом деле порядок восстановления простой: сначала быстро вернуть сайт в рабочее состояние, затем спокойно найти причину и только потом снова перейти на новую версию. Разберём этот порядок на практическом примере.
Первые пять минут: вернуть сайт в рабочее состояние
Если сайт сломался сразу после смены версии PHP, причина почти наверняка в несовместимости с новой версией. Поэтому самое быстрое решение — вернуть прежнюю версию. В панели ISPmanager откройте нужный сайт в списке сайтов, выберите в настройках PHP предыдущую версию и сохраните. В большинстве случаев сайт снова заработает через несколько секунд, и клиенты даже не заметят проблемы.
Перед откатом полезно сделать одно действие: скопировать последние строки журнала ошибок или хотя бы записать текст ошибки. После запуска сайта эта информация останется в журнале, но если заранее знать время и файл ошибки, дальнейший анализ пойдёт быстрее.
Поиск причины в журнале
Белая страница или ошибка 500 ничего не говорят посетителю, но в журнале сервера причина записана точно. В ISPmanager журналы сайта можно посмотреть прямо в панели; обычно они хранятся в папке logs вашего аккаунта под именем домена. Если есть доступ по SSH, последние строки можно посмотреть так (имя файла может немного отличаться в зависимости от сервера):
# Последние 50 строк
tail -n 50 ~/logs/example.uz.error.log
# Только фатальные ошибки
grep "PHP Fatal error" ~/logs/example.uz.error.log | tail -n 20В строке журнала есть три важных элемента: тип ошибки, текст сообщения и путь к файлу с номером строки. Путь часто сразу указывает на проблемный плагин или тему, например на файл в папке wp-content/plugins/old-slider/. Так круг поиска сужается до одного компонента.
Самые частые ошибки и что они означают
При переходе старого кода на новый PHP одни и те же ошибки встречаются снова и снова. Таблица поможет быстро их распознать:
| Сообщение в журнале | Причина | Направление решения |
|---|---|---|
Call to undefined function mysql_connect() | Функции mysql_* удалены в PHP 7.0 | Перевести код на mysqli или PDO |
Call to undefined function create_function() или each() | Удалены в PHP 8.0 | Обновить плагин или код |
count(): Argument #1 ($value) must be of type Countable|array | В PHP 8 подсчёт не-массива стал ошибкой | Обновить плагин или добавить проверку в код |
Array and string offset access syntax with curly braces is no longer supported | Запись $str{0} удалена в PHP 8.0 | Заменить на $str[0] |
Call to undefined function mb_strlen() | В новой версии не включено расширение mbstring | Включить расширение в панели |
requires the ionCube PHP Loader | Загрузчик для закодированного скрипта отсутствует или несовместим | Включить загрузчик или получить совместимую версию у разработчика скрипта |
Последние два случая связаны не с кодом, а с настройками. У каждой версии PHP свой набор расширений, и включённое в старой версии расширение может быть выключено в новой. Тогда трогать код не нужно — достаточно включить расширение в панели. Если не получается сделать это самостоятельно, напишите тикет в техподдержку из кабинета sayt.uz.
Пример: сайт ресторана в Фергане
Сайт ресторана в Фергане example.uz работает на WordPress, на странице меню установлен старый плагин слайдера. Владелец перешёл с PHP 7.4 на 8.3 и вместо главной страницы увидел «На сайте произошла критическая ошибка». Первым делом он вернул 7.4, и сайт сразу восстановился. Затем в журнале нашлась ошибка count(): Argument #1 ($value) must be of type Countable|array, null given с путём к файлу в папке плагина слайдера.
Плагин не обновлялся несколько лет, так что ждать исправления не имело смысла. На тестовой копии владелец удалил его, установил другой активно поддерживаемый слайдер и заново разместил фотографии меню. Когда тестовая копия заработала на 8.3 без ошибок, те же изменения сделали на основном сайте и снова переключили PHP на 8.3.
Дополнительные инструменты WordPress
При фатальной ошибке WordPress отправляет на почту администратора письмо со ссылкой на режим восстановления. По ней можно войти в админку и отключить проблемный плагин. Если письмо не пришло, плагин можно отключить, переименовав его папку через файловый менеджер или SSH: WordPress не загружает плагин из переименованной папки.
cd ~/www/example.uz/wp-content/plugins
mv old-slider old-slider.offЧтобы ошибки записывались в файл, а не выводились на экран, можно временно добавить в wp-config.php строки ниже. Ошибки будут записываться в wp-content/debug.log. После проверки уберите эти настройки, так как файл журнала может быть доступен извне.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Что сделать перед повторным обновлением
Когда причина найдена и устранена, переходить на новую версию нужно без спешки. Надёжнее всего сначала проверить всё на тестовой копии: скопировать сайт на поддомен, например test.example.uz, назначить ему новую версию PHP и по очереди открыть основные страницы. Особенно важно проверить отправку форм, корзину, оплату и админку, потому что ошибка может проявляться только на конкретной странице.
- Перед обновлением сделайте резервную копию файлов и базы данных.
- Обновите все плагины и тему до последних версий, замените неподдерживаемые.
- Проверьте, что в новой версии включены нужные расширения.
- Переключайтесь в период низкой посещаемости и следите за журналом один-два дня.
Помните, что откат версии — лишь временное решение. Старые версии PHP не получают исправлений безопасности, поэтому, когда сайт снова заработал, не стоит успокаиваться: назначьте конкретный срок для исправления и повторного обновления.