Une classe de widget Elementor qui dépasse le millier de lignes accumule, avec le temps, des méthodes qui se passent des données entre elles sans jamais vérifier leur type réel. PHP, en mode par défaut, convertit silencieusement une chaîne en entier, un entier en chaîne, ou un booléen en valeur numérique, sans avertissement. Cette souplesse, pratique au premier abord, devient une source de bugs difficiles à tracer sur une classe volumineuse où une valeur peut transiter par cinq méthodes avant de provoquer un comportement inattendu au rendu final.
Ce que change réellement le mode strict
L’instruction declare(strict_types=1);, placée en toute première ligne d’un fichier PHP après la balise d’ouverture, désactive la conversion implicite de type sur les appels de fonctions et de méthodes typées dans ce fichier précis. Une méthode déclarée avec un paramètre int $priorite qui reçoit une chaîne de caractères ne convertit plus silencieusement cette chaîne en entier : elle lève une erreur TypeError explicite, immédiatement visible en développement.
<?php
declare(strict_types=1);
class Widget_Temoignage extends \Elementor\Widget_Base {
protected function get_priorite_affichage(): int {
$priorite = $this->get_settings_for_display( 'priorite' );
return (int) $priorite;
}
}
Où ce typage révèle des bugs existants
Sur une classe de widget volumineuse, les points de fragilité les plus fréquents se trouvent dans les méthodes qui manipulent les valeurs issues de get_settings_for_display(). Ces valeurs proviennent de l’éditeur Elementor et arrivent presque toujours sous forme de chaîne de caractères, même pour un contrôle de type nombre. Une méthode qui attend un entier natif sans conversion explicite, et qui devient soudain stricte sur son typage, révèle immédiatement ces zones où la conversion était implicite et non vérifiée.
Méthode d’introduction progressive
Activer le typage strict sur une classe de mille lignes d’un coup, sans préparation, génère en général une avalanche d’erreurs TypeError à l’exécution, ce qui rend le changement risqué en production. La méthode retenue consiste à :
- ajouter
declare(strict_types=1);sur une copie du fichier en environnement de développement local ; - exécuter l’ensemble des scénarios d’usage du widget (édition, rendu, export de template) pour recenser les erreurs déclenchées ;
- corriger chaque appel fautif en ajoutant une conversion explicite au bon endroit, plutôt qu’en désactivant le mode strict ;
- répéter le cycle jusqu’à ce qu’aucune erreur ne subsiste sur les scénarios testés ;
- déployer uniquement une fois la classe stabilisée sur l’environnement de développement.
Ce que ce changement ne résout pas
Le typage strict ne détecte pas les erreurs de logique métier : une méthode qui retourne un entier correct mais faux dans son sens continue de fonctionner sans avertissement. Il ne remplace pas non plus une suite de tests automatisés, qui reste le seul moyen de couvrir systématiquement les scénarios d’usage d’une classe volumineuse. Le gain porte spécifiquement sur les erreurs de type glissées par inadvertance entre deux méthodes, pas sur la correction générale du comportement du widget.
Sur une classe existante déjà en production, on n’active jamais le typage strict directement sur le fichier live. Le cycle de test en local, même sommaire, évite de découvrir les erreurs en même temps que les utilisateurs du site.
Étendre la pratique aux nouvelles classes du projet
Une fois la méthode validée sur une classe existante, la règle la plus simple à appliquer pour la suite consiste à imposer declare(strict_types=1); systématiquement sur toute nouvelle classe créée dans le projet, dès sa première ligne de code, avant même d’écrire la première méthode. Cette discipline évite d’accumuler à nouveau la dette qu’a demandé de corriger la classe volumineuse initiale, et rend le typage strict progressivement la norme plutôt que l’exception sur l’ensemble de la base de code.
En résumé
Une seule ligne ajoutée en tête d’un fichier PHP suffit à transformer des conversions de type silencieuses en erreurs explicites et immédiates. Sur une classe de widget Elementor volumineuse, où les valeurs issues de l’éditeur transitent souvent sous forme de chaîne avant d’être attendues comme un nombre ailleurs, ce changement révèle des fragilités invisibles jusque-là, à condition d’être introduit progressivement plutôt que d’un bloc.
