# PHP 8.4 : les propriétés implicitement nullable qui cassent un thème > En testant un thème hérité sur la première bêta de PHP 8.4, un avertissement de dépréciation sur des propriétés promues depuis un constructeur, typées mais non explicitement nullables. Diagnostic et correctif. - Auteur : WordPress Développement - Publié le : 2024-08-12 - Mis à jour le : 2026-09-30 - Catégorie : Thèmes - URL : https://www.wpmoderne.fr/themes/php84-proprietes-implicitement-nullable-theme/ ## L’essentiel - PHP 8.4 déprécie la nullabilité implicite d'un paramètre typé avec une valeur par défaut null - Une propriété promue depuis un constructeur hérite exactement du même typage que son paramètre - Le correctif consiste à ajouter explicitement le préfixe ? au type `Deprecated: Mon_Theme_Reglages::__construct(): Implicitly marking parameter $option as nullable is deprecated, the explicit nullable type must be used instead in wp-content/themes/mon-theme/inc/class-reglages.php on line 18`. Ce message, obtenu en testant un thème hérité de six ans sur une version alpha de PHP 8.4, alors que la sortie stable est encore attendue pour la fin d'année, n'empêche rien de fonctionner dans l'immédiat — mais il annonce un changement de comportement que PHP appliquera plus strictement dans une version future. Ce diagnostic couvre précisément ce type d'avertissement de dépréciation appliqué aux propriétés d'objet promues depuis un constructeur ; il ne traite pas les autres dépréciations introduites par PHP 8.4 ni la migration des extensions tierces installées sur le même site. ## Ce que PHP 8.4 change concrètement En PHP, un paramètre typé avec une valeur par défaut `null` était historiquement considéré comme implicitement « nullable », même sans le préfixe `?` devant le type. Cette tolérance, héritée des débuts du typage des paramètres en PHP 7, est désormais dépréciée : PHP 8.4 signale chaque cas où un développeur s'appuie sur cette nullabilité implicite plutôt que de la déclarer explicitement. Or, depuis PHP 8.0, un paramètre de constructeur peut être « promu » directement en propriété de classe grâce à la promotion de propriétés — ce qui signifie que le même typage implicite, appliqué à un paramètre de constructeur promu, devient le typage d'une véritable propriété d'objet. ``` // Avant : promotion de propriété avec nullabilité implicite, dépréciée en PHP 8.4 class Mon_Theme_Reglages { public function __construct( private string $option = null, private int $priorite = null ) {} } // Après : nullabilité explicite sur les propriétés promues class Mon_Theme_Reglages { public function __construct( private ?string $option = null, private ?int $priorite = null ) {} } ``` La différence tient à un seul caractère par propriété, mais son absence sur un thème ancien, écrit à une époque où la promotion de propriétés commençait tout juste à se répandre dans les habitudes de codage orienté objet, peut se répéter des dizaines de fois dans les classes de configuration d'un thème. ## Où ces occurrences se sont concentrées sur ce thème Sur le thème audité, trente-quatre occurrences de cet avertissement sont apparues, mais concentrées presque entièrement dans deux classes : `Mon_Theme_Reglages`, qui centralisait les réglages du thème via des propriétés promues depuis son constructeur, et `Mon_Theme_Widget_Config`, où chaque widget personnalisé déclarait sa configuration selon le même schéma de typage. > L'essentiel à retenir : PHP 8.4 déprécie la nullabilité implicite d'un paramètre typé avec une valeur par défaut null ; Une propriété promue depuis un constructeur hérite exactement du même typage que son paramètre ; Le correctif consiste à ajouter explicitement le préfixe ? au type ## Diagnostic : lister toutes les occurrences avant de corriger Plutôt que de corriger fichier par fichier au fil des avertissements affichés, un passage systématique permet de cartographier l'ensemble du problème en une seule fois, avec une recherche par expression régulière ciblant les propriétés promues (précédées de `private`, `public` ou `protected` dans la signature d'un constructeur) typées et suivies d'une valeur par défaut `null` : ``` grep -rnE '(private|public|protected)\s+(string|int|float|bool|array|callable)\s+\$[a-zA-Z_]+\s*=\s*null' \ wp-content/themes/mon-theme/ --include="*.php" ``` Cette commande ne capture pas tous les cas (elle ignore par exemple les types de classes personnalisées ou les unions de types), mais elle couvre la majorité des occurrences réelles sur un thème orienté objet, avant un passage plus fin avec un analyseur statique comme PHPStan ou PHP_CodeSniffer configuré avec les règles de compatibilité PHP 8.4. ## Correctif propriété par propriété Le correctif consiste à ajouter le préfixe `?` devant chaque type de propriété promue concerné, sans changer la logique de la classe : ``` // inc/class-widget-config.php, avant correctif class Mon_Theme_Widget_Config { public function __construct( private string $couleur_accent = null, private array $options_avancees = null ) {} public function get_couleur_accent(): string { return $this->couleur_accent ?? '#0073aa'; } } // Après correctif class Mon_Theme_Widget_Config { public function __construct( private ?string $couleur_accent = null, private ?array $options_avancees = null ) {} public function get_couleur_accent(): string { return $this->couleur_accent ?? '#0073aa'; } } ``` Un script de remplacement automatique par expression régulière peut accélérer ce travail répétitif sur les cas les plus simples, mais chaque remplacement mérite une relecture rapide : certaines propriétés promues, bien que typées avec une valeur par défaut `null` en apparence identique, référencent en réalité une classe personnalisée du thème plutôt qu'un type scalaire, et méritent une vérification individuelle avant application automatique du correctif. ### Pourquoi corriger maintenant plutôt que d'ignorer l'avertissement Un avertissement de dépréciation n'interrompt jamais l'exécution du thème dans l'immédiat : le site continue de fonctionner normalement, avec ou sans correctif. Mais l'historique des versions de PHP montre une constante : ce qui est déprécié dans une version finit, quelques versions majeures plus tard, par devenir une erreur fatale bloquante. Corriger maintenant, pendant que le thème est encore ouvert et que le contexte est frais, coûte nettement moins cher que de le faire dans l'urgence, plusieurs années plus tard, sur un thème dont plus personne ne maîtrise les détails. > Un avertissement de dépréciation est un message du futur adressé au présent : l'ignorer ne le fait pas disparaître, il ne fait que repousser le jour où quelqu'un devra s'en occuper dans l'urgence. ## En résumé PHP 8.4 rend explicite une nuance de typage jusqu'ici tolérée implicitement, y compris pour les propriétés promues depuis un constructeur, ce qui fait remonter, sur un thème orienté objet, des dizaines d'avertissements bénins mais révélateurs d'habitudes de code datées. Le correctif — ajouter un simple `?` devant chaque type de propriété concerné — est mécanique une fois les occurrences cartographiées, et vaut la peine d'être traité avant la sortie stable de cette version, plutôt qu'après.