PHP 8.4 côté serveur d’un bloc dynamique : ce qui casse après la montée de version

Fatal error: Cannot assign null to property Catalogue\RenduFiche::$sousTitre of type string. Cette erreur, absente en PHP 8.3, apparaît brutalement après une montée de version PHP 8.4 sur un bloc dynamique de fiche produit, uniquement sur les fiches où le champ « sous-titre » n’a jamais été renseigné par l’éditeur.

Ce cas concerne exclusivement cette erreur précise, liée au rendu serveur d’un bloc dynamique orienté objet. Il ne couvre pas les autres dépréciations introduites par PHP 8.4 ni la migration générale des extensions tierces du projet.

Symptôme

Le bloc catalogue/fiche-produit utilise, côté PHP, une petite classe de valeur pour structurer les données transmises au template de rendu, plutôt qu’un tableau associatif brut. Depuis la montée vers PHP 8.4, l’affichage de toute fiche sans sous-titre renseigné provoque une erreur fatale, remplaçant tout le contenu de la page par l’écran d’erreur PHP, visible des visiteurs si WP_DEBUG_DISPLAY traîne encore activé.

Diagnostic

La classe de rendu du bloc déclare ses propriétés avec un type strict, sans valeur par défaut ni indication de nullabilité explicite :

class RenduFiche {
    public string $titre;
    public string $sousTitre;
    public float  $prix;

    public function __construct( array $attributs ) {
        $this->titre     = $attributs['titre'] ?? '';
        $this->sousTitre = $attributs['sousTitre'] ?? null;
        $this->prix      = (float) ( $attributs['prix'] ?? 0 );
    }
}

Jusqu’à PHP 8.3, assigner null à une propriété typée string déclenchait déjà une erreur en mode strict, mais certains contextes silencieux (notamment via des accesseurs magiques ou des frameworks de compatibilité) masquaient parfois le problème. PHP 8.4 a durci plusieurs comportements autour du typage des propriétés, rendant cette assignation systématiquement fatale dès qu’elle se produit, sans exception cachée.

Correctif

Deux corrections sont possibles selon l’intention réelle du champ. Si le sous-titre peut légitimement être absent, le type doit devenir explicitement nullable :

class RenduFiche {
    public string  $titre;
    public ?string $sousTitre;
    public float   $prix;

    public function __construct( array $attributs ) {
        $this->titre     = $attributs['titre'] ?? '';
        $this->sousTitre = $attributs['sousTitre'] ?? null;
        $this->prix      = (float) ( $attributs['prix'] ?? 0 );
    }
}

Si, à l’inverse, un sous-titre vide doit toujours être traité comme une chaîne vide plutôt que comme une absence de valeur, la correction porte plutôt sur la valeur par défaut, sans toucher au type :

$this->sousTitre = $attributs['sousTitre'] ?? '';

Pourquoi le second correctif est souvent préférable

Sur ce bloc précis, le template de rendu appelait strtoupper( $rendu->sousTitre ) pour l’affichage en majuscules. Rendre la propriété nullable sans adapter le template aurait simplement déplacé l’erreur : strtoupper( null ) génère lui aussi une dépréciation en PHP 8.1 et plus, devenue plus stricte au fil des versions. Le choix d’une chaîne vide par défaut a évité une cascade de correctifs en aval.

• Distinguer une valeur réellement absente (nullable légitime) d’une valeur vide par convention métier.
• Vérifier chaque usage en aval de la propriété avant de choisir entre ?string et une valeur par défaut vide.
• Auditer les classes de valeur du registre de blocs avant toute montée de version PHP majeure.

Prévention

Ce type d’erreur touche spécifiquement les blocs qui utilisent des classes orientées objet pour structurer leurs données de rendu, une pratique de plus en plus courante sur les registres de blocs volumineux pour remplacer les tableaux associatifs peu typés. Un script de recette exécutant chaque bloc avec des attributs volontairement vides, avant chaque montée de version PHP, aurait détecté cette erreur avant la production.

Un typage strict protège contre les erreurs silencieuses, à condition d’être vérifié avec des données volontairement incomplètes, pas seulement avec le cas nominal qui fonctionne toujours.

En résumé

PHP 8.4 durcit le comportement autour des propriétés typées, transformant en erreur fatale ce qui pouvait rester silencieux auparavant sur certains blocs orientés objet. Le correctif est rapide une fois la cause identifiée, mais la vraie prévention consiste à tester systématiquement les blocs avec des attributs vides avant chaque montée de version majeure de PHP, plutôt que de découvrir le problème en production.