Symptôme. Après la mise à jour d’un serveur mutualisé vers PHP 8.2, une extension de gestion d’événements maison s’est mise à remplir le journal d’erreurs de milliers de lignes du type Deprecated: Creation of dynamic property Mon_Extension\Evenement::$lieu_id is deprecated. Le site continuait à fonctionner — une dépréciation n’est pas une erreur fatale — mais le volume de journalisation faisait exploser l’espace disque alloué au log, et masquait les vraies erreurs au milieu du bruit.
Diagnostic : comprendre ce que PHP 8.2 change
Avant PHP 8.2, il était parfaitement toléré d’assigner une propriété à un objet sans l’avoir déclarée dans la classe :
class Evenement {
public $titre;
}
$e = new Evenement();
$e->titre = 'Conférence WordPress';
$e->lieu_id = 42; // propriété jamais déclarée dans la classe
PHP créait alors silencieusement une propriété dynamique sur l’instance. À partir de PHP 8.2, ce comportement déclenche un avis de dépréciation, dans la perspective d’une suppression totale dans une future version majeure de PHP. L’objectif du langage est de renforcer la fiabilité du typage : une classe qui déclare explicitement ses propriétés est plus facile à analyser statiquement, plus sûre à refactoriser, et évite des fautes de frappe silencieuses (assigner $e->lieu_Id par erreur crée une nouvelle propriété au lieu de signaler une faute).
Repérer les classes concernées
Avec une base de code de taille modeste, une relecture manuelle des classes suffit. Sur une extension plus large, on active la journalisation des dépréciations et on la laisse tourner sur un environnement de test avec un scénario d’usage complet :
// wp-config.php, en environnement de test uniquement
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
error_reporting( E_ALL );
Chaque ligne du journal correspondant à une propriété dynamique indique précisément la classe et le nom de propriété fautifs, ce qui permet de dresser une liste exhaustive sans deviner.
Correctif : trois approches selon le contexte
1. Déclarer explicitement la propriété (la vraie correction)
C’est la correction à privilégier chaque fois que la classe vous appartient et que la propriété est utilisée de façon prévisible :
class Evenement {
public string $titre = '';
public ?int $lieu_id = null;
public array $participants = array();
}
Cette approche a un bénéfice collatéral appréciable : elle documente la classe elle-même, et permet à un éditeur de code de proposer l’autocomplétion sur ces propriétés, ce qui n’était pas le cas avec des propriétés créées dynamiquement.
2. Étendre stdClass ou utiliser l’attribut AllowDynamicProperties
Quand une classe reçoit légitimement des propriétés variables selon le contexte (par exemple un objet qui reflète une structure de données externe changeante, comme une réponse d’API dont les champs varient), PHP 8.2 introduit l’attribut #[AllowDynamicProperties] pour désactiver explicitement la dépréciation sur une classe précise :
#[AllowDynamicProperties]
class Reponse_Api_Externe {
public function __construct( array $donnees ) {
foreach ( $donnees as $cle => $valeur ) {
$this->$cle = $valeur;
}
}
}
Cet attribut est un compromis assumé, pas une solution à généraliser : il désactive une protection utile. Il convient uniquement quand la nature dynamique des propriétés est un choix de conception réel, pas une négligence à corriger.
3. Utiliser un tableau ou stdClass plutôt qu’un objet typé
Pour des structures véritablement libres, souvent il est plus honnête de ne pas utiliser une classe dédiée du tout, et de manipuler un simple tableau associatif ou un stdClass — cette dernière classe native de PHP reste, elle, exemptée de la dépréciation, précisément parce qu’elle n’a jamais eu vocation à déclarer de propriétés fixes.
Le cas particulier des classes héritant du cœur WordPress
Certaines classes du cœur WordPress, comme WP_Widget ou d’anciennes classes de compatibilité, ont historiquement toléré des propriétés dynamiques ajoutées par des extensions tierces. Si votre extension étend une telle classe et lui ajoute des propriétés non déclarées dans la classe parente, la dépréciation s’applique à l’instance de votre sous-classe, pas à la classe parente elle-même. La correction reste la même : déclarer la propriété dans votre sous-classe.
class Mon_Widget extends WP_Widget {
protected ?array $options_cache = null; // déclaration explicite, corrige la dépréciation
}
Vérifier la correction
- Relancer les mêmes scénarios de test avec
WP_DEBUG_LOGactif et confirmer la disparition des lignes de dépréciation. - Passer un analyseur statique comme PHPStan sur le code, avec un niveau suffisant pour détecter les accès à des propriétés non déclarées — un bon complément à la relecture manuelle.
- Vérifier que les correctifs n’ont pas changé le typage attendu ailleurs dans le code : déclarer une propriété
?intqui recevait parfois une chaîne peut révéler un bug préexistant masqué par le typage faible.
Un réflexe qu’on applique désormais sur toute nouvelle classe : déclarer systématiquement chaque propriété utilisée, même à
nullpar défaut. Le coût est nul à l’écriture, et ça évite ce genre de rattrapage en urgence à chaque montée de version PHP.
Prévention
La dépréciation des propriétés dynamiques ne cassera rien en PHP 8.2 lui-même — c’est un avertissement, pas une erreur bloquante — mais elle annonce une suppression future. Corriger dès maintenant évite un rattrapage plus douloureux le jour où une future version majeure de PHP transformera cet avis en erreur fatale, un jour qu’il vaut mieux anticiper que subir.
