Deprecated: Creation of dynamic properties is deprecated in class-block-renderer.php on line 47. Ce message est apparu dans les journaux d’erreurs d’un serveur mutualisé, deux jours après une montée automatique vers PHP 8.2 proposée par l’hébergeur. Le site continuait de fonctionner visuellement, mais chaque affichage du bloc concerné générait cette ligne, noyant les journaux et alertant l’équipe de supervision qui surveille le volume d’avertissements PHP.
PHP 8.2, sorti en décembre 2022, introduit une série de dépréciations qui ne cassent rien immédiatement mais annoncent des suppressions futures. Pour un bloc dynamique construit autour d’une classe PHP de rendu, la dépréciation des propriétés dynamiques est de loin la plus fréquente à rencontrer.
Identifier la ligne responsable
La classe en cause suit un schéma courant chez les développeurs de blocs qui viennent du monde des shortcodes : une classe de rendu instanciée une fois, dans laquelle des propriétés sont assignées à la volée sans jamais être déclarées dans l’en-tête de la classe.
class Block_Renderer {
public function render( $attributes ) {
$this->title = $attributes['title'] ?? '';
$this->theme_color = get_theme_mod( 'accent_color' );
// ...
}
}
Avant PHP 8.2, assigner $this->title sans l’avoir déclarée dans la classe ne posait aucun problème visible : PHP créait silencieusement la propriété. Depuis PHP 8.2, ce comportement déclenche un avertissement de dépréciation à chaque exécution, et sera très probablement rendu fatal dans une version majeure ultérieure.
Corriger : déclarer ou utiliser un attribut
Deux corrections sont possibles selon le contexte. La première, la plus directe, consiste à déclarer explicitement chaque propriété utilisée par la classe :
class Block_Renderer {
public string $title = '';
public string $theme_color = '';
public function render( $attributes ) {
$this->title = $attributes['title'] ?? '';
$this->theme_color = get_theme_mod( 'accent_color' );
// ...
}
}
La seconde, utile lorsque la classe reçoit réellement des données dont la liste n’est pas connue à l’avance (par exemple un tableau d’attributs de bloc entièrement dynamique), consiste à ajouter l’attribut #[AllowDynamicProperties] au-dessus de la déclaration de classe :
#[AllowDynamicProperties]
class Block_Renderer {
// ...
}
Cette seconde option doit rester l’exception : elle désactive la protection offerte par PHP 8.2 plutôt que de corriger le problème de fond, et masque des fautes de frappe qui autrement resteraient invisibles (une propriété $this->titel mal orthographiée, par exemple, ne générerait plus aucun signal).
D’autres dépréciations à surveiller dans le même code
Un audit complet du bloc a permis de repérer deux autres points sensibles, moins visibles car ils ne se déclenchent que sur certaines entrées :
- L’utilisation de
${variable}pour l’interpolation de chaînes dans les gabarits PHP du bloc, syntaxe dépréciée au profit de{$variable}. - Un appel à
utf8_encode()pour normaliser un titre saisi par l’éditeur, fonction également dépréciée en PHP 8.2 au profit de l’extensioniconvoumbstring. - Des paramètres nullable implicites dans les signatures de fonctions du plugin (
function foo( string $bar = null )), qui deviendront une dépréciation supplémentaire à corriger lors d’une future montée de version.
Mettre en place une détection avant la mise en production
Le vrai problème n’était pas la correction elle-même, rapide une fois identifiée, mais le fait qu’elle n’ait été découverte qu’en production. Une commande simple, exécutée en environnement de recette avec l’affichage des dépréciations activé, aurait permis de la détecter avant la bascule :
WP_DEBUG=true wp eval-file test-rendu-bloc.php --allow-root
Sur ce projet, l’équipe a ajouté une étape de vérification automatisée dans son pipeline de déploiement, qui exécute la suite de tests du plugin sur une image PHP 8.2 avant chaque mise en production, avec error_reporting( E_ALL ) activé et un échec du pipeline si un avertissement de dépréciation apparaît dans la sortie.
Sur les projets que je maintiens, je préfère toujours corriger la dépréciation dès son apparition plutôt que de la neutraliser avec un attribut : trois mois plus tard, personne ne se souvient pourquoi
#[AllowDynamicProperties]a été ajouté à telle classe.
En résumé
La dépréciation des propriétés dynamiques ne casse rien du jour au lendemain, mais elle est un signal fiable de code écrit avant l’existence de types stricts en PHP. Pour un bloc dynamique, la classe de rendu est le premier endroit à vérifier : il suffit généralement d’ajouter les déclarations de propriétés manquantes pour faire disparaître l’avertissement, sans toucher à la logique métier.
