PHP 8.4 est disponible depuis novembre 2024, et son lot de nouveautés — au premier rang desquelles les property hooks — soulève une question très concrète pour qui gère un parc d’extensions WordPress : qu’est-ce qui va réellement casser à la bascule ? La réponse tient moins aux fonctionnalités ajoutées qu’aux dépréciations qui les accompagnent, souvent moins documentées.
Sur les parcs que nous avons audités ce mois-ci, la majorité des soucis ne viennent pas des property hooks eux-mêmes, quasiment jamais utilisés dans du code WordPress existant, mais de changements plus discrets sur le typage implicite. Voici le recensement des points qui cassent réellement, pour préparer une montée de version sans mauvaise surprise, sans revenir sur la migration vers PHP 8.3 déjà couverte précédemment.
Les property hooks, une fonctionnalité neuve qui ne casse rien par défaut
Les property hooks permettent d’attacher un comportement get et set directement à une propriété de classe, sans passer par des méthodes magiques comme __get ou __set. C’est une nouveauté purement additive : aucun code WordPress existant n’en dépendait avant PHP 8.4, puisque la syntaxe n’existait pas.
class Produit {
public string $nom {
get => ucfirst($this->nom);
set(string $valeur) {
$this->nom = trim($valeur);
}
}
}
Le seul point de vigilance concerne les extensions qui définissent des propriétés dont le nom entre en collision avec un mot réservé du nouveau système de hooks, ce qui reste rare en pratique sur le code WordPress que nous avons inspecté.
La vraie source de casse : les types implicitement nullable
PHP 8.4 déprécie officiellement la déclaration implicite d’un paramètre nullable via une valeur par défaut à null sans annotation explicite ?type. C’est un pattern extrêmement courant dans les extensions WordPress plus anciennes.
// Déprécié en PHP 8.4 : nullable implicite
function formater_prix(int $montant = null) {
return $montant === null ? '' : number_format($montant, 2);
}
// Correct
function formater_prix(?int $montant = null) {
return $montant === null ? '' : number_format($montant, 2);
}
Ce changement génère un avertissement de dépréciation, pas une erreur fatale immédiate, mais les avertissements empilés finissent par polluer les journaux au point de masquer de vraies erreurs. Sur une extension premium de gestion de formulaires que nous avons testée, six avertissements distincts de ce type sont apparus dès l’activation sur un environnement PHP 8.4.
Recenser les usages avant de basculer le parc
Plutôt que de basculer un serveur de production et de découvrir les avertissements en direct, un recensement préalable en environnement de test permet de prioriser les corrections.
- Activer
display_errorseterror_reporting(E_ALL)sur un environnement de staging isolé - Faire naviguer un jeu de tests couvrant les fonctionnalités principales de chaque extension active
- Collecter les messages de dépréciation dans un fichier de log dédié plutôt que dans la sortie standard
- Prioriser les extensions générant le plus d’avertissements, souvent aussi les moins maintenues
Le cas des extensions tierces non maintenues
Le point le plus délicat d’une montée de version ne concerne jamais le cœur de WordPress, généralement réactif sur la compatibilité PHP, mais les extensions tierces abandonnées ou peu maintenues. Une extension sans mise à jour depuis deux ans a de fortes chances de contenir des patterns dépréciés qui ne seront jamais corrigés par son auteur.
Sur un parc client, nous documentons systématiquement, extension par extension, la dernière date de mise à jour connue avant toute montée de version majeure de PHP : c’est le meilleur indicateur du risque réel, bien avant le contenu du changelog.
Planifier la bascule sans interrompre le parc
Pour un parc de plusieurs dizaines de sites, la bascule vers PHP 8.4 se planifie par vagues : d’abord les sites les plus simples et les mieux maintenus, puis progressivement les sites plus complexes, avec un environnement de rollback prêt en cas d’avertissement bloquant transformé en erreur fatale.
| Type de site | Ordre de bascule recommandé |
|---|---|
| Sites vitrines, peu d’extensions | Première vague |
| Sites e-commerce, extensions premium à jour | Deuxième vague |
| Sites avec extensions non maintenues | Dernière vague, après correction ou remplacement |
Pour aller plus loin
PHP 8.4 n’introduit pas de rupture majeure pour un parc WordPress bien tenu, mais il révèle sans pitié les extensions négligées. Le recensement des avertissements de dépréciation en amont, extension par extension, reste la seule méthode fiable pour anticiper les corrections plutôt que de les découvrir en production après la bascule.
