Порядок смены PHP для WordPress: инвентаризация компонентов, изолированный стенд, проверка веб- и CLI-окружения, тест операций, анализ ошибок и возврат версии.
Выберите цель и поддерживаемую ветку
Смена PHP затрагивает выполнение WordPress, темы, плагинов и пользовательского кода. Наличие версии в панели означает возможность её выбрать, но не успешную проверку вашего приложения. Начните с причины изменения: завершение поддержки текущей ветки, требования компонентов или плановая миграция. Сверьте актуальный жизненный цикл на официальном сайте PHP в день работ; не выбирайте версию по старой статье с обещанием «самая новая».
Для каждого критичного компонента уточните поддерживаемый диапазон и известные ограничения. Рекомендация WordPress не является гарантией для давно не обновлявшегося плагина оплаты или закрытого модуля интеграции. Если в проекте используется код с ionCube или другим загрузчиком, отдельно подтвердите совместимый загрузчик и сборку. Успешная загрузка главной страницы не проверяет этот код, пока не выполнена соответствующая операция.
Соберите паспорт исходного окружения
Зафиксируйте версию PHP для сайта, способ запуска, необходимые расширения, параметры загрузки файлов и ограничения выполнения. Запишите версии WordPress, темы, важных плагинов и собственных модулей. Сведения «Здоровье сайта → Информация» относятся к окружению веб-запроса. Версия команды php в SSH может отличаться от версии, выбранной для домена в панели.
| Объект | Что записать | Типичная ошибка |
|---|---|---|
| PHP веб-сайта | Версия, обработчик, расширения | Смотреть только php -v в SSH |
| Фоновые команды | Путь к бинарнику PHP и пользователь | Cron остаётся на другой ветке |
| Модули проекта | Тема, плагины, собственный код | Проверить только ядро WordPress |
| Конфигурация | Нужные лимиты и загруженные расширения | Предполагать перенос всех ini-настроек |
| Возврат | Предыдущая доступная ветка и процедура | Обнаружить отсутствие возврата после сбоя |
Не оставляйте публичный phpinfo-файл ради инвентаризации: он раскрывает подробности среды. Используйте штатную административную информацию и согласованный способ диагностики. Снимок паспорта храните в закрытом рабочем документе без паролей, токенов и полного списка персональных путей, если они не нужны исполнителю.
Подготовьте копию и границы тестового стенда
До изменения нужна восстанавливаемая копия файлов и базы, а также понимание, как вернуть конфигурацию PHP. Копия данных не сохраняет автоматически настройки панели хостинга. Отдельно запишите домен, каталог, обработчик и параметры. Проверьте доступ к панели при отказе WordPress: если единственный способ управления находится внутри сломанной CMS, план возврата неполон.
Разверните изолированный стенд с репрезентативным составом приложения. Для магазина обезличьте клиентские данные, отключите реальные платёжные операции, уведомления и внешние обмены штатными тестовыми механизмами. Стенд не должен отправлять рабочие вебхуки. Защита от индексации не является ограничением доступа; применяйте предусмотренную площадкой защиту там, где находятся закрытые данные.
- Сохраните паспорт и конфигурацию до работ.
- Проверьте наличие полной копии и доступность восстановления в отдельный контур.
- Назначьте владельца решения и окно переключения.
- Определите операции, которые должны пройти до продолжения.
- Подтвердите, что прежняя ветка доступна для согласованного возврата.
Проверьте руководство миграции и зависимости
Официальное руководство PHP для перехода между ветками перечисляет изменения совместимости, устаревающие возможности и изменения поведения. Если переход охватывает несколько веток, прочитайте затронутые руководства последовательно. Разработчик должен сопоставить изменения с используемым кодом; универсальный сканер не выполняет все возможные сценарии интеграций и не заменяет тест.
Проверьте требования библиотек Composer и внешних модулей. Обновление зависимостей может само менять поведение приложения, поэтому фиксируйте его отдельным шагом на стенде. Не совмещайте в рабочем окне смену PHP, темы, десятка плагинов и базы данных без предварительно проверенной последовательности. Иначе при отказе будет непонятно, какое изменение возвращать.
Когда нужна помощь разработчика
Если компонент не поддерживается, не имеет понятной документации или выдаёт несовместимые вызовы, сначала определите замену либо исправление. Подавление сообщения не меняет несовместимый код. Обещание «хостинг поддерживает PHP» относится к среде, а не к обязательству починить любое расширение сайта.
Переключите PHP только на стенде и сравните настройки
В панели выберите домен тестового контура и нужную версию по инструкции своего поставщика. Интерфейсы различаются, поэтому перед подтверждением проверьте, к какому сайту применяется изменение и не наследуют ли настройку соседние проекты. После переключения снова откройте информацию WordPress и сравните расширения и ограничения с паспортом. Некоторые значения задаются отдельно для каждой ветки.
php -v
php --ini
php -mЕсли cron или WP-CLI используют явно заданный путь к старому бинарнику, изменение домена может их не затронуть. Согласуйте путь со специалистом и проверьте именно реальную фоновую команду. Не заменяйте системные ссылки и пакеты на shared по чужой инструкции: используйте предусмотренный хостером механизм. На VPS изменение сервиса требует отдельного эксплуатационного плана.
Пройдите матрицу функциональной приёмки
Проверяйте сценарии, в которых участвует разный код: чтение, запись, загрузка файла, обработка изображения, поиск, почта, интеграция и фоновые задания. Для магазина добавьте корзину, тестовое оформление и изменение тестового товара. Реальный платёж не нужен, если задача — проверить техническую совместимость: используйте документированный тестовый режим конкретного модуля.
| Сценарий | Проверяемый результат | Где искать подтверждение |
|---|---|---|
| Вход редактора | Авторизация и сохранение работают | Новая сессия и сохранённая тестовая запись |
| Изображение | Файл загружается и обрабатывается | Медиа и сформированные размеры |
| Форма | Сообщение обработано и доставлено в тестовый ящик | Журнал приложения и полученный тест |
| Магазин | Корзина и тестовый заказ согласованы | Статус, сумма и отсутствие реального списания |
| Фоновые задачи | Известная тестовая задача завершена | Журнал и ожидаемый результат |
| Внешний обмен | Тестовые данные обработаны без дубля | Протокол тестовой интеграции |
Сверяйте данные до и после, а не только отсутствие красного сообщения. Дублированный тестовый заказ или потерянное вложение могут сопровождаться HTTP 200. После очистки разрешённых кэшей повторите независимую сессию, чтобы старая готовая страница не скрывала отказ PHP. Не удаляйте журналы до фиксации проблемы.
Разберите ошибки по уровню и времени
При белом экране или HTTP 500 сопоставьте момент запроса с журналом PHP и WordPress. Fatal error обычно требует исправления соответствующего кода или зависимости; предупреждение об устаревшем вызове не всегда останавливает выполнение, но показывает работу для разработчика. Ошибка отсутствующего расширения отличается от нехватки памяти и недоступности базы. Повышение лимитов не является универсальным исправлением.
На стенде можно использовать документированный режим журналирования, сохраняя ошибки вне публичного отображения. Выберите закрытый путь и срок хранения, проверьте права доступа. Журналы могут содержать токены и данные формы: перед передачей удаляйте секреты, оставляя время, тип ошибки и необходимый контекст. Не включайте вывод отладки посетителям рабочего магазина.
- Определите, на какой операции появляется ошибка и воспроизводится ли она.
- Найдите первый значимый сбой, а не только последующее сообщение браузера.
- Запишите компонент и версию, не обвиняя хостинг по одному коду HTTP.
- После отдельного исправления повторите исходный сценарий и соседние операции.
Перенесите проверенную последовательность на рабочий сайт
Перед рабочим окном убедитесь, что стенд не отстал по составу от сайта. Новый плагин или обновлённая тема меняют результат теста. Сохраните актуальную копию и повторно проверьте процедуру возврата. При необходимости согласуйте ограничение изменений данных на время работ; для магазина отдельно учитывайте новые заказы и фоновые события, которые продолжают поступать.
Примените только проверенную смену окружения и связанные подтверждённые настройки. Сразу выполните короткую критичную матрицу, затем наблюдайте журналы и фоновые задачи в согласованный период. Не завершайте приёмку после первого открытия главной. Зафиксируйте фактическую веб-версию, состояние CLI/cron, время и результаты операций. Изменение конфигурации без теста остаётся непроверенным.
Как вернуть прежнее состояние без потери данных
Если изменяли только PHP и настройки, предусмотренный панелью возврат ветки обычно является первым техническим действием при несовместимости. После него проверьте необходимые расширения и приложение. Если вместе с обновлениями компонентов изменилась схема базы, одной смены PHP недостаточно: нужен план согласованного возврата кода и данных, подготовленный до работ.
Восстановление вчерашней базы поверх работающего магазина может удалить новые заказы. Сначала остановите дальнейшие изменения по процедуре проекта и согласуйте сохранение поступивших данных. Не выдавайте массовое восстановление за безопасную универсальную кнопку. Результат возврата подтверждают те же операции, которые не прошли новую версию, и проверка сохранности новых записей.
FAQ и результат миграции
PHP в SSH обновилась — значит сайт тоже перешёл?
Нет. CLI и обработчик веб-сайта могут использовать разные бинарники и конфигурации. Проверьте оба контекста независимо.
Достаточно ли совместимости ядра WordPress?
Нет. Нужны тема, плагины, пользовательский код, расширения PHP и фоновые команды проекта.
Можно ли скрыть deprecated и считать миграцию завершённой?
Скрытие сообщений от посетителей полезно для эксплуатации, но не исправляет устаревший код. Зафиксируйте проблему разработчику и отдельно проверьте функциональность.
Можно ли не делать стенд для маленького сайта?
Риск зависит от операций, а не числа страниц. Даже маленький сайт может принимать важные обращения. Проверенная копия, возврат и матрица функций всё равно нужны.
Итогом должен быть паспорт нового окружения, протокол функций, перечень оставшихся предупреждений и проверенный способ возврата. Не публикуйте обещание ускорения без сопоставимых измерений: главная цель перехода — поддерживаемая и работоспособная среда конкретного проекта.
Источники и дата
- WordPress: подготовка смены PHP
- Поддерживаемые версии PHP
- PHP: пример руководства миграции 8.3 → 8.4
- WordPress: отладка
- WordPress — PHP
- WordPress — требования
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
