Passer à PHP 8.x en quatre étapes – Entretien avec Juliette Reinders Folmer

La mise à niveau d'un site, d'un plugin ou d'un thème WordPress vers une nouvelle version de PHP est une tâche qui revient régulièrement. Mais comment faire cela le plus efficacement possible ? Comment savez-vous que vous ne négligerez rien ? Existe-t-il une feuille de route pour cela ?

Dans cet article, nous aborderons ces questions (et bien d'autres) et examinerons ce qu'implique une transition en douceur vers PHP 8.x pour votre site, plugin ou thème WordPress, y compris une feuille de route.

Nous le ferons sur la base d'une interview que nous avons menée avec l'expert PHP Juliette Reinders Folmer. Elle consacre la majeure partie de sa vie quotidienne à la programmation et à tout ce qui l'entoure, se concentrant principalement sur des projets open source, dont WordPress.

Êtes-vous prêt à faire le changement en douceur vous aussi ? Curieux de connaître notre plan étape par étape? Alors plongeons dedans !

PHP 8.x — Ce qui a changé

Pour un aperçu des changements, nous vous recommandons les articles ci-dessous :

• Notes de version pour PHP 8.0 et PHP 8.1
• Guide de migration pour PHP 8.0 et PHP 8.1
• WordPress et PHP 8.0 et état actuel
• Quoi de neuf dans PHP 8.0 et PHP 8.1

Après avoir lu ces articles, vous serez complètement mis à jour sur ce qui a changé dans PHP 8.x et sur ce que vous devez faire pour que vos projets PHP fonctionnent sans aucun problème.

Si vous ne savez pas quelle est la meilleure façon de commencer, pas de problème. Dans la conversation avec Juliette, nous en avons discuté en détail, et nous vous expliquerons dans cet article aussi complètement que possible comment vous pouvez passer à PHP 8.x.

Nous vous expliquerons également dans des encadrés informatifs comment effectuer diverses opérations dans MyKinsta, notre panneau de contrôle propriétaire pour tous vos sites, applications et bases de données WordPress.

Passer à PHP 8.x : Comment démarrer

Passer à PHP 8.x semble simple, et techniquement, ça l'est. De nombreux hébergeurs vous permettent de spécifier la version de PHP que vous souhaitez utiliser pour votre site Web dans le panneau d'administration. Chez Kinsta, le changement de version PHP peut se faire en un seul clic dans le tableau de bord MyKinsta.

Mais avant de le faire, il y a certaines choses dont vous devez être sûr. Selon votre niveau de connaissance et d'expérience, nous vous recommandons ce qui suit :

• Si vous avez créé votre propre site WordPress avec des thèmes et des plugins standard, sans avoir beaucoup de connaissances en PHP, engagez un développeur ou une agence pour déterminer si votre site peut fonctionner sur PHP 8.x. Cherchez-vous un tiers qui peut vous aider avec cela? Ensuite, consultez notre page Partenaires répertoriant plusieurs entreprises de confiance qui peuvent vous aider.
• Si votre site WordPress a été créé par un tiers externe, un développeur ou une agence, contactez-le pour lui demander si votre site peut fonctionner sur PHP 8.x.
• Si vous avez construit votre site WordPress – avec votre propre thème personnalisé, par exemple, ou des plugins auto-développés – nous avons une feuille de route pour vous ci-dessous.

Si votre site appartient à l'une des deux premières catégories, nous vous invitons certainement à lire la suite de l'article, mais nous vous déconseillons de commencer à tester vous-même la compatibilité PHP 8 de votre site. Laissez faire les professionnels.

Quoi que vous choisissiez, nous vous conseillons de ne pas simplement passer votre site en ligne à PHP 8 et de « voir si cela fonctionne ». Vous êtes curieux de savoir à quoi ressemblera votre site et vous avez hâte de le voir fonctionner sur PHP 8 ? Commencez ensuite les tests dans un environnement de test. Un bon hébergeur vous permettra de mettre en place facilement un environnement de staging.

Dans l'environnement de staging, vous pouvez activer PHP 8.x et voir si cette mise à jour fonctionne bien avec votre site. Il est également possible de travailler avec une copie locale de votre site. Avec notre outil de développement gratuit DevKinsta, vous pouvez facilement importer votre site depuis le tableau de bord MyKinsta, après quoi vous pouvez changer la version PHP en 8.0 ou 8.1.

Si vous ne voyez aucun problème dans l'environnement de staging, cela ne signifie pas nécessairement qu'il n'y a en fait aucun problème. La feuille de route ci-dessous vous expliquera pourquoi.

Test de compatibilité PHP 8.x : la feuille de route

Tester : le mot-clé d'un bon logiciel. Même pour les sites Web WordPress et leurs composants, tels que les thèmes, les plugins et le noyau WordPress, les tests sont le moyen de s'assurer que les choses ne se produisent pas que vous ne vouliez pas se produire.

Un projet de développement logiciel consiste en grande partie en des tests. Dans cet article, nous examinons spécifiquement les tests qui peuvent vous aider à effectuer la transition vers PHP 8.x en douceur. Dans notre article sur les outils DevOps, vous trouverez une section avec une collection d'outils que vous pouvez utiliser.

Les types de tests suivants sont abordés dans cet article de blog :

Examinons de plus près les différents types de tests que nous pouvons effectuer.

Analyse statique (ou test statique)

La première étape que vous pouvez effectuer en tant que développeur PHP consiste à effectuer une analyse statique de votre code avec divers outils. L'analyse statique est le processus d'analyse d'un logiciel sans exécuter le code. Avec l'analyse statique, il est possible de détecter des erreurs, de détecter des problèmes de compatibilité avec PHP 8.x, d'appliquer des normes de codage (par exemple, les normes de codage WordPress), et même de modifier et de nettoyer le code.

Outils d'analyse statique

Vous pouvez effectuer une analyse statique avec divers outils, tels que :

• Compatibilité PHP
• Psaume
• PHP Stan

Au moment de la rédaction, toutes les vérifications PHP 8.1 ne sont pas prises en charge dans la dernière version de PHPCompatibility. Les vérifications PHP 8.1 peuvent être dans la version de développement, alors assurez-vous de les utiliser (pour l'instant) lorsque vous utilisez PHPCompatibility pour analyser votre projet et voir quelles erreurs/recommandations il y a.

Les vérifications PHP 8.1 seront bientôt publiées dans une nouvelle version majeure . Si vous souhaitez être tenu au courant à ce sujet et que vous disposez d'un compte GitHub, ouvrez le référentiel GitHub de PHPCompatibility et accédez à Watch -> Custom -> Releases , où vous pouvez choisir d'être averti lorsqu'une nouvelle version est publiée.

PHPCompatibility, qui teste uniquement la compatibilité d'une version particulière (ou d'une gamme de versions) de PHP, est facile à configurer. Vous obtenez les meilleurs résultats si vous exécutez un testVersion - par exemple, 8.0+ (8.0 et plus) - dans PHPCompatibility.

Vous devriez rechercher les fonctions obsolètes ou supprimées, les valeurs par défaut modifiées des paramètres de fonction, s'il faut utiliser concat sans parenthèses, s'il faut utiliser match comme nom de fonction (puisqu'il est réservé depuis PHP 8.0), etc.

Psalm et PHPStan sont de bons ajouts et peuvent vous aider en effectuant des vérifications supplémentaires liées aux types de variables. L'inconvénient de ces outils est qu'il faut beaucoup de configuration pour obtenir des rapports sur PHP 8.0 et 8.1. Même s'ils réussissent, vous pouvez vous attendre à de nombreux faux positifs. Les faux positifs sont des notifications qui sont données à tort, en raison des limites de l'analyse statique.

De solides connaissances sont nécessaires pour interpréter correctement les résultats de ces deux outils, mais ces connaissances peuvent vous aider à identifier des incompatibilités supplémentaires que PHPCompatibility ne peut pas trouver. Consultez la documentation de Psalm et PHPStan si vous souhaitez en savoir plus à leur sujet.

Résumé:

• Effectuer une analyse statique avec PHPCompatibility, Psalm, PHPStan
• Résoudre tous les problèmes légitimes

Tests unitaires

La prochaine étape du processus est le test unitaire. Les tests unitaires sont une méthode de test individuel des morceaux de code. Dans les tests unitaires, des tests ciblés spécifiques seront développés pour chaque unité. Cela impliquera de parcourir différents scénarios. De préférence, chaque scénario est testé séparément des autres afin que les tests soient indépendants les uns des autres.

Avoir des tests unitaires seuls, bien sûr, ne suffit pas. Ils doivent également être exécutés. Les tests unitaires sont mieux automatisés à l'aide d'outils CI (intégration continue) tels que Jenkins, GitHub Actions ou Travis.

Prise en charge de plusieurs versions de PHP

En tant que constructeur de plugins, si vous souhaitez prendre en charge plusieurs versions de PHP, assurez-vous que les tests dans CI sont exécutés sur toutes les versions de PHP que vous prenez en charge.

Bien sûr, vous pouvez également ne prendre en charge que les versions plus récentes, le choix vous appartient entièrement.

Tester avec plusieurs versions de PHP nécessite que vous utilisiez plusieurs versions de PHPUnit, selon la version de PHP. Étant donné que PHPUnit a introduit plusieurs changements au fil des ans qui affectent la façon dont les tests sont écrits, cette partie peut être délicate.

Pour contourner ce problème, vous pouvez utiliser les PHPUnit Polyfills (écrits par Juliette et sponsorisés par Yoast). Cela vous permet d'écrire des tests qui ne sont officiellement pas pris en charge pour PHPUnit 9 (et peuvent donc s'exécuter sur PHP 8.x). Les Polyfills font ensuite fonctionner vos tests dans PHPUnit 4.x à 9.x et avec PHP 5.4 à PHP 8.1 (à partir de maintenant).[/notice]

Maintenant que les tests sont en cours d'exécution, l'étape suivante consiste à s'assurer que les problèmes détectés dans les tests sont résolus.

Couverture de code

L'exécution de ces tests est le moyen le plus fiable de trouver des incompatibilités entre versions.

Ce faisant, faites attention à la couverture de code de vos tests :

• Supposons que vous ayez une fonction A et que vous ayez écrit un test pour celle-ci, et que la fonction A appelle les fonctions B, C et D dans le cadre de la logique de la fonction.
• Le test de la fonction A est écrit pour tester la logique de la fonction A, mais il appellera également les fonctions B, C et D pendant le test. Pour les fonctions B, C et D, vous ne testez alors généralement que le "chemin heureux" - la situation où tout se passe bien - et donc, ces fonctions ne sont pas encore entièrement testées, bien qu'une partie du code de ces fonctions soit exécuté lors du test de la fonction A.
• Pour chacun de vos tests, indiquez quel code est spécifiquement testé. Pour ce faire, attribuez à chaque test un @covers. Ainsi, B, C et D ne sont pas « comptés » dans le calcul de la couverture du code, ce qui vous permet de voir quelle partie de votre code est couverte par les tests.

Souvent, les développeurs écrivent et testent - parfois même sans le savoir - pour le "chemin heureux". Dans ces cas, il est également nécessaire de tester ce qui se passe lorsque des données inattendues sont transmises à une fonction. Tester avec uniquement les valeurs/types attendus ne suffit pas .

''Lors d'un test, vous devez vous assurer qu'une fonction fait ce qu'elle doit faire, mais aussi qu'une fonction ne fait pas ce qu'elle ne devrait pas faire.'' - Juliette Reinders Folmer Click to Tweet

La deuxième partie de la citation ci-dessus est souvent oubliée, alors qu'elle est peut-être encore plus importante que la première partie. Que se passe-t-il si vous passez un type incorrect ? Recevez-vous un message d'erreur ? Ou est-ce que la variable cast avec la fonction continue normalement? Que se passe-t-il si une valeur inattendue est transmise à la fonction ?

Assurez-vous de tester vos fonctions avec des variables, des types et des valeurs inattendus. Ce n'est qu'alors que vous pourrez vous fier à vos tests pour trouver les problèmes qu'une nouvelle version de PHP peut causer.

PHP devient plus strict

PHP devient plus précis (strict) dans la façon dont il gère les "types" pour les propres fonctions de PHP, ainsi que des choses comme les propriétés dynamiques. Ces modifications sont généralement destinées à aider les développeurs à fournir un code sans erreur (enfin, un code avec moins d'erreurs). Mais cela peut présenter un obstacle de mise à niveau pour le code préexistant écrit sur la base des "anciens" principes de PHP.

En raison de ce lecteur de messages d'erreur plus utiles en PHP, vous pouvez voir que rendre le code existant adapté aux nouvelles versions de PHP prend de plus en plus de temps. Rendre le code qui fonctionnait sur PHP 5.6 adapté à PHP 7.0 n'a pris qu'une fraction du temps dans la plupart des cas par rapport à la mise à niveau du code pour le rendre compatible avec PHP 8.1. Et cela malgré le fait que PHP 7.0 était une version "majeure", tandis que PHP 8.1 est une version "mineure".

Dans de nombreux cas, les tests restent le seul moyen fiable de déterminer ce qui doit être modifié pour prendre en charge une nouvelle version.

Les tests unitaires sont possibles avec divers outils, notamment :

• PHPUnit
• Moquerie
• Behat,
• Storyplayer

Beaucoup de ces outils sont basés sur ou en conjonction avec PHPUnit.

En fin de compte, peu importe les outils que vous utilisez. La chose la plus importante est que vous testiez et que les tests soient exécutés sur les nouvelles versions de PHP. Cette étape peut parfois être très délicate, mais heureusement, comme mentionné précédemment, il existe des outils pour cela, comme PHPUnit Polyfills.

Tests d'intégration

Les tests d'intégration sont la prochaine étape que nous allons effectuer, après l'analyse statique et les tests unitaires. Un test d'intégration consiste à tester des situations réelles dans un contexte plus large qu'une simple "unité de code". Ceux-ci incluent des tests avec une base de données active (de test) ou des tests avec une API externe, pour ne donner que deux exemples.

Ainsi, lorsque vous testez le code d'un plugin ou d'un thème dans le contexte de WordPress et que vous utilisez une vraie version, ce sont, par définition, des tests d'intégration.

WP Test Utils (encore une fois écrit par Juliette et sponsorisé par Yoast) est un excellent outil pour les tests d'intégration. WP Test Utils fournit des outils pour écrire des tests d'intégration et unitaires, dans lesquels WordPress est "simulé" à l'aide de Brainmonkey et Mockery, où les fonctions WordPress couramment utilisées sont "truquées" afin que vous testiez votre propre code et non le code WordPress.

Les tests d'intégration avec WordPress sont une histoire plus délicate car ils impliquent une intégration avec WordPress et la suite de tests de WordPress. Selon les versions de WordPress prises en charge par un plugin ou un thème, vous devez déterminer quelles versions de PHPUnit sont prises en charge par WordPress lui-même pour exécuter les tests sur différentes versions de PHP.

Par exemple, WordPress 5.6 à 5.8 utilise PHPUnit 5 à 7 pour tester PHP 5.6 à PHP 8.0, mais à partir de WordPress 5.9, WordPress lui-même utilise également PHPUnit Polyfills pour une prise en charge plus large. WP Test Utils agit comme un pont pour surmonter toutes ces différences.

Vous voulez en savoir plus sur la façon d'exécuter des tests d'intégration sur plusieurs versions différentes de WordPress, y compris WordPress 5.9 et supérieur ? Lisez ensuite à ce sujet sur le site Web de WordPress.

Test manuel

Maintenant que vous avez effectué les tests unitaires et les tests d'intégration et que vous avez résolu tous les problèmes que vous avez rencontrés, il est temps de faire des tests manuels. Votre site fonctionne et votre propre code fonctionne, mais vous utilisez également les plugins A, B et C. Savez-vous si ces plugins sont compatibles ?

Par exemple, vérifiez cela auprès des auteurs du plugin et voyez s'ils indiquent qu'il est compatible avec PHP 8.x. La question est alors, bien sûr, de savoir comment le plugin a été testé. Souvent, la réponse ici est : dans l'isolement. Les fonctions du plugin ont généralement été testées en conjonction avec WordPress seul, sans autres plugins actifs. Et même si d'autres plugins ont été utilisés dans ces tests, il est probable que tous les plugins que vous avez utilisés ne faisaient pas partie des tests, alors prenez une telle déclaration de compatibilité avec un grain de sel.

Par exemple, un site WordPress avec 3 plugins (A, B et C). Il est possible que le plugin B, par exemple, renvoie un type de variable incorrect via un filtre, avec lequel le plugin C, utilisant le même filtre, veut travailler. Cela peut alors provoquer une erreur fatale car le type n'est plus celui attendu. Le plugin C est alors considéré comme le coupable du message d'erreur, même si le plugin B est le véritable coupable.

Les incompatibilités d'interopérabilité des plugins sont impossibles à découvrir lors de tests isolés. Plus les plugins sont actifs, plus il y a de chances que quelque chose se passe mal. Par exemple, il serait très avantageux de transmettre les demandes de page d'un site Web en direct à un environnement de staging (avec la journalisation des erreurs activée) pour découvrir ce qui ne va pas.

Avec ce type de problème, un propriétaire de site ne verra généralement qu'un message indiquant qu'il y a eu une erreur avec le dernier code exécuté (dans ce cas, du plugin C), même si le plugin C n'est pas nécessairement la cause du problème.

Dans la plupart des cas, beaucoup de travail manuel et humain est impliqué, et une bonne quantité d'huile de coude est nécessaire pour détecter et résoudre ces problèmes. Cela pourrait être automatisé en utilisant des tests de bout en bout, mais nous ne voyons pas cela se produire beaucoup dans WordPress.

Tester la disponibilité des plugins utilisés

Pour les développeurs et les équipes de développement : n'acceptez le code que lorsque des tests sont disponibles. De cette façon, vous vous assurez que moins de tests manuels sont nécessaires, ce qui vous fait gagner beaucoup de temps.

Remettez en question sa stratégie de test si vous souhaitez acheter un plugin ou un thème commercial. De cette façon, nous créons collectivement une prise de conscience parmi les développeurs/équipes de développement de la communauté WordPress pour que les tests soient plus importants à l'ordre du jour, et nous en bénéficions tous.

Les tests sont souvent considérés - à tort - comme un coût alors qu'en réalité, ils permettent d'économiser de l'argent. L'investissement supplémentaire requis pour écrire des tests porte ses fruits sous la forme de beaucoup moins de rapports de bogues et moins de temps passé à corriger les bogues. De plus, avec les tests logiciels automatisés, les extensions et les modifications peuvent être effectuées plus rapidement car les tests peuvent rapidement confirmer que les fonctionnalités existantes continuent de fonctionner.

''Soyez gentil avec votre futur moi, s'il vous plait ;-)'' - Juliette Reinders Folmer Click to Tweet

Le rôle des hôtes WordPress et PHP 8.x

Pour le propriétaire de site moyen, les conseils de votre hôte sont hautement souhaitables. Considérer ce qui suit:

• Documentation et mises à jour pour les clients que WordPress Core, les plugins et/ou les thèmes ne sont (dans certains cas) pas compatibles avec les versions croisées de PHP
• Options de test (telles que l'utilisation d'un environnement de test)
• Méthodes de signalement d'erreurs et de contact avec l'assistance

Cela profite également à un hébergeur, car les propriétaires de sites contactent souvent l'hébergeur pour obtenir de l'aide en cas de problème. Dans le cas d'un passage à PHP 8.0 ou 8.1, le propriétaire du site est responsable des problèmes potentiels, et plus le propriétaire dispose d'informations pour bien se préparer au passage, mieux c'est.

Mettre PHP 8.0 ou 8.1 à la disposition des clients en tant qu'hébergeur Web est une chose, mais ce faisant, ils doivent s'assurer de sensibiliser les clients afin qu'ils soient conscients que des problèmes pourraient survenir. Il est recommandé de tester votre site dans un environnement intermédiaire avec une version différente de celle en direct. (La sélection des versions PHP est disponible par défaut chez Kinsta.)

Version PHP minimale pour WordPress

Plus de 15 % de tous les sites Web utilisent actuellement PHP version 7.0 ou inférieure. Cela peut être vu dans les statistiques officielles de WordPress. Environ 83% de tous les sites WordPress utilisent actuellement PHP version 7.4 ou inférieure. Veuillez noter que tout ce qui est inférieur ou égal à la version 7.4 n'est actuellement plus pris en charge par PHP. L'utilisation de versions en fin de vie de PHP peut entraîner des problèmes car les mises à jour de sécurité ne sont plus publiées.

Pour éviter les problèmes, il est important que les propriétaires de sites WordPress connaissent et soient informés de la version minimale de PHP qui permettra à leur site de fonctionner en toute sécurité. De leur côté, les propriétaires de sites peuvent modifier eux-mêmes la version PHP (possible chez Kinsta pour tous les packages) ou demander à leur hébergeur de mettre à jour le site vers une version PHP plus récente. Dans les cas extrêmes, vous pouvez basculer vers un hôte qui prend en charge ces nouvelles versions.

Étant donné que WordPress ne nécessite qu'une version minimale de 7.4, de nombreux hébergeurs et propriétaires de sites Web ne sont pas suffisamment motivés pour mettre à jour leurs sites. Et ceci malgré le fait que PHP 7.4 a atteint sa fin de vie en novembre 2022.

Si jamais WordPress augmente la version minimale de PHP, cela peut signifier que de nombreux sites ne seront plus compatibles avec une mise à jour vers la dernière version de WordPress. Cependant, des mises à jour de sécurité continueront d'être publiées pour ces versions obsolètes pendant un certain temps.

Résumé

Pour passer à PHP 8.0 ou supérieur pour votre site Web, vous, ou votre développeur, devez effectuer plusieurs étapes. Les étapes importantes incluent :

• Analyse statique
• Tests unitaires
• Tests d'intégration
• Test manuel

Lors du passage à PHP 8.x, assurez-vous que tout a été correctement testé. C'est le seul moyen de garantir que votre site fonctionnera correctement, rapidement et en toute sécurité sur une version plus récente de PHP.

Nous remercions énormément Juliette pour sa participation à cet article et pour tout son travail sur les outils évoqués !

Photo de Juliette, prise par Jip Moors et utilisée avec permission.