WordPress показывает белый экран после перехода на PHP 8.2

Почему после переключения WordPress на PHP 8.2 появляется белый экран

Если WordPress перестал формировать страницу сразу после перехода на PHP 8.2, первым подозреваемым становится PHP-код или PHP-окружение, которое изменилось вместе с версией. Когда показ ошибок посетителю отключён, вместо текста Fatal error браузер может получить пустой ответ или страницу с HTTP 500.

Сценарий обычно выглядит просто: на PHP 7.4, 8.0 или 8.1 сайт открывается, в панели выбирают PHP 8.2, после чего главная становится белой. Возврат прежней версии восстанавливает работу. Это ещё не показывает виновный файл, но круг поиска уже сильно сужается.

Причём не всегда падает весь WordPress. Один сайт перестаёт открываться полностью, у другого ломается только публичная часть, а /wp-admin/ продолжает работать. Иногда ошибка возникает только на карточке товара, странице с конкретным shortcode или URL, где запускается определённый виджет. Бывает обратная картина: главная открывается, а AJAX, REST API или cron уже падают на новой версии PHP.

Полезный первый тест занимает несколько минут: зафиксировать текущую версию PHP, вернуть прежнюю, открыть проблемную страницу и проверить /wp-admin/. Если сайт ожил, дальше уже не нужно гадать. Нужно поймать ошибку.

Нужно ли сразу откатывать PHP 8.2, если сайт перестал открываться

Если рабочий WordPress лёг сразу после смены PHP, временный откат — нормальный первый шаг. Он возвращает сайт посетителям и одновременно работает как диагностический тест. Оставлять старую версию PHP навсегда не нужно, но чинить коммерческий сайт в состоянии постоянного HTTP 500 тоже нет смысла.

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

Если после отката сайт по-прежнему белый, связь с PHP 8.2 уже не так очевидна. Возможно, одновременно изменился обработчик, PHP-FPM не поднялся корректно, очистился кеш или проблема просто совпала по времени с другим изменением. Сам факт переключения версии ещё ничего не доказывает.

Если же старая версия PHP стабильно работает, а PHP 8.2 стабильно роняет тот же запрос, связь подтверждена достаточно хорошо. Теперь новую версию лучше включать либо на staging, либо в короткое контролируемое окно, когда можно сразу открыть журнал и воспроизвести ошибку.

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

Где найти настоящую ошибку PHP, если WordPress показывает только пустую страницу

Причину белого экрана лучше искать в PHP error log или в wp-content/debug.log. Одна строка Fatal error с путём к файлу обычно полезнее десяти попыток отключать плагины наугад.

Где искать PHP error_log

На хостинге для WordPress точное расположение журнала зависит от конфигурации сервера. Журнал может быть доступен в панели управления сайтом, находиться рядом с файлами виртуального хоста, записываться отдельным PHP-FPM pool или уходить в системный журнал службы. При HTTP 500 полезно проверить и журнал ошибок веб-сервера.

Если есть SSH-доступ и путь к журналу известен, последние записи можно посмотреть так:

tail -n 100 /path/to/error.log

Для наблюдения во время воспроизведения ошибки:

tail -f /path/to/error.log

Если файл большой:

grep -iE "fatal|uncaught|error" /path/to/error.log | tail -n 50

Смотрите не только на текст ошибки. Нужны четыре вещи: время, тип ошибки, путь к PHP-файлу и номер строки. Если журнал содержит stack trace, сохраняйте его целиком — путь в первой видимой строке не всегда показывает настоящую первопричину.

Как временно включить WP_DEBUG

Если серверный журнал недоступен, WordPress умеет писать собственный debug log. В wp-config.php можно временно включить:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

При такой конфигурации WordPress обычно пишет сообщения в wp-content/debug.log, но не выводит технические детали посетителям. После диагностики отладку лучше отключить.

WP_DEBUG_LOG не заменяет серверный журнал PHP-FPM. Если выполнение останавливается слишком рано или запрос вообще не доходит до нормальной загрузки WordPress, в debug.log нужной записи может не оказаться.

Что делать, если PHP error_log пуст

Пустой журнал — тоже диагностический сигнал. Если браузер стабильно получает ошибку, а в ожидаемом PHP error log ничего нет, сначала нужно убедиться, что вы вообще смотрите журнал того обработчика, который обслуживает домен.

1. Откройте проблемный URL и зафиксируйте точное время запроса.
2. Проверьте, какой PHP handler назначен домену в панели.
3. Сверьте PHP-FPM pool и его журнал.
4. Посмотрите журнал веб-сервера на то же время.
5. Проверьте через web-PHP параметры log_errors и error_log.
6. Повторите один контролируемый запрос и снова сравните журналы по времени.

Если HTTP-ответ уже не 500, а, например, 502 или 504, бессмысленно сразу разбирать плагины WordPress. Сначала нужно проверить, отвечает ли PHP-FPM и доступен ли upstream вообще. Это уже другая ветка диагностики.

Если ответ приходит с кодом 200, тело пустое, а PHP-ошибок нет, причиной может быть не Fatal error. Тогда придётся проверить код на ранний exit/die, нестандартный обработчик запроса, кеш или другой сценарий, при котором WordPress сознательно не формирует обычную страницу.

Сначала ловим фатал, потом уже лечим. Получив конкретный путь вроде wp-content/plugins/example-plugin/... или wp-content/themes/child-theme/functions.php, можно перейти от общего симптома к конкретному компоненту.

Как понять, виноват плагин WordPress или сама версия PHP 8.2

Если Fatal error указывает на файл внутри wp-content/plugins/, первым кандидатом становится соответствующий плагин. Это ещё не абсолютное доказательство: один модуль может вызвать функцию другого, а stack trace иногда заканчивается в WordPress Core, хотя ошибка пришла из стороннего кода.

Путь ведёт в plugins — сервер пока не трогаем. Сначала изолируем компонент.

Если административная панель доступна, деактивируйте подозрительный плагин обычным способом. При недоступном /wp-admin/ каталог можно временно переименовать через файловый менеджер или SSH:

wp-content/plugins/example-plugin/
wp-content/plugins/example-plugin-disabled/

WordPress перестанет загружать плагин по прежнему пути. После этого снова воспроизведите проблему на PHP 8.2. Если белый экран исчез, связь с компонентом становится намного сильнее.

При наличии WP-CLI:

wp plugin list
wp plugin deactivate plugin-slug

Отключение всех плагинов:

wp plugin deactivate --all

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

После локализации не ограничивайтесь выводом «этот плагин несовместим». Проверьте, существует ли новая версия, не входит ли проблемный PHP-файл в старую библиотеку внутри расширения и воспроизводится ли ошибка после обновления компонента.

Есть ещё один важный сценарий: плагин отключили, сайт снова упал, но уже с другим Fatal error. Это не означает, что первая диагностика была неправильной. Первый Fatal просто останавливал выполнение раньше. После его устранения PHP дошёл до следующего несовместимого участка.

Такое особенно заметно на старых проектах, которые перескакивают через несколько поколений PHP. После каждого изменения повторяйте один и тот же цикл: запрос → свежий лог → новый stack trace.

Как проверить тему WordPress и functions.php на несовместимость с PHP 8.2

Если ошибка ведёт в wp-content/themes/, functions.php или дочернюю тему, искать нужно уже не среди обычных плагинов. Родительская тема может быть свежей, а кастомный PHP-код в child theme при этом оставаться неизменным годами.

Посмотрите полный путь из Fatal error. Если он ведёт в активную тему, временно переключите WordPress на одну из стандартных тем, уже установленных на сайте. Через WP-CLI:

wp theme list
wp theme activate theme-slug

После переключения снова откройте проблемную страницу на PHP 8.2. Если сайт заработал, круг поиска сужается до прежней темы, её библиотек, functions.php, шаблонов и пользовательских вставок.

Отдельно проверяйте child theme. Обновление родительской темы не исправляет автоматически код, который разработчик когда-то добавил в дочернюю. Точно так же остаются незатронутыми PHP-сниппеты, собственные интеграции и файлы, вручную добавленные в проект.

Если после переключения на стандартную тему ничего не изменилось, тему можно временно убрать из списка основных подозреваемых и переходить к конфигурации PHP, mu-plugins, drop-ins и кеширующим компонентам.

Но есть пограничный случай: фронтенд падает, а /wp-admin/ работает. Здесь тема становится особенно подозрительной, потому что часть её кода выполняется только при формировании публичной страницы. Проверяйте шаблон конкретного URL, hooks, shortcodes и функции, которые запускаются только на фронтенде.

Какие ошибки PHP 8.2 чаще всего выявляют старый код WordPress

При белом экране в первую очередь ищите сообщения, которые действительно останавливают выполнение: Fatal error, необработанный Error, TypeError или другую исключительную ситуацию без обработчика. Большое количество Deprecated в журнале само по себе ещё не объясняет падение страницы.

Как читать Fatal error и stack trace

Условная запись может выглядеть так:

PHP Fatal error: Uncaught TypeError:
Example_Service::build(): Argument #1 ($config) must be of type array, null given
in /var/www/site/wp-content/plugins/example-plugin/includes/class-service.php:84

Stack trace:
#0 /var/www/site/wp-content/plugins/example-plugin/example-plugin.php(...): Example_Service->build(NULL)
#1 /var/www/site/wp-includes/class-wp-hook.php(...): example_bootstrap(...)
#2 {main}

Из такой записи нужно взять не только название последнего файла. Сначала смотрим тип ошибки — TypeError. Затем сообщение: метод ожидал массив, а получил null. После этого — файл и строку, где PHP остановился. И только потом читаем stack trace сверху вниз, чтобы понять, кто вызвал проблемный метод.

Если в trace присутствует wp-includes/class-wp-hook.php, это не повод сразу обвинять WordPress Core. Core мог лишь выполнить hook, зарегистрированный сторонним плагином. То же самое относится к vendor/: нужно определить, какому плагину или теме принадлежит библиотека.

Какие ошибки действительно могут остановить страницу

Почему Deprecated ещё не объясняет белый экран

После перехода на PHP 8.2 старый проект может засыпать журнал сообщениями Deprecated. Например, код может использовать механизмы, которые новая ветка PHP уже считает устаревающими. Это технический долг и его лучше исправить, но по умолчанию само сообщение Deprecated обычно не обрывает выполнение страницы.

Типичная ловушка — открыть большой debug.log, увидеть десятки Deprecated и начать исправлять их по одному, хотя ниже находится одна строка Uncaught TypeError. Не лечим весь лог сразу. Сначала ищем то, что роняет выполнение.

Есть и исключение: сторонний код может превращать предупреждения или deprecated-сообщения в исключения собственным error handler. Поэтому оценивать нужно не только название уровня, но и то, чем заканчивается конкретный stack trace.

Не все поломки после перехода вызваны именно нововведением PHP 8.2

Если сайт переключили сразу с PHP 7.4 на PHP 8.2, в одном изменении фактически встретились несовместимости нескольких поколений PHP. Поэтому фраза «PHP 8.2 сломал плагин» может быть слишком упрощённой. Код мог перестать быть совместимым ещё на переходе к PHP 8.0 или 8.1, просто раньше эту ветку на сайте не включали.

Практический вывод здесь простой: ориентируйтесь не на предположение о конкретном изменении языка, а на реальный Fatal error, файл, строку и stack trace. Именно они показывают, что исправлять.

Может ли WordPress падать на PHP 8.2 из-за memory_limit или расширений PHP

Да. После смены версии PHP WordPress может получить другой php.ini, другой лимит памяти или другой набор расширений. Тогда проблема выглядит как несовместимость PHP 8.2, хотя тот же код способен нормально работать при одинаковом окружении.

Как проверить memory_limit

Если в журнале есть:

Allowed memory size of ... bytes exhausted

PHP остановился из-за исчерпания памяти. Для CLI текущее значение можно посмотреть командой:

php -i | grep memory_limit

Но этот результат относится к PHP CLI. Веб-сайт может обслуживаться другим PHP-FPM pool с другим конфигурационным файлом. Реальное значение для WordPress лучше сверить через панель, WordPress Site Health или временную страницу phpinfo(), доступ к которой ограничен и которая удаляется сразу после проверки.

Просто увеличить memory_limit до большого значения — слабая диагностика. Если конкретный плагин съедает память из-за ошибки или слишком тяжёлой операции, повышение лимита лишь передвинет точку падения. Сначала сравните, не изменился ли сам лимит после перехода на PHP 8.2.

Как понять, какой php.ini использует сайт

В выводе web-версии phpinfo() найдите параметр Loaded Configuration File. Он показывает основной конфигурационный файл PHP, который обслуживает этот HTTP-запрос. Рядом полезно проверить каталоги дополнительных INI-файлов, потому что расширения и отдельные настройки могут подключаться через дополнительные конфиги.

Сравнивать стоит именно web-PHP старой и новой версии. Команда php --ini по SSH показывает конфигурацию CLI и сама по себе не отвечает на вопрос, какой php.ini читает PHP-FPM вашего домена.

Какие расширения PHP проверить

Отсутствующее расширение часто выдаёт себя сообщением об неизвестной функции или классе. Набор нужных модулей зависит от конкретного проекта. В разных установках WordPress и плагинах могут использоваться mbstring, intl, curl, mysqli, xml, zip, GD или Imagick.

Для CLI список модулей:

php -m

И снова: php -m описывает CLI. Для web-PHP набор расширений проверяйте через панель, phpinfo() или другой штатный механизм конкретного хостинга.

Сравните старую и новую среду минимум по четырём пунктам: memory_limit, загруженные extensions, Loaded Configuration File и обработчик домена. Версия PHP поменялась одной цифрой, а окружение при этом могло поменяться заметно сильнее.

Почему php -v по SSH может показывать не ту версию PHP, на которой работает WordPress

Команда php -v показывает версию PHP CLI. WordPress в браузере обычно обслуживается через PHP-FPM или другой веб-обработчик, поэтому эти версии не обязаны совпадать.

На сервере могут одновременно существовать PHP 8.1 для одного сайта, PHP 8.2 для другого и отдельная версия, назначенная CLI по умолчанию. Отсюда классический диагностический тупик: по SSH php -v показывает 8.2, администратор уверен, что сайт тоже работает на 8.2, а домен в панели по-прежнему подключён к другому PHP-FPM.

Базовые команды:

php -v
php --ini
php -m

покажут версию CLI, конфигурацию CLI и CLI-модули. Для просмотра служб PHP-FPM на сервере может пригодиться:

systemctl status php*-fpm

Если WordPress размещён на VPS / VDS, такие проверки обычно выполняются непосредственно на сервере. Конкретные имена служб, сокетов и конфигурационных файлов зависят от дистрибутива и способа установки PHP, поэтому универсального пути здесь нет.

Если wp-admin недоступен, проверить web-PHP всё равно можно через панель или временный защищённый PHP-файл, который выполняется через тот же домен. Главное — не делать вывод о сайте только по SSH.

CLI — не веб. Для диагностики белого экрана нужно проверять именно PHP, который обслуживает HTTP-запрос проблемного домена.

Что проверить, если плагины и тема совместимы, а белый экран на PHP 8.2 остаётся

Если обычные плагины отключены, тема заменена, а WordPress всё равно падает, значит стандартная проверка закончилась. Именно здесь диагностика часто застревает: в списке Plugins всё выключено, но сторонний PHP-код продолжает выполняться.

Как проверить mu-plugins и drop-ins

Must-use plugins находятся в:

wp-content/mu-plugins/

Они загружаются иначе, чем обычные плагины, и не отключаются стандартной кнопкой Deactivate. Поэтому фраза «все плагины выключены» ещё не означает, что WordPress работает без стороннего кода.

Проверьте также drop-ins. В первую очередь:

wp-content/object-cache.php
wp-content/advanced-cache.php

object-cache.php может продолжать участвовать в работе object cache независимо от обычного списка plugins. advanced-cache.php обычно связан с механизмом кеширования и загружается при соответствующей конфигурации WordPress. На конкретном проекте могут присутствовать и другие drop-ins — проверяйте только реально существующие файлы и их происхождение.

Когда имеет смысл очистить OPcache или перезапустить PHP-FPM

Если проблемный PHP-файл уже обновили или заменили, но в поведении сайта будто ничего не изменилось, стоит проверить OPcache и состояние PHP-FPM. При определённых настройках OPcache скомпилированный PHP-код может сохраняться дольше, чем ожидает администратор.

Штатная очистка OPcache или перезапуск нужного PHP-FPM pool помогает получить чистый повторный тест после изменения кода. Но перезапуск — ещё не исправление. Если после рестарта сайт ожил, а через некоторое время ошибка вернулась, нужно искать реальную причину, а не превращать restart в постоянное лечение.

И наоборот: если Fatal error каждый раз воспроизводится в одной и той же строке после чистого запуска PHP-FPM, кеш уже не главный подозреваемый. Возвращаемся к коду.

Что делать, если после исправления одного Fatal появляется следующий

Такое поведение нормально для старого проекта. Первый Fatal останавливал PHP раньше, поэтому код ниже вообще не выполнялся. После исправления первой несовместимости PHP проходит дальше и обнаруживает следующую.

Не откатывайте первое исправление только потому, что появилась новая ошибка. Сравните stack trace. Если путь и сообщение изменились, это уже другая точка отказа.

1. Исправили или отключили первый проблемный компонент.
2. Выполнили один контрольный запрос.
3. Получили новый Fatal error.
4. Сравнили файл, строку и stack trace с предыдущим.
5. Если ошибка другая — диагностируем её отдельно.

Что проверить, если staging работает, а production падает

Работа staging на PHP 8.2 доказывает только то, что конкретная тестовая среда совместима. Production может отличаться.

Если staging чистый, а production падает, искать нужно различие между средами. Простое копирование «рабочих» файлов поверх production может ничего не изменить.

Что делать, если падает только REST API, AJAX или cron

Главная страница может работать идеально, а отдельные фоновые или API-запросы — падать. Поэтому проверка только браузером не закрывает миграцию на PHP 8.2.

REST API можно проверить через используемые сайтом маршруты в /wp-json/. AJAX-запросы удобнее воспроизводить через DevTools → Network: выполнить действие на сайте, найти запрос к admin-ajax.php или REST endpoint, посмотреть HTTP status и сразу сопоставить время запроса с error_log.

Для WP-Cron при наличии WP-CLI полезно сначала посмотреть события:

wp cron event list

А в контролируемой среде можно запустить просроченные события вручную:

wp cron event run --due-now

Если Fatal появляется только при cron-задаче, обычное открытие главной его не покажет. Это одна из причин, почему сайт может казаться «полностью рабочим» сразу после смены PHP, а через некоторое время начать терять фоновые функции.

Если проблема возникает только у неавторизованных посетителей, сравните путь запроса с авторизованным пользователем. Администратор может обходить page cache, видеть другой набор блоков или запускать другую ветку PHP-кода. Здесь полезно тестировать сайт и в обычном браузере без активной сессии WordPress.

Как безопасно подготовить WordPress к повторному переходу на PHP 8.2

Повторный переход лучше проводить как небольшую миграцию: резервная копия, возможность отката, тест, переключение и контроль журналов. Просто выбрать PHP 8.2 в панели и увидеть работающую главную недостаточно.

Перед новой попыткой обновите WordPress Core, плагины и тему до версий, которые планируете использовать в production. Отдельно проверьте child theme, пользовательские сниппеты, mu-plugins и собственные интеграции. Они не обновляются автоматически вместе с основными компонентами.

Если есть staging-копия, сначала включите PHP 8.2 там. Но staging полезен только при понимании различий с production. Если тестовая среда использует другой PHP-FPM, другой object cache или другой набор extensions, успешный тест не гарантирует аналогичный результат на основном сайте.

• Есть свежая резервная копия файлов WordPress и базы данных.
• Понятно, как быстро вернуть предыдущую версию PHP.
• WordPress Core обновлён.
• Плагины и тема обновлены.
• Проверены child theme и пользовательские PHP-сниппеты.
• Проверены mu-plugins и drop-ins.
• Сверены необходимые PHP extensions.
• Проверен memory_limit web-PHP.
• Проверен реальный PHP handler домена.
• PHP 8.2 по возможности протестирован на staging.
• После переключения проверяется не только главная страница.
• После теста повторно просматривается PHP error log.
• Временный WP_DEBUG отключается после диагностики.

Не обязательно делать десятки проверок до переключения. Но нужно заранее знать, как быстро вернуться назад и где смотреть ошибку. Тогда смена PHP превращается из «нажал и надеюсь» в контролируемое изменение.

Когда проблема после PHP 8.2 уже требует разработчика или администратора сервера

Если Fatal error стабильно указывает на кастомный PHP-код, сигнатуру метода, собственную интеграцию или библиотеку без совместимого обновления, дальнейшая работа относится к разработке. Если проблема находится в PHP-FPM, модулях, pool, обработчике сайта или серверной конфигурации, нужен администратор сервера или поддержка хостинга.

Перед обращением соберите минимальный диагностический пакет: домен, время теста, предыдущую и новую версию PHP, точный текст Fatal error, путь к файлу, номер строки, stack trace и список уже выполненных проверок.

Сообщение «после PHP 8.2 белый экран» заставляет специалиста начинать с нуля. Сообщение «на предыдущей версии сайт работает, на PHP 8.2 воспроизводится Uncaught TypeError в таком-то файле, после отключения компонента ошибка меняется» уже задаёт понятную точку входа.

Хороший лог сокращает половину переписки.

Как убедиться, что WordPress стабильно работает после исправления проблемы с PHP 8.2

Исправление можно считать завершённым только после повторного теста WordPress на PHP 8.2 и проверки журналов. Работа одной главной страницы не подтверждает совместимость всего сайта.

Что проверить на обычном WordPress

После исправления снова включите PHP 8.2 и выполните несколько реальных сценариев, а не просто обновите homepage.

• Главная и несколько внутренних страниц.
• Страница входа и /wp-admin/.
• Создание или редактирование записи, если это рабочий сценарий сайта.
• Загрузка файла в Media Library.
• Формы.
• Поиск.
• AJAX-действия.
• REST API, если он используется сайтом или интеграциями.
• WP-Cron и фоновые задачи.

Если проблема раньше возникала только на конкретной странице, обязательно повторите именно тот сценарий. «Другие страницы работают» здесь ничего не доказывает.

Что дополнительно проверить на WooCommerce

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

• открытие каталога;
• карточка товара;
• добавление товара в корзину;
• корзина;
• checkout;
• личный кабинет;
• AJAX-обновления, если они используются;
• фоновые задачи магазина.

Сайт может отдавать 200 OK на всех информационных страницах и падать только при оформлении заказа. Поэтому проверять нужно действия, а не только URL.

Что посмотреть в error_log после функционального теста

После каждого важного сценария откройте свежие строки PHP error log. Не нужно добиваться абсолютно пустого журнала: старый WordPress может писать Notice или Deprecated, которые не связаны с текущей аварией. Критерий другой — после тестов не должны появляться новые Fatal error и необработанные Error/TypeError, связанные с выполненными действиями.

Полезно проверять журнал по времени. Выполнили checkout — сразу посмотрели свежие строки. Запустили cron — снова посмотрели. Так легче связать сообщение с конкретным действием.

Как понять, что миграция действительно закончена

После проверки отключите временный WP_DEBUG, удалите диагностические PHP-файлы вроде временного phpinfo() и зафиксируйте, какой компонент пришлось обновить, отключить или исправить. Если проблема повторится на другом сайте или при следующем обновлении PHP, эта информация сэкономит время.

Рабочая последовательность остаётся одной и той же: подтвердить связь со сменой PHP → вернуть сайт в работу → получить точную ошибку → определить компонент по stack trace → изолировать причину → проверить PHP-окружение → повторно включить PHP 8.2 → прогнать реальные сценарии → проверить журнал. Если эта цепочка пройдена без новых Fatal error, переход можно считать завершённым.