# PHPCompatibility : vérifier la compatibilité PHP de votre code WordPress > Configurer PHPCompatibilityWP avec PHPCS, cibler une plage de versions PHP précise, et traiter les alertes avant une migration de serveur. - Auteur : Clément Hadrot - Publié le : 2021-04-27 - Mis à jour le : 2021-04-27 - Catégorie : Tests - URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/phpcompatibility-verifier-compatibilite-php/ ## L’essentiel - Un jeu de règles distinct des standards de code - Cibler une plage de versions, pas une seule - Distinguer erreur bloquante et avertissement de dépréciation Un hébergeur a prévenu ses clients qu'il désactiverait PHP 7.4 dans deux mois, poussant tout le monde vers PHP 8.1 au minimum. Sur une extension maintenue depuis 2016, personne ne savait avec certitude si le code utilisait encore des fonctionnalités supprimées en cours de route, comme les accolades pour l'accès aux chaînes ou certaines fonctions dépréciées. Plutôt que de tester à l'aveugle sur un environnement de préproduction, PHPCompatibility a permis de lister l'intégralité des points bloquants en quelques minutes, sans exécuter une seule ligne du code. PHPCompatibility est un jeu de règles pour PHP_CodeSniffer, distinct des standards de style comme WordPress Coding Standards : il ne vérifie pas la mise en forme du code, mais sa compatibilité avec une ou plusieurs versions de PHP cibles, en analysant statiquement chaque instruction. ## Installer PHPCompatibilityWP La variante `PHPCompatibilityWP` ajoute par-dessus `PHPCompatibility` la connaissance des fonctions et constantes spécifiques à WordPress, pour éviter les faux positifs sur des fonctions comme `wp_die()` ou `__()` : ``` composer require --dev phpcompatibility/phpcompatibility-wp vendor/bin/phpcs --config-set installed_paths vendor/phpcompatibility/php-compatibility,vendor/phpcompatibility/phpcompatibility-wp ``` ## Cibler une plage de versions précise L'intérêt de PHPCompatibility est de pouvoir cibler une plage plutôt qu'une seule version, ce qui correspond mieux à la réalité d'une extension distribuée à des clients hébergés sur des versions PHP différentes : ``` src ``` ``` vendor/bin/phpcs --standard=phpcs.xml ``` > L'essentiel à retenir : Un jeu de règles distinct des standards de code ; Cibler une plage de versions, pas une seule ; Distinguer erreur bloquante et avertissement de dépréciation Avec `testVersion=7.4-8.1`, PHPCompatibility signale toute construction qui casserait sur au moins une version de la plage, y compris les fonctionnalités trop récentes pour 7.4 et celles trop anciennes pour 8.1. ## Traiter les alertes remontées Le rapport distingue plusieurs niveaux de sévérité, et il ne faut pas les traiter tous de la même façon : - **Erreur bloquante** : une syntaxe supprimée qui provoquera une erreur fatale, par exemple `create_function()`, retirée en PHP 8.0 - **Avertissement de dépréciation** : une fonctionnalité encore fonctionnelle mais qui affichera un avertissement, comme le passage d'un paramètre nul à un paramètre non nullable en PHP 8.1 - **Changement de comportement** : le code continue de s'exécuter mais produit un résultat différent, le cas le plus dangereux car silencieux Un exemple typique remonté sur PHP 8.0 : l'opérateur `@` de suppression d'erreurs ne masque plus les erreurs fatales, ce qui peut révéler brutalement des erreurs jusque-là invisibles en production. PHPCompatibility signale ces usages pour qu'ils soient revus avant la migration, pas découverts après. ## Corriger un cas concret ``` // Signalé : each() supprimé en PHP 8.0 while ( list( $cle, $valeur ) = each( $tableau ) ) { // ... } // Correction : foreach natif foreach ( $tableau as $cle => $valeur ) { // ... } ``` ## Prioriser les corrections sur un gros volume d'alertes Sur une base de code ancienne, le nombre d'alertes remontées peut dépasser plusieurs centaines dès le premier lancement. Plutôt que de tout corriger dans l'ordre du rapport, il est plus efficace de trier par sévérité et par fréquence : - Traiter d'abord les erreurs bloquantes qui provoqueraient une erreur fatale immédiate, elles sont peu nombreuses mais critiques - Regrouper les avertissements de dépréciation par motif identique (par exemple tous les passages de `null` à un paramètre non nullable) pour les corriger en une seule série de commits - Laisser volontairement de côté les changements de comportement les moins risqués si le calendrier presse, en les documentant pour un passage ultérieur ## Automatiser la vérification en intégration continue Une fois la base de code assainie pour la plage de versions ciblée, ajouter PHPCompatibility comme étape distincte du pipeline évite qu'une régression future ne réintroduise du code incompatible sans être détectée avant la revue de code : ``` - name: Vérifier la compatibilité PHP run: vendor/bin/phpcs --standard=phpcs.xml --report=summary ``` Contrairement à un test fonctionnel, cette vérification reste rapide, de l'ordre de quelques secondes sur une extension de taille moyenne, ce qui permet de la garder active en permanence sans ralentir le pipeline. ## En résumé PHPCompatibility ne remplace pas des tests réels sur la version cible, mais il permet de dégrossir le travail avant même d'installer un environnement de test, en listant précisément les lignes à corriger et en les triant par sévérité. Les standards de code WordPress (indentation, nommage, espacement) répondent à un objectif différent — la cohérence stylistique — et méritent leur propre configuration, séparée de celle-ci.