В связи с тем, что вышел новый релиз 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, был предложен и установлен еще в 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.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 () и связанные функции.
Функция именованных параметров вносит существенный вклад в обратную совместимость для всего кода 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, когда один из операндов является массивом, неперегруженным объектом или ресурсом. Исключением является массив + массив, который останется без изменений.
Обработка числовой строки была изменена, чтобы сделать ее более интуитивной и более удобной. Конечные пробелы теперь разрешены в числовых строках для согласованности с тем, как обрабатывается ведущее пространство. В основном это влияет на:
Концепция «строки с начальными цифрами» в основном была отброшена; случаи, когда это остается, существуют для облегчения миграции. Строки, которые генерируют E_NOTICE «Обнаружено некорректное числовое значение», теперь будут генерировать E_WARNING «Обнаружено нечисловое значение», а все строки, которые испустили E_WARNING «Обнаружено нечисловое значение», теперь будут вызывать TypeError. В основном это влияет на:
Изменение E_WARNING на TypeError также влияет на E_WARNING «Недопустимое смещение строки« строка »» для недопустимых смещений строки. Поведение явных приведений к int / float из строк не изменилось.
Нестрогие сравнения чисел и нечисловых строк теперь работают путем преобразования числа в строку и сравнения строк. Сравнение чисел и числовых строк продолжает работать, как и раньше. Примечательно, что это означает, что 0 == «не-число» теперь считается ложным.
Несколько других шаблонов кода, которые могут быть общими в плагинах и темах, которые будут затронуты:
Было реклассифицировано большое количество ранее существовавших ошибок. Вот некоторые из наиболее часто встречающихся:
Поскольку 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. Были открыты запросы на извлечение, чтобы гарантировать включение этих изменений в будущие выпуски этих библиотек.
Как всегда, настоятельно рекомендуется прочитать весь документ по обновлению.
Несмотря на то, что WordPress Core продолжает расширять свою поддержку новых версий PHP, поддержка старых версий останется прежней, оставаясь на уровне PHP 5.6.20 и выше, пока статистика использования не покажет, что влияние на пользователей минимально.
WordPress продолжает призывать всех пользователей использовать самые последние и лучшие версии PHP.
Так вы сможете получать новые статьи первыми