PHP 8.2 : qu'est-ce que cela signifie pour WordPress, les plugins et les développeurs ?

Publié: 2022-12-14

PHP 8.2.0 a fait ses débuts le 8 décembre 2022. En tant que mise à jour majeure, il apporte des améliorations de performances, une syntaxe plus simple et une plus grande sécurité de type avec null , false et true en tant que types autonomes. L'un des plus grands changements susceptibles de défier les développeurs WordPress est l'introduction de classes en lecture seule , qui interdisent les propriétés dynamiques.

Les propriétés dynamiques sont obsolètes et produiront une erreur fatale dans PHP 9 ou éventuellement PHP 10. Bien que potentiellement douloureuse, en particulier pour le cœur de WordPress, l'obsolescence est une fonctionnalité clé et un cadeau pour les développeurs de PHP.

Jetons un coup d'œil à l'évolution récente de PHP et à la manière dont les développeurs WordPress maintiennent la compatibilité descendante tout en tirant parti des nouvelles fonctionnalités lorsqu'elles profiteront le plus aux utilisateurs finaux.

Suivre le développement PHP dans WordPress

Étant donné que le cœur de WordPress maintient une compatibilité descendante importante sans dates de fin de vie prévues lorsque les anciennes versions ne seront pas prises en charge, il incombe aux entreprises WordPress de déterminer leur propre cycle de vie de produit ou de service et les versions de PHP qu'elles prendront en charge.

Contrairement à WooCommerce, qui nécessite un minimum de PHP 7.4, le noyau WordPress ne recommande actuellement que PHP 7.4 ou supérieur. Il "fonctionne également avec" PHP 5.6.20, qui a atteint sa date de fin de vie fin 2018. Le projet WordPress le note et avertit que l'utilisation de versions PHP non prises en charge "peut exposer votre site à des failles de sécurité". (Exigences de WordPress.org)

Heureusement, seulement 5,1 % de tous les sites WordPress utilisent actuellement PHP 5.6, et seulement 2 % utilisent une version encore plus ancienne. 20 % utilisent PHP 7.0 à 7.3, et le plus grand groupe (56,7 %) utilise PHP 7.4. (Statistiques WordPress.org)

Malheureusement, PHP 7.4 vient d'atteindre sa date de fin de vie fin novembre 2022. Il reste moins d'un an à PHP 8.0 pour son support de sécurité officiel pendant la majeure partie de 2023. La version actuelle et activement prise en charge, PHP 8.1, expirera à la fin. de 2024. PHP 8.2, qui vient de sortir sa première version stable, bénéficiera d'un support de sécurité jusqu'en décembre 2025.

Il s'agit d'un cycle de publication rapide, et il n'est pas surprenant que l'écosystème WordPress ait du mal à le suivre. Avec plus de la moitié du Web fonctionnant sur WordPress, c'est un gros navire qui ne peut pas tourner rapidement. C'est bien plus un acte d'équilibre qu'une course vers le bord saignant. Le passage à PHP 8 présente cependant de nombreux avantages, avec de grandes fonctionnalités d'amélioration des performances telles que la compilation PHP juste-à-temps (JIT) au moment de l'exécution pour une exécution plus rapide avec moins d'utilisation de la mémoire.

Le compromis entre rétrocompatibilité et stabilité, avant-gardisme et innovation

Le compromis entre la restauration du public le plus large possible d'utilisateurs et le maintien de l'actualité avec PHP a toujours posé un dilemme pour les développeurs, les hébergeurs et les sociétés de produits WordPress. Les agences et les indépendants ayant des clients de longue date et des sites hérités sont confrontés au même problème : la mise à jour des exigences minimales peut obliger les clients existants à apporter des modifications importantes à leurs sites ou à les voir tomber en panne.

D'une part, les avantages de rester à jour avec PHP sont une sécurité et des performances améliorées et les derniers concepts et capacités de programmation pour les développeurs. D'un autre côté, le principal avantage de retarder le PHP minimum requis est une clientèle heureuse (quoique complaisante) et large. C'est une situation « payez-moi maintenant ou payez-moi plus tard ». À un moment donné, il faut arracher le pansement.

De bonnes données et une télémétrie sur les environnements utilisateur peuvent aider à déterminer le moment le moins perturbateur pour augmenter une exigence de version minimale de PHP. La plupart des développeurs de plugins gardent un œil sur ces chiffres avec leurs propres outils, car cela ne fait pas partie des données d'installation actives du référentiel de plugins WordPress.org. Inévitablement, tout changement susceptible d'affecter de nombreuses personnes entraînera à coup sûr une multitude de tickets d'assistance.

Donner la priorité à la rétrocompatibilité implique également un travail de maintenance important. La prise en charge d'une base d'utilisateurs très large et diversifiée est idéale pour l'utilisateur final, mais cela signifie que les développeurs doivent faire en sorte que leur code fonctionne avec de nombreux environnements différents. "J'adore prendre en charge les anciennes versions de PHP à mesure que de nouvelles fonctionnalités sont ajoutées", - n'a jamais dit aucun développeur !

Ce n'est pas seulement l'héritage PHP dont ils doivent s'inquiéter - c'est aussi les bases de données héritées et des dizaines d'autres variantes de la pile WordPress. Les cas marginaux surgissent et confondent même les experts lorsqu'il existe un large éventail d'environnements de serveurs WordPress avec des éléments obsolètes.

Le meilleur moment pour augmenter votre exigence minimale en PHP

La version iThemes Security Pro 7.2 est un bon exemple d'augmentation des exigences PHP minimales d'un produit WordPress pour offrir à la fois innovation et stabilité aux clients existants.

Depuis la version 7.2, iThemes Security Pro nécessite PHP 7.3 ou supérieur et prend en charge jusqu'à 8.1. La décision de mettre à jour les exigences PHP pour iThemes Security Pro a été prise pour implémenter le framework WebAuthn. L'implémentation nécessitait des bibliothèques nécessitant PHP 7.3+ pour gérer le chiffrement et les clés publiques. Les fonctionnalités de connexion 2FA, passe-partout et biométrique introduites dans iThemes Security Pro 7.2 sont le résultat direct de cette décision. À une époque où ses mots de passe clairs sont brisés, l'équipe iThemes Security a introduit pour la première fois la connexion sans mot de passe à WordPress en tant qu'expérience d'authentification utilisateur principale.

Il aurait été possible de construire ces fonctionnalités en réécrivant les bibliothèques WebAuthn pour une compatibilité avec les anciennes versions de PHP. Bien sûr, cela demanderait beaucoup plus de travail et créerait du code supplémentaire à maintenir. Le plus sage était de suivre la communauté PHP à un rythme modéré en adoptant des dépendances qui nécessitent PHP 7.3 ou supérieur. La plupart de leurs utilisateurs étaient déjà là. C'est pourquoi l'équipe de développement d'iThemes Security a décidé d'augmenter l'exigence PHP minimale pour les utilisateurs nouveaux et existants.

Pour les produits WordPress fortement investis dans l'éditeur de blocs Gutenberg, comme GiveWP, la gestion du changement peut être encore plus difficile. La stabilité et la lenteur des changements dans le cœur de WordPress peuvent être frustrantes pour les développeurs PHP back-end, mais cela permet aux développeurs JavaScript/React front-end de faire avancer la plate-forme.

Jason Adams, responsable du développement de GiveWP, note qu'ils n'ont pas besoin d'être rétrocompatibles car ils peuvent migrer les utilisateurs d'une version à l'autre à mesure que l'éditeur du site évolue. Cependant, "il n'y a pas de migration pour PHP", a-t-il commenté. Finalement, ils devront s'adapter à l'architecture PHP 9 et s'éloigner des fonctionnalités nouvellement obsolètes de PHP 8.2.

Il n'y a pas de « bon moment » pour chaque produit de l'écosystème WordPress pour mettre à jour les exigences PHP minimales. "Ce n'est pas un problème que vous pouvez résoudre avec philosophie", m'a dit Adams. Cela dépend vraiment d'un jugement basé sur le nombre d'utilisateurs qui seront affectés par le changement. Si 90% ou plus sont sur PHP 7.2 ou 7.4, augmenter l'exigence minimale à ce niveau est viable.

Ces chiffres peuvent varier considérablement en fonction de la base d'utilisateurs spécifique d'un produit, explique Adams. Un produit utilisé par des clients plus compétents sur le plan technique aura tendance à être plus proche des versions PHP actuellement prises en charge. Un produit comme GiveWP, avec de nombreuses organisations à but non lucratif qui l'utilisent, devra accorder plus d'importance à la rétrocompatibilité. Une autre voie à suivre consiste à laisser le code hérité et ses utilisateurs se ramifier dans une version à long terme qui sera prise en charge mais qui ne verra pas de nouvelles fonctionnalités ajoutées. Lorsque les utilisateurs sont prêts à effectuer la mise à niveau, ils peuvent migrer vers une nouvelle version majeure conçue pour la future compatibilité PHP.

Les avis d'obsolescence font avancer le développement

WordPress.com vient de déployer PHP 8.2 en option pour ses plans Business et Ecommerce avec des fonctionnalités d'hébergement activées, et dans l'écosystème WordPress.org, un code plus ancien raisonnablement bien conçu est peu susceptible de casser ou de devenir non sécurisé avec la prochaine version majeure de PHP. Libération. Même si la base de code principale de WordPress.org n'offre officiellement qu'un support "bêta" pour PHP 8.0, elle fonctionne généralement très bien avec les dernières versions de PHP, tout comme les plugins bien pris en charge. Ils ne lanceront pas d'erreurs fatales ou d'analyse. Vous ne devriez même pas voir de nombreux avertissements avec le débogage activé. Vous pouvez voir de nombreux avis de fonctions obsolètes, qui ne sont pas encore des erreurs.

Les frustrations d'un cycle de publication rapide de PHP ont beaucoup à voir avec le fait que les développeurs s'enlisent dans les mauvaises herbes en refactorisant leur code et en rattrapant les aspects obsolètes de PHP. Ce travail critique peut leur laisser moins de temps pour explorer et innover avec les nouveaux concepts et capacités apportés par la dernière version de PHP.

Il y a une autre façon de voir cette situation. La gestion des fonctionnalités obsolètes de PHP est en fait tournée vers l'avenir et oblige les développeurs à maîtriser les prochaines itérations d'un langage en évolution. Sans cet exercice quelque peu forcé, les connaissances existantes s'installeraient plus facilement dans de vieilles habitudes qui deviendront mauvaises lorsqu'elles seront obsolètes.

Les avis d'obsolescence signalent des choses qui fonctionnent maintenant mais qui se briseront dans les futures versions de PHP. C'est bon pour vous si vous êtes développeur, comme l'explique Brent Roose. Si les développeurs prêtent attention à ces avis, ils auront tout le temps de se familiariser avec tout code obsolète. Et cela ne devrait pas être un obstacle aux mises à jour de versions mineures.

Timothy Jacobs, développeur principal d'iThemes Security et WordPress Core Committer, dit qu'il est bon d'avoir des avertissements de dépréciation. Ils poussent les développeurs à adopter un code "plus correct" et "moins fragile" qui sera de plus en plus sécurisé, performant, à l'épreuve des erreurs et mieux à même de faire face aux cas extrêmes. Dans cette vue, les avis E_DEPRECATED remplissant votre journal des erreurs sont "comme un système d'avertissement précoce que les choses vont se casser à l'avenir, mais elles ne sont pas cassées maintenant."

Se passer des propriétés dynamiques après PHP 8.2

La justification de Nikita Popov pour la suppression progressive des propriétés dynamiques dans PHP 9 est un bon exemple de l'évolution de PHP vers un code et des conventions de programmation plus résilients :

La motivation de ce changement est double : pour éviter les erreurs (dues à des fautes de frappe ou à des changements de nom) dans le cas courant, et pour rendre explicites les utilisations intentionnelles. Le problème principal est que la lecture à partir d'une propriété inexistante génère un diagnostic qui rend le problème immédiatement apparent, tandis que l'écriture dans une propriété inexistante est entièrement silencieuse. PHP ne donne aucune indication que le programmeur a fait une erreur.

La vidéo de deux minutes de Brent Roose sur l'évolution de PHP 5.6 à 8.2 est une illustration visuelle brillante et simple du chemin parcouru par PHP de 2014 à aujourd'hui. En utilisant l'exemple d'un simple objet de transfert de données, Roose montre comment le code PHP 5.6 se réduit considérablement à un bloc de code beaucoup plus simple, plus léger et globalement plus élégant sur le chemin de PHP 8.2.

Comme le note Roose dans ses conseils pour gérer les propriétés dynamiques (qui sont obsolètes dans PHP 8.2), les développeurs devraient avoir suffisamment de temps pour mettre à jour leur code existant avant que les avertissements d'obsolescence ne se transforment en erreurs fatales. Cependant, cette piste diminuera rapidement et WordPress est un cas particulier. Tonya Mork a une proposition acceptée dans Trac pour gérer les dépréciations de propriétés dynamiques inconnues dans le noyau de WordPress. Elle et Juliette Reinders Folmer craignent que les développeurs WordPress n'aient pas assez de temps pour refactoriser leur code, sans parler des défis particuliers que représente le maintien de la compatibilité ascendante pour un projet vieux de vingt ans. Mork, Reinders Folmer et Sergey Biryukov ont été les héros largement méconnus de cette tâche ardue.

Dans leur discussion sur les propriétés dynamiques et les méthodes magiques dans PHP 8.2, Mork et Reinders Folmer soulignent que les racines de WordPress dans PHP 3 et 4 le maintiennent dans un univers de programmation solidement procédural tandis que PHP continue de progresser en tant que langage orienté objet. Les développeurs principaux doivent trouver un moyen de maintenir le comportement du code hérité dans PHP d'aujourd'hui sans rompre la compatibilité descendante "et toujours rendre le code meilleur et plus sûr et atténuer la dépréciation des propriétés dynamiques de PHP 8.2", comme le dit Reinders Folmer. "En fait, nous nous rendons la vie très difficile avec [WordPress core's] no [backward compatibility] break rule", note-t-elle dans la vidéo.

"Il y a une bonne raison à cela", répond Mork - "c'est pour les utilisateurs. Les utilisateurs ont confiance qu'ils peuvent appuyer sur ce bouton et mettre à niveau, et que nous avons pensé à la rétrocompatibilité, que nous lui avons donné la priorité. C'est une pierre angulaire pour nous… afin que les utilisateurs puissent avoir la confiance nécessaire pour effectuer la mise à niveau.

Tout développement est maintenance…

C'est un défi unique d'essayer de rétroporter PHP "moderne" pour qu'il fonctionne avec les deux versions majeures précédentes de PHP dans le but de maintenir la rétrocompatibilité dans le cœur de WordPress. Les développeurs de plugins ont une tâche beaucoup plus facile de mettre à jour leur code de manière à tirer parti des nouvelles fonctionnalités, telles que les classes en lecture seule de PHP 8.2 et la dépréciation des propriétés dynamiques. Une grande partie de ce travail est également une forme d'entretien.

Sur le plan architectural, les changements apportés par PHP 8+ mettent l'accent sur des concepts de programmation tels que l'immuabilité. Les structures de données immuables « ne résolvent pas intrinsèquement les problèmes de sécurité », mais elles aident le code des développeurs à être moins sujet aux erreurs et plus correct, selon Jacobs :

Je ne dirais pas qu'une structure de données immuable est intrinsèquement sécurisée et qu'une structure de données mutable n'est pas sécurisée. Au contraire, des structures de données immuables peuvent aider à éliminer les erreurs de programmation pouvant entraîner des problèmes de sécurité. En réduisant le nombre d'états différents dans lesquels notre code peut exister, nous pouvons réduire la complexité de notre code, et donc réduire les risques de faire des erreurs.

La meilleure raison de maintenir le code au niveau des versions PHP activement prises en charge est la réduction des risques de sécurité. PHP 8.2 apporte des commodités utiles et des "garde-corps" selon Adams, mais peu qui exciteront les programmeurs ou seront considérés comme des changeurs de jeu. Quelque chose comme l'attribut #[\SensitiveParameter] pourrait être plus significatif dans la pratique car il permet de filtrer les données sensibles des traces de pile qui vont souvent à des services tiers. Introduits dans PHP 8, les attributs sont le choix d'Adams pour la dernière innovation qui a attiré son attention pour permettre quelque chose que vous ne pouviez pas faire auparavant : "décrire quelque chose [comme des classes, des variables, des méthodes, etc.] d'un point de vue méta."

Tirer parti des nouvelles fonctionnalités de PHP 8.0 à 8.2 et des versions futures est l'endroit où la créativité des développeurs peut briller, mais le simple fait de prendre en charge ces versions, afin que les plugins et le noyau WordPress ne se cassent pas dessus, est à la fois pratique et vital.

… Et toute maintenance est de l'art

Jeff Atwood a un article de blog ancien mais exceptionnel intitulé "The Noble Art of Maintenance Programming" que j'ai lu récemment, grâce à la newsletter Hacker de Kale Davis. "La programmation de maintenance est largement considérée comme un travail de conciergerie", écrit Atwood. Cela m'a rappelé l'artiste Mirele Laderman Ukeles, dont le "Maintenance Art Manifesto" m'a toujours semblé très pertinent pour la programmation et le développement Web :

Deux systèmes de base : Développement et Maintenance. L'aigre boule de toute révolution : après la révolution, qui va ramasser les ordures le lundi matin ? […] Les systèmes de développement sont des systèmes de rétroaction partielle avec une grande marge de changement. Les systèmes de maintenance sont des systèmes de rétroaction directe avec peu de place pour la modification.

Laderman Ukeles était une jeune artiste et une nouvelle mère en 1969 lorsqu'elle a écrit le manifeste et déclaré que Maintenance is Art. Elle était frustrée par la façon dont les œuvres d'art de pointe et le travail de haut niveau sont séparés du travail qui les rend possibles : être parent, enseigner des compétences et des traditions artistiques, ou simplement organiser une exposition d'art. Elle a fait une exposition mémorable basée sur elle-même en tant que concierge de musée. Elle a ensuite passé la majeure partie de sa carrière (en cours) en tant qu'artiste en résidence du Département de l'assainissement de la ville de New York. Son premier projet dans ce rôle consistait à remercier personnellement les 8 500 travailleurs de l'assainissement "pour avoir maintenu New York en vie".

Atwood a une vision similaire de la programmation. Il cite plusieurs personnalités majeures du génie logiciel qui disent que le dénigrement des travaux de maintenance est tout à fait faux. Robert L. Glass a estimé que "la maintenance est un défi intellectuel important ainsi qu'une solution et non un problème", elle doit donc être considérée comme une tâche importante pour les personnes les plus qualifiées. Joel Spolsky a écrit il y a longtemps que les développeurs sont paresseux, et la raison pour laquelle ils "veulent toujours jeter le code et recommencer" est qu'"il est plus difficile de lire du code que de l'écrire".

Dans une conversation avec Andy Hunt, Dave Thomas a expliqué : « Toute programmation est une programmation de maintenance car vous écrivez rarement du code original. …. Vous passez la plupart de votre temps en mode maintenance. Donc, vous pouvez aussi bien mordre la balle et dire: «Je maintiens depuis le premier jour.» Les disciplines qui s'appliquent à la maintenance devraient s'appliquer à l'échelle mondiale. Hunt a convenu: «Ce ne sont que les 10 premières minutes que le code est original lorsque vous le tapez pour la première fois. C'est ça."

Atwood penche finalement vers ce point de vue mais fait écho à la perspective commune des développeurs WordPress que j'ai entendue de Jason Adams et Timothy Jacobs. L'art particulier du développement/maintenance WordPress ?

"C'est un exercice d'équilibre."

Le meilleur plugin de sécurité WordPress pour sécuriser et protéger WordPress maintenant à 35 % de réduction !

WordPress alimente actuellement plus de 40 % de tous les sites Web, il est donc devenu une cible facile pour les pirates ayant des intentions malveillantes. Le plugin iThemes Security Pro élimine les conjectures de la sécurité de WordPress pour faciliter la sécurisation et la protection de votre site Web WordPress. C'est comme avoir un expert en sécurité à plein temps dans le personnel qui surveille et protège constamment votre site WordPress pour vous.

Économisez 35 % maintenant !