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;
// ...
}
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_LOGsur 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
stringdansblock.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.
