# PHP 8.3 dans un bloc dynamique : ces warnings discrets qui polluent les logs

> Symptôme, diagnostic, correctif et prévention : comment une fonction de rendu de bloc dynamique se met à générer des warnings PHP 8.3 dépréciés sans faire tomber le site.

- Auteur : Clément Hadrot
- Publié le : 2024-12-21
- Mis à jour le : 2024-12-21
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/php-8-3-warnings-bloc-dynamique/

## L’essentiel

- Warning silencieux qui n'interrompt pas l'affichage du bloc
- Cause identifiée dans render_callback et un cast implicite
- Correctif sans changer la signature publique du bloc

`Deprecated: Implicit conversion from float-string "3.50" to int loses precision`. Ce message, répété des centaines de fois par jour dans les logs PHP d'un site montée de version, ne fait tomber aucune page, n'affiche aucune erreur visible pour le visiteur, et c'est bien ce qui le rend dangereux : il s'accumule silencieusement jusqu'à saturer les journaux applicatifs et masquer les vraies erreurs qui méritent une attention immédiate.

Ce cas concerne la montée de version PHP 8.3 (sortie en novembre 2023, adoptée fin 2024 sur ce projet) d'un bloc dynamique existant. Il ne couvre pas les autres dépréciations introduites par PHP 8.3, ni la migration des extensions tierces qui l'accompagne : uniquement ce warning précis, sa cause, et son correctif.

## Symptôme

Le bloc concerné est un bloc de tarification dynamique, `catalogue/prix-degressif`, qui calcule un prix arrondi en fonction d'une quantité saisie par l'éditeur dans l'inspecteur. Depuis la montée vers PHP 8.3, chaque affichage de page contenant ce bloc génère un warning dans le journal d'erreurs PHP, visible dans `wp-content/debug.log` lorsque `WP_DEBUG_LOG` est activé. Rien n'apparaît côté front : le prix s'affiche correctement, arrondi, sans que le visiteur ne s'en aperçoive.

## Diagnostic

Le `render_callback` du bloc contient une ligne qui convertit un attribut stocké sous forme de chaîne en entier, pour un calcul de remise :

```
function catalogue_render_prix_degressif( $attributes ) {
    $prix_base = $attributes['prixBase']; // chaîne "42.50"
    $quantite  = (int) $attributes['quantite'];

    $remise = $prix_base % $quantite;   // ici : conversion implicite
    // ...
}
```

L'opérateur `%` attend deux entiers. Jusqu'à PHP 8.2, PHP convertissait silencieusement la chaîne `"42.50"` en entier `42`, sans avertissement. Depuis PHP 8.3, cette conversion implicite d'une chaîne représentant un nombre à virgule vers un entier déclenche un warning de dépréciation, précisément parce qu'elle perd de l'information (le `.50` disparaît sans que le développeur l'ait explicitement demandé).

## Correctif

Le correctif ne change pas le comportement métier du bloc — le calcul doit continuer à arrondir la partie décimale — mais rend la conversion explicite, ce qui supprime le warning sans modifier le résultat :

```
function catalogue_render_prix_degressif( $attributes ) {
    $prix_base = (int) round( (float) $attributes['prixBase'] );
    $quantite  = (int) $attributes['quantite'];

    $remise = $prix_base % $quantite;
    // ...
}
```

> L'essentiel à retenir : Warning silencieux qui n'interrompt pas l'affichage du bloc ; Cause identifiée dans render_callback et un cast implicite ; Correctif sans changer la signature publique du bloc

La différence tient en une ligne : au lieu de laisser PHP deviner comment tronquer `"42.50"`, le code déclare explicitement l'intention (arrondir, puis convertir). PHP 8.3 ne se plaint jamais d'une conversion explicite, seulement d'une conversion implicite qui aurait pu être un bug. C'est là tout l'intérêt du warning : il pointe des endroits où le comportement dépendait d'un hasard d'arrondi plutôt que d'une décision du code.

## Prévention

Sur un registre de blocs conséquent, ce type de warning se cache souvent dans des opérations arithmétiques sur des attributs stockés en chaîne — ce qui est le cas de tout attribut de type `string` déclaré dans `block.json`, même quand il représente un nombre. Une revue rapide avant montée de version PHP consiste à rechercher les opérateurs `%`, `/`, `<<` et `>>` appliqués directement à des attributs sans cast préalable.

- Ajouter `WP_DEBUG_LOG` sur un environnement de recette avant chaque montée de version PHP majeure.
- Rechercher systématiquement les opérations arithmétiques sur des attributs typés `string` dans `block.json`.
- Caster explicitement dès la lecture de l'attribut, pas au moment du calcul, pour garder le typage lisible sur toute la fonction.

## Un point commun à surveiller sur d'autres blocs

Ce même schéma s'est retrouvé, sur ce projet, dans un second bloc de calcul de délai de livraison, où un attribut `joursDelai` déclaré en `string` était utilisé directement dans une division. Le correctif a été identique : caster explicitement en `float` ou en `int` selon l'intention, plutôt que de laisser PHP choisir.

> Un warning de dépréciation PHP n'est jamais un bruit à ignorer : c'est PHP qui signale un endroit où le code faisait une hypothèse qu'il ne peut plus garantir.

## En résumé

Ce warning précis — conversion implicite d'une chaîne décimale en entier — touche particulièrement les blocs dynamiques qui manipulent des attributs numériques stockés en chaîne, ce qui est la norme dans `block.json`. Le correctif tient en un cast explicite, sans impact sur le comportement visible, et la prévention consiste surtout à activer les logs PHP en recette avant chaque montée de version majeure, plutôt qu'en production après coup.