Un widget Elementor qui perd silencieusement ses réglages après une mise à jour

Le ticket est arrivé un mardi matin : « la bannière promotionnelle de la page d’accueil a perdu sa couleur de fond, et personne n’y a touché ». Le widget custom en question gérait une bannière avec plusieurs contrôles avancés (dégradé conditionnel, superposition d’opacité, décalage responsive), développé en interne un an plus tôt. Aucune modification n’avait été apportée côté contenu depuis des semaines. Le seul changement récent visible dans le journal du site : une mise à jour mineure d’Elementor Pro, appliquée automatiquement dix jours plus tôt.

Ce genre de régression est particulièrement pénible parce qu’elle ne génère aucune erreur PHP, aucun message dans les logs, rien qui alerte une surveillance classique. Le widget continue de s’afficher, juste avec une valeur de contrôle silencieusement retombée à sa valeur par défaut.

Symptôme

Visuellement, un seul contrôle semblait affecté : le dégradé conditionnel de fond repassait à une couleur unie. En ouvrant l’éditeur Elementor sur la page concernée, le contrôle du dégradé apparaissait vide, comme si aucune valeur n’avait jamais été saisie, alors que l’historique de révisions de la page montrait clairement une configuration précédente avec deux couleurs et un angle personnalisé.

Diagnostic

La cause s’est révélée être un changement interne dans la structure de Group_Control_Background côté Elementor Pro, où le nom de la clé associée au type de dégradé conditionnel avait légèrement évolué entre deux versions mineures. Le widget custom référençait encore l’ancienne clé dans son code de rendu, ce qui suffisait à afficher correctement l’ancienne donnée stockée en base… jusqu’à ce que l’éditeur, lors d’une simple ouverture de la page par un rédacteur, resauvegarde les réglages du widget avec la nouvelle structure attendue, écrasant discrètement l’ancienne valeur.

Autrement dit, la donnée n’était pas perdue tout de suite après la mise à jour : elle a survécu jusqu’à la première sauvegarde ultérieure de la page dans l’éditeur, ce qui explique le délai de dix jours entre la mise à jour et l’apparition visible du problème.

Correctif

1. Exporter un snapshot JSON de la page affectée avant toute nouvelle sauvegarde, via WP_CLI ou l’export natif de template Elementor, pour figer la donnée encore valide.
2. Comparer la structure des données du contrôle concerné entre l’ancienne et la nouvelle version d’Elementor Pro, en consultant le changelog du plugin et, si besoin, le code source des classes Controls concernées.
3. Mettre à jour la définition du widget custom pour lire les deux formats de clé (ancien et nouveau) en fallback, le temps que toutes les pages du site soient resaisies avec la nouvelle structure.
4. Resaisir manuellement les valeurs affectées sur les pages où la donnée a déjà été écrasée par une sauvegarde intermédiaire.

Prévention

Depuis cet incident, chaque widget custom critique du site fait l’objet d’un export JSON automatisé hebdomadaire via une tâche WP-CLI planifiée, comparé au précédent par un script simple qui alerte sur toute clé disparue ou renommée dans la structure des réglages. Ce n’est pas un test unitaire sophistiqué, juste une diff de structure, mais cela aurait détecté la régression le jour même de la mise à jour plutôt que dix jours plus tard.

#!/usr/bin/env bash
wp elementor library export-templates --output=/backups/elementor/$(date +%F).zip
diff <(unzip -p /backups/elementor/$(date +%F).zip | jq -S .) \
     <(unzip -p /backups/elementor/$(date -d '-7 days' +%F).zip | jq -S .) \
     > /backups/elementor/diff-$(date +%F).txt

Une mise à jour mineure n’est mineure que dans le numéro de version. Pour un widget custom qui s’appuie sur les structures internes d’Elementor Pro, chaque mise à jour mérite une vérification, pas seulement une confiance aveugle au semantic versioning.

En résumé

Les widgets custom qui réutilisent des groupes de contrôles natifs d’Elementor Pro (fond, bordure, typographie) restent exposés aux changements internes de structure de données, même mineurs. Un système de snapshot et de comparaison automatisée, aussi simple soit-il, transforme une découverte client désagréable en une alerte technique gérée en amont, avant que qui que ce soit ne s’en aperçoive côté production.