Заказать обновление PHP: этапы, риски и сроки

Когда обновление PHP пора заказывать

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

Второй частый повод — требования окружения. Хостинг-провайдеры постепенно отключают старые версии, а разработчики CMS и популярных плагинов повышают минимальную планку. В итоге вы не можете установить свежий модуль оплаты, обновить тему или подключить новый сервис, потому что они требуют PHP новее, чем у вас на сервере.

Третий повод — производительность. Начиная с ветки 7.0 язык серьёзно ускорился, а в 8.x появились JIT-компиляция, улучшенная типизация и более предсказуемое поведение. Для магазина или портала с высокой нагрузкой это означает меньшее время ответа сервера, а значит, лучшие пользовательские метрики и более устойчивую работу под пиковым трафиком.

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

Что именно ломается при переходе на новую версию

Основной риск — обратная несовместимость. Между ветками 5.x, 7.x и 8.x из языка убирали устаревшие функции и меняли поведение отдельных конструкций. Старый код, который годами работал без нареканий, после переключения может выдать фатальную ошибку или, что хуже, начать вести себя иначе без видимых сообщений.

Вот типичные проблемы, с которыми сталкиваются при миграции: удалённое расширение mysql_* (его заменяют на mysqli или PDO), исчезнувшие функции вроде each() и create_function(), изменившиеся правила сравнения строк и чисел в PHP 8, предупреждения о динамических свойствах классов в 8.2, а также строгая проверка типов аргументов во встроенных функциях.

Отдельная зона риска — сторонние компоненты. Темы оформления, плагины и модули, которые давно не обновлялись автором, часто содержат устаревший код. Иногда проще заменить такой модуль аналогом, чем переписывать его. Именно поэтому профессиональное обновление начинается с аудита, а не с переключения версии.

Главный принцип этой последовательности — сначала безопасная копия, потом рабочий сайт. Если исполнитель предлагает «просто попробовать» на живом проекте, это повод насторожиться: в случае ошибки вы теряете заказы, а поисковые роботы Яндекса и Google фиксируют ошибки 5xx.

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

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

Стоимость тоже определяется после аудита: исполнитель оценивает объём правок и риски. Настороженность должны вызывать фиксированные цены «по телефону», не учитывающие состав проекта, и обещания обновить «за час» любой сайт без тестовой копии.