Переход на PHP 8.3/8.4: чек-лист проверки совместимости темы и плагинов WordPress

02.09.2026г.
Веб-технологии
216

#php #wordpress

Время на прочтение: 6 мин.

Переход на PHP 8.3/8.4 помогает сделать WordPress быстрее и безопаснее. Но обновление без проверки темы и плагинов может вызвать ошибки. В этой статье разберём, как проверить сайт и выполнить переход без простоя — используйте чек-лист перед обновлением.

Зачем нужен переход на PHP 8.3/8.4

PHP отвечает за выполнение серверной части WordPress. Версия PHP влияет на безопасность, скорость и стабильность сайта.

Старые версии PHP постепенно теряют поддержку. Например, PHP 8.3 получает только обновления безопасности с конца 2025 года. Для PHP 8.3 поддержка безопасности продлится до 31 декабря 2027 года. PHP 8.4 получает активную поддержку до 31 декабря 2026 года.

WordPress сейчас рекомендует PHP 8.3 или выше. Также проект рекомендует современную версию базы данных и HTTPS.

При этом обновление PHP не равно обновлению WordPress.

Сайт состоит из нескольких уровней:

WordPress Core.
Активная тема.
Дочерняя тема.
Плагины.
Кастомный PHP-код.
Интеграции и API.
Серверные расширения PHP.
Кэширование.
База данных.

Если один элемент использует устаревший PHP-код, после обновления могут появиться ошибки.

Поэтому переход на PHP 8.3/8.4 нужно выполнять как технический проект. Сначала проверяем совместимость. Затем создаём резервную копию. После этого тестируем сайт на копии.

Переход на PHP 8.3/8.4: что проверить до обновления

Начните с аудита текущего сайта.

Зафиксируйте:

текущую версию PHP;
версию WordPress;
версию темы;
список активных плагинов;
версии всех плагинов;
наличие дочерней темы;
кастомные сниппеты;
серверные расширения PHP;
версию MySQL или MariaDB;
настройки кэширования.

Эти данные позволяют понять масштаб работ.

1. Проверьте версию PHP

В WordPress откройте:

Инструменты → Здоровье сайта → Информация → Сервер.

WordPress самостоятельно проверяет версию PHP. В Site Health также есть проверки PHP-расширений и других параметров сервера.

На сервере версию можно проверить через WP-CLI:

wp --info
php -v

Если есть SSH-доступ, команда php -v покажет версию PHP.

Важно проверить именно PHP, который использует сайт. Версия PHP в SSH и версия PHP-FPM могут отличаться.

2. Проверьте версию WordPress

Современный WordPress лучше подготовлен к новым версиям PHP.

По данным WordPress Core, версии WordPress 6.4 и выше полностью поддерживают PHP 8.3. WordPress 6.8 и выше полностью поддерживают PHP 8.4.

Поэтому старый WordPress стоит обновить до актуальной версии до смены PHP.

Но обновлять всё сразу на боевом сайте не стоит.

Сначала создайте тестовую копию.

3. Проверьте тему

Тема часто содержит собственный PHP-код. Особенно внимательно проверяйте старые коммерческие темы.

Проблемные места:

functions.php;
шаблоны WooCommerce;
пользовательские классы;
хуки WordPress;
AJAX-обработчики;
REST API;
кастомные виджеты;
интеграции с формами.

Если используется дочерняя тема, проверяйте обе темы.

Особое внимание уделите коду, который создавался несколько лет назад. Старый код может работать на прежней версии PHP и ломаться после обновления.

4. Проверьте плагины

Составьте таблицу:

Компонент	Версия	PHP 8.3	PHP 8.4	Действие
WordPress	актуальная	✓	✓	оставить
Тема	4.2	?	?	проверить
WooCommerce	актуальная	✓	✓	обновить
SEO-плагин	старая	?	?	обновить
Кастомный плагин	1.0	?	?	тестировать

Для каждого расширения ищите информацию разработчика.

Не ограничивайтесь надписью «работает с PHP 8».

PHP 8.3 и PHP 8.4 имеют собственные изменения и несовместимости. Официальная документация PHP рекомендует тестировать приложения перед переходом на новые ветки.

Какие ошибки встречаются после перехода на PHP 8.3/8.4

Большинство проблем возникает не в WordPress Core. Чаще причиной становится сторонний или кастомный код.

Устаревшие конструкции

PHP продолжает удалять старые механизмы и ужесточать поведение некоторых функций.

Например, PHP 8.3 помечает ряд конструкций как устаревшие. Среди них некоторые варианты использования get_class() и операций инкремента строк.

В PHP 8.4 появились дополнительные изменения поведения.

Например, exit() и die() теперь работают более строго с типами. Некорректные значения могут привести к TypeError.

На практике это означает простой принцип:

код нужно не угадывать, а запускать на целевой версии PHP.

Deprecated — это тоже сигнал

Предупреждение Deprecated не всегда ломает сайт.

Но игнорировать его нельзя.

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

Пример:

function get_value($value = null) {
    return $value;
}

Если сторонний код использует устаревшие конструкции, PHP может начать выводить предупреждения.

На рабочем сайте такие сообщения не должны показываться посетителям. Их нужно искать в логах.

Как проверить совместимость PHP-кода

Самый надёжный вариант — объединить статический анализ и реальное тестирование.

Статический анализ

Инструменты совместимости PHP могут найти потенциально проблемный код без запуска сайта.

Для WordPress можно использовать решения на базе PHPCompatibility.

Но автоматический анализ не даёт гарантии.

Он отвечает на вопрос:

«Есть ли в коде конструкции, которые могут быть несовместимы?»

А тестовый сайт отвечает на другой вопрос:

«Работает ли сайт после обновления?»

Нужны оба подхода.

Проверка через PHPCompatibility

Для проекта с доступом к Composer можно выполнить анализ кода.

Пример конфигурации PHP_CodeSniffer:

composer require --dev phpcompatibility/php-compatibility

После этого можно анализировать собственный код.

Пример команды:

vendor/bin/phpcs \
  --standard=PHPCompatibility \
  --runtime-set testVersion 8.4 \
  wp-content/themes/my-theme

Для плагина команда будет похожей:

vendor/bin/phpcs \
  --standard=PHPCompatibility \
  --runtime-set testVersion 8.4 \
  wp-content/plugins/my-plugin

Результаты нужно проверять вручную.

Некоторые предупреждения относятся к коду, который вообще не выполняется на конкретном сайте.

Другие ошибки могут быть критичными.

Переход на PHP 8.3/8.4 на тестовом сервере

Лучший сценарий — создать staging-копию сайта.

Схема выглядит так:

Продакшен → резервная копия → staging → PHP 8.3/8.4 → тестирование → исправления → продакшен.

На staging должна быть максимально точная копия сайта.

Проверьте:

базу данных;
изображения;
загрузки;
тему;
плагины;
настройки;
cron-задачи;
кэш;
интеграции.

После этого переключите PHP.

Не используйте продакшен для первого теста.

Чек-лист функционального тестирования

После перехода на PHP 8.3/8.4 проверьте сайт как обычный пользователь.

Главная страница

Открывается без ошибок.
Работают меню.
Загружаются изображения.
Работают формы.
Корректно отображаются блоки.

Авторизация

Вход работает.
Выход работает.
Восстановление пароля работает.
Личный кабинет открывается.

Формы

Проверьте каждую важную форму:

контактную;
обратного звонка;
заявки;
регистрации;
авторизации;
подписки.

Проверяйте не только отображение.

Отправьте реальную тестовую заявку.

WooCommerce

Если сайт использует интернет-магазин, проверяйте:

карточку товара;
корзину;
оформление заказа;
промокоды;
оплату;
доставку;
письма;
личный кабинет;
возвраты;
вебхуки.

Особенно важно проверить платёжные интеграции.

Ошибка может проявиться только при создании заказа.

Административная часть

Проверьте:

создание записи;
редактирование страницы;
загрузку изображения;
обновление меню;
работу редактора;
настройки плагинов;
импорт и экспорт данных.

Также проверьте консоль браузера и серверные логи.

Как включить логирование ошибок WordPress

Для диагностики можно временно включить журналирование.

В wp-config.php:

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

После этого ошибки будут записываться в:

/wp-content/debug.log

На боевом сайте не стоит показывать PHP-ошибки посетителям.

После диагностики верните настройки в безопасное состояние.

Например:

define('WP_DEBUG', false);

Если используется серверное логирование PHP-FPM, проверяйте и его.

Иногда критическая ошибка не попадает в debug.log.

Что делать, если сайт сломался

Представим типовой кейс.

Проблема: после перехода на PHP 8.4 сайт показывает белый экран.

Наша задача: не откатывать изменения вслепую, а найти причину.

Первый шаг — посмотреть логи.

В них может быть:

PHP Fatal error:
Uncaught TypeError:
Argument #1 must be of type string

Далее определяем файл и плагин.

Например:

/wp-content/plugins/example-plugin/includes/api.php:142

Теперь понятно, где искать проблему.

Дальше возможны три сценария:

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

Если плагин критичен для бизнеса, его нельзя просто отключить на продакшене.

Сначала нужно оценить влияние.

Переход на PHP 8.3/8.4: итоговый чек-лист

Перед изменением PHP отметьте каждый пункт.

До обновления

Создана резервная копия.
Проверена версия WordPress.
Проверена версия PHP.
Обновлены тема и плагины.
Проверена дочерняя тема.
Найден кастомный PHP-код.
Проверены требования плагинов.
Проверены PHP-расширения.
Создан staging.
Проверено восстановление резервной копии.

На staging

Установлен PHP 8.3 или 8.4.
Проверены PHP-логи.
Проверен debug.log.
Проверена главная страница.
Проверены формы.
Проверена авторизация.
Проверены ключевые страницы.
Проверен WooCommerce.
Проверены платежи.
Проверены письма.
Проверены cron-задачи.
Проверены внешние API.

Перед продакшеном

Критических ошибок нет.
Deprecated-ошибки изучены.
Производительность проверена.
Резервная копия актуальна.
Есть план отката.
Есть доступ к серверу.
Определено время обновления.

PHP 8.3 или PHP 8.4: какую версию выбрать

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

PHP 8.4 новее и дольше останется на активной поддержке. PHP 8.3 получает только security-обновления с конца 2025 года.

Поэтому при отсутствии ограничений со стороны темы и плагинов разумно рассматривать PHP 8.4.

Но совместимость конкретного сайта важнее самой цифры версии.

Если старый плагин стабильно работает на PHP 8.3, но ломается на 8.4, не стоит рисковать рабочим магазином ради формального обновления.

Сначала исправьте совместимость.

Кстати, каждая ветка PHP получает два года активной поддержки и ещё два года поддержки критических исправлений. Это даёт примерно четыре года жизненного цикла одной ветки.

Когда стоит заказать проверку специалистам

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

Но есть признаки, когда лучше привлечь разработчика.

Обратитесь к специалистам, если:

сайт приносит заявки каждый день;
работает интернет-магазин;
есть онлайн-оплата;
используется CRM;
есть интеграции с API;
тема написана специально под проект;
есть много кастомных плагинов;
сайт работает на старой версии PHP;
нет staging-сервера;
резервные копии давно не проверялись.

Особенно рискован переход на PHP на сайте, который никто не обслуживал несколько лет.

В таком случае сначала нужен технический аудит.

Как мы выполняем переход на PHP 8.3/8.4

В «Компьюти» мы не меняем PHP на боевом сайте методом проб и ошибок.

Мы используем последовательный процесс.

Вы столкнулись с проблемой: хостинг предлагает обновить PHP, но неизвестно, выдержит ли сайт.

Мы решаем её: проверяем WordPress, тему, плагины и кастомный код. Затем создаём тестовую копию и переключаем PHP на staging.

Вы получаете результат: рабочий сайт с проверенной совместимостью и понятным планом обновления.

При необходимости мы:

проводим аудит PHP-кода;
проверяем тему и плагины;
исправляем несовместимый код;
настраиваем staging;
обновляем WordPress;
выполняем переход на PHP 8.3/8.4;
проверяем сайт после обновления;
анализируем ошибки;
контролируем производительность.

Такой подход снижает риск простоя и потери заявок.

Заключение

Переход на PHP 8.3/8.4 — нормальный этап технического обслуживания WordPress. Современная версия PHP повышает безопасность и помогает поддерживать актуальную инфраструктуру.

Главное — не менять версию PHP вслепую.

Проверьте WordPress, тему, плагины и кастомный код. Создайте резервную копию. Проведите переход на staging. Затем выполните функциональное тестирование.

Если сайт коммерческий, лучше доверить переход специалистам.

Нужен безопасный переход на PHP 8.3/8.4? Обратитесь в «Компьюти». Проведём аудит WordPress, найдём потенциальные проблемы и подготовим сайт к обновлению без лишнего риска.

Автор

Токмаков Александр

Подробнее об авторе →

Приглашаем поучаствовать в обсуждении статьи:

Комментариев 0