WordPress и PHP 8 — совместимость и преимущества!

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

Что ж, как только вышел PHP 8, наше экспертное время погрузилось в самый глубокий уровень тестирования, и результат может шокировать любого! Да, теперь мы все знаем и с удовольствием выставляем напоказ свои отчеты и результаты дегустаций.

Мы не только покажем, что все изменилось, но и дадим вам четкий совет относительно того, стоит ли вам обновляться до PHP 8 или нет.

Так много критических изменений в PHP 8: но почему?

PHP 8 — это огромное обновление PHP, и общепринятой практикой является удаление минусов в основных версиях из недавнего ряда второстепенных версий. Для получившего широкую огласку PHP 8 в предыдущих версиях 7.* было сокращено несколько критических изменений.

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

Мы бы сказали, что миграция с PHP 5.6 на PHP 7 была довольно простой, но переход с 7.x на 8 может быть несколько болезненным, особенно для старых кодовых баз, включая WordPress, помимо нескольких доступных плагинов.

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

WordPress уже совместим с PHP 8?

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

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

Какие изменения производительности грядут?

Главной потенциально интересной функцией, появившейся в PHP 8, является компиляция и отладка JIT (Just In Time). Как мы знаем, PHP является интерпретируемым языком, что означает, что он транслируется в машинный код при запуске.

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

Включение JIT в различные языки, например, в JavaScript, исторически приводило к бурному развитию новых приложений. Например, виртуальные машины, работающие на JS, были бы немыслимы на заре Интернета. Несколько задач, которые в прошлом потребовали бы установки модулей на сервер, будут практичны с использованием основных библиотек PHP.

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

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

Как обновить PHP для вашего сайта WordPress?

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

Если вам не терпится узнать путь, просто проверьте текущую версию PHP, а затем обновите WordPress до последней версии. После этого установите «сканер one.com PHP» и запустите сканирование, чтобы устранить потенциальные проблемы. Кроме того, обновите PHP до последней версии и проверьте, работает ли ваш сайт должным образом или нет.

Покажем весь процесс.

Шаг 1. Проверьте текущую версию PHP.

В самом начале вы должны проверить, с какой версией PHP вы сейчас работаете. Вы можете получить информацию о текущей версии PHP вашего сайта на странице phpinfo.

Если вы работаете в cPanel, вы можете просмотреть версию PHP из статьи , как просмотреть и изменить версию PHP в cPanel.

Если вы используете PHP версии 7.3 или выше, то все в порядке. Для тех, у кого PHP 7.2, необходимо обновление. Пожалуйста, лелеяйте шаг 2.

Шаг 2: Обновите WordPress до последней версии

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

1. Войдите в свою административную панель WordPress и нажмите «Панель управления » > «Обновления » .
2. Проверьте, установлена ​​ли у вас последняя версия WordPress и все ли темы и плагины обновлены. Обновите свой WordPress до последней версии прямо сейчас.

Шаг 3: Установите «сканер PHP one.com».

1. В панели администратора WordPress коснитесь one.com > Плагины .
2. Найдите сканер one.com PHP и нажмите «Установить сейчас » .
3. Теперь нажмите « Активировать » и перейдите к следующему шагу.

Шаг 4. Запустите сканирование и устраните потенциальные проблемы

1. В меню слева нажмите Сканер PHP .
2. Нажмите « PHP версии 7.4 », затем « Все темы и плагины », а затем нажмите «Начать сканирование » .
3. Вы можете продолжить после завершения сканирования.
4. У вас может быть три результата:

- Совместимо = значит все хорошо!

– Предупреждение = Это означает, что это должно работать, но может вызвать проблемы с предстоящей версией PHP.

– Ошибка = Это не так хорошо, после обновления наверняка возникнут проблемы.

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

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

Шаг 5: Обновите PHP до версии 8.0

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

1. В панели управления вернитесь к настройкам PHP и базы данных .
2. Прокрутите вниз до сообщений об ошибках PHP .
3. Нажмите « Обновить » после установки для сообщений об ошибках значения « Вкл .».
4. Непосредственно под этим измените версию и нажмите «Обновить » .

Шаг 6: Убедитесь, что ваш сайт работает должным образом.

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

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

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

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

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

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

Проблемы совместимости WordPress и PHP8

Мы покажем вам несколько стратегий, которые вы можете использовать, чтобы сделать существующую кодовую базу совместимой с PHP 8.

• Инструменты статического анализа, такие как PHPCompatibility, для обнаружения синтаксических проблем.
• Автоматизированное тестирование для обнаружения проблем во время выполнения.
• Ручное тестирование для выявления проблем во время выполнения.

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

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

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

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

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

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

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

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

Сканирование WordPress с PHPCompatibility

«__destruct() больше не будет вызываться после die() в __construct()» — это еще одна проблема PHP 8, обнаруженная PHPCompatibility. Это прекрасно определяется сканером. Однако после дальнейшего анализа выяснилось, что в данном случае это не проблема.

Кроме того, PHPCompatibility обнаружил проблему в коде, используемом «редактором плагинов/тем». Анализ задействованного кода определил наличие скрытого упущения в коде. В редакторе WordPress ожидает минимального анализа кода; однако он не принимает во внимание код PHP 5.3+.

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

Сканирование WordPress с помощью Exakat

Говоря о последнем общедоступном сканировании, которое состоялось 16 октября на основе транка WP, Exakat сообщает о 149 567 проблемах.

Отчет о совместимости с PHP 8 показывает нам в общей сложности 93 проблемы. Однако он неполный, так как число анализов, относящихся к PHP 8, не включено в отчет.

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

Неважно, что только 1% найденных проблем является правильным, это все равно уменьшится до ~450 ошибок, с которыми еще нужно разобраться. Кроме того, требуется огромное количество времени, чтобы отсеять подлинные проблемы от ложных срабатываний.

Сканирование WordPress с помощью PHPStan

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

Примечание: мы не критикуем инструментарий PHPStan, но во многом это связано с тем, что WordPress почти не использует объявления типов, в то время как, с другой стороны, PHPStan в первую очередь склонен к проектам, использующим современный код, не так ли?

Первоначальное сканирование, включающее самые основные конфигурации, выявит более 20 000 проблем. Сканирование с помощью упомянутого выше набора правил с высокой степенью настройки, предназначенного конкретно для проблем, связанных с PHP 8, по-прежнему дает ровно 580 проблем на уровне 5 и дополнительных 2150 потенциальных проблем на уровне 7. Они, вероятно, будут содержать несколько ложных срабатываний и тем не менее дадут еще 380 проблем. на уровне 8 с аналогичной оговоркой.

Недавно была открыта заявка Trac для устранения списка проблем, связанных с неизвестной конфигурацией, но полностью нацеленных на несоответствие типа переданного параметра (уровень 5). Доступен проект PR для устранения этих проблем.

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

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

Тестирование

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

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

Иметь качественные автоматизированные тесты и запускать их на PHP 8 важнее всего. Это даст идеальное указание на ожидаемую проблему PHP 8.0.

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

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

Теперь давайте перейдем к Запуску автоматических тестов на PHP 8.

Запуск автоматических тестов на PHP 8

PHPUnit 9.3 — это первая версия PHPUnit, официально совместимая с PHP 8.0, и она была выпущена в августе 2020 года. Что ж, запуск автоматизированного набора тестов, работающего на PHP, сложен, потому что де-факто это инструмент для модульного тестирования.

Запуск набора автоматизированных тестов для PHP 8 ведет нас к следующей кроличьей норе в качестве де-факто инструмента для выполнения модульных тестов в мире PHP; PHPUnit обычно выпускает огромный релиз каждый год, с каждым крупным выпуском поддержки предыдущих версий PHP. Он вносит критические изменения, но поскольку PHPUnit 9.3 официально совместим с PHP 8.0, как мы упоминали выше, беспокоиться не о чем!

Мы знаем, что как минимум WordPress по-прежнему поддерживает PHP 5.6. Для запуска тестов на PHP 8.0 любой тестовый набор, связанный с WordPress, должен быть полностью совместим с PHPUnit 5 до PHPUnit 9. Конечно, инструменты созданы, чтобы помочь вам в этом; по-прежнему требуются усилия и время для реализации этих инструментов, чтобы сделать набор тестов совместимым.

Запуск тестов на PHP8 для WordPress Core

Тесты для WP Core в настоящее время проходят и работают с PHP 8. Эти тесты проводятся на установленной версии композитора PHPUnit 7.5. Несмотря на то, что PHPUnit 9.3 является самой старой версией PHPUnit, официально совместимой с PHP 8.

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

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

Если копнуть глубже, то еще в 2016 году был открыт тикет Trac для решения этой проблемы. Учитывая более строгое соблюдение типов в PHP, этот тикет был восстановлен. Была проделана большая работа, чтобы смягчить это.

Пока мы писали, существует около 800 экземпляров (676 assertEquals() добавлены к 96 assertNotEquals()). По-прежнему используется свободная проверка типов — по сравнению с 8000 экземплярами.

Частично оставшиеся свободные утверждения типа являются законными при сравнении объектов; отчасти их, безусловно, необходимо решать. Однако в настоящее время это приведет к сбоям в тестировании. Эти последние подчеркивают недостатки либо в тестах, либо, реже, в тестируемом коде.

Тестирование тем и плагинов

Существует лишь небольшой процент доступных плагинов, профессионально разработанных и более популярных, с автоматизированными тестами. Вообще говоря, это вызывает беспокойство, поскольку на обычном сайте WordPress наверняка установлено около 19 или 20 плагинов. Довольно много сайтов используют еще больше плагинов! Наличие автоматизированного тестирования для тем встречается еще реже.

Сложно разрешить запуск этих наборов тестов на PHP версии 8. А также до того, как можно будет получить представление о совместимости плагинов и тем с PHP 8.

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

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

Для тем и плагинов, у которых есть тесты, в основном есть два типа тестов, которые они могут иметь или не иметь прямо на месте:

• Модульные тесты . Автономные тесты, которые «высмеивают» WP, чтобы разрешить тестирование кода плагина. Используются популярные фреймворки, такие как BrainMonkey и Mockery .
• Интеграционные тесты . Теперь интеграционные тесты — это то место, где сам WordPress загружается до того, как мы запустим набор тестов, и он будет использовать код WPcore и интегрироваться с набором тестов WP.

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

Мы знаем, что WordPress решил придерживаться PHPUnit 7.5. Что это значит?

Что ж, для интеграционных тестов для тем и плагинов они также будут переведены на PHPUnit 7.5 (максимум).

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

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

Модульные тесты

Для модульных тестов с помощью Mockery или BrainMonkey требуется PHPUnit > 8, поскольку платформа Mockery, доступная для PHPUnit 7.x, несовместима с PHP 8.0. Следовательно, сопоставимость этих наборов тестов обязательна с PHPUnit 5 и 9, что, безусловно, добавляет еще одну проблему.

Как?

Для запуска каждого набора тестов требуются разные версии PHPUnit, когда используются оба типа наборов тестов. Чтобы усугубить это обстоятельство, плагины обычно имеют зафиксированный файл composer.lock, чтобы гарантировать, что их зависимости во время выполнения находятся в заданной версии, на которую они могут полагаться, и которая полностью совместима с PHP 5.6.

В определенное время эта последняя часть обеспечивается наличием конфигурации платформы php 5.6 в файле composer.json. Это также означает, что их dev-зависимости BrainMonkey, Mockery, PHPUnit также будут заблокированы на версии, совместимой с PHP 5.6. теперь это наверняка помешает запускать тесты на PHP 8.0.

Вы можете преодолеть это, удалив платформу на лету, помимо обновления файлов composer.lock и composer.json. Однако это делает запуск тестов на PHP 8.0 более сложным как в CI, так и локально для его разработчиков.

Совместимость с PHP 8 выглядит несколько сложной на больших сайтах WordPress.

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

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

Как долго разработчики должны обновляться?

Жизненный цикл каждой версии PHP составляет 2 года, и за это время исправляются ошибки. Добавляется еще один год, в течение которого исправляются проблемы с безопасностью. PHP 7.4 появился в ноябре 2019 года. Это была финальная версия PHP 7. Это означает, что ошибки в PHP 7.4 будут исправлены до ноября 2021 года. Проблемы безопасности будут исправлены до ноября 2022 года. Он достигнет своего «конца жизни». в тот момент времени.

Следовательно, крайняя дата — ноябрь 2022 года: к этому времени весь PHP-код должен быть совместим с PHP 8, иначе существует опасность застревания на потенциально уязвимой версии PHP.

Вывод

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

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

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

Конечно, это становится довольно сложно из-за того, что время выполнения и синтаксические различия между PHP 5 и 8 невероятно велики.

Хорошо использовать PHP 8 на WordPress или нет? На самом деле это не аргумент здесь. Единственный вывод здесь - это становится очень сложно сделать.

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

Итак, что мы советуем?

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

Покрытие тестами практически отсутствует для зависимостей и низкое. Следовательно, трудно сказать, что такое совместимость ядра WordPress с PHP 8 в полном смысле этого слова.

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

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

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

Основная цель этой статьи от Accuweb — проинформировать и сделать обзор проблем и проблем, связанных с совместимостью PHP 8 в WP. Мы очень надеемся, что он идеально подходит для этой цели.