Версии PHP: поддержка и безопасное обновление

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

Начать стоит с официальной таблицы поддержки PHP. Она помогает выбрать ветку и составить план обновлений. Переход на PHP 8.5 имеет смысл, если эту ветку поддерживают приложение, зависимости и хостинг. Поддерживаемая и проверенная PHP 8.4 тоже может быть подходящей рабочей основой.

Что означает поддержка версии

PHP развивается несколькими ветками. У каждой есть свой срок поддержки.

• Активная поддержка: проект PHP исправляет ошибки и уязвимости, выпускает обновления.
• Исправления безопасности: активная поддержка завершилась; ветка получает исправления критических проблем безопасности по мере необходимости.
• Окончание поддержки, EOL: проект PHP больше не поддерживает ветку. Для дальнейшей эксплуатации нужно планировать переход.

Общая политика PHP — примерно два года активной поддержки и ещё два года исправлений безопасности. Конкретную дату смотрите в таблице для нужной ветки. Она важнее расчёта по возрасту версии.

Даты сверены с PHP.net 14 октября 2026 года. Перед выбором версии откройте источник ещё раз: эту таблицу в статье тоже нужно поддерживать в актуальном состоянии.

Ветка 8.4 и конкретный выпуск 8.4.x — разные уровни выбора. Срок до конца 2028 года относится к ветке. Чтобы получать доступные исправления, нужно устанавливать её актуальные выпуски. Старый 8.4.0 не становится защищённым только потому, что поддержка 8.4 ещё действует.

Поддержка последней ветки семейства PHP 7, версии 7.4, завершилась 28 ноября 2022 года. Более ранние ветки 7.x также не поддерживаются проектом PHP. Отдельная поддержка поставщиком ОС или хостинга может иметь свои условия; её нельзя считать продолжением поддержки PHP без подтверждения поставщика.

Как мы выбирали PHP 8.4

В 2025 году мы переводили ключевые проекты с PHP 7.x, старых CentOS и BitrixEnv 7.x на Rocky Linux 9, BitrixEnv 9.x и PHP 8.4. При выборе ветки опирались на ту же таблицу PHP.net.

Она давала понятный ориентир: поддержка PHP 8.4 на уровне исправлений безопасности заявлена до 31 декабря 2028 года. Такой горизонт помогает заранее распределить работу и подготовить следующий переход. Внутри выбранной ветки обновления всё равно нужны.

В октябре 2026 года, после новостей о критических уязвимостях в PHP, мы оперативно перешли на PHP 8.5. Поддержка этой ветки на уровне исправлений безопасности заявлена до 31 декабря 2029 года.

Следующую стабильную ветку, PHP 8.6 или более новую, будем рассматривать после её выхода, если она подойдёт проектам. Это предварительный план. Окончательный выбор будет зависеть от совместимости приложений, поддержки инфраструктуры и результатов проверки. Время покажет.

Таблица PHP определяет сроки PHP. Она не обещает поддержку всей связки до той же даты. У Rocky Linux, BitrixEnv, Битрикс, веб-сервера и библиотек свои условия и сроки — их проверяем отдельно.

Зачем поддерживать актуальность ПО

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

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

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

Где помогают SRE и DevOps

SRE — инженерная работа над надёжностью сервиса. Для обновления это означает понятные критерии: что должно продолжать работать, какие ошибки недопустимы и по каким признакам мы решим вернуть прежнюю версию.

Навыки DevOps помогают связать код с окружением: управлять настройками, повторять сборку, проверять зависимости и выпускать изменения в согласованном порядке. Разработчику полезно понимать, какой PHP обслуживает сайт, какие расширения нужны приложению и где смотреть ошибки. Инфраструктурному специалисту нужен список важных пользовательских сценариев и зависимостей проекта.

Перед обновлением стоит согласовать четыре вещи:

1. Состав среды: версии PHP, ОС, приложения, расширений и библиотек.
2. Критерии проверки: какие действия пользователя и интеграции должны работать.
3. Восстановление: кто возвращает прежнюю среду, где лежит копия и как восстановить данные.
4. Наблюдение после выпуска: ошибки, доступность, время ответа и выполнение важных операций.

Повторяемый выпуск и проверенный способ восстановления помогают команде управлять изменением. Эти практики можно применять и без отдельной должности SRE или DevOps. На shared-хостинге часть работы выполняет провайдер, поэтому границы ответственности нужно уточнить заранее.

Узнайте, какой PHP действительно работает

На shared-хостинге начните с панели: посмотрите версию PHP для домена и включённые расширения. Уточните доступные настройки и журналы у провайдера. Для этого не нужен доступ к bash.

Если у команды есть терминал на тестовом сервере или компьютере, выполните:

php -v
php -m

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

Для многоязычного сайта проверьте UTF-8 и необходимые расширения. Например, обработчик Markdown может использовать mbstring при расчёте отступов с табуляцией. Его отсутствие иногда проявляется только на одном материале.

Проверьте код и реальные сценарии

Для перехода с PHP 8.3 на 8.5 изучите изменения обеих промежуточных веток: 8.4 и 8.5. PHP предупреждает, что несовместимости нужно проверить до смены версии в рабочей среде.

При наличии терминала из корня проекта можно проверить синтаксис:

rg --files -g '*.php' -0 | xargs -0 -n 1 php -l

Команда требует rg и xargs. Она перечисляет PHP-файлы и проверяет синтаксис выбранной версией PHP. Она не выполняет пользовательские сценарии. При отсутствии консоли используйте доступную тестовую копию и проверки, которые может выполнить провайдер.

На тестовой среде включите E_ALL и журнал ошибок. Отображение ошибок допускайте только в закрытом для посетителей окружении. Проверьте страницы, фоновые обработки и интеграции, которые есть в проекте. RSS и sitemap тоже нужно открыть: предупреждение PHP внутри XML может испортить документ.

Устаревшие конструкции исправляйте по результатам проверки. Например, nullable-параметр объявляйте явно:

function loadTitle(?string $title = null): string
{
    return $title ?? 'Без названия';
}

В PHP 8.5 предпочитайте обычные приведения (int), (bool), (float) и (string). В новых участках кода не используйте устаревшие варианты (integer), (boolean), (double) и (binary). Не скрывайте предупреждения оператором @; выясняйте причину и проверяйте изменение на реальных входных данных.

Сохраните защиту и подготовьте откат

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

Для текста в HTML используйте явную кодировку:

function escapeHtml(string $text): string
{
    return htmlspecialchars($text, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

Для JSON, адресов и других контекстов нужны соответствующие способы кодирования. Markdown с чужим HTML обрабатывайте в безопасном режиме.

Сохраните файлы, настройки и данные, если проект использует БД. Проверьте восстановление на тестовой копии. При обновлении ОС или структуры данных возврата файлов может быть недостаточно — способ отката нужно согласовать заранее.

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

Источники

• PHP: сроки поддержки веток.
• PHP: ветки с завершённой поддержкой.
• Миграция на PHP 8.4.
• Миграция на PHP 8.5.
• Параметры командной строки PHP.
• Ошибки и безопасность.
• Экранирование HTML.
• Google SRE: воспроизводимый выпуск ПО.
• Оформление кода PSR-12.

Переходы на PHP 8.4 в 2025 году и на PHP 8.5 в 2026 году, а также план на следующую ветку описаны по опыту нашей команды. Проверки и рекомендации в следующих разделах не являются отчётом о шагах, выполненных в этих миграциях.