Срочно обновить PHP на сайте: пошаговый план

Почему обновление PHP нельзя откладывать

Когда ветка PHP достигает конца жизненного цикла (EOL), разработчики перестают выпускать для неё любые патчи, в том числе исправления критических уязвимостей. Злоумышленники это знают: уязвимости в старых версиях публично описаны, а автоматические сканеры ищут такие сайты по всему Рунету. Взлом обычно выглядит буднично: на сайте появляются спамовые страницы, скрытые редиректы, вредоносный код в файлах. После этого поисковики помечают сайт как опасный, а позиции в Яндексе и Google падают.

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

Третья причина — скорость. Уже переход с PHP 5.6 на PHP 7.0 ускорил обработку запросов почти вдвое, а ветки 8.x добавили ещё оптимизаций, включая JIT-компиляцию. Быстрый отклик сервера улучшает пользовательские метрики и помогает поисковым роботам обходить больше страниц за визит.

Как узнать, какая версия PHP стоит на сайте

Первый шаг — выяснить, с чем вы работаете. Есть несколько надёжных способов.

Панель хостинга. В ISPmanager, cPanel, Plesk и фирменных панелях хостеров версия PHP указана в разделе «PHP», «Языки программирования» или «Настройки сайта». Там же обычно доступен список всех версий, на которые можно переключиться.

Админка CMS. В WordPress откройте «Инструменты» → «Здоровье сайта» → «Информация» → «Сервер»: там указаны версия PHP и рекомендации по обновлению. В 1С-Битрикс версию показывает проверка системы в разделе «Настройки» → «Инструменты».

Файл phpinfo. Создайте в корне сайта файл с одной строкой `<?php phpinfo();` и откройте его в браузере. Обязательно удалите файл сразу после проверки: он раскрывает конфигурацию сервера.

Отдельно проверьте версию PHP для командной строки (CLI). Она может отличаться от веб-версии, и тогда cron-задачи, выгрузки и обмен с 1С продолжат работать на старом интерпретаторе или, наоборот, сломаются.

Подготовка: бэкап и тестовая копия

Срочность не отменяет подготовку, наоборот: чем меньше времени, тем важнее не допустить простоя. Начните с полной резервной копии: файлы сайта и база данных. Многие хостинги делают копии автоматически, но проверьте, что свежая копия существует и её можно развернуть. Лучше сделать ещё одну вручную прямо перед работами.

Затем создайте тестовую копию сайта (staging) на поддомене или во временной папке и включите на ней новую версию PHP. Если хостинг позволяет выбирать версию для каждого сайта или поддомена отдельно, это делается за несколько минут. Все проверки выполняйте на копии: рабочий сайт при этом продолжает принимать заказы и заявки.

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

Что чаще всего ломается при переходе на PHP 8

Основные проблемы связаны с тем, что в новых версиях удалили старые функции и ужесточили проверки. Расширение mysql_* исчезло ещё в PHP 7.0, функции create_function() и each() удалены в PHP 8.0, а в PHP 8.2 появилось предупреждение об устаревании динамических свойств классов. Код, написанный лет десять назад, может использовать любую из этих конструкций.

Самый частый симптом — «белый экран смерти» или ошибка 500. Это не значит, что сайт потерян: PHP просто не смог выполнить код и остановился. Причина всегда записана в журнале ошибок, поэтому включите его заранее и не отключайте вывод ошибок «вслепую». На рабочем сайте показ ошибок посетителям должен быть выключен (display_errors = Off), а запись в лог — включена.

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

SEO и мониторинг после обновления

Сама по себе смена версии PHP не меняет контент и разметку, поэтому позиции в выдаче Яндекса и Google не должны пострадать. Риск возникает только в одном случае: если страницы начали отдавать ошибки 5xx, а поисковые роботы пришли именно в этот момент. Поэтому первые дни после переключения нужно наблюдать.

Откройте Яндекс Вебмастер и Google Search Console: следите за разделами с ошибками сканирования и доступностью сайта. Рост числа ответов 5xx — сигнал немедленно проверить журнал. В Яндекс Метрике и Google Analytics сравните конверсии, отказы и число заявок с предыдущей неделей: резкое падение цели «отправка формы» часто означает, что форма перестала работать, хотя страницы открываются.

После стабилизации сравните время ответа сервера (TTFB) и показатели скорости в отчётах Core Web Vitals. На многих сайтах после перехода с PHP 7.x на 8.x они заметно улучшаются, а это приятный бонус к безопасности.

Когда лучше обратиться к специалисту

Многие сайты на WordPress с популярными плагинами обновляются без участия разработчика. Но есть ситуации, где самостоятельная работа рискованна: самописная тема или модуль, интеграция с 1С и платёжными системами, интернет-магазин с высоким трафиком, неподдерживаемые плагины без аналогов. В таких случаях нужно не просто переключить версию, а переписать устаревшие участки кода.

Если хостинг не даёт выбрать современную версию PHP, это повод задуматься о переезде. Сегодня практически все российские и международные хостинг-провайдеры предлагают PHP 8.3 и 8.4. Если провайдер остановился на 7.x, то вместе с ним на риск остановился и ваш сайт.

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

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