Обновление PHP: сайт работает, но хостинг требует — что будет, если не трогать

В панели хостинга висит плашка «версия PHP устарела, поддержка прекращена», в админке своё письмо счастья — «обновите PHP». А сайт открывается, формы отправляются, заказы идут. Владелец логично решает: работает — не лезь. Через полгода хостинг переводит аккаунт принудительно, и в понедельник вместо сайта белый экран. Вот тут меня и зовут: обновить PHP WordPress нужно было заранее и спокойно, а приходится срочно и наугад.

Дальше — что ломается при смене версии, как за вечер проверить плагины и тему и как откатиться за минуту. Конкретные номера версий я не называю специально: пока вы читаете текст, актуальная ветка может смениться. Правило одно — смотрите список поддерживаемых веток на php.net и берите ту, что в активной поддержке, а не ту, что доживает на security-патчах.

Почему хостинг требует обновления, если сайт работает

У каждой ветки PHP есть срок жизни, известный заранее: примерно два года активной поддержки, потом около года только патчи безопасности. После этого ветка становится end-of-life — дыры в ней не закрывают, даже если о них знают публично.

Дальше арифметика хостера. На одном сервере живут сотни аккаунтов. Если на половине крутится ветка с известной уязвимостью выполнения кода, взлом одного сайта становится проблемой всего сервера: рассылка спама, блокировка IP у почтовых провайдеров. Поэтому сначала предупреждают, потом убирают ветку из селектора, потом переводят силой.

Второй мотив — ресурсы. Новые ветки быстрее на том же коде: переработанный движок, кэш байткода, с восьмой ветки ещё и JIT для части операций. Хостингу это экономия процессора, вам — быстрее генерация страницы, а значит лучше скорость WordPress, которая обычно тормозит из-за кэша и базы.

Что реально ломается при переходе

Ломается не «сайт вообще», а функции, которые из языка удалили. Механизм один: автор плагина использовал конструкцию, её объявили устаревшей, потом выкинули. Старая ветка — работает с записью в лог, новая — фатальная ошибка и белый экран.

• Старый доступ к базе. Функции вида mysql_connect() выкинули ещё в седьмой ветке. Прямой запрос через них в теме — фатал.
• Анонимные функции старого образца. create_function() удалена в восьмой ветке. Её любили авторы виджетов десятилетней давности.
• Обход массивов через each(). Тоже удалена. Встречается в старых генераторах карт сайта.
• Символ строки в фигурных скобках — $str{0} вместо $str[0]. Удалено.
• Строгость по типам. Что было предупреждением, стало исключением TypeError. Код не «почти работает», а падает.
• Передача null во встроенные функции вместо строки. Сайт жив, но лог пухнет на гигабайты и съедает квоту — и тогда сайт встаёт по «нет места».

Отдельная категория — платные темы и плагины, купленные однажды и не обновлявшиеся: лицензия истекла, автор проект закрыл. Такой код не переживёт смену двух веток подряд, и это самый частый тупик.

Что будет, если не трогать: четыре сценария

«Не трогать» — не нейтральное решение, а выбор одного из четырёх исходов. Причём выбираете не вы.

Принудительный перевод. Уведомление приходит за месяц, тонет в спаме, в назначенную дату аккаунт переезжает. Сайт падает в момент, когда вас нет за компьютером.

Взлом. Уязвимости EOL-веток публикуют открыто, по ним ходят автоматические сканеры. Дальше в файлах дописанные строки, в индексе сотни страниц про казино — я описывал, как убрать спам-страницы из индекса Яндекса после взлома. Разгребать дороже, чем обновиться.

Тихая деградация. Сайт работает, но ядро не обновляется: новые версии требуют свежего PHP. Не ставятся современные плагины, не подключается новый способ оплаты. Каждая задача решается костылём.

Вы обновляетесь сами, в спокойный вторник, с копией под рукой. Единственный сценарий, где ничего не происходит.

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

Последовательность устроена так, чтобы любой шаг отменялся.

1. Снять полную копию: файлы плюс дамп базы, скачанные к себе. Не «бэкап в панели» — он живёт на той же инфраструктуре, что и проблема.
2. Зафиксировать состояние: версия PHP, список активных плагинов с номерами, версии ядра и темы. Без этой записи откат превращается в угадывание.
3. Обновить всё на старой версии PHP. Сначала ядро, потом плагины, потом тема: свежие плагины почти всегда уже совместимы с новыми ветками, старые — нет. Подробнее: как обновить WordPress и не сломать сайт.
4. Проверить заголовки. У нормального плагина в главном файле есть поле Requires PHP. Пустое или древнее — плагин под вопросом.
5. Поднять тестовую копию и переключить версию уже на ней.
6. Включить лог ошибок и пройти сайт руками: главная, листинг, карточка, корзина, оформление заказа, форма заявки, админка.
7. Разобрать лог. Фаталы устранять обязательно, deprecated можно пережить, но источник записать.
8. Переключить продакшн. Это секунды и так же быстро отменяется.
9. Проверить продакшн и заглянуть в лог через сутки. Часть проблем вылезает не на страницах, а на фоновых задачах: крон, рассылка, выгрузка.

Как проверить совместимость заранее

Способ	Что показывает	Чего не увидит
«Здоровье сайта» в админке	Текущую и рекомендуемую версию, модули	Совместимость кода — не проверяет вообще
Заголовок Requires PHP	Минимальную версию, заявленную автором	Максимальную: плагин требует «7.0 и выше» и падает на восьмёрке
Статический анализ (PHPCompatibility для PHP_CodeSniffer)	Удалённые конструкции во всех файлах темы и плагинов	Ошибки, возникающие только на живых данных
Прогон на тестовой копии с логом	Реальные фаталы и предупреждения	Сценарии, куда вы не зашли руками

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

Тестовая площадка: три варианта

Обновлять сразу на живом сайте можно, если это визитка на пять страниц. Появился магазин, личный кабинет, интеграция с 1С или оплата — нужна копия.

Вариант	Плюсы	Минусы	Риск ошибиться
Поддомен на том же хостинге	Те же настройки сервера, свой селектор PHP	Надо закрыть от индексации; на части тарифов версия задаётся на весь аккаунт	Средний: можно переключить версию всему аккаунту
Локальная копия у себя	Можно ломать сколько угодно	Другие модули, права, версия базы; интеграции не работают	Высокий: «локально завелось» — иллюзия
Staging средствами хостинга	Копия один в один, переключение изолированное	Есть не у всех; плагины клонирования падают на больших базах	Низкий, если хостинг умеет это штатно

Тестовую копию закройте от поиска паролем на уровне сервера. Иначе в индекс уедет вторая версия сайта, и вместо обновления PHP вы будете разбираться с дублями.

Если заодно думаете менять хостинг — совместите: обновлять PHP на сервере, с которого через месяц уезжаете, смысла мало. Порядок действий я описывал отдельно: перенос сайта WordPress на другой хостинг. После переезда сайт часто недоступен из-за записей DNS, а не из-за версии PHP.

Как откатиться, если упало

Откат по версии PHP — самая дешёвая операция во всей истории: в панели выбираете предыдущую ветку, сохраняете, обновляете страницу. Это единственное изменение, которое отменяется одним переключателем.

Сложнее, если вы успели наделать других правок. Тогда откат многоступенчатый, и здесь нужна запись из второго шага. Порядок обратный: версия PHP, потом файлы из архива, потом база. Базу восстанавливают последней и только если в неё что-то записалось после обновления — иначе потеряете заказы за это время.

Про белый экран. Включите WP_DEBUG_LOG и посмотрите последнюю фатальную запись: там имя файла и строка, то есть сразу виден виноватый плагин. Его достаточно переименовать через файловый менеджер — WordPress его отключит, сайт поднимется. Это же спасает, когда админка недоступна.

Когда обновление НЕ нужно или не сработает

• Ветка ещё в поддержке, просто не самая новая. Гнаться за свежайшей незачем, а прыжок через две ветки сразу — самый травматичный.
• Самописный движок, автора нет. Обновление превращается в переписывание: иногда дешевле сделать новый сайт, иногда — арендовать сервер с нужной версией и выиграть год.
• Идёт реклама или сезон продаж. Переносите на спокойные дни: простой в пик стоит дороже уязвимости.
• Нет копии. Пока архив не скачан — обновления не происходит.
• Критичная интеграция с банком, ЭДО или складом официально не поддерживает новую ветку. Сначала запрос поставщику, потом обновление.

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

Влияет ли версия PHP на позиции

Напрямую нет: в факторах ранжирования нет пункта «версия серверного языка». Влияние идёт двумя обходными путями. Первый — время ответа сервера: новые ветки быстрее генерируют страницу, это заметно на каталогах с фильтрами. Второй — доступность: если робот несколько дней получает ошибку сервера, страницы вылетают из индекса.

Так что «обновим PHP и вырастем в выдаче» — неправда. Обновление убирает один из способов потерять то, что уже есть. Для роста работают структура, тексты и чистка технических ошибок — этим я и занимаюсь в рамках продвижения сайта под ключ, где техническая часть идёт первым этапом, а не вместо остальных.

Чек-лист перед переключением

Шаг	Что проверить	Признак готовности
Копия	Архив файлов и дамп базы скачаны к себе	Архив открывается, в дампе есть таблица записей
Запись состояния	Версии PHP, ядра, темы, список плагинов	Файл со списком лежит рядом с архивом
Обновления	Ядро, плагины, тема обновлены на старой версии	Нет ожидающих обновлений
Брошенные плагины	Нет плагинов без обновлений больше двух лет	Найдены замены или плагин удалён
Тестовая копия	Поднята, закрыта от индексации, версия переключена	Посторонним отдаётся пароль
Прогон	Листинг, карточка, корзина, оплата, форма, админка	Ни одного фатала в логе
Фоновые задачи	Крон, письма с сайта, выгрузки	Задачи отработали

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

Коротко

• Хостинг требует обновления не из вредности: после срока поддержки дыры в ветке не закрывают.
• Ломаются не сайты, а удалённые из языка функции в старых плагинах и темах.
• Порядок: копия → запись состояния → обновления на старой версии → тестовая копия → прогон с логом → продакшн → проверка через сутки.
• Цель — не «последняя версия», а ветка в активной поддержке на момент работы.
• Прыгать через две ветки опаснее, чем идти по одной.
• Откат — одно переключение в панели.
• Позиции от обновления не вырастут: оно защищает от падения и взлома.

Частые вопросы

Сколько времени занимает обновление?

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

Что делать, если старый плагин не работает, а замены нет?

Три варианта по возрастанию стоимости: найти форк или аналог; вынести нужную функцию в небольшой собственный код и выкинуть плагин; править сам плагин, помня, что при его обновлении правки исчезнут. Остаться на EOL-ветке ради одного плагина — худший вариант.