Поиск по сайту:

Как перенести ваш код с PHP 7.4 на 8.1

В связи с недавним окончанием поддержки PHP 7.4 пришло время перенести ваш код. Вот несколько вариантов сделать это.

Конец жизни (EOL) PHP 7.4 наступил в понедельник, 28 ноября 2022 года. Если вы похожи на меня, эта дата наступила гораздо быстрее, чем ожидалось. Хотя ваш код PHP 7.4 не перестанет сразу работать, вам все же нужно начать строить планы на будущее этой кодовой базы.

Какие у вас есть варианты?

Вы можете продолжать использовать PHP 7.4, но обновление имеет несколько преимуществ. Самыми большими из них являются риск безопасности и поддержка. По мере того, как мы все дальше и дальше отходим от даты EOL, злоумышленники сосредоточат свое внимание на PHP 7.4, зная, что любые обнаруженные ими уязвимости останутся неисправленными в большинстве систем. Использование PHP 7.4 резко увеличивает риск взлома вашего сайта в будущем. Аналогичным образом, поиск поддержки по проблемам, с которыми вы сталкиваетесь в PHP 7.4, становится все труднее. Кроме того, вы, скорее всего, начнете сталкиваться с проблемами совместимости со сторонним кодом/пакетами, поскольку они обновляют свой код для совместимости с более поздними версиями и прекращают поддержку 7.4. Вы также упустите значительные улучшения скорости и производительности, представленные в версии 8.0 и улучшенные в версии 8.1. Но обновлять весь этот устаревший код сложно!

Когда начать?

К счастью, PHP предоставляет официальное руководство по переходу с PHP 7.4 на 8.0, которое поможет вам начать (а также руководство по переходу с 8.0 на 8.1). Обязательно прочтите разделы «Обратно несовместимые изменения» и «Устаревшие функции». Хотя эти руководства невероятно удобны, вам вполне могут потребоваться проверить десятки тысяч строк кода, некоторые из которых вы, возможно, унаследовали. К счастью, есть несколько вариантов, которые помогут определить потенциальные проблемные области при миграции.

PHPCodeSniffer + PHPСниффинг совместимости

PHPCodeSniffer (PCS) — пакет для проверки синтаксиса PHP-кода. Он проверяет ваш код на соответствие набору определенных правил (также известных как «обнюхивания»), называемых «стандартами». PHPCodeSniffer поставляется с набором стандартов, которые вы можете использовать, включая PEAR, PSR1, PSR2, PSR12, Squiz и Zend. К счастью, вы можете написать свою собственную коллекцию сниффов, чтобы определить любой набор правил, который вам нравится.

PHPCompability вошёл в чат

PHPCompatibility «представляет собой набор сниффов для PHP CodeSniffer, который проверяет совместимость между версиями PHP», позволяющий вам протестировать вашу кодовую базу на совместимость с различными версиями PHP, включая PHP 8.0 и 8.1. Это означает, что вы можете использовать PHPCodeSniffer для сканирования вашей кодовой базы, применяя правила PHPCompability для выявления любых несовместимостей с PHP 8.1, которые могут присутствовать.

Прежде чем я продолжу…

Хотя PHP8.2 был выпущен 8 декабря 2022 г., и я советую вам просмотреть официальное руководство по переходу с 8.1 на 8.2 и начать строить планы по обновлению, большинство программ проверки, которые я упоминаю в этой статье, не завершили полную поддержку 8.2. в это время. По этим причинам я сосредоточусь на переносе кода на PHP 8.1, а не на 8.2.

В процессе написания этой статьи я обнаружил, что у PHPCompatibility есть известная проблема при проверке совместимости с PHP 8.0/8.1, когда он сообщает о проблемах, которые должны быть Ошибками, как Предупреждения. Единственный обходной путь на данный момент — использовать ветку develop для PHPCompatibility вместо master. Хотя они заявляют, что это стабильная ветка, имейте в виду, что в этой статье я использую нестабильную ветку. Возможно, вам захочется взвесить все «за» и «против» использования ветки develop, прежде чем реализовывать ее где-либо еще, кроме локальной среды разработки. Хотя я считаю, что PCS+PHPCompatibility является наиболее простым и комплексным решением для проверки несовместимого кода, если вы не хотите использовать нестабильную версию PCS, см. раздел в конце статьи об альтернативных вариантах.

Для целей этой статьи я буду использовать версию SimpleSAMLphp 1.4.6 для проверки несовместимости. Это версия кодовой базы шестилетней давности. Я делаю это не для того, чтобы придираться к SimpleSAMLphp, а потому, что мне нужно что-то, что определенно будет содержать некоторые ошибки. Как выяснилось, весь протестированный мной код Platform.sh, а также мой собственный код уже были совместимы с PHP8.1 и не требовали никаких изменений.

Начать

Для начала сначала клонируйте свою кодовую базу, а затем создайте новую ветку. Теперь вам нужно будет решить, хотите ли вы установить зависимости и запустить сканирование на своем локальном компьютере или в локальной среде разработки, используя что-то вроде DDEV, Lando или Docksal. В этой демонстрации я использую DDEV. Я предлагаю использовать локальную среду разработки, а не запускать непосредственно на локальном компьютере, потому что, хотя не обязательно использовать ту версию PHP, которую вы хотите протестировать, для достижения наилучших результатов рекомендуется это сделать. Если у вас не установлен PHP или не установлена целевая версия, локальная среда разработки позволяет вам создать временную среду с именно тем, что вам нужно, не меняя компьютер.

После настройки среды для PHP 8.1 в командной строке терминала (в моем случае я запустил ddev start и как только контейнеры станут доступны, запустите веб-приложение с помощью ddev ssh), вам необходимо добавить эти новые пакеты, чтобы использовать их для тестирования. Я буду добавлять их с помощью композитора, однако есть несколько способов установить их, если вы предпочитаете сделать это по-другому. Если ваша кодовая база еще не использует композитор, вам нужно будет выполнить инициализацию композитора, прежде чем продолжить.

Поскольку вы будете использовать ветку разработки PHPCompatibility, вам придется выполнить несколько дополнительных шагов, которых нет в обычных инструкциях по установке. Во-первых, для разработки ветки PHPCompatibility требуется альфа-версия phpcsstandards/phpcsutils. Поскольку он помечен как альфа-версия, вам необходимо сообщить композитору, что этот пакет можно установить, даже если он не соответствует вашим минимальным требованиям к стабильности.

$композитору требуется --dev phpcsstandards/phpcsutils:"^1.0@dev"

Затем установите PHPCompatibility, ориентируясь на ветку develop.

$композитору требуется --dev phpcompatibility/php-compatibility:dev-develop

Ветка develop также устанавливает dealerdirect/phpcodesniffer-composer-installer, поэтому вам не нужно добавлять его вручную или напрямую PCS к этому новому стандарту.

Чтобы убедиться, что наши новые стандарты установлены, PCS отобразит известные ему стандарты.

$ phpcs -i
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, PHPCompatibility, PHPCS23Utils and PHPCSUtils

Теперь, когда вы знаете, что ваши стандарты доступны, вы можете поручить PCS сканировать наш код. Чтобы указать PCS использовать определенный стандарт, используйте параметр --standard и укажите ему использовать PHPCompatibility. Однако вам также необходимо указать PHPCompatibility, какую версию PHP вы хотите протестировать. Для этого используйте опцию PCS --runtime-set и передайте ей ключ testVersion и значение 8.1.

Прежде чем начать сканирование, остается одна проблема: код, который вы хотите сканировать, находится в корне проекта (.), но непосредственно поставщик также находится в проекте. корень. Вы не хотите, чтобы код в vendor сканировался, поскольку это не те пакеты, которые вы обязательно контролируете. PCS позволяет вам запретить сканирование файлов/каталогов с помощью опции --ignore. Наконец, вы хотите увидеть ход анализа файла PCS, поэтому передайте параметр -p.

Собираем все вместе:

$phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.1 --ignore=*/vendor/*

Это запустит PCS, который будет выводить информацию о ходе работы по мере сканирования кода вашего проекта. W означает Предупреждения, а E означает Ошибки. В конце сканирования выводится: полный отчет с файлом, содержащим проблему, номер строки, в которой возникает проблема, является ли проблема Предупреждением или Ошибкой. > И конкретная проблема обнаружена.

В общем, Ошибки — это ситуации, которые приводят к фатальной ошибке в PHP 8.1 и которые необходимо исправить перед миграцией. Предупреждения могут относиться к вещам, которые устарели в версии 8.0/8.1, но еще не удалены, или к проблемам, с которыми PCS столкнулся при попытке проанализировать файл.

Учитывая, что отчет может быть длинным и выводится на ваш терминал сразу, существует множество вариантов изменения информации, включенной в отчет, а также несколько форматов отчета.

Когда вы начнете исправлять свой код, вы сможете повторно запустить отчет столько раз, сколько необходимо. Однако в какой-то момент вам понадобится протестировать код в реальной среде PHP8.1 с реальными данными. Если вы используете Platform.sh, это так же просто, как создать ветку, изменить одну строку в файле конфигурации и отправить эту ветку нам. Вы можете посмотреть это видео и убедиться, насколько это просто!

Слишком многое нужно исправить!

Теперь, когда у вас есть четкое представление о том, что необходимо обновить перед миграцией, вам, возможно, предстоит проделать невероятный объем работы. К счастью, у вас есть несколько вариантов, которые могут вам помочь. PCS поставляется с средством исправления кода PHP Code Beautifier and Fixer (phpcbf). Запуск phpcbf практически идентичен запуску phpcs, и большинство опций идентичны. Другой вариант — Ректор. Использование этих инструментов выходит за рамки этой статьи, но, как и в случае любой автоматизации, вам необходимо протестировать и проверить их, прежде чем вносить изменения в рабочую среду.

Альтернативные варианты

Если по какой-либо причине вам неудобно использовать нестабильную версию PCS, у вас есть другие варианты проверки вашего кода.

Фан

Phan — статический анализатор кода PHP. Он предлагает несколько уровней анализа и позволяет постепенно усиливать этот анализ.

«Статический анализ необходимо внедрять медленно, если вы хотите, чтобы ваша команда не сошла с ума. »

Phan не нацелен только на совместимость с новыми версиями, он может выделять области кода, в которых в более поздних версиях возникнут ошибки. Однако есть некоторые предостережения при использовании Phan для проверки совместимости:

  • Медленнее, чем PCS+PHPCompatibility.
  • Phan требует расширения ast php, которое по умолчанию недоступно в Platform.sh (или в DDEV). Вам нужно будет установить его в локальной среде разработки и добавить в файл php.ini. Альтернативно вы можете использовать опцию --allow-polyfill-parser, но это значительно медленнее.
  • Вывод отчетов Phan по умолчанию не так легко читать, как другие варианты.
  • Я столкнулся с проблемой: если ваша база кода устанавливает другой каталог vendor через [config:vendor-dir] композитора (https://getcomposer.org/doc/06-config.md #vendor-dir), выдаст сообщение об ошибке, сообщающее, что не удалось найти определенные файлы в каталоге vendor.
  • Как уже упоминалось, Phan анализирует гораздо больше, чем просто совместимость PHP8.1. Хотя в других ситуациях это, безусловно, преимущество, но если ваша цель — как можно быстрее перейти с версии 7.4 на версию 8.1, вам придется анализировать ошибки, не связанные с совместимостью версий.
  • Требуется запустить его на той версии PHP, на которую вы хотите настроить таргетинг.

PHPStan

Подобно Phan, PHPStan — это статический анализатор кода PHP, который обещает «находить ошибки без написания тестов». И аналогичный набор предостережений применим:

  • Медленнее, чем PCS или Phan
  • Анализирует гораздо больше, чем просто совместимость PHP8.1, поэтому в зависимости от вашей текущей кодовой базы вам, возможно, придется анализировать кучу ошибок, не связанных с совместимостью версий.
  • Требуется запустить его на той версии PHP, на которую вы хотите настроить таргетинг.

Параллельный анализ PHP

Очень быстрый PHP-линтер, который может проверять вашу кодовую базу на наличие проблем, а также проверять наличие устаревших версий. Несмотря на то, что он исключительно быстр, это всего лишь линтер, и поэтому он может выявлять только устаревшие версии, возникающие во время компиляции, а не во время выполнения. В моем примере кода было обнаружено только 2 устаревания против 960 обнаруженных PCS.

Краткое содержание

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

Эта статья первоначально была опубликована на сайте сообщества Platform.sh и переиздана с разрешения.