Sorti en novembre 2022, PHP 8.2 a introduit une dépréciation qui a mis un an à se faire vraiment sentir sur le terrain : la création de propriétés dynamiques sur un objet, une pratique très répandue dans du code de traduction ancien, écrit avant que la programmation orientée objet stricte ne devienne la norme dans l’écosystème WordPress.
Ce sujet ne traite pas de WPML, déjà largement couvert par ailleurs sur ce point précis : il se concentre sur des extensions de traduction plus modestes, souvent développées en interne par des agences pour des besoins spécifiques, qui ont commencé à afficher des avertissements de dépréciation en nombre sur des sites récemment passés à PHP 8.2.
La nouveauté en cause : la fin des propriétés dynamiques
Avant PHP 8.2, il était possible d’assigner une propriété à un objet sans l’avoir déclarée dans la classe, une pratique courante et sans conséquence visible pendant des années :
class GestionnaireTraduction {
public function __construct() {
$this->langues_actives = array( 'fr', 'en', 'de' );
}
}
Dans cet exemple, la propriété langues_actives n’existe dans aucune déclaration de classe, mais PHP l’acceptait silencieusement avant la version 8.2. Depuis cette version, ce comportement déclenche un avertissement de dépréciation (Deprecated: Creation of dynamic property is deprecated), sans casser immédiatement le fonctionnement du site, mais en polluant les journaux d’erreurs et en annonçant une suppression complète de la fonctionnalité dans une version future de PHP.
Nouveautés classées par impact réel
Impact fort : les extensions de traduction internes anciennes
Sur plusieurs sites audités un an après la sortie de PHP 8.2, ce sont systématiquement les extensions de traduction développées en interne, il y a plusieurs années, par des équipes ayant depuis quitté l’entreprise, qui concentraient le plus grand nombre d’avertissements. Ces extensions stockaient souvent la configuration de langue directement comme propriétés dynamiques d’un objet de configuration global, sans jamais déclarer ces propriétés explicitement.
- Extensions de traduction internes non maintenues activement : impact fort
- Extensions publiées sur le dépôt officiel de WordPress.org : impact généralement faible, la plupart ayant déjà corrigé ce point
- Thèmes anciens avec logique de traduction intégrée au thème lui-même : impact variable selon l’ancienneté du code
Impact modéré : le solutionnement par attribut
PHP 8.2 introduit l’attribut #[AllowDynamicProperties], qui permet de désactiver la dépréciation pour une classe précise, sans réécrire tout le code existant :
#[AllowDynamicProperties]
class GestionnaireTraduction {
public function __construct() {
$this->langues_actives = array( 'fr', 'en', 'de' );
}
}
Cette solution, rapide à appliquer, ne constitue qu’un sursis : elle supprime l’avertissement sans corriger le problème de fond, à savoir l’absence de déclaration explicite des propriétés de la classe, ce qui reste une mauvaise pratique indépendamment de la version de PHP utilisée.
Impact faible : la correction propre par déclaration explicite
La correction durable consiste à déclarer explicitement chaque propriété dans la classe, une démarche plus longue mais qui améliore aussi la lisibilité du code et permet à un éditeur de code moderne de proposer une meilleure autocomplétion :
class GestionnaireTraduction {
public array $langues_actives = array();
public function __construct() {
$this->langues_actives = array( 'fr', 'en', 'de' );
}
}
Comment repérer ces cas sur un site existant
Avant toute mise à jour de PHP sur un site multilingue ancien, activer temporairement l’affichage des avertissements de dépréciation en environnement de préproduction, puis parcourir méthodiquement chaque écran d’administration lié à la traduction, permet de faire remonter ces avertissements avant qu’ils n’atteignent la production.
| Version PHP | Comportement sur propriété dynamique |
|---|---|
| 8.1 et antérieures | Acceptée silencieusement |
| 8.2 | Avertissement de dépréciation, fonctionnement conservé |
| Versions futures annoncées | Suppression complète prévue à terme |
Ce qu’il faut vérifier avant de mettre à jour
Un an après la sortie de PHP 8.2, cette dépréciation continue de surprendre des équipes qui pensaient leur code de traduction stable depuis des années. La bonne pratique reste double : appliquer #[AllowDynamicProperties] comme mesure d’urgence sur du code impossible à réécrire rapidement, puis planifier une refonte propre avec déclaration explicite des propriétés, avant que les versions futures de PHP ne suppriment purement et simplement le comportement de repli actuel.
