PHP 8.4 и старый код: какие проблемы могут появиться — личный опыт
 

PHP 8.4 и старый код: какие проблемы могут появиться — личный опыт

Введение
PHP 8.4 уже не за горами, и у многих из нас остались проекты, которые писались под старые версии — от PHP 7.x до 8.0-8.2. С одной стороны — хочется ловить новые фишки, с другой — страх, что после обновления что-то перестанет работать и придется в срочном порядке перебирать весь код. В этой теме хочу поделиться тем, с чем столкнулся сам при попытке перейти на PHP 8.4, рассказать о проблемах, которые могут возникнуть, и на что стоит обратить внимание, чтоб избежать критичных сбоев.

Что нового и почему это важно
PHP 8.4 — это не просто очередное обновление. Это шаг к тому, чтобы язык стал более строгим и правильным, с точки зрения типизации, безопасности и производительности. Разработчики активно убирают устаревший функционал, усиливают правила работы с типами, меняют некоторые базовые механизмы.

Если у вас код, который написан под PHP 7 или даже ранние версии восьмой, то при переходе на 8.4 может случиться так, что часть функций просто перестанет работать, а другое поведение вызовет странные баги. Обновлять старый код надо тщательно: просто заменить версию php в настройках сервера и надеяться, что все само заработает — слишком большой риск.

Особенности перехода на PHP 8.4
Что конкретно изменится в относительно старом коде?

Типизация и проверка возвращаемых значений
В PHP 8.4 гораздо строже относятся к типам. Это значит, что если у вас были функции без деклараций типов или с объявлением, которое раньше воспринималось лояльно, теперь возможны ошибки. Например, раньше можно было спокойно возвращать null из функции, которая по аннотациям должна выдавать int. Теперь такое вызовет TypeError.

Если у вас много legacy-кода без строгой типизации, придётся либо постепенно добавлять декларации, либо писать проверки и касты вручную. Или пользоваться аннотациями в phpdoc, но на них нововведения не влияют, это больше для IDE.

Deprecated функции и удалённые возможности
С каждым новым релизом PHP уходят по-настоящему устаревшие функции. В PHP 8.4 полностью отказываются от таких функций, как create_function(), each(), ereg() и других, которые активно использовались в старом коде.

Если где-то в проекте до сих пор встречается create_function, его надо срочно переписывать на анонимные функции, потому что при загрузке скрипта PHP выдаст "undefined function" и скрипт не запустится. То же самое касается журнала deprecated-уведомлений — раньше это были лишние предупреждения, теперь это реальные ошибки.

Ключевые слова и их использование
PHP 8.4 добавляет новые ключевые слова, например match. Если в вашем коде есть методы, свойства или переменные с такими именами, столкнётесь с синтаксической ошибкой — код просто не пройдет парсер. Придётся переименовывать.

Это достаточно частая проблема на больших проектах, где частенько "match" встречается как метод, сокращение или часть имени функции. Совет — перед миграцией прогоните весь код по статическому анализатору типа PHPStan или Psalm. Они помогут найти похожие проблемы заранее.

Изменения в работе с массивами и объектами
PHP 8.4 слегка меняет логику преобразования и сравнения. Например, приведение типов массивов или обращение к объектам по определённым индексовым ключам теперь может вести себя иначе.

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

Стоит внимательно проверить все места, где сливаются массивы, происходит спринговое преобразование типов, касты к массивам и наоборот, а также обращаться с объектами как с массивами.

Автозагрузка и namespace
В PHP 8.4 появились улучшения в работе с автозагрузкой классов, в том числе более строгие требования к PSR-4 и PSR-0. Если вы до сих пор используете костыльные решения, например, самописные автозагрузчики, которые не соответствуют современным стандартам, скорее всего, после апдейта они перестанут работать или будут вызывать медленную загрузку и ошибки.

Плюс теперь надо внимательно относиться к namespace и структуре проекта — много чего теперь отлавливается на уровне языка и парсера при первом включении файла.

Практические примеры из жизни
- В одном из проектов у меня было много вызовов функции create_function для динамического описания колбеков. После обновления сайт стал падать с Fatal error. Перекодировал все на анонимные функции, а заодно избавился от кучи костылей.
- В другой ситуации несколько функций возвращали null, хотя должны были отдавать int или string (по аннотации). PHP 8.4 стал жестко ругаться, пришлось добавить проверки и возвращать значения по умолчанию.
- На фреймворке с кастомным автолоадером после перехода на PHP 8.4 начались ошибки "class not found". В итоге перешёл на Composer и стандарт PSR-4, что решило проблему и ускорило загрузку.
- Были проблемы из-за использования namespace "match" в одном проекте, пришлось переименовывать.

Типичные ошибки при миграции
- Ожидание, что код просто заработает без изменений — лучше всего тестировать сначала на отдельной ветке.
- Игнорирование deprecated warnings — они теперь переходят в ошибки.
- Отсутствие проверки типа в функциях и методах, что приводит к TypeError после обновления.
- Непроверенные сторонние библиотеки, которые не обновлялись под PHP 8 и содержат устаревший функционал.
- Использование переменных и методов с именами новых ключевых слов.

Чек-лист перед обновлением на PHP 8.4
1. Прогоните весь код через статический анализатор (PHPStan / Psalm) на предмет ошибок и deprecated.
2. Проверьте и обновите третьесторонние зависимости, особенно если они старые.
3. Замените все create_function() и устаревшие функции.
4. Добавьте строгую типизацию в функции и методы, особенно возвращаемые значения.
5. Проверьте код на использование новых ключевых слов как идентификаторов.
6. Пересмотрите автозагрузку, если она самописная, лучше перейти на Composer + PSR-4.
7. Проведите прогон юнит-тестов и интеграционных тестов, если их нет – создайте базовые.
8. Тестируйте на staging или локальной копии.

FAQ
Вопрос: Мой код на PHP 7.4, можно ли сразу мигрировать на PHP 8.4?
Ответ: Можно, но делать это нужно поэтапно. Рекомендуется сначала перейти на 8.0 или 8.1, исправить все ошибки и deprecated-уведомления, а уже потом двигаться на 8.4. Резкий переход может сломать всё.

Вопрос: Что делать, если используемые мной библиотеки не поддерживают PHP 8.4?
Ответ: Ищите обновления или замену. Если это невозможно, есть смысл либо откатиться на предыдущую стабильную версию PHP, либо форкать библиотеку и исправлять вручную.

Вопрос: Как проверить, что мой код не использует новые ключевые слова в качестве идентификаторов?
Ответ: Создайте скрипт, который спокойно парсит весь код или используйте статический анализ с современными инструментами. Также можно просто искать по тексту ключевые слова, например "match", "enum" и другие.

Вопрос: Многие пишут, что строгая типизация усложняет жизнь, как с этим бороться?
Ответ: Типизация реально добавляет дисциплины, но она и помогает избегать багов на проде. Лучше постепенно вводить типы, не пытаться переписать всё сразу. Можно добавить типы в новых функциях и постепенно мигрировать старый код.

Вопрос: Как удалять deprecated функции, если они в огромном количестве?
Ответ: Начинайте с самых критичных и частоупотребимых. Можно сделать поиск по проекту. Частично заменяйте на аналоги современных функций или анонимные функции.

---

В общем, апдейт на PHP 8.4 — дело серьезное, особенно если в проекте много старого и мало дисциплины с типами. Но если подойти аккуратно, с тестами и постепенно — получите более современный и стабильный код, плюс много новых возможностей, которые облегчат разработку в будущем. Всем удачи с миграцией!