Mettre à niveau un site, une extension ou un thème WordPress vers une nouvelle version de PHP est une tâche qui revient régulièrement. Mais comment faire pour la réaliser aussi efficacement que possible ? Comment savez-vous que vous n’oublierez rien ? Existe-t-il une feuille de route pour cela ?
Dans cet article, nous répondrons à ces questions (et à bien d’autres) et examinerons ce qu’implique une transition en douceur vers PHP 8.x pour votre site, extension ou thème WordPress, y compris une feuille de route.
Pour cela, nous nous baserons sur un entretien que nous avons réalisé avec l’experte PHP Juliette Reinders Folmer. Elle consacre la majeure partie de son quotidien à la programmation et à tout ce qui l’entoure, en se concentrant principalement sur les projets open source, dont WordPress.
Êtes-vous prêt à franchir le pas en douceur vous aussi ? Vous êtes curieux de connaître notre plan étape par étape ? Alors plongeons-y !
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
- Nouveautés de PHP 8.0 et PHP 8.1
- Nouveautés de PHP 8.2 et guide de migration vers PHP 8.2.
Après avoir lu ces articles, vous serez parfaitement au courant de ce qui a changé dans PHP 8.x et de ce que vous devez faire pour que vos projets PHP fonctionnent sans problème.
Si vous n’êtes pas sûr de 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 de la manière la plus complète 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.
Passage à 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 de PHP se fait 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. En fonction de votre niveau de connaissance et d’expérience, nous vous recommandons ce qui suit :
- Si vous avez construit votre propre site WordPress avec des thèmes et des extensions standard, sans avoir beaucoup de connaissances en PHP, faites appel à un développeur ou à une agence pour vérifier si votre site est apte à fonctionner avec PHP 8.x. Vous cherchez un tiers qui peut vous aider ? Consultez alors notre page Partenaires qui liste plusieurs entreprises de confiance qui peuvent vous aider.
- Si votre site WordPress a été construit par une partie externe, un développeur ou une agence, contactez-les pour leur demander si votre site peut fonctionner avec PHP 8.x.
- Si vous avez construit votre site WordPress – avec votre propre thème personnalisé, par exemple, ou des extensions développées par vous-même – nous avons une feuille de route pour vous ci-dessous.
Si votre site entre dans l’une des deux premières catégories, nous vous invitons certainement à lire le reste de l’article, mais nous ne vous recommandons pas de commencer à tester vous-même la compatibilité de votre site avec PHP 8. Laissez cela aux professionnels.
Quel que soit votre choix, nous vous conseillons de ne pas simplement passer votre site en production en PHP 8 et de « voir si ça marche » Vous êtes curieux de savoir à quoi ressemblera votre site, et vous êtes impatient de le voir fonctionner en PHP 8 ? Alors commencez à tester dans un environnement de staging. Un bon hébergeur vous permettra de configurer 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 à partir du 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 en a pas. La feuille de route ci-dessous vous expliquera pourquoi.
Tests de compatibilité avec PHP 8.x : La feuille de route
Les tests : le mot clé d’un bon logiciel. Même pour les sites web WordPress et leurs composants, tels que les thèmes, les extensions et le cœur de WordPress, les tests sont le moyen de s’assurer que les choses que vous ne voulez pas voir se produire ne se produisent pas.
Un projet de développement de logiciel est en grande partie constitué de tests. Dans cet article, nous examinons spécifiquement les tests qui peuvent vous aider à faire en sorte que la transition vers PHP 8.x se fasse 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 mesure que vous pouvez prendre en tant que développeur PHP est d’effectuer une analyse statique de votre code avec différents outils. L’analyse statique est le processus d’analyse d’un logiciel sans exécuter le code. Grâce à l’analyse statique, il est possible de détecter les erreurs, de détecter les problèmes de compatibilité avec PHP 8.x, d’appliquer les normes de codage (par exemple, les normes de codage de WordPress), et même de modifier et de nettoyer le code.
Outils d’analyse statique
Vous pouvez effectuer une analyse statique avec différents outils, tels que :
Au moment de la rédaction de cet article, toutes les vérifications de PHP 8.1 ne sont pas supportées dans la dernière version de PHPCompatibility. Les vérifications de PHP 8.1 peuvent être dans la version de développement, donc assurez-vous d’utiliser celles-ci (pour l’instant) lorsque vous utilisez PHPCompatibility pour analyser votre projet et voir quelles sont les erreurs/recommandations.
Les vérifications de PHP 8.1 seront bientôt publiées dans une nouvelle version majeure . Si vous voulez être tenu au courant de cela, et que vous avez un compte GitHub, ouvrez le dépôt GitHub de PHPCompatibility et naviguez vers Watch -> Custom -> Releases, où vous pouvez choisir d’être notifié quand une nouvelle version est publiée.
PHPCompatibility, qui ne teste la compatibilité que pour une version particulière (ou 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 devez être attentif aux fonctions dépréciées ou supprimées, aux valeurs par défaut modifiées des paramètres de fonction, à l’utilisation de concat sans parenthèses, à l’utilisation de 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 données à tort, causées par les 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 sur ces outils.
Résumé :
- Effectuez une analyse statique avec PHPCompatibility, Psalm, PHPStan
- Résolvez tous les problèmes légitimes
Test unitaire
L’étape suivante du processus est le test unitaire. Les tests unitaires sont une méthode permettant de tester des morceaux de code individuellement. Dans les tests unitaires, des tests spécifiques ciblés seront développés pour chaque unité. Cela implique l’exécution de 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. La meilleure façon d’automatiser les tests unitaires est d’utiliser un outil d’intégration continue (IC) tel que Jenkins, GitHub Actions ou Travis.
Prise en charge de plusieurs versions de PHP
En tant que créateur d’extensions, si vous souhaitez prendre en charge plusieurs versions de PHP, assurez-vous que les tests dans l’IC sont exécutés contre toutes les versions de PHP que vous prenez en charge.
Bien sûr, vous pouvez aussi ne prendre en charge que les versions les plus récentes, le choix vous appartient entièrement.
Tester avec plusieurs versions de PHP nécessite que vous utilisiez plusieurs versions de PHPUnit, en fonction de la version de PHP. Comme PHPUnit a introduit plusieurs changements au cours des années qui affectent la façon dont les tests sont écrits, cette partie peut être délicate.
Pour contourner cela, vous pouvez utiliser les Polyfills de PHPUnit (écrits par Juliette et sponsorisés par Yoast). Cela vous permet d’écrire des tests qui ne sont officiellement pas pris en charge par PHPUnit 9 (et qui peuvent donc fonctionner sur PHP 8.x). Les Polyfills font alors 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 fonctionnent, l’étape suivante consiste à s’assurer que les problèmes trouvés dans les tests sont corrigés.
Couverture du 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 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, même si (une partie) du code de ces fonctions est exécutée pendant le test de la fonction A.
- Pour chacun de vos tests, indiquez quel code est spécifiquement testé. Vous le faites en donnant à chaque test un @covers. De cette façon, 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 uniquement avec les valeurs/types attendus n’est pas suffisant.
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 ? Obtenez-vous un message d’erreur ? Ou bien la variable passée avec la fonction se poursuit-elle normalement ? Que se passe-t-il si une valeur inattendue est transmise à la fonction ?
Veillez à tester vos fonctions avec des variables, des types et des valeurs inattendus. Ce n’est qu’ainsi que vous pourrez vous fier à vos tests pour trouver les problèmes qu’une nouvelle version de PHP pourrait causer.
PHP devient plus strict
PHP devient plus précis (strict) dans la façon dont il gère les « types » pour les fonctions propres à PHP, ainsi que des choses comme les propriétés dynamiques. Ces changements sont généralement destinés à aider les développeurs à fournir un code sans erreur (enfin, un code avec moins d’erreurs). Mais cela peut représenter un obstacle à la mise à niveau pour le code préexistant écrit sur la base des « anciens » principes de PHP.
En raison de cette volonté d’obtenir des messages d’erreur plus utiles en PHP, vous pouvez constater que l’adaptation du code existant aux nouvelles versions de PHP prend de plus en plus de temps. Adapter du code qui fonctionnait avec PHP 5.6 à PHP 7.0 ne prend qu’une fraction du temps dans la plupart des cas, comparé à la mise à jour du code pour le rendre compatible avec PHP 8.1. Et ce, malgré le fait que PHP 7.0 était une version « majeure », alors que PHP 8.1 est une version « mineure »
Dans de nombreux cas, les tests sont encore le seul moyen fiable de déterminer ce qui doit être modifié pour supporter une nouvelle version.
Les tests unitaires sont possibles avec divers outils, notamment :
Beaucoup de ces outils sont construits sur la base de, ou en conjonction avec, PHPUnit.
En fin de compte, les outils que vous utilisez n’ont pas d’importance. La chose la plus importante est que vous testiez, et que vous fassiez fonctionner les tests 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, tels que PHPUnit Polyfills.
Tests d’intégration
Les tests d’intégration sont l’étape suivante 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 » Il s’agit notamment de tests avec une base de données (de test) active ou de tests avec une API externe, pour ne donner que deux exemples.
Ainsi, lorsque vous testez le code d’une extension ou d’un thème dans le contexte de WordPress et que vous utilisez une version réelle, il s’agit, par définition, de 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 des tests unitaires, dans lesquels WordPress est « maquillé » à l’aide de Brainmonkey et Mockery, où les fonctions courantes de WordPress sont « truquées » afin que vous testiez votre propre code et non celui de 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. En fonction des versions de WordPress qu’une extension ou un thème prend en charge, vous devez considérer 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 un support 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 contre plusieurs versions différentes de WordPress, y compris WordPress 5.9 et plus ? Alors lisez ce qui suit sur le site web WordPress.
Tests manuels
Maintenant que vous avez effectué les tests unitaires et les tests d’intégration et que vous avez corrigé tous les problèmes que vous avez trouvés, il est temps de procéder aux tests manuels. Votre site fonctionne et votre propre code fonctionne, mais vous utilisez également les plugins A, B et C. Savez-vous si ces extensions sont compatibles ?
Vérifiez par exemple auprès des auteurs de l’extension et voyez s’ils indiquent qu’il est compatible avec PHP 8.x. La question est alors, bien sûr, de savoir comment l’extension a été testée. Souvent, la réponse est : en isolation. Les fonctions de l’extension ont généralement été testées en conjonction avec WordPress seul, sans autres extensions actives. Et même si d’autres extensions ont été utilisées dans le cadre de ces tests, il y a de fortes chances que toutes les extensions que vous utilisez n’aient pas fait partie des tests, alors prenez une telle déclaration de compatibilité avec des pincettes.
Par exemple, un site WordPress avec 3 extensions (A, B, et C). Il est possible que l’extension B, par exemple, renvoie un type de variable incorrect via un filtre, avec lequel l’extension C, utilisant le même filtre, veut travailler. Cela peut alors provoquer une erreur fatale car le type n’est plus celui attendu. L’extension C est alors considérée comme la coupable du message d’erreur, même si l’extension B est la véritable fautive.
L’interopérabilité et l’incompatibilité des extensions sont impossibles à découvrir lors de tests isolés. Plus il y a d’extensions actives, plus il y a de chances que quelque chose se passe mal. Par exemple, il serait très avantageux de faire passer les requêtes de pages d’un site web en production à 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, de l’extension C), même si l’extension C n’est pas nécessairement la cause du problème.
Dans la plupart des cas, il s’agit de beaucoup de travail manuel, humain, et une bonne quantité d’huile de coude est nécessaire pour détecter et corriger ces problèmes. Cela pourrait être automatisé en utilisant des tests de bout en bout, mais nous ne voyons pas cela arriver souvent dans WordPress.
Disponibilité des tests pour les plugins utilisés
Pour les développeurs et les équipes de développement : Acceptez le code uniquement lorsque les 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 une extension ou un thème commercial. De cette façon, nous sensibilisons collectivement les développeurs/équipes de développement de la communauté WordPress pour que les tests deviennent une priorité, et nous en bénéficions tous.
Les tests sont souvent considérés – injustement – comme un coût alors qu’en réalité, ils permettent d’économiser de l’argent. L’investissement supplémentaire nécessaire à l’écriture de tests est rentabilisé par une réduction significative du nombre de rapports de bogues et du temps consacré à la correction des bogues. En outre, avec les tests automatisés de logiciels, les extensions et les modifications peuvent être effectuées plus rapidement car les tests peuvent rapidement confirmer que la fonctionnalité existante continue de fonctionner.
Le rôle des hébergeurs WordPress et de PHP 8.x
Pour le propriétaire de site moyen, les conseils de votre hébergeur sont hautement souhaitables. Considérez les points suivants :
- Documentation et mises à jour pour les clients que le cœur de WordPress, les extensions, et/ou les thèmes ne sont (dans certains cas) pas compatibles avec les versions croisées de PHP
- Options pour les tests (comme travailler avec un environnement de staging)
- Méthodes pour signaler les erreurs et contacter le support
Cela profite également à un hébergeur, car les propriétaires de sites contactent souvent l’hébergeur pour obtenir de l’aide lorsque des problèmes surviennent. Dans le cas d’un passage à PHP 8.0, 8.1 ou 8.2, le propriétaire du site est responsable des problèmes potentiels, et plus le propriétaire dispose d’informations pour se préparer correctement au passage, mieux c’est.
Mettre PHP 8.1 ou 8.2 à 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 de staging 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 la version 7.0 ou inférieure de PHP. Cela peut être constaté dans les statistiques officielles de WordPress. Environ 83 % de tous les sites WordPress utilisent actuellement la version 7.4 ou inférieure de PHP. Veuillez noter que tout ce qui est inférieur ou égal à la version 8.0 n’est actuellement plus pris en charge par PHP. L’utilisation de versions de PHP en fin de vie 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 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 packs) ou demander à leur hébergeur de mettre à jour le site vers une version PHP plus récente. Dans les cas extrêmes, vous pouvez passer à un hébergeur qui prend en charge ces versions plus récentes.
Étant donné que WordPress ne requiert 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 ce, malgré le fait que PHP 7.4 a atteint sa fin de vie en novembre 2022.
Si WordPress augmente un jour la version minimale de PHP, cela pourrait signifier que de nombreux sites ne seront plus compatibles avec une mise à jour de la dernière version de WordPress. Toutefois, les mises à jour de sécurité continueront à être publiées pour ces versions obsolètes pendant un certain temps.
Résumé
Pour passer à PHP 8.0 ou plus pour votre site web, il y a plusieurs étapes que vous, ou votre développeur, devez effectuer. Les étapes importantes sont les suivantes :
- Analyse statique
- Tests unitaires
- Tests d’intégration
- Tests manuels
Lorsque vous passez à PHP 8.x, assurez-vous que tout a été correctement testé. C’est la seule façon de garantir que votre site fonctionnera correctement, rapidement et en toute sécurité sur une version PHP plus récente.
Nous remercions infiniment Juliette pour sa participation à cet article et pour tout son travail sur les outils mentionnés !
Photo de Juliette, prise par Jip Moors et utilisée avec permission.
Laisser un commentaire