Tester la compatibilité WordPress avec PHP 8.4 et 8.5

Changer la version PHP d’un site WordPress peut améliorer les performances, renforcer la sécurité et prolonger la durée de vie technique du site. Mais cela peut aussi révéler un vieux plugin bancal, un thème oublié ou un snippet copié-collé en 2014. Bref, PHP ne casse pas toujours WordPress. Il révèle souvent ce qui était déjà fissuré.

Voici une méthode propre pour tester la compatibilité d’un site WordPress avec PHP 8.4 ou PHP 8.5 avant de basculer la production.

Kinsta: Premium Managed WordPress hosting

WordPress et PHP 8 : où en est-on ?

WordPress recommande aujourd’hui PHP 8.3 ou supérieur pour de meilleures performances et une meilleure sécurité. WordPress peut encore fonctionner avec PHP 7.4, mais cette branche est officiellement en fin de vie. Elle ne doit plus servir de base sérieuse pour un site maintenu.

La situation actuelle est simple :

PHP 8.5 : excellent objectif pour un site WordPress très bien maintenu.
PHP 8.4 : meilleur compromis pour la majorité des sites récents et propres.
PHP 8.3 : base minimale recommandée aujourd’hui.
PHP 8.2 et inférieur : à éviter pour une nouvelle migration.
PHP 7.4 : branche en fin de vie, à sortir du parc dès que possible.

Le point crucial : WordPress core n’est généralement pas le problème. Les blocages viennent presque toujours des plugins, thèmes, mu-plugins, snippets, intégrations WooCommerce ou vieux bouts de code maison.

Pourquoi tester avant de changer PHP ?

Un changement de version PHP peut transformer un simple avertissement en erreur fatale. Cela concerne notamment :

les fonctions supprimées ou dépréciées ;
les signatures de méthodes incompatibles ;
les propriétés dynamiques en PHP 8.2+ ;
les accès à des tableaux mal typés ;
les conversions implicites plus strictes ;
les vieux constructeurs PHP 4 ;
les appels à des extensions PHP absentes ;
les plugins qui chargent du code même lorsqu’ils sont désactivés ;
les snippets stockés en base de données.

Autrement dit, un simple php -v ne suffit pas. Il faut scanner le code, tester le site, puis lire les logs. Oui, c’est moins glamour qu’un bouton “upgrade”. Mais c’est aussi ce qui évite le fameux écran blanc un vendredi à 18h.

La méthode sûre en 6 étapes

Créer une sauvegarde complète des fichiers et de la base de données.
Cloner le site sur un environnement de staging.
Mettre WordPress, les plugins et le thème à jour.
Scanner le code avec des outils de compatibilité PHP.
Basculer le staging vers la nouvelle version PHP.
Tester les parcours critiques avant de passer la production.

Pour un site vitrine, testez au minimum l’accueil, les formulaires, la recherche, les pages importantes, les envois d’emails et l’éditeur WordPress.

Pour une boutique WooCommerce, ajoutez le panier, la commande, les moyens de paiement, les emails transactionnels, les comptes clients, les remboursements, les coupons, les taxes, les webhooks et les exports. WooCommerce adore rappeler qu’un site e-commerce n’est pas “juste un WordPress avec deux plugins”.

Étape 1 : connaître la version PHP actuelle

Depuis WordPress, allez dans :

Outils ;
Santé du site ;
Informations ;
Serveur.

En SSH, vous pouvez aussi utiliser :

php -v

Attention toutefois : la version PHP en ligne de commande peut différer de celle utilisée par le site web via PHP-FPM, Apache ou l’interface de l’hébergeur. Vérifiez donc les deux.

Avec WP-CLI, contrôlez aussi les informations WordPress :

wp core version
wp --info

Si vous utilisez souvent WP-CLI, l’article Installer WP-CLI sans accès root ni sudo via SSH peut vous aider à travailler proprement même sur un hébergement verrouillé.

Étape 2 : sauvegarder avant de tester

Avant toute migration PHP, exportez les fichiers et la base de données. En SSH, une sauvegarde minimale peut ressembler à ceci :

wp db export "backup-before-php-upgrade-$(date +%F).sql"Langage du code : JavaScript (javascript)

Puis archivez les fichiers du site :

tar -czf "site-files-before-php-upgrade-$(date +%F).tar.gz" public_htmlLangage du code : JavaScript (javascript)

Adaptez évidemment le chemin public_html à votre serveur. Sur certains hébergements, le répertoire peut s’appeler htdocs, www, public ou web.

Si vous migrez aussi de serveur, vous pouvez suivre la méthode détaillée dans Migrer WordPress avec WP-CLI vers un nouveau serveur.

Étape 3 : scanner la syntaxe avec php-parallel-lint

php-parallel-lint reste très utile pour repérer rapidement les erreurs de syntaxe dans des milliers de fichiers PHP. Il ne remplace pas un audit complet, mais il donne un premier signal très rapide.

Créez un dossier d’outillage hors du site, par exemple dans votre répertoire personnel :

mkdir -p ~/wp-php-audit
cd ~/wp-php-audit

Installez ensuite l’outil avec Composer :

composer require --dev php-parallel-lint/php-parallel-lintLangage du code : JavaScript (javascript)

Scannez les plugins :

vendor/bin/parallel-lint /chemin/vers/wordpress/wp-content/plugins \
  --exclude vendor \
  --exclude node_modules

Scannez les thèmes :

vendor/bin/parallel-lint /chemin/vers/wordpress/wp-content/themes \
  --exclude vendor \
  --exclude node_modules

Et n’oubliez pas les mu-plugins :

vendor/bin/parallel-lint /chemin/vers/wordpress/wp-content/mu-plugins \
  --exclude vendor \
  --exclude node_modules

Si le dossier mu-plugins n’existe pas, la commande échouera simplement parce que le chemin est absent. Ce n’est pas un problème PHP, juste un dossier qui n’existe pas.

Ce test répond à une question précise : “ce code peut-il être parsé par cette version de PHP ?”. Il ne répond pas à la question : “ce code fonctionnera-t-il correctement avec WordPress, WooCommerce et mes données ?”. Pour cela, il faut aller plus loin.

Étape 4 : utiliser PHPCS avec PHPCompatibilityWP

Pour un vrai audit de compatibilité PHP, utilisez PHP_CodeSniffer avec PHPCompatibilityWP. Cette règle est pensée pour les projets WordPress et évite certains faux positifs liés aux fonctions polyfillées par WordPress.

Dans votre dossier d’audit, installez les dépendances :

composer require --dev \
  squizlabs/php_codesniffer \
  phpcompatibility/php-compatibility \
  phpcompatibility/phpcompatibility-wp \
  dealerdirect/phpcodesniffer-composer-installerLangage du code : JavaScript (javascript)

Vérifiez que PHPCS voit bien les standards disponibles :

vendor/bin/phpcs -i

Vous devriez voir PHPCompatibility et PHPCompatibilityWP dans la liste.

Pour tester la compatibilité avec PHP 8.4 et 8.5, lancez par exemple :

vendor/bin/phpcs \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.4-8.5 \
  --extensions=php \
  --ignore=*/vendor/*,*/node_modules/* \
  /chemin/vers/wordpress/wp-content/plugins \
  /chemin/vers/wordpress/wp-content/themes \
  /chemin/vers/wordpress/wp-content/mu-pluginsLangage du code : JavaScript (javascript)

Si vous voulez commencer plus prudemment avec PHP 8.3 ou 8.4, adaptez simplement la plage :

--runtime-set testVersion 8.3-8.4Langage du code : CSS (css)

Pour sauvegarder le rapport dans un fichier :

vendor/bin/phpcs \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.4-8.5 \
  --extensions=php \
  --ignore=*/vendor/*,*/node_modules/* \
  --report=full \
  /chemin/vers/wordpress/wp-content/plugins \
  /chemin/vers/wordpress/wp-content/themes \
  /chemin/vers/wordpress/wp-content/mu-plugins \
  > php-compatibility-report.txtLangage du code : JavaScript (javascript)

Si vous développez vos propres plugins ou thèmes, ajoutez aussi WordPress Coding Standards à votre workflow. J’ai détaillé la mise en place dans Valider votre projet VSCode avec PHP CodeSniffer et WordPress Coding Standards.

Étape 5 : tester les plugins installés avec WP-CLI

Avant de basculer PHP, commencez par faire l’inventaire des plugins :

wp plugin list --fields=name,status,version,update --format=tableLangage du code : PHP (php)

Listez aussi les thèmes :

wp theme list --fields=name,status,version,update --format=tableLangage du code : PHP (php)

Pour exporter un état complet avant intervention :

wp plugin list --format=json > plugins-before-php-upgrade.json
wp theme list --format=json > themes-before-php-upgrade.jsonLangage du code : PHP (php)

Si vous devez archiver les extensions avant migration, l’article Comment sauvegarder, archiver et installer par lots des extensions WordPress avec WP-CLI complète bien cette étape.

Étape 6 : ne pas oublier les snippets

Les snippets stockés dans la base de données sont le piège classique. Un scanner de fichiers ne les verra pas. Pourtant, ils peuvent contenir le code le plus fragile du site.

Vérifiez notamment :

les snippets ajoutés via Code Snippets ;
les snippets ajoutés dans un plugin maison ;
les mu-plugins créés à la main ;
les fonctions dans functions.php du thème enfant ;
les champs personnalisés qui exécutent du PHP ;
les intégrations anciennes avec WooCommerce, Gravity Forms, Contact Form 7 ou WPML.

Si vous avez beaucoup de plugins historiques, commencez par identifier les options en base qui leur appartiennent encore. L’article Identifiez les options de base de données liées à vos plugins WordPress peut aider à faire le ménage avant une migration technique.

Le plus lu : Optimiser les images JPG, PNG, WebP et AVIF sur un serveur Linux

Activer les logs sur le staging

Sur l’environnement de staging, activez les logs WordPress dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Langage du code : JavaScript (javascript)

Ensuite, testez le site et surveillez le fichier :

tail -f wp-content/debug.log

Sur un serveur avec PHP-FPM, consultez aussi les logs PHP et serveur web. Selon votre configuration, ils peuvent se trouver dans :

/var/log/php8.4-fpm.log
/var/log/php8.5-fpm.log
/var/log/nginx/error.log
/var/log/apache2/error.logLangage du code : JavaScript (javascript)

Adaptez les chemins à votre distribution et à votre panel d’hébergement.

Basculer le staging vers PHP 8.4 ou PHP 8.5

La bascule dépend de votre hébergeur. Sur un hébergement managé, vous utiliserez souvent un sélecteur PHP dans le panel. Sur un serveur dédié, vous pouvez avoir plusieurs pools PHP-FPM.

Sur Ubuntu, j’ai détaillé l’installation côté serveur dans ces deux guides :

Après la bascule, testez la version PHP réellement utilisée par WordPress avec Santé du site, pas seulement avec php -v. La CLI peut mentir par omission : elle vous donne sa version, pas forcément celle de PHP-FPM.

Checklist de test après bascule PHP

Sur le staging, testez au minimum :

la page d’accueil ;
les pages importantes ;
la recherche interne ;
les formulaires ;
l’envoi d’emails ;
le login WordPress ;
l’édition d’un article ;
l’upload d’un média ;
les tâches cron WordPress ;
les exports et imports ;
les pages avec shortcodes ;
les pages construites avec un builder ;
les endpoints REST ;
les appels AJAX ;
les logs PHP, Nginx, Apache et WordPress.

Pour WooCommerce, ajoutez :

la page boutique ;
les fiches produits ;
les variations ;
le panier ;
le tunnel de commande ;
les moyens de paiement ;
les emails de commande ;
les coupons ;
les taxes ;
les frais de livraison ;
les remboursements ;
les webhooks ;
les abonnements si WooCommerce Subscriptions est installé ;
les règles de prix dynamiques ;
les intégrations ERP, CRM, transporteurs ou facturation.

Si votre boutique utilise WooCommerce HPOS ou doit y passer, vérifiez aussi la compatibilité des extensions. J’ai publié un guide dédié : Rendre votre plugin WooCommerce compatible avec HPOS.

Erreurs fréquentes après passage à PHP 8

Voici les familles d’erreurs qui reviennent souvent pendant une migration PHP 8 :

Fatal error: Uncaught TypeError
Deprecated: Creation of dynamic property
Warning: Trying to access array offset on value of type bool
Warning: Undefined array key
Fatal error: Declaration of ... must be compatible with ...
Call to undefined function
Allowed memory size exhausted

Certaines erreurs sont anodines en staging. D’autres peuvent casser le checkout, l’admin ou l’API REST. Traitez donc d’abord les erreurs fatales, puis les avertissements récurrents liés aux plugins actifs.

Si vous voyez des erreurs du type Creating default object from empty value, l’article PHP : résoudre l’erreur “Creating default object from empty value” peut servir de point de départ.

Faut-il corriger, remplacer ou supprimer un plugin incompatible ?

Tout dépend du plugin et du risque métier.

Plugin maintenu : mettez-le à jour, puis retestez.
Plugin abandonné : remplacez-le avant la migration PHP.
Plugin maison : corrigez le code, ajoutez des tests et versionnez-le.
Plugin critique WooCommerce : testez chaque scénario métier avant production.
Plugin désactivé mais présent : supprimez-le si vous n’en avez plus besoin.

La migration PHP est souvent le bon moment pour réduire la dette technique. Moins de plugins, moins de code mort, moins de surprises. Étonnamment, ça marche mieux.

Procédure de bascule en production

Quand le staging est validé, préparez la production :

Planifiez une fenêtre de maintenance courte.
Faites une sauvegarde complète juste avant la bascule.
Désactivez les tâches lourdes ou imports planifiés.
Basculez la version PHP.
Purgez les caches serveur, objet, page et CDN.
Testez les parcours critiques.
Surveillez les logs pendant au moins quelques heures.

Le plus lu : Erreur HTTP 406 Not Acceptable : causes et solutions avec WordPress, Apache et ModSecurity

Pour auditer les performances après changement PHP, Auditer les problèmes de performance WordPress avec wp profile peut aider à repérer les hooks, plugins ou requêtes qui ralentissent le site.

Commandes utiles pour auditer rapidement un site WordPress

Voici une base pratique à adapter à votre serveur :

# Version PHP CLI.
php -v

# Informations WP-CLI.
wp --info

# Version WordPress.
wp core version

# Plugins installés.
wp plugin list --fields=name,status,version,update --format=table

# Thèmes installés.
wp theme list --fields=name,status,version,update --format=table

# Vérifier les checksums du core.
wp core verify-checksums

# Export base de données.
wp db export "backup-before-php-upgrade-$(date +%F).sql"

# Lire les erreurs WordPress.
tail -f wp-content/debug.logLangage du code : PHP (php)

Si vous gérez plusieurs sites sur un serveur, automatisez ces contrôles site par site. Mais gardez une règle simple : on scanne en masse, on corrige avec discernement.

Résumé rapide

WordPress recommande PHP 8.3 ou supérieur.
PHP 8.4 est aujourd’hui un excellent choix pour les sites bien maintenus.
PHP 8.5 convient aux sites à jour, testés et techniquement propres.
Le risque principal vient des plugins, thèmes, snippets et mu-plugins.
php-parallel-lint détecte les erreurs de syntaxe.
PHPCompatibilityWP détecte davantage d’incompatibilités PHP dans un contexte WordPress.
Un staging reste indispensable avant une bascule en production.
Les logs valent mieux que les suppositions.

Articles liés sur SkyMinds

Pour compléter l’audit et la migration PHP d’un site WordPress, ces articles peuvent vous aider :

FAQ

Quelle version PHP utiliser avec WordPress aujourd’hui ?

Pour un site WordPress maintenu, PHP 8.4 est un très bon choix. PHP 8.5 convient aussi si WordPress, les plugins, le thème et le code personnalisé sont à jour et testés. PHP 8.3 reste la base minimale recommandée.

WordPress est-il compatible avec PHP 8.5 ?

Oui, les versions récentes de WordPress documentent la compatibilité avec PHP 8.5. En revanche, cela ne garantit pas que tous vos plugins, thèmes et snippets personnalisés soient prêts.

php-parallel-lint suffit-il pour valider une migration PHP ?

Non. Il vérifie surtout la syntaxe PHP. Ajoutez PHPCS avec PHPCompatibilityWP, testez le site en staging, puis surveillez les logs WordPress, PHP et serveur après la bascule.

Faut-il tester les plugins désactivés ?

Oui, si vous comptez les réactiver plus tard. Sinon, supprimez-les. Un plugin désactivé mais abandonné n’apporte rien, sauf une future mauvaise surprise et un peu plus de désordre.

Pourquoi la version PHP en SSH diffère-t-elle de celle du site ?

Parce que PHP CLI et PHP-FPM peuvent utiliser deux binaires ou deux versions différentes. Vérifiez la version côté WordPress avec Santé du site, puis comparez avec php -v en ligne de commande.

Dois-je tester WooCommerce différemment ?

Oui. Une boutique WooCommerce exige des tests plus larges : panier, commande, paiement, emails, taxes, livraison, coupons, webhooks, abonnements et intégrations externes. Le checkout doit être validé avant toute bascule en production.

Sources

Report a typo

Facebook Tweet Pin LinkedIn