« Fatal error: Uncaught TypeError » : ce message générique, qui ne dit rien en lui-même, devient l’ennemi numéro un de toute équipe qui prépare un registre de blocs hérité pour un relèvement du seuil minimal de PHP vers la version 8.4, à l’approche de la sortie de WordPress 7.0. Cette checklist recense les motifs de code qui déclenchent le plus souvent ce type d’erreur sur des blocs dynamiques anciens.
Elle ne couvre pas les nouveautés éditoriales apportées par WordPress 7.0 lui-même, ni la migration des extensions tierces du site, uniquement les motifs de code des blocs dynamiques maison susceptibles de casser avec ce relèvement du seuil PHP minimal.
1. Relever le seuil PHP réel du registre de blocs
Avant toute correction, un audit du seuil PHP réellement supporté par chaque bloc du registre s’impose, via une exécution complète de la suite de tests sur un environnement PHP 8.4 dédié, distinct de la production. Beaucoup de blocs hérités n’ont jamais été testés au-delà de PHP 8.1, ce qui rend cette étape non négociable avant toute autre correction.
2. Corriger les propriétés typées non nullables
Les classes orientées objet utilisées dans certains render_callback pour structurer les données de rendu sont le premier point de rupture observé sur les blocs hérités. Une propriété déclarée string sans indication de nullabilité, recevant occasionnellement null depuis un attribut de bloc non renseigné, provoque une erreur fatale déjà bien documentée depuis PHP 8.4.
- Rechercher toutes les propriétés typées strictement dans les classes de rendu de blocs.
- Vérifier, pour chacune, si une valeur nulle peut légitimement lui être assignée depuis un attribut vide.
- Déclarer explicitement
?typeou fixer une valeur par défaut non nulle, selon l’intention réelle du champ.
3. Vérifier les fonctions dépréciées depuis PHP 8.1 et plus
Certaines fonctions couramment utilisées dans des blocs hérités écrits avant 2022 restent dépréciées depuis plusieurs versions successives de PHP, sans avoir jamais été corrigées faute d’occasion de montée de version majeure. Le passage à PHP 8.4 est le moment de les traiter définitivement plutôt que de continuer à accumuler les warnings.
| Motif de code | Déprécié depuis | Correctif recommandé |
|---|---|---|
| Passage par référence implicite dans un tableau | PHP 8.1 | Passage explicite ou copie du tableau |
| Conversion implicite chaîne décimale vers entier | PHP 8.3 | Cast explicite avant l’opération |
| Assignation de null à une propriété typée non nullable | PHP 8.4 | Type explicitement nullable ou valeur par défaut |
4. Auditer les opérations arithmétiques sur les attributs de bloc
Les attributs de bloc déclarés en string dans block.json, mais représentant en réalité des nombres (prix, quantité, délai), restent une source récurrente de warnings quand ils sont utilisés directement dans des opérations arithmétiques sans cast préalable. Une recherche systématique des opérateurs %, /, << et >> appliqués à des attributs de bloc permet de couvrir la quasi-totalité de ces cas avant qu’ils ne deviennent bloquants.
5. Tester chaque bloc avec des attributs volontairement incomplets
La majorité des erreurs liées au typage strict de PHP 8.4 ne se manifeste que sur des cas limites : un attribut jamais renseigné, un champ optionnel laissé vide par l’éditeur. Un script de recette qui appelle chaque render_callback du registre avec des attributs volontairement vides ou incomplets révèle ces cas avant la montée de version, plutôt qu’en production après coup.
- Générer une liste exhaustive des blocs dynamiques du registre à auditer.
- Exécuter chaque
render_callbackavec un jeu d’attributs vides, en environnement PHP 8.4 isolé. - Consigner chaque erreur ou warning déclenché, classé par famille de motif de code.
- Corriger en priorité les erreurs fatales, puis les warnings de dépréciation restants.
Un relèvement du seuil PHP minimal ne se prépare pas la veille de la sortie de la version qui l’impose : il se prépare avec un audit systématique, bien en amont, sur un environnement isolé de la production.
En résumé
Préparer un registre de blocs hérité pour le seuil PHP 8.4 annoncé à l’approche de WordPress 7.0 tient en cinq vérifications ciblées : seuil réel du registre, propriétés typées nullables, fonctions dépréciées accumulées, opérations arithmétiques sur attributs mal typés, et test systématique avec des attributs incomplets. Aucune de ces vérifications n’est complexe individuellement ; c’est leur absence cumulée sur plusieurs années qui rend la montée de version brutale si elle n’est pas anticipée.
