WordPress и PHP 8.0

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

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

 

Что здесь означает «совместимость»?

Значительные усилия были приложены к тому, чтобы WordPress 5.6 сам по себе был совместим с PHP 8, но весьма вероятно, что некоторые проблемы остались.

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

Также следует признать, что WordPress никогда не используется изолированно (без какой-либо темы или плагинов), поэтому возможность работы WordPress на PHP 8 не означает «полную» совместимость. Состояние поддержки PHP 8 в более широкой экосистеме (плагины, темы и т. д.) узнать невозможно. По этой причине WordPress 5.6 следует считать «бета-совместимым» с PHP 8.

 

«Бета-совместимость»

Назвать WordPress 5.6 «бета-совместимым» — это хороший первый шаг. Это свидетельствует о большой работе, проделанной для того, чтобы WordPress работал на PHP 8 без серьезных проблем и прошел тесты PHPUnit. Также отмечается приверженность проекта к обеспечению совместимости с новыми версиями PHP, когда они будут выпущены.

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

Всем разработчикам плагинов и тем, а также сообществам хостинга предлагается сделать свой код совместимым с PHP 8. Это позволит WordPress быстрее достичь действительно «полной совместимости», и конечным пользователям не придется нести бремя.

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

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

 

Типы выпусков PHP

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

В текущем основном выпуске PHP — 7 за последние 5 лет было выпущено 4 функциональных выпуска (7.1, 7.2, 7.3 и 7.4) и более 130 выпусков безопасности и исправлений ошибок для этих функциональных выпусков.

 

Выпуски функций

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

Когда в этих выпусках более старые функции не рекомендуются, они остаются функциональными. Обычно устаревшие функции вызывают ошибки (обычно уровень E_WARNING, E_NOTICE или E_DEPRECATED), информируют разработчиков о том, что функция не рекомендуется. Устаревшие функции могут быть удалены только в будущем выпуске.

 

Основные выпуски

Как и выпуски функций, исправления ошибок и новые функции могут быть добавлены в основные выпуски. Однако старые функции можно полностью удалить, поддержка обратной совместимости и совместимости API не требуется.

Начиная с PHP 8 RC4, в ядре PHP было 48 изменений, нарушающих обратную совместимость, и 166 изменений во всем PHP 8 в целом (расширения, библиотеки и т. д.).

 

Что это значит для разработчиков?

Сайты, которые постоянно обновляются до последних версий PHP и решают проблемы с каждым выпуском функций, обычно с меньшей вероятностью будут испытывать проблемы при обновлении до новой основной версии. Новые функции PHP 8 несовместимы с PHP 7 или PHP 5 и обычно вызывают фатальные ошибки.

Несмотря на то, что настоятельно рекомендуется делать плагин или тему совместимыми с PHP 8, использовать функции, добавленные в PHP 8, не рекомендуется, если для параметра Requires PHP не установлено значение 8.0 в разделе заголовка основного файла плагина или файла style.css темы.

 

Изменения в PHP 8

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

 

Именованные параметры

В PHP 8 появилась возможность передавать аргументы функции по имени параметра вместо позиции параметра. Это удобно по многим причинам, но вот несколько из них:·

• Значение аргумента становится самодокументированным.
• Аргументы становятся независимыми от порядка.
• Значения по умолчанию можно пропустить.

В качестве примера рассмотрим получение термина в виде ассоциативного массива с помощью get_term().

<?php

// PHP < 8.0

$my_term = get_term( 1, », ARRAY_A );

 

// PHP >= 8.0

$my_term = get_term( output: ARRAY_A, term: 1 );

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

Именованные параметры также работают с внутренними функциями PHP.

<?php

// Using positional arguments:

array_fill( 0, 100, 50 );

 

// Using named arguments:

array_fill( start_index: 0, count: 100, value: 50 );

Это упрощенный обзор функции именованных параметров. Пожалуйста, прочтите полный запрос комментариев (RFC) на веб-сайте PHP, чтобы получить полную разбивку, в которой подробно описывается влияние на вариативные функции, func_get_args () и связанные функции, а также call_user_func_array () и связанные функции.

 

Именованные параметры и WordPress

Функция именованных параметров вносит существенный вклад в обратную совместимость для всего кода PHP в будущем. С введением этой функции имена параметров становятся частью контракта API, и любые изменения их имен в будущих выпусках WordPress нарушат обратную совместимость, вызывая фатальную ошибку, когда код вызывает функцию с использованием устаревшего имени параметра.

Был предложен активный обзор сигнатур функций во всем WordPress Core, чтобы гарантировать, что все имена параметров являются описательными, точными и не используют зарезервированные ключевые слова, чтобы избежать какой-либо путаницы, но это не будет частью WordPress 5.6.

Использование именованных параметров при вызове функций и методов класса WordPress явно не поддерживается и настоятельно не рекомендуется, пока этот аудит не будет завершен, поскольку во время аудита имена параметров могут быть изменены без предварительного уведомления. Когда этот аудит будет завершен, об этом будет объявлено в будущей заметке разработчика. Если вы решите воспользоваться преимуществами именованных параметров при использовании функций и классов WordPress Core до этого времени, то вы рискуете.

Кроме того, PHP Core пересматривает собственные имена параметров. Поскольку документация PHP еще не обновлена, чтобы отразить изменения PHP 8, некоторые имена параметров, подробно описанные в документации, также могут измениться.

 

Строгие проверки типа / значения для внутренних функций

Когда в PHP 7.0 была добавлена ​​поддержка объявлений скалярных типов, также была добавлена ​​новая (необязательная) директива для каждого файла для обеспечения строгой проверки типов. Включая declare (strict_types = 1) в верхней части файла обеспечит выполнение строгой проверки типов для всех аргументов и возвращаемых значений, в которых были объявлены скалярные типы.

При настройке строгая проверка типов также распространяется на расширения и внутренние функции PHP, вызываемые в файле. В строгом режиме, когда тип переданного значения не соответствует ожидаемому типу, выдается критическая ошибка: Uncaught TypeError.

Однако, когда строгая проверка типов не была включена, поведение внутренних функций при получении неожиданного типа было очень непоследовательным. Некоторые выдали предупреждение и вернули NULL, некоторые вернули false и выбросили TypeError со строгими типами, а другие сгенерировали TypeError (даже если strict_types не был объявлен).

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

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

Проверка типов для пользовательских функций останется прежней. Включая declare (strict_types = 1); в верхней части файлов требуется для обеспечения строгой проверки типов во всем файле. Ни один код WordPress Core не использует строгий режим.

 

Более строгие проверки типов для арифметических и побитовых операторов

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

Начиная с PHP 8, все арифметические и побитовые операторы будут вызывать ошибку TypeError, когда один из операндов является массивом, неперегруженным объектом или ресурсом. Исключением является массив + массив, который останется без изменений.

 

Более разумные числовые строки

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

• Функция is_numeric ()
• Сравнение строк со строками
• Объявления типов
• Операции увеличения и уменьшения

Концепция «строки с начальными цифрами» в основном была отброшена; случаи, когда это остается, существуют для облегчения миграции. Строки, которые генерируют E_NOTICE «Обнаружено некорректное числовое значение», теперь будут генерировать E_WARNING «Обнаружено нечисловое значение», а все строки, которые испустили E_WARNING «Обнаружено нечисловое значение», теперь будут вызывать TypeError. В основном это влияет на:

• Арифметические операции
• Побитовые операции

Изменение E_WARNING на TypeError также влияет на E_WARNING «Недопустимое смещение строки« строка »» для недопустимых смещений строки. Поведение явных приведений к int / float из строк не изменилось.

 

Нестрогие сравнения чисел и нечисловых строк

Нестрогие сравнения чисел и нечисловых строк теперь работают путем преобразования числа в строку и сравнения строк. Сравнение чисел и числовых строк продолжает работать, как и раньше. Примечательно, что это означает, что 0 == «не-число» теперь считается ложным.

Несколько других шаблонов кода, которые могут быть общими в плагинах и темах, которые будут затронуты:

• » < 0 теперь считается истинным.
• ‘not-a-number’ > 0 также теперь считается истинным.

 

Ошибки, предупреждения и уведомления об изменениях

Было реклассифицировано большое количество ранее существовавших ошибок. Вот некоторые из наиболее часто встречающихся:

 

Предупреждения преобразованные в исключение ошибок

• Попытка записи в свойство не-объекта. Ранее это неявно создал объект stdClass для нулевых, ложных и пустых строк.
• Попытка добавить элемент в массив, для которого уже используется ключ PHP_INT_MAX.
• Попытка использовать недопустимый тип (массив или объект) в качестве ключа массива или смещение строки.
• Попытка записать в индекс массива скалярное значение.
• Попытка распаковать не-массив / Traversable.

 

Уведомления преобразованные в предупреждения

• Попытка прочитать неопределенную переменную.
• Попытка прочитать неопределенное свойство.
• Попытка прочитать неопределенный ключ массива.
• Попытка прочитать свойство не-объекта.
• Попытка получить доступ к индексу массива не-массива.
• Попытка преобразовать массив в строку.
• Попытка использовать ресурс в качестве ключа массива.
• Попытка использовать null, логическое значение или число с плавающей запятой в качестве строкового смещения.
• Попытка прочитать смещение строки за пределами допустимой границы.
• Попытка присвоить смещению строки пустую строку.

Изменения, связанные с инструментами сборки и тестирования

Поскольку WordPress поддерживает PHP 5.6.20 или выше, запустить набор тестов WordPress Core PHPUnit на PHP 8 непросто.

PHPUnit > = 9.3 — единственная версия PHPUnit, которая в настоящее время поддерживает PHP 8.

PHPunit 5.7.x — последняя версия, которая включает поддержку PHP 5.6.

PHPUnit 8.x изменил несколько методов, которые не возвращают значения, чтобы указать объявление типа возврата void. Однако этот тип возврата недоступен в PHP <7.1.

Чтобы сохранить возможность запуска набора тестов на PHP 5.6, а также разрешить запуск тестов на PHP 8, необходимые изменения PHPUnit были перенесены в набор тестов WordPress Core, а Composer используется для управления процессом автозагрузки для PHPUnit. 7.x.

Чтобы запустить набор тестов WordPress Core PHPUnit на PHP 8, необходимо использовать Composer для установки и запуска.

Чтобы упростить эту задачу, был добавлен новый сценарий NPM для запуска набора тестов в локальной среде Docker с использованием установленной Composer версии PHPUnit.

Внешние библиотеки

Несколько внешних библиотек были обновлены совместно с WordPress Core, чтобы исправить проблемы совместимости с PHP 8. Были открыты запросы на извлечение, чтобы гарантировать включение этих изменений в будущие выпуски этих библиотек.

• SimplePie обновлен с версии 1.5.5 до 1.5.6. Кроме того, класс WP_Feed_Cache объявлен устаревшим и будет загружаться для обратной совместимости только в том случае, если SimplePie < 3 загружен в плагин.
• sodium_compat был обновлен, чтобы избежать ошибки при попытке доступа к константе MB_OVERLOAD_STRING, которая была удалена в PHP 8.
• Text_Diff был обновлен для исправления фатальной ошибки «Нестатический метод не может быть вызван статически».

 

Дополнительные замечания

• create_function () удален. Последний экземпляр этой функции в WordPress был удален
• Оператор @ больше не отключает фатальные ошибки. Следует позаботиться о том, чтобы сообщения об ошибках не отображались в производственной среде, что может привести к утечке информации.
• Сразу после оператора хеш-комментария # открывающая скобка больше не поддерживается в качестве комментария, поскольку этот синтаксис теперь используется для атрибутов.
• libxml_disable_entity_loader () устарела.
• Изменён тип возвращаемого значения ресурса в объект, включая введение функции is_gd_image ().
• Изменения в сортировке: если какой-либо код полагался на определенный порядок сортировки, основанный на предыдущем поведении, теперь это может не работать.
• Типы параметров / возвращаемых значений для различных функций PHP изменились и могут оказать влияние. Такие тонкие изменения, как substr () теперь всегда будут возвращать строку. Ранее она возвращало string | false.

 

Как всегда, настоятельно рекомендуется прочитать весь документ по обновлению.

Несмотря на то, что WordPress Core продолжает расширять свою поддержку новых версий PHP, поддержка старых версий останется прежней, оставаясь на уровне PHP 5.6.20 и выше, пока статистика  использования не покажет, что влияние на пользователей минимально.

WordPress продолжает призывать всех пользователей использовать самые последние и лучшие версии PHP.

Оригинальный текст статьи на английском языке