PHP 8.2: что это значит для WordPress, плагинов и разработчиков?

Опубликовано: 2022-12-14

PHP 8.2.0 дебютировал 8 декабря 2022 года. В качестве крупного обновления оно обеспечивает повышение производительности, упрощение синтаксиса и повышение безопасности типов с помощью null , false и true в качестве отдельных типов. Одним из самых больших изменений, которое может бросить вызов разработчикам WordPress, является введение классов только для чтения , которые запрещают динамические свойства.

Динамические свойства устарели и приведут к фатальной ошибке в PHP 9 или, возможно, PHP 10. Хотя потенциально болезненно — особенно для ядра WordPress — устаревание является ключевой функцией и подарком PHP разработчикам.

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

Идти в ногу с разработкой PHP в WordPress

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

В отличие от WooCommerce, для которого требуется как минимум PHP 7.4, ядро ​​WordPress в настоящее время рекомендует только PHP 7.4 или выше. Он «также работает с» PHP 5.6.20, срок службы которого истек в конце 2018 года. Проект WordPress отмечает это и предупреждает, что использование неподдерживаемых версий PHP «может подвергнуть ваш сайт уязвимостям безопасности». (Требования WordPress.org)

К счастью, только 5,1% всех сайтов WordPress в настоящее время используют PHP 5.6, и только 2% используют еще более старую версию. 20% используют PHP от 7.0 до 7.3, а самая большая группа (56,7%) использует PHP 7.4. (Статистика WordPress.org)

К сожалению, в конце ноября 2022 года срок действия версии PHP 7.4 истек. Для официальной поддержки безопасности PHP 8.0 осталось меньше года в течение большей части 2023 года. Текущая и активно поддерживаемая версия PHP 8.1 устареет в конце. от 2024 года. PHP 8.2, который только что выпустил свой первый стабильный выпуск, будет иметь поддержку безопасности до декабря 2025 года.

Это быстрый цикл выпуска, и неудивительно, что экосистема WordPress с трудом успевает за ним. Поскольку более половины Интернета работает на WordPress, это большой корабль, который не может быстро развернуться. Это гораздо больше похоже на балансирование, чем на гонку к переднему краю. Однако переход на PHP 8 имеет много преимуществ, включая большие функции повышения производительности, такие как компиляция PHP Just-in-Time (JIT) во время выполнения для более быстрого выполнения с меньшим использованием памяти.

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

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

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

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

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

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

Лучшее время для повышения минимальных требований к PHP

Выпуск iThemes Security Pro 7.2 является хорошим примером повышения минимальных требований к PHP для продукта WordPress, чтобы обеспечить как инновации, так и стабильность для существующих клиентов.

Начиная с версии 7.2, для iThemes Security Pro требуется PHP 7.3 или выше и поддерживается до версии 8.1. Решение обновить требование PHP для iThemes Security Pro было принято для реализации фреймворка WebAuthn. Для реализации требовались библиотеки, которым нужен PHP 7.3+ для управления шифрованием и открытыми ключами. Функции двухфакторной аутентификации, пароля и биометрического входа в систему, представленные в iThemes Security Pro 7.2, являются прямым результатом этого решения. В то время, когда его четкие пароли сломаны, команда безопасности iThemes впервые представила беспарольный вход в WordPress в качестве основного способа аутентификации пользователя.

Эти функции можно было бы реализовать, переписав библиотеки WebAuthn для совместимости со старыми версиями PHP. Конечно, это потребовало бы гораздо больше работы и создания дополнительного кода для поддержки. Разумнее было бы идти в ногу с сообществом PHP в умеренном темпе, принимая зависимости, требующие PHP 7.3 или выше. Большинство их пользователей уже были там. Вот почему команда разработчиков iThemes Security решила повысить минимальные требования к PHP для новых и существующих пользователей.

Для продуктов WordPress, которые вложили значительные средства в редактор блоков Gutenberg, таких как GiveWP, управление изменениями может быть еще более сложным. Стабильность и медленная скорость изменений в ядре WordPress могут разочаровывать бэкенд-разработчиков PHP, но позволяют фронтенд-разработчикам JavaScript/React продвигать платформу вперед.

Джейсон Адамс, менеджер по развитию GiveWP, отмечает, что они не должны быть обратно совместимыми, потому что они могут перемещать пользователей между версиями по мере развития редактора сайта. Однако «Нет такой вещи, как миграция для PHP», — прокомментировал он. В конце концов, им придется адаптироваться к архитектуре PHP 9 и отказаться от новых устаревших функций в PHP 8.2.

Для каждого продукта в экосистеме WordPress не существует единственного «правильного времени» для обновления минимальных требований к PHP. «Это не та проблема, которую можно решить философски, — сказал мне Адамс. Это действительно зависит от суждения, основанного на том, сколько пользователей будет неблагоприятно затронуто изменением. Если 90% или более используют PHP 7.2 или 7.4, повышение минимальных требований до этого уровня оправдано.

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

Уведомления об устаревании стимулируют развитие

WordPress.com только что выпустил PHP 8.2 в качестве опции для своих планов Business и Ecommerce с активированными функциями хостинга, а в экосистеме WordPress.org достаточно хорошо спроектированный старый код вряд ли сломается или станет небезопасным со следующей основной версией PHP. выпускать. Несмотря на то, что основная кодовая база WordPress.org официально предлагает только «бета-версию» поддержки PHP 8.0, в целом она прекрасно работает с последними версиями PHP, как и с хорошо поддерживаемыми плагинами. Они не будут выдавать фатальные ошибки или ошибки синтаксического анализа. Вы даже не должны видеть много предупреждений при включенной отладке. Вы можете увидеть много уведомлений об устаревших функциях, которые пока не являются ошибками.

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

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

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

Тимоти Джейкобс (Timothy Jacobs), ведущий разработчик iThemes Security и ответственный за WordPress Core, говорит, что хорошо иметь предупреждения об устаревании. Они подталкивают разработчиков к принятию «более правильного» и «менее хрупкого» кода, который будет становиться все более безопасным, производительным, защищенным от ошибок и лучше справляться с пограничными случаями. В этом представлении уведомления E_DEPRECATED, заполняющие ваш журнал ошибок, «подобны системе раннего предупреждения о том, что в будущем что-то сломается, но не сейчас».

Как обойтись без динамических свойств после PHP 8.2

Обоснование Никиты Попова поэтапного отказа от динамических свойств в PHP 9 является хорошим примером эволюционного стремления PHP к более отказоустойчивому коду и соглашениям программирования:

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

Двухминутное видео Брента Руса об эволюции от PHP 5.6 до 8.2 — блестящая и простая наглядная иллюстрация того, как далеко продвинулся PHP с 2014 года по настоящее время. На примере простого объекта передачи данных Руз показывает, как код PHP 5.6 резко сокращается до гораздо более простого, компактного и в целом более элегантного блока кода на пути к PHP 8.2.

Как отмечает Руз в своих советах по работе с динамическими свойствами (которые объявлены устаревшими в PHP 8.2), у разработчиков должно быть достаточно времени для обновления существующего кода, прежде чем предупреждения об устаревании превратятся в фатальные ошибки. Однако эта взлетно-посадочная полоса быстро сократится, и WordPress — особый случай. У Тони Морк есть принятое предложение в Trac по обработке устаревших неизвестных динамических свойств в ядре WordPress. Она и Джульетта Рейндерс Фолмер обеспокоены тем, что у разработчиков WordPress не будет достаточно времени для рефакторинга своего кода, не говоря уже об особых проблемах обеспечения прямой совместимости для проекта двадцатилетней давности. Морк, Рейндерс Фолмер и Сергей Бирюков были незамеченными героями этой сложной задачи.

В своем обсуждении динамических свойств и магических методов в PHP 8.2 Морк и Рейндерс Фолмер отмечают, что корни WordPress в PHP 3 и 4 удерживают его в прочной вселенной процедурного программирования, в то время как PHP продолжает развиваться как объектно-ориентированный язык. Основные разработчики должны найти способ сохранить поведение устаревшего кода в современном PHP, не нарушая обратной совместимости, «и при этом сделать код лучше и безопаснее, а также смягчить устаревание динамических свойств PHP 8.2», как выразился Рейндерс Фолмер. «На самом деле мы очень усложняем себе жизнь из-за правила [основной части WordPress] не нарушать [обратную совместимость]», — отмечает она в видео.

«Для этого есть веская причина, — отвечает Морк, — это для пользователей. Пользователи уверены, что они могут нажать эту кнопку и выполнить обновление, и что мы подумали об обратной совместимости, что мы отдали ей приоритет. Это краеугольный камень для нас… поэтому пользователи могут быть уверены в обновлении».

Всякое развитие — это обслуживание…

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

С точки зрения архитектуры, изменения PHP 8+ фокусируются на таких концепциях программирования, как неизменяемость. По словам Джейкобса, неизменяемые структуры данных «не решают проблемы безопасности», но они помогают разработчикам сделать код менее подверженным ошибкам и более правильным:

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

Лучшая причина поддерживать код в соответствии со стандартом активно поддерживаемых версий PHP — это снижение риска безопасности. PHP 8.2 предлагает полезные удобства и «ограничители», по мнению Адамса, но мало что может заинтересовать программистов или изменить правила игры. Что-то вроде атрибута #[\SensitiveParameter] может быть более важным с практической точки зрения, поскольку он позволяет отфильтровывать конфиденциальные данные из трассировки стека, которые часто передаются сторонним службам. Атрибуты, представленные в PHP 8, были выбраны Адамсом как последнее нововведение, которое привлекло его внимание тем, что позволяет делать то, что вы не могли сделать раньше: «описывать что-то [например, классы, переменные, методы и т. д.] с мета-перспективы».

Использование преимуществ новых функций в PHP 8.0–8.2 и будущих выпусках — это то, где творческие способности разработчиков могут проявить себя, но простая поддержка этих версий, чтобы плагины и ядро ​​WordPress не ломались, является одновременно практичным и жизненно важным.

…И любое техническое обслуживание — это искусство

У Джеффа Этвуда есть старая, но выдающаяся запись в блоге под названием «Благородное искусство программирования сопровождения», которую я недавно прочитал благодаря Hacker Newsletter Кейла Дэвиса. «Программирование сопровождения широко рассматривается как работа по уборке, — пишет Этвуд. Это напомнило мне о художнице Миреле Ладерман Укелес, чей «Манифест искусства обслуживания» всегда казался мне очень актуальным для программирования и веб-разработки:

Две основные системы: Разработка и Сопровождение. Кислый шарик каждой революции: после революции кто будет собирать мусор в понедельник утром? […] Системы разработки — это системы частичной обратной связи с большими возможностями для изменений. Системы технического обслуживания представляют собой системы с прямой обратной связью, в которых мало места для изменений.

Ладерман Укелес была молодой художницей и новоиспеченной матерью в 1969 году, когда она написала манифест и объявила «Техническое обслуживание — это искусство». Она была разочарована тем, как передовые произведения искусства и высокостатусный труд отделены от работы, которая делает их возможными: воспитание детей, обучение художественным навыкам и традициям или просто проведение арт-шоу. Она устроила памятную выставку, посвященную тому, как она работала дворником в музее. Затем она провела большую часть своей (текущей) карьеры в качестве штатного художника Департамента санитарии Нью-Йорка. Ее первым проектом в этой роли была личная благодарность всем 8500 санитарным работникам «за сохранение жизни в Нью-Йорке».

У Этвуда похожее отношение к программированию. Он цитирует нескольких крупных фигур в области разработки программного обеспечения, которые говорят, что клевета на работу по обслуживанию совершенно неверна. Роберт Л. Гласс считал, что «техническое обслуживание является серьезной интеллектуальной задачей, а также решением, а не проблемой», поэтому его следует рассматривать как важную задачу для самых квалифицированных людей. Джоэл Спольски давно писал, что разработчики ленивы, и причина, по которой они «всегда хотят выбросить код и начать сначала», заключается в том, что «читать код труднее, чем писать его».

В разговоре с Энди Хантом Дэйв Томас заявил: «Все программирование — это поддерживающее программирование, потому что вы редко пишете исходный код. …. Вы проводите большую часть своего времени в режиме обслуживания. Так что вы можете просто стиснуть зубы и сказать: «Я поддерживаю с первого дня». Дисциплины, применимые к техническому обслуживанию, должны применяться во всем мире». Хант согласился: «Это только первые 10 минут, когда вы вводите код в первый раз, он остается оригинальным. Вот и все."

Этвуд в конечном итоге склоняется к этой точке зрения, но перекликается с общей точкой зрения разработчиков WordPress, которую я слышал от Джейсона Адамса и Тимоти Джейкобса. Особое искусство разработки/обслуживания WordPress?

«Это балансирование».

Лучший плагин безопасности WordPress для защиты и защиты WordPress теперь со скидкой 35%!

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

Сэкономьте 35% сейчас!