Переход на PHP 8.x за четыре шага — интервью с Джульетт Рейндерс Фолмер

Обновление сайта, плагина или темы WordPress до новой версии PHP — это регулярно повторяющаяся задача. Но как сделать это максимально эффективно? Откуда вы знаете, что ничего не пропустите? Есть ли дорожная карта для этого?

В этой статье мы рассмотрим эти (и многие другие) вопросы и рассмотрим, что необходимо для плавного перехода на PHP 8.x для вашего сайта, плагина или темы WordPress, включая дорожную карту.

Мы сделаем это на основе интервью, которое мы провели с экспертом по PHP Джульеттой Рейндерс Фолмер. Она посвящает большую часть своей повседневной жизни программированию и всему, что с ним связано, уделяя основное внимание проектам с открытым исходным кодом, включая WordPress.

Готовы ли вы сделать переход плавным? Интересен наш пошаговый план? Тогда давайте погрузимся прямо в!

PHP 8.x — что изменилось

Для обзора изменений мы рекомендуем следующие статьи:

• Примечания к выпуску для PHP 8.0 и PHP 8.1
• Руководство по миграции для PHP 8.0 и PHP 8.1
• WordPress и PHP 8.0 и текущий статус
• Что нового в PHP 8.0 и PHP 8.1

Прочитав эти статьи, вы будете полностью в курсе того, что изменилось в PHP 8.x и что вам нужно сделать, чтобы ваши PHP-проекты работали без проблем.

Если вы не уверены, с чего лучше всего начать, не проблема. В разговоре с Джульеттой мы обсудили это подробно, и максимально подробно объясним вам в этой статье, как можно перейти на PHP 8.x.

Мы также объясним в информационных полях, как выполнять различные операции в MyKinsta, нашей собственной панели управления для всех ваших сайтов, приложений и баз данных WordPress.

Переход на PHP 8.x: с чего начать

Переход на PHP 8.x звучит просто, и технически это так. Многие хостинги позволяют указать, какую версию PHP вы хотите использовать для своего сайта в панели администратора. В Kinsta переключение версии PHP можно выполнить одним щелчком мыши на панели инструментов MyKinsta.

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

• Если вы создали свой собственный сайт WordPress со стандартными темами и плагинами, не имея достаточных знаний о PHP, наймите разработчика или агентство, чтобы выяснить, подходит ли ваш сайт для работы на PHP 8.x. Вы ищете третью сторону, которая может помочь вам в этом? Затем загляните на нашу страницу «Партнеры», где перечислены несколько надежных компаний, которые могут вам помочь.
• Если ваш сайт WordPress был создан сторонней организацией, разработчиком или агентством, свяжитесь с ними, чтобы узнать, может ли ваш сайт работать на PHP 8.x.
• Если вы создали свой сайт WordPress — например, с собственной пользовательской темой или самостоятельно разработанными плагинами — у нас есть дорожная карта для вас ниже.

Если ваш сайт попадает в одну из первых двух категорий, мы, безусловно, приглашаем вас прочитать оставшуюся часть статьи, но мы не рекомендуем вам самостоятельно начинать тестирование своего сайта на совместимость с PHP 8. Оставьте это профессионалам.

Что бы вы ни выбрали, мы советуем вам не просто переключать ваш работающий сайт на PHP 8 и «смотреть, работает ли он». Вам интересно, как будет выглядеть ваш сайт, и вам не терпится увидеть, как он будет работать на PHP 8? Затем начните тестирование в промежуточной среде. Хороший хост позволит вам легко настроить промежуточную среду.

В тестовой среде вы можете активировать PHP 8.x и посмотреть, хорошо ли это обновление работает с вашим сайтом. Также есть возможность работать с локальной копией вашего сайта. С помощью нашего бесплатного инструмента разработки DevKinsta вы можете легко импортировать свой сайт с панели управления MyKinsta, после чего вы можете изменить версию PHP на 8.0 или 8.1.

Если вы не видите никаких проблем в промежуточной среде, это не обязательно означает, что на самом деле проблем нет. Дорожная карта ниже расскажет вам, почему.

Тестирование совместимости с PHP 8.x: дорожная карта

Тестирование: ключевое слово для хорошего программного обеспечения. Даже для веб-сайтов WordPress и их компонентов, таких как темы, плагины и ядро ​​WordPress, тестирование — это способ убедиться, что не происходит того, чего вы не хотите.

Проект разработки программного обеспечения состоит в основном из тестирования. В этой статье мы специально рассмотрим тесты, которые помогут вам сделать переход на PHP 8.x плавным. В нашей статье об инструментах DevOps вы найдете раздел с набором инструментов, которые вы можете использовать.

В этом сообщении блога обсуждаются следующие типы тестов:

Давайте более подробно рассмотрим различные типы тестов, которые мы можем выполнять.

Статический анализ (или статическое тестирование)

Первый шаг, который вы можете сделать как разработчик PHP, — это выполнить статический анализ вашего кода с помощью различных инструментов. Статический анализ — это процесс анализа программного обеспечения без выполнения кода. С помощью статического анализа можно обнаруживать ошибки, выявлять проблемы с совместимостью с PHP 8.x, применять стандарты кодирования (например, стандарты кодирования WordPress) и даже изменять и очищать код.

Инструменты для статического анализа

Вы можете выполнять статический анализ с помощью различных инструментов, таких как:

• PHPСовместимость
• Псалом
• PHPStan

На момент написания не все проверки PHP 8.1 поддерживаются в последней версии PHPCompatibility. Проверки PHP 8.1 могут быть в выпуске разработки, поэтому убедитесь, что вы используете их (на данный момент) при использовании PHPCompatibility для анализа вашего проекта и просмотра ошибок/рекомендаций.

Проверки PHP 8.1 скоро будут выпущены в новой основной версии. Если вы хотите быть в курсе последних событий и у вас есть учетная запись GitHub, откройте GitHub-репозиторий PHPCompatibility и перейдите в Watch -> Custom -> Releases , где вы можете получать уведомления о выпуске новой версии.

PHPCompatibility, который проверяет совместимость только для конкретной версии (или диапазона версий) PHP, легко настроить. Вы получите наилучшие результаты, если запустите testVersion — например, 8.0+ (8.0 и выше) — в PHPCompatibility.

Вы должны следить за устаревшими или удаленными функциями, измененными значениями параметров функций по умолчанию, использовать ли concat без круглых скобок, использовать ли match в качестве имени функции (поскольку оно было зарезервировано с PHP 8.0) и т. д.

Psalm и PHPStan являются хорошими дополнениями и могут помочь вам, выполняя дополнительные проверки, связанные с типами переменных. Недостатком этих инструментов является то, что для получения отчетов в PHP 8.0 и 8.1 требуется много настроек. Даже если они успешны, вы можете ожидать много ложных срабатываний. Ложные срабатывания — это ошибочные уведомления, вызванные ограничениями статического анализа.

Необходимы глубокие знания для правильной интерпретации результатов этих двух инструментов, но эти знания могут помочь вам выявить дополнительные несовместимости, которые PHPCompatibility не может найти. Посмотрите документацию по Psalm и PHPStan, если хотите узнать о них больше.

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

• Выполнение статического анализа с помощью PHPCompatibility, Psalm, PHPStan
• Решить все законные проблемы

Модульное тестирование

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

Одного юнит-теста, конечно, недостаточно. Их тоже нужно запускать. Модульные тесты лучше всего автоматизировать с помощью инструментов непрерывной интеграции, таких как Jenkins, GitHub Actions или Travis.

Поддержка нескольких версий PHP

Как разработчик плагинов, если вы хотите поддерживать несколько версий PHP, убедитесь, что тесты в CI выполняются для всех поддерживаемых вами версий PHP.

Конечно, вы также можете поддерживать только более новые версии, выбор полностью за вами.

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

Чтобы обойти это, вы можете использовать PHPUnit Polyfills (написанный Джульеттой и спонсируемый Yoast). Это позволяет вам писать тесты, которые официально не поддерживаются для PHPUnit 9 (и поэтому могут работать на PHP 8.x). Затем полифиллы заставляют ваши тесты работать в PHPUnit от 4.x до 9.x и с PHP 5.4 до PHP 8.1 (на данный момент).[/notice]

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

Покрытие кода

Запуск этих тестов — самый надежный способ найти несовместимость между версиями.

При этом обратите внимание на покрытие кода ваших тестов:

• Предположим, у вас есть функция A и вы написали для нее тест, а функция A вызывает функции B, C и D как часть логики функции.
• Тест для функции A написан для проверки логики функции A, но во время тестирования он также будет вызывать функции B, C и D. Для функций B, C и D вы обычно тестируете только «счастливый путь» — ситуацию, когда все идет хорошо — и, таким образом, эти функции еще не полностью протестированы, хотя (часть) кода в этих функциях выполняется во время тестирования функции A.
• Для каждого из ваших тестов укажите, какой код конкретно тестируется. Вы делаете это, давая каждому тесту @covers. Таким образом, B, C и D не «учитываются» при расчете покрытия кода, что позволяет вам видеть, какая часть вашего кода покрыта тестами.

Часто разработчики пишут и тестируют — иногда даже неосознанно — для «счастливого пути». В этих случаях также необходимо проверить, что происходит, когда в функцию передаются неожиданные данные. Тестирования только с ожидаемыми значениями/типами недостаточно .

«При тестировании вы должны убедиться, что функция делает то, что должна делать, но также и то, что функция не делает того, чего не должна», — Джульетта Рейндерс Фолмер. Нажмите, чтобы твитнуть

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

Обязательно протестируйте свои функции с неожиданными переменными, типами и значениями. Только тогда вы можете полагаться на свои тесты, чтобы найти проблемы, которые может вызвать новая версия PHP.

PHP становится строже

PHP становится более точным (строгим) в том, как он обрабатывает «типы» для собственных функций PHP, а также таких вещей, как динамические свойства. Эти изменения обычно предназначены для того, чтобы помочь разработчикам предоставлять безошибочный код (ну, код с меньшим количеством ошибок). Но это может стать серьезным препятствием для обновления уже существующего кода, написанного на основе «старых» принципов PHP.

Из-за этого стремления к более полезным сообщениям об ошибках в PHP вы можете видеть, что приведение существующего кода в соответствие с новыми версиями PHP занимает все больше и больше времени. Создание кода, который работал на PHP 5.6, подходящего для PHP 7.0, в большинстве случаев занимало лишь часть времени по сравнению с обновлением кода, чтобы сделать его пригодным для PHP 8.1. И это несмотря на то, что PHP 7.0 был «основным» выпуском, а PHP 8.1 — «второстепенным».

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

Модульное тестирование возможно с помощью различных инструментов, в том числе:

• PHPUnit
• издевательство
• Бехат,
• Сюжет

Многие из этих инструментов созданы на основе PHPUnit или в сочетании с ним.

В конечном счете, не имеет значения, какие инструменты вы используете. Самое главное, что вы тестируете и запускаете тесты на новых версиях PHP. Этот шаг иногда может быть очень сложным, но, к счастью, как упоминалось ранее, для этого есть инструменты, такие как PHPUnit Polyfills.

Интеграционное тестирование

Интеграционное тестирование — это следующий шаг, который мы выполним после статического анализа и модульного тестирования. В интеграционном тесте проверяются ситуации из реальной жизни в более широком контексте, чем просто «единица кода». К ним относятся тестирование с активной (тестовой) базой данных или тестирование с внешним API, и это только два примера.

Итак, когда вы тестируете код плагина или темы в контексте WordPress и используете реальную версию, это по определению интеграционные тесты.

WP Test Utils (снова написанный Джульеттой и спонсируемый Yoast) — отличный инструмент для интеграционного тестирования. WP Test Utils предоставляет инструменты для написания интеграционных и модульных тестов, в которых WordPress «моделируется» с помощью Brainmonkey и Mockery, где часто используемые функции WordPress «подделываются», чтобы вы тестировали свой собственный код, а не код WordPress.

Интеграционное тестирование с WordPress — более сложная история, потому что оно включает в себя интеграцию с WordPress и набором тестов WordPress. В зависимости от того, какие версии WordPress поддерживает плагин или тема, вы должны учитывать, какие версии PHPUnit поддерживаются самим WordPress, чтобы запускать тесты на разных версиях PHP.

Например, WordPress с 5.6 по 5.8 использует PHPUnit с 5 по 7 для тестирования PHP с 5.6 по PHP 8.0, но начиная с WordPress 5.9 сам WordPress также использует PHPUnit Polyfills для более широкой поддержки. WP Test Utils действует как мост для преодоления всех этих различий.

Хотите узнать больше о том, как запускать интеграционные тесты для разных версий WordPress, включая WordPress 5.9 и выше? Тогда прочитайте об этом на веб-сайте WordPress.

Ручное тестирование

Теперь, когда вы прошли модульное и интеграционное тестирование и устранили все обнаруженные проблемы, пришло время провести ручное тестирование. Ваш сайт работает, и ваш собственный код работает, но вы также используете плагины A, B и C. Вы знаете, совместимы ли эти плагины?

Например, проверьте это у авторов плагина и посмотрите, указывают ли они, что он совместим с PHP 8.x. Тогда вопрос, конечно, в том, как тестировался плагин. Часто ответ здесь таков: в изоляции. Функции плагина обычно тестировались только в сочетании с WordPress, без других активных плагинов. И даже если в этих тестах использовались другие плагины, есть вероятность, что не все плагины, используемые вами , были частью тестирования, поэтому отнеситесь к такому заявлению о совместимости с долей скептицизма.

Например, сайт WordPress с 3 плагинами (A, B и C). Возможно, что плагин B, например, возвращает неверный тип переменной через фильтр, с которым хочет работать плагин C, используя тот же фильтр. Это может привести к фатальной ошибке, поскольку тип больше не соответствует ожидаемому. Затем плагин C рассматривается как виновник сообщения об ошибке, даже если плагин B является настоящим нарушителем.

Несовместимость совместимости плагинов невозможно обнаружить при изолированном тестировании. Чем больше активных плагинов, тем больше вероятность, что что-то пойдет не так. Например, было бы очень полезно передавать запросы страниц с работающего веб-сайта в промежуточную среду (с включенным ведением журнала ошибок), чтобы выяснить, что на самом деле происходит не так.

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

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

Проверка доступности используемых плагинов

Для разработчиков и групп разработчиков: Принимайте код только при наличии тестов. Таким образом, вы гарантируете, что потребуется меньше ручного тестирования, что сэкономит вам много времени.

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

Тестирование часто рассматривается — несправедливо — как затраты, хотя на самом деле оно экономит деньги. Дополнительные инвестиции, необходимые для написания тестов, окупаются в виде значительно меньшего количества отчетов об ошибках и меньшего времени, затрачиваемого на исправление ошибок. Кроме того, автоматизированное тестирование программного обеспечения позволяет быстрее выполнять расширения и модификации, поскольку тесты могут быстро подтвердить, что существующая функциональность продолжает работать.

''Будьте добры к себе в будущем, пожалуйста ;-)'' - Джульет Рейндерс Фолмер Click to Tweet

Роль хостов WordPress и PHP 8.x

Среднестатистическому владельцу сайта очень желательно руководство от вашего хоста. Рассмотрим следующее:

• Документация и обновления для клиентов о том, что ядро ​​WordPress, плагины и/или темы (в некоторых случаях) несовместимы с разными версиями PHP.
• Варианты тестирования (например, работа с промежуточной средой)
• Способы сообщения об ошибках и обращения в службу поддержки

Это также приносит пользу веб-хостингу, поскольку владельцы сайтов часто обращаются к хосту за помощью при возникновении проблем. В случае перехода на PHP 8.0 или 8.1 ответственность за возможные проблемы несет владелец сайта, и чем больше у него информации для надлежащей подготовки к переходу, тем лучше.

Сделать PHP 8.0 или 8.1 доступным для клиентов в качестве веб-хостинга — это одно, но при этом они должны убедиться, что клиенты осведомлены о возможных проблемах. Рекомендуется протестировать ваш сайт в тестовой среде с версией, отличной от реальной. (Выбор версий PHP по умолчанию доступен в Kinsta.)

Минимальная версия PHP для WordPress

В настоящее время более 15% всех веб-сайтов используют PHP версии 7.0 или ниже. Это видно из официальной статистики WordPress. Около 83% всех сайтов WordPress в настоящее время используют PHP версии 7.4 или ниже. Обратите внимание, что все, что ниже или равно версии 7.4, в настоящее время больше не поддерживается PHP. Использование устаревших версий PHP может привести к проблемам, поскольку обновления безопасности больше не выпускаются.

Чтобы избежать проблем, важно, чтобы владельцы сайтов WordPress знали и сообщали о минимальной версии PHP, которая позволит их сайту работать безопасно. Со своей стороны, владельцы сайтов могут сами изменить версию PHP (это возможно в Kinsta для всех пакетов) или попросить своего хоста обновить сайт до более новой версии PHP. В крайних случаях вы можете переключиться на хост, который поддерживает эти более новые версии.

Поскольку для WordPress требуется только минимальная версия 7.4, у многих хостов и владельцев веб-сайтов недостаточно мотивации для обновления своих сайтов. И это несмотря на то, что PHP 7.4 подошел к концу в ноябре 2022 года.

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

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

Чтобы перейти на PHP 8.0 или выше для вашего веб-сайта, вам или вашему разработчику необходимо выполнить несколько шагов. Важные шаги включают в себя:

• Статический анализ
• Модульное тестирование
• Интеграционное тестирование
• Ручное тестирование

При переходе на PHP 8.x убедитесь, что все правильно протестировано. Это единственный способ гарантировать, что ваш сайт будет работать правильно, быстро и безопасно на более новой версии PHP.

Мы безмерно благодарим Джульетту за участие в этой статье и за всю ее работу над упомянутыми инструментами!

Фотография Джульетты, сделанная Джипом Мурсом и использованная с разрешения.