PHP 8.0 sort le 26 novembre 2020. Six mois plus tard, une partie non négligeable des hébergements mutualisés grand public continue de proposer PHP 7.2 comme version par défaut, et n’affiche PHP 8.0 qu’en version « bêta » dans le tableau de bord, quand elle est proposée du tout. Pour un développeur qui gère plusieurs sites WordPress chez ces hébergeurs, ce décalage devient un vrai sujet de planification.
Ce n’est pas tant l’absence immédiate de PHP 8.0 qui pose problème : WordPress fonctionne encore correctement sur des versions antérieures activement maintenues. Le vrai risque se situe dans l’anticipation. Un hébergeur qui tarde structurellement à proposer les nouvelles versions majeures indique, indirectement, une politique de mise à jour peu réactive, qui se répétera lors des prochaines transitions.
Ce que change réellement PHP 8.0, au-delà des nouveautés annoncées
PHP 8.0 introduit plusieurs changements de comportement qui peuvent casser du code fonctionnant sans erreur sous PHP 7.x. Le typage plus strict des arguments de fonctions internes, la suppression de certaines fonctions dépréciées depuis longtemps, et un traitement plus rigoureux des erreurs autrefois silencieuses figurent parmi les points qui touchent le plus directement les thèmes et extensions WordPress un peu anciens.
- Les erreurs de type
Warningdeviennent parfois desTypeErrorbloquants - La comparaison entre chaînes de caractères et nombres change de comportement dans certains cas
- Les fonctions internes dépréciées de longue date, comme certaines fonctions liées aux tableaux, sont retirées
Un exemple concret rencontré sur un thème ancien
Sur un site testé en environnement de recette sous PHP 8.0, un thème datant de plusieurs années générait une erreur fatale à l’activation, provoquée par un appel de fonction avec un nombre d’arguments incorrect, auparavant simplement ignoré :
PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function
theme_get_option(), 1 passed and exactly 2 expected in
/wp-content/themes/exemple-theme/functions.php:142
Sous PHP 7.4, cet appel générait simplement un avertissement, sans interrompre l’exécution. Sous PHP 8.0, il s’agit désormais d’une erreur fatale qui bloque entièrement l’affichage de la page concernée.
Pourquoi certains hébergeurs tardent à proposer les nouvelles versions
Un hébergeur mutualisé qui sert un très grand nombre de clients hérite mécaniquement d’un parc de sites hétérogène, dont une partie repose sur du code ancien, parfois non maintenu. Proposer trop rapidement une nouvelle version majeure de PHP par défaut risquerait de casser des sites clients existants, d’où une tendance à repousser la mise à disposition, voire à la limiter à une activation manuelle et non documentée.
Un hébergeur qui expose clairement, sur une page dédiée, sa feuille de route de support des versions de PHP donne une indication fiable sur son sérieux technique. L’absence totale d’information à ce sujet doit, à l’inverse, alerter.
Comment un développeur peut anticiper ce décalage
Plusieurs vérifications simples permettent d’anticiper ce type de situation avant qu’elle ne devienne bloquante pour un client :
- Vérifier, dans le tableau de bord de l’hébergeur, la liste des versions de PHP réellement disponibles, au-delà de la valeur par défaut
- Tester le site en environnement de recette sur la nouvelle version avant toute bascule en production
- Documenter, pour chaque client, la date de fin de vie de la version de PHP actuellement utilisée
Ce que ce décalage impose comme discipline
Sur les sites suivis par cette équipe, la règle retenue est de tester systématiquement la version de PHP suivante en environnement de recette dès sa sortie stable, indépendamment de la disponibilité chez l’hébergeur du client. Cette anticipation permet de corriger les incompatibilités de code en amont, plutôt que de découvrir un blocage au moment où l’hébergeur impose finalement la bascule, parfois avec un préavis très court.
Prévoir la discussion avec le client concerné
Au-delà de l’aspect purement technique, ce décalage entre la sortie d’une version majeure et sa disponibilité réelle chez un hébergeur mutualisé mérite d’être expliqué au client, en particulier lorsqu’il s’interroge sur la lenteur de son site ou sur des messages d’erreur inhabituels apparus après une mise à jour d’extension. Deux options concrètes se présentent alors : patienter jusqu’à ce que l’hébergeur propose enfin la version corrigée, ou envisager une migration vers un hébergement dont la feuille de route de support de PHP est plus explicite et plus réactive.
- Expliquer clairement au client que le retard vient de l’hébergeur, pas du code du site lui-même
- Documenter la version de PHP minimale requise par chaque extension installée
- Prévoir, dans le devis de maintenance, un budget dédié aux tests de compatibilité lors de chaque nouvelle version majeure de PHP
