Устаревшая версия PHP (EOL): риски и план обновления сайта

Многие сайты годами работают на той версии PHP, которая была установлена при запуске. Сайт открывается, заказы приходят, и владелец не видит причин что-то менять. Но у версии PHP есть срок жизни, и когда он заканчивается, то есть наступает EOL (end of life), версия перестаёт получать исправления безопасности. Разберём, в чём конкретно состоят риски старой версии и как составить план безопасного обновления.

Как устроен жизненный цикл версий PHP

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

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

Видно, что даже сайтам на 8.2 пора готовиться к обновлению, а сайты на 7.4 и 8.0 уже несколько лет работают без патчей.

Реальные риски старой версии

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

Второй риск связан с CMS и плагинами. Новые версии WordPress, Joomla и других систем со временем прекращают поддержку старого PHP. Владелец не может обновить CMS, потому что новая версия не работает на старом PHP, а уязвимости в плагинах исправляются только в новых версиях. Так старый PHP запирает весь сайт внутри устаревшего и уязвимого кода.

Третье — производительность. В серии PHP 8 появились внутренние оптимизации и JIT-компилятор, и многие сайты заметно ускоряются от простой смены версии. А скорость важна и для пользователей, и для позиций в поисковых системах.

Ограничения со стороны хостинга

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

Пример: сайт школы в Намангане

Сайт частной школы в Намангане misol.uz построен в 2018 году на Joomla 3 и работает на PHP 7.4. На нём новости, расписание уроков и форма обратной связи для родителей. Сама Joomla 3 тоже официально не поддерживается, так что проблема двойная: старая CMS и старый PHP. Если просто переключить PHP на 8.3, сайт сломается, потому что Joomla 3 эту версию не поддерживает.

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

План обновления по шагам

При переводе любого сайта со старого PHP на новый такой порядок снижает количество ошибок:

1. Зафиксируйте текущее состояние: версия PHP, версии CMS и плагинов, есть ли самописный код.
2. Выберите целевую версию. Сейчас разумно брать минимум 8.3, а лучше 8.4, чтобы хватило на несколько лет.
3. Сделайте полную резервную копию файлов и базы данных.
4. Создайте тестовую копию и включите на ней целевую версию.
5. Обновите CMS, тему и плагины, замените несовместимые.
6. Проверьте журнал ошибок и исправьте найденные проблемы.
7. Обновите основной сайт в период низкой посещаемости и понаблюдайте несколько дней.

В самописном коде самые частые проблемы можно найти заранее. Команда ниже ищет в папке сайта функции, удалённые в PHP 7 и 8:

# mysql_* удалены в PHP 7.0, create_function и each — в PHP 8.0
grep -rnE "mysql_(connect|query|fetch)|create_function\(|[^a-zA-Z_]each\(" \
  --include=*.php ~/www/misol.uz | grep -v "/vendor/"

# Проверка синтаксиса новой версией (путь зависит от сервера)
find ~/www/misol.uz -name "*.php" -not -path "*/vendor/*" \
  -exec /opt/php83/bin/php -l {} \; | grep -v "No syntax errors"

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

Сколько времени это займёт

На современном сайте WordPress, где тема и плагины регулярно обновлялись, смена версии часто занимает несколько минут плюс последующую проверку. Если CMS не обновлялась несколько лет, сначала придётся обновить её, и это может занять день-два. В старом самописном коде нужен просмотр разработчиком, и объём работы зависит от объёма кода.

На хостинге sayt.uz версия PHP выбирается для каждого сайта отдельно, поэтому можно спокойно готовиться на тестовом поддомене с новой версией, оставив основной сайт на старой. Главное — воспринимать старую версию как временное состояние и назначить конкретный срок обновления.