Comment tester la compatibilité PHP WordPress sur différentes versions de plugin

Les tests de compatibilité PHP WordPress consistent à vérifier si votre plugin se comporte correctement sur chaque combinaison de versions PHP et WordPress que vous supportez. Avec un sandbox WordPress sur wp.run, vous pouvez lancer des installations de test propres, comme PHP 8.4 avec WordPress 6.9, puis répéter le même test de fumée sans serveurs locaux ni risque en production.

Vous pouvez lancer la première vérification dès maintenant : appuyez sur Lancer WordPress en haut de cette page, choisissez les versions PHP et WordPress que vous voulez tester, et exécutez le plugin dans un site WordPress jetable avec un accès wp-admin réel.

Pourquoi la compatibilité PHP WordPress nécessite une matrice

Un plugin peut passer sur un stack et échouer sur un autre. Les changements PHP peuvent exposer de la syntaxe obsolète, un typage plus strict, des fonctions supprimées, ou des avertissements qui n’apparaissaient pas sur un ancien environnement d’exécution. Les changements WordPress peuvent affecter le comportement de l’éditeur, les hooks, les endpoints REST, les écrans d’administration et le JavaScript embarqué.

C’est pourquoi une simple vérification « ça marche sur ma machine » ne suffit pas. Les tests de compatibilité de plugin doivent couvrir les combinaisons que vos utilisateurs utilisent réellement :

Le manuel officiel de WordPress Core tient à jour un tableau de compatibilité PHP pour WordPress lui-même. Prenez-le comme référence pour le cœur. Votre travail consiste à tester votre plugin par-dessus ces stacks, car la compatibilité de WordPress core ne garantit pas que chaque plugin ou thème se comporte correctement.

Construisez une petite matrice PHP x versions WordPress

Commencez par la matrice la plus petite qui répond à une vraie question de version. Pour la plupart des équipes, cela veut dire trois lignes avant chaque version significative :

1. Le stack le plus ancien supporté. Cela détecte la syntaxe ou l’usage d’API qui casse chez les utilisateurs qui n’ont pas encore mis à jour.
2. Le stack actuel recommandé. C’est le stack que vous attendez pour la plupart de vos nouveaux tests et démos.
3. Le stack le plus récent. Cela détecte les changements PHP et WordPress à venir avant que les utilisateurs ne les signalent.

Sur wp.run, la fenêtre de lancement permet de choisir explicitement les versions WordPress et PHP. Vous pouvez aussi utiliser des URLs de lancement pour lancer un sandbox WordPress depuis un lien de test reproductible, par exemple :

https://wp.run/new?php=8.4&wp=6.9

Pour les presets pris en charge, ajoutez le paramètre plugin afin de rendre l’environnement reproductible :

https://wp.run/new?plugin=woocommerce&php=8.4&wp=6.9

Pour vos propres builds de plugin, téléchargez le ZIP dans wp-admin et notez le build exact. Chaque ligne de votre matrice doit indiquer un stack, une version de plugin, les vérifications effectuées et le résultat.

Comment tester la compatibilité du plugin avec PHP 8.4 sur wp.run

1. Lancez le stack cible. Appuyez sur Lancer WordPress, choisissez PHP 8.4 et la version WordPress que vous voulez valider, créez le sandbox. wp.run provisionne une installation WordPress temporaire avec des identifiants administrateur et une URL *.wprun.site.
2. Confirmez l’environnement. Ouvrez wp-admin, vérifiez Outils → Santé du site → Informations pour les versions PHP et WordPress avant de commencer les tests.
3. Installez ou activez le plugin. Chargez un preset depuis un paramètre d’URL de lancement, ou téléchargez le ZIP de votre plugin dans wp-admin. Notez le build exact du plugin dans votre journal de test.
4. Exécutez la vérification d’activation. Surveillez les erreurs fatales, avis d’administration, dépendances manquantes, boucles de redirection et échecs de l’assistant de configuration.
5. Exercez la fonctionnalité principale. Exécutez le plus petit flux de travail réel que le plugin est censé supporter : créer un formulaire, compléter un paiement, ajouter un bloc, générer un sitemap, importer du contenu ou déclencher la tâche planifiée.
6. Vérifiez les surfaces admin et front-end. Ouvrez l’éditeur de blocs, les paramètres du plugin, la sortie de la page publique, les endpoints REST le cas échéant et la console du navigateur.
7. Répétez sur le stack suivant. Lancez la version PHP ou WordPress suivante et exécutez la même liste de contrôle. Changez une dimension à la fois quand vous isolez un échec.

Cela vous donne rapidement un signal de compatibilité manuel. Cela ne remplace pas les tests unitaires, les tests d’intégration ou l’analyse statique, mais cela détecte les échecs au niveau produit que les utilisateurs voient réellement dans wp-admin et sur le front-end.

Ajoutez un scan statique, mais ne vous arrêtez pas là

Les scanners de compatibilité statiques sont utiles car ils détectent les motifs de code avant l’exécution. La leçon Learn WordPress sur le test de compatibilité de vos produits avec les versions PHP couvre deux approches courantes : le test manuel dans un environnement PHP cible et le scan avec les règles PHPCompatibility via PHP_CodeSniffer.

Utilisez les deux signaux ensemble :

• Scan statique d’abord. Trouvez les fonctions supprimées, signatures obsolètes et syntaxe PHP spécifique à une version.
• Test en sandbox ensuite. Confirmez que le plugin démarre, affiche son interface, écrit les options attendues et complète son flux de travail réel sur le stack cible.
• Note de régression en dernier. Enregistrez ce qui a échoué, les versions exactes de PHP/WP/plugin et si le problème est un avertissement, une erreur fatale, une interface cassée ou un problème de données.

Les outils statiques peuvent vous dire qu’une ligne de code est peut-être incompatible. Un sandbox vous dit si le plugin fonctionne toujours en tant que produit WordPress.

Ce qu’il faut vérifier lors des tests de versions WP

Les tests de versions WP ne se limitent pas à savoir si le plugin s’active. Les bugs les plus coûteux apparaissent souvent après l’activation, quand un utilisateur modifie du contenu, configure des paramètres ou met à niveau depuis une version plus ancienne.

Vérifiez ces domaines sur chaque ligne de la matrice :

• Activation et désactivation. Le plugin doit s’activer proprement, se désactiver proprement et ne pas laisser le site dans un état cassé.
• Chemin de mise à jour. Installez la version précédente, créez des données exemples, puis mettez à jour et confirmez que les migrations s’exécutent.
• Écrans admin et éditeur. Ouvrez chaque menu que le plugin ajoute. S’il touche aux blocs, shortcodes, embeds, types de contenu personnalisés ou meta boxes, testez l’éditeur sur chaque version WordPress.
• Sortie front-end. Confirmez que les modèles, shortcodes, ressources, redirections, flux de paiement, formulaires ou widgets s’affichent correctement.
• REST, AJAX et tâches planifiées. Testez les requêtes d’endpoint pertinentes et le comportement dépendant des crons là où le plugin s’appuie sur des tâches en arrière-plan.
• Hygiène de désinstallation. Désactivez et supprimez dans un sandbox jetable pour vérifier si le comportement de nettoyage est acceptable.

Gardez cette liste de contrôle cohérente. Si chaque testeur invente un nouveau chemin dans wp-admin, votre matrice devient plus difficile à comparer.

Une matrice pratique pour la version d’un plugin

Voici une matrice compacte pour une équipe de plugin qui prépare une version :

Utilisez la matrice comme un critère de mise en production, pas comme une réflexion après coup pour la documentation. Si une ligne échoue, copiez les étapes exactes, incluez les sorties de débogage ou des captures d’écran, et joignez l’URL temporaire du sandbox tant qu’il est encore actif.

Échecs de compatibilité courants à surveiller

La plupart des échecs de compatibilité suivent quelques schémas :

• Erreur fatale à l’activation. Généralement causée par des fonctions PHP supprimées, des classes manquantes, des problèmes de chargement automatique des dépendances, ou du code qui s’exécute trop tôt.
• Avertissements qui deviennent bruyants sur PHP plus récent. Les propriétés dynamiques, les arguments nullables, les hypothèses de typage strict et les signatures obsolètes peuvent inonder les journaux même quand la page semble fonctionner.
• Rupture de l’éditeur. Le plugin fonctionne en front-end mais l’éditeur de blocs échoue sur WordPress plus récent.
• Échecs AJAX, REST ou de mise à jour. La gestion des nonces, l’enregistrement des routes, les options enregistrées ou les tables personnalisées peuvent révéler des hypothèses fragiles.
• Conflits de dépendances. Deux plugins peuvent embarquer des versions incompatibles d’une bibliothèque PHP partagée ou d’un package JavaScript.

Quand une ligne échoue, ne sautez pas directement à « PHP est incompatible ». Réexécutez le même plugin sur la même version WordPress avec la version PHP précédente, puis changez WordPress en gardant PHP stable. Isoler une dimension à la fois est la façon de trouver la vraie ligne de faute.

Où se situe le sandbox

Un sandbox WordPress jetable est idéal pour les tests de fumée de compatibilité, les vérifications de version candidate, la reproduction de tickets support, les liens de démo et la QA rapide de plugins. Utilisez le staging ou un environnement local quand le test dépend d’une base de données façonnée pour la production, de fichiers persistants, d’une configuration serveur particulière ou d’un débogage de longue durée.

Le flux de travail pratique se construit en couches : scannez le code, exécutez les tests automatisés, utilisez les sandboxes wp.run pour les vérifications de compatibilité PHP et WordPress au niveau produit, puis passez au staging seulement quand vous devez vérifier un site précis.

Questions fréquentes

Qu’est-ce que la compatibilité PHP WordPress ? La capacité de WordPress core, d’un plugin ou d’un thème à fonctionner correctement sur une version PHP spécifique. Pour les plugins, la compatibilité doit être testée dans un vrai environnement WordPress, car le plugin dépend des hooks WordPress, des écrans d’administration, du comportement de la base de données et d’autre code actif.

Comment tester un plugin sur PHP 8.4 ? Lancez un sandbox wp.run avec PHP 8.4, confirmez la version PHP dans Santé du site, installez le plugin, puis exécutez les vérifications d’activation, admin, éditeur, front-end, REST/AJAX et désinstallation. Répétez la même liste de contrôle sur la version PHP précédente si vous devez isoler un échec spécifique à PHP.

La compatibilité de WordPress core signifie-t-elle que mon plugin est aussi compatible ? Non. WordPress core peut être compatible avec une version PHP tandis qu’un plugin échoue toujours à cause de son propre code, de ses dépendances, de son interface admin ou de sa logique de mise à jour. Utilisez le tableau de compatibilité de WordPress core comme référence, puis testez le plugin séparément.

Combien de combinaisons PHP et WordPress dois-je tester ? Testez la plus ancienne que vous supportez, la version par défaut actuelle que vous attendez des utilisateurs et la plus récente que vous voulez anticiper. Ajoutez des lignes pour les chemins de mise à jour, les dépendances ou les environnements signalés par les clients quand cela compte.

Rendez les tests de compatibilité reproductibles

Le meilleur processus de compatibilité est ennuyeux : une matrice, une liste de contrôle, un journal de résultats, répétés pour chaque version candidate. wp.run vous donne la couche d’environnement rapide pour ce processus : WordPress propre, versions PHP et WordPress sélectionnables, accès admin généré, et sandboxes temporaires que vous pouvez jeter une fois chaque ligne terminée.