# PHP 8.3 et les constantes typées : un bloc qui perd son état par défaut

> PHP 8.3, sorti en novembre 2023, introduit les constantes de classe typées et les classes readonly. Effet concret sur une bibliothèque de blocs existante, avec une régression discrète à surveiller.

- Auteur : WordPress Développement
- Publié le : 2024-03-05
- Mis à jour le : 2026-09-30
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/php-8-3-constantes-typees-bloc-perd-etat-defaut/

## L’essentiel

- Les constantes de classe typées lèvent une erreur fatale en cas de valeur incompatible
- Les classes readonly imposées à des objets d'état de bloc cassent des mises à jour attendues
- La migration demande d'auditer les valeurs par défaut avant de monter en version

Face à face entre l'ancienne habitude PHP, qui tolérait une constante de classe sans type déclaré, et la nouvelle rigueur introduite par PHP 8.3, sorti en novembre 2023 : c'est cette confrontation qui a révélé une régression discrète dans une bibliothèque de blocs maintenue depuis plusieurs années, au moment de la montée de version du serveur d'hébergement.

## Nouveautés classées par impact

### Impact élevé : les constantes de classe typées

PHP 8.3 permet désormais de déclarer explicitement le type d'une constante de classe, et surtout, applique cette contrainte strictement :

```
class ConfigurationBloc {
    public const string VERSION_DEFAUT = '1.0';
    public const int LIMITE_ELEMENTS = 20;
}
```

Le problème est apparu sur une classe existante dans le projet, où une constante déclarée comme devant contenir un entier recevait en réalité, dans une extension tierce chargée sur certains sites, une chaîne de caractères numérique héritée d'une ancienne configuration :

```
class ConfigurationBlocEtendue extends ConfigurationBloc {
    public const int LIMITE_ELEMENTS = '20'; // Erreur fatale sous PHP 8.3
}
```

Sous les versions précédentes de PHP, cette incohérence de type passait silencieusement. Sous PHP 8.3, elle déclenche une erreur fatale au chargement de la classe, bien avant que le bloc ne soit seulement rendu.

> L'essentiel à retenir : Les constantes de classe typées lèvent une erreur fatale en cas de valeur incompatible ; Les classes readonly imposées à des objets d'état de bloc cassent des mises à jour attendues ; La migration demande d'auditer les valeurs par défaut avant de monter en version

### Impact moyen : les classes readonly et l'état d'un bloc

PHP 8.3 étend également l'usage des classes marquées `readonly`, une fonctionnalité apparue en partie dès PHP 8.2 mais renforcée ici. Une classe représentant l'état interne d'un bloc, si elle est déclarée `readonly`, interdit toute modification de ses propriétés après l'instanciation :

```
readonly class EtatBlocCompteur {
    public function __construct(
        public int $valeurInitiale,
        public string $etiquette,
    ) {}
}
```

Un bloc qui tentait de réutiliser cette classe pour représenter un état évolutif au fil du rendu (en réassignant une propriété après construction, une pratique déjà fragile mais tolérée auparavant) échouait désormais avec une erreur explicite, ce qui a forcé une clarification bienvenue : cette classe ne devait représenter qu'un instantané figé, pas un état mutable.

### Impact faible : dépréciations mineures sans effet direct sur les blocs

PHP 8.3 introduit par ailleurs plusieurs dépréciations de fonctions rarement utilisées dans le contexte d'un bloc Gutenberg, sans impact constaté sur la bibliothèque auditée ici.

## Ce que la migration a demandé concrètement

1. Un audit de toutes les constantes de classe du projet, à la recherche de valeurs dont le type réel ne correspondait pas au type attendu ;
2. Une correction des constantes mal typées, en alignant la valeur sur le type déclaré plutôt que l'inverse ;
3. Une revue des classes `readonly` existantes, pour s'assurer qu'aucune ne servait, même de façon détournée, à représenter un état censé évoluer.

## Un point de vigilance pour la suite

Cette régression n'était pas visible en environnement de développement local, où la version de PHP utilisée par l'équipe restait en 8.1. Elle n'est apparue qu'au moment du déploiement sur un serveur de recette déjà passé en PHP 8.3, ce qui a confirmé l'utilité de garder les environnements de test alignés sur la version cible de production, plutôt que de découvrir ce type d'incompatibilité au dernier moment.

> Une montée de version de PHP ne casse jamais un bloc « pour rien » : elle révèle simplement une hypothèse implicite qui n'était plus tout à fait exacte depuis un moment.

## En résumé

PHP 8.3 renforce la rigueur autour des constantes de classe typées et des classes `readonly`, deux évolutions qui peuvent révéler des incohérences déjà présentes, mais silencieuses, dans une bibliothèque de blocs existante. Un audit préalable des constantes et des classes immuables avant la montée de version évite la mauvaise surprise découverte ici en environnement de recette. La compatibilité avec PHP 8.4, dont la sortie est attendue à l'automne, fera l'objet d'un article séparé.