PHP 8.2, sorti en décembre 2022, a introduit une dépréciation qui touche silencieusement une bonne partie de l’écosystème WordPress plus ancien : la création de propriétés dynamiques sur une classe, c’est-à-dire assigner une valeur à une propriété d’objet qui n’a jamais été déclarée explicitement dans la classe. Ce style d’écriture, très répandu en PHP jusqu’à récemment, ne provoque en 8.2 qu’un avertissement de dépréciation, sans casser le site. Mais il annonce un changement de comportement plus strict dans une version PHP future, ce qui en fait un signal à traiter tôt plutôt qu’à ignorer jusqu’à la prochaine montée de version majeure.
Ce billet ne traite pas de PHP 8.1 et WPML, déjà couvert précédemment pour une extension et une version différentes : il porte spécifiquement sur ce que Polylang déclenche comme avertissements sur PHP 8.2, et sur la manière de les traiter avant qu’un changement de version PHP suivant ne les transforme en erreurs bloquantes.
Ce que change concrètement PHP 8.2
Avant PHP 8.2, écrire $this->une_propriete_jamais_declaree = 'valeur'; dans une classe qui ne déclare pas $une_propriete_jamais_declaree fonctionnait silencieusement : PHP créait la propriété à la volée. Depuis PHP 8.2, ce comportement déclenche un avertissement de dépréciation (Deprecated: Creation of dynamic property ... is deprecated), sauf si la classe implémente explicitement l’attribut #[AllowDynamicProperties] ou étend une classe qui l’implémente déjà. Certaines classes internes de Polylang, écrites avant que cette pratique ne soit considérée comme un problème de fiabilité du code, créent encore des propriétés de cette manière dans certaines versions de l’extension.
Comment ces avertissements se manifestent en pratique
Sur un site de recette basculé en PHP 8.2 avec le débogage activé, les logs font apparaître des lignes de ce type, généralement liées à des classes de gestion des options ou des modèles de traduction internes à Polylang :
Deprecated: Creation of dynamic property PLL_Model::$options is deprecated in
/wp-content/plugins/polylang/include/model.php on line 142
Ces avertissements n’interrompent rien visuellement pour un visiteur du site, mais ils polluent les logs d’erreurs, ce qui rend plus difficile le repérage d’un vrai problème parmi le bruit, et ils indiquent un code qui devra être adapté avant qu’une future version PHP ne rende ce comportement réellement bloquant.
Ce qu’il faut faire, dans l’ordre
Comme pour toute dépréciation liée à une extension tierce largement maintenue, la première action reste la mise à jour vers la dernière version stable de Polylang : les éditeurs de l’extension corrigent progressivement ces avertissements de compatibilité PHP au fil de leurs versions, et une mise à jour simple élimine souvent la majorité des occurrences sans aucune intervention de code personnalisé.
Si des avertissements persistent après mise à jour, notamment sur des extensions additionnelles de l’écosystème Polylang moins activement maintenues, une solution de contournement temporaire consiste à faire taire spécifiquement ce type d’avertissement pour ce fichier précis, sans désactiver globalement l’affichage des erreurs sur le reste du site, via un gestionnaire d’erreurs ciblé :
set_error_handler( function( $errno, $errstr, $errfile ) {
if ( str_contains( $errfile, 'polylang' ) && str_contains( $errstr, 'dynamic property' ) ) {
return true; // avertissement absorbé, mais uniquement pour ce cas précis
}
return false; // laisse PHP gérer normalement tous les autres cas
}, E_DEPRECATED );
Cette solution reste un pansement, pas une correction : elle masque le symptôme dans les logs pour ne pas noyer les vrais signaux, mais elle ne prépare en rien le code à la version PHP suivante, qui pourrait transformer cet avertissement en erreur fatale.
Anticiper la version PHP suivante
Le vrai travail de fond, à programmer dans un cycle de maintenance plutôt que dans l’urgence, consiste à vérifier régulièrement le changelog de Polylang pour repérer les mentions explicites de compatibilité PHP 8.2 et au-delà, et à planifier la montée de version de l’extension en parallèle de toute montée de version PHP prévue avec l’hébergeur, jamais après.
Le cas des extensions tierces qui étendent Polylang
Un cas plus délicat concerne les extensions tierces, parfois développées en interne par une agence, qui étendent des classes de Polylang pour ajouter un comportement personnalisé. Ces extensions héritent souvent du même défaut de propriétés dynamiques si elles ont été écrites en suivant le style de code de Polylang lui-même. Un audit de ces extensions internes, avant toute montée de version PHP, permet d’éviter de découvrir le problème seulement après la mise en production.
- Mettre à jour Polylang vers sa dernière version stable avant toute autre action
- Ne masquer les avertissements résiduels que de façon ciblée et documentée, jamais globalement
- Vérifier le changelog de l’extension à chaque montée de version PHP prévue avec l’hébergeur
- Auditer les extensions internes qui étendent des classes de Polylang pour le même défaut
En résumé
La dépréciation des propriétés dynamiques introduite par PHP 8.2 ne casse rien immédiatement sur un site utilisant Polylang, ce qui en fait précisément le genre de signal que les équipes techniques négligent le plus facilement. Traiter ces avertissements par une mise à jour régulière de l’extension, plutôt que par un silence prolongé, évite un chantier correctif bien plus lourd le jour où une version PHP future rendra ce comportement réellement bloquant.
