Сайт на старом PHP 7.x: что уже сломано и как перейти на PHP 8.3/8.4

Если сайт работает на PHP 7.x, у вас не «стабильная версия», а версия без обновлений безопасности. Патчей на неё не будет никогда — дата закрытия поддержки прошла ещё в 2022 году. Для бизнеса это значит простую вещь: известная дыра в PHP остаётся открытой навсегда, и обнаружат её не вы.

Чем опасен PHP 7.x сейчас

• Ноль патчей безопасности. Закрытые после даты EOL уязвимости в самом PHP не исправляются — в любую версию 7.x. Хостер не поможет: он ставит обновления, но только те, что выходит команда PHP, а её больше нет на 7.4.
• Домино на расширения. Компоненты вокруг (расширения, библиотеки, фреймворки) перестают поддерживать 7.x — совместимые версии просто перестают выходить.
• Аудиты и страховые это видят. PHP 7.4 в отчёте сканера — это красный флаг: уязвимости «из коробки», о которых известно всем, включая автоматизированные атаки.
• Панели хостинга уходят вперёд. Новый сервер с PHP 8 по умолчанию — и старый сайт на нём не запускается. Миграция станет проблемой «завтра», но неизбежно.

Где мы во времени

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

• PHP 7.4 — закрыт полностью с ноября 2022 года. Любая новая уязвимость в нём останется незакрытой навсегда.
• PHP 8.0, 8.1 — поддержка тоже завершена (конец 2023-го и конец 2025-го). Это уже не «свежие» версии.
• PHP 8.2 — обновления безопасности до конца 2026 года: последний год жизни, обновляться на неё уже бессмысленно.
• PHP 8.3 — поддерживается до конца 2027-го: цель по умолчанию для большинства сайтов.
• PHP 8.4 — линейка до конца 2028 года: выбирайте её, если ваш фреймворк и плагины к ней готовы.

Правило простое: цель — версия с поддержкой минимум на год вперёд. Обновление «до последней поддерживаемой» без тестов — не цель, а риск.

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

Сайт не «сломается сам по себе» — сломается то, что было написано под правила семёрки. Обычно это четыре группы:

1. Строгость языка. Внутренние функции теперь выдают ошибку типа вместо тихого предупреждения: неверный аргумент — белый экран вместо warning в логах.
2. Сравнения строк и чисел. В PHP 8 изменилась логика 0 == "слово" — старые проверки вроде if ($id == 'abc') начинают вести себя иначе.
3. Удалённые функции. create_function(), each(), фигурные скобки для строки $str{0} — типовые «костыли» старых плагинов и шаблонов.
4. Фреймворки и CMS. Старые версии Laravel, Joomla, Drupal и самописных движков на 7.x официально не поддерживают PHP 8 — сначала обновляют CMS, потом версию PHP.

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

1. Аудит: текущая версия PHP, CMS/фреймворк и их совместимость с 8.3/8.4.
2. Тестовое зеркало сайта на новой версии — прогон всех ключевых сценариев, не только главной.
3. Обновление зависимостей: CMS, плагины, темы, Composer-пакеты.
4. Переключение в проде в часы минимальной нагрузки + мониторинг логов первые сутки.
5. Возврат плана: старая версия остаётся на бэке до конца недели.

Для вашего программиста

• Проверить совместимость можно через PHP Compatibility (PHP_CodeSniffer) по коду проекта и командой composer why-not php 8.3.
• Смотреть vendor/composer/installed.json и CHANGELOG каждого пакета: подняться с Laravel 5/6 сразу на 8.x-код нельзя — пошагово.
• Особое внимание — @-оператору и кастам: в 8.x они ведут себя строже.
• После обновления включить display_errors в off, но вести error_log с алертами.

Итог: PHP 7.x — это сайт, за который никто не отвечает. Обновление — не разовая «чистка», а регулярный шаг: минимум раз в год сверяться с расписанием поддержки.