# Elementor et Sentry : distinguer une erreur de widget d’une erreur de thème

> « Add as much context as you can », recommande la documentation Sentry. Sur un site Elementor multi-widgets, ce contexte fait toute la différence pour trier les alertes sans perdre de temps.

- Auteur : WordPress Développement
- Publié le : 2022-05-05
- Mis à jour le : 2022-05-05
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/elementor-sentry-distinguer-erreur-widget-theme/

## L’essentiel

- Sans contexte, chaque alerte Sentry ressemble à toutes les autres
- Des tags par widget et par emplacement accélèrent le tri
- Les breadcrumbs retracent le parcours avant l'erreur

« Add as much context as you can to help you diagnose and triage the problem. » Ce conseil, tiré directement de la documentation officielle de Sentry, prend tout son sens sur un site Elementor où cohabitent une dizaine de widgets personnalisés développés à des périodes différentes, pour des besoins différents, sans convention commune de nommage des erreurs.

Sur ce site, quarante alertes Sentry arrivaient chaque semaine dans un flux unique, sans distinction entre une erreur mineure d'un widget secondaire et une erreur bloquante du widget de paiement. Ce recette de tags a permis de réduire le tri manuel à une dizaine de minutes par semaine, contre plus d'une heure auparavant.

## Le problème : un flux d'alertes indifférencié

Chaque widget Elementor personnalisé du site initialisait sa propre instance minimale de capture Sentry, sans tag distinctif. Résultat : dans le tableau de bord Sentry, toutes les erreurs remontaient sous un même projet, classées uniquement par message d'erreur brut, souvent identique d'un widget à l'autre (`Cannot read properties of undefined` revenait dans au moins six widgets différents, pour des causes chaque fois distinctes).

## La recette : des tags systématiques à l'initialisation

La solution ne consiste pas à réécrire chaque widget individuellement, mais à centraliser l'ajout de contexte dans une fonction utilitaire partagée, appelée par chaque widget juste avant de capturer une exception :

```
function capturerErreurWidget(erreur, widgetType, emplacement) {
  Sentry.withScope(function (scope) {
    scope.setTag('widget', widgetType);
    scope.setTag('emplacement', emplacement);
    scope.setLevel('warning');
    scope.addBreadcrumb({
      category: 'elementor-widget',
      message: 'Rendu du widget ' + widgetType,
      level: 'info'
    });
    Sentry.captureException(erreur);
  });
}
```

> L'essentiel à retenir : Sans contexte, chaque alerte Sentry ressemble à toutes les autres ; Des tags par widget et par emplacement accélèrent le tri ; Les breadcrumbs retracent le parcours avant l'erreur

Chaque widget appelle désormais cette fonction unique en passant simplement son propre identifiant (`widgetType`) et l'emplacement de la page où il se trouve. Le tri dans Sentry devient immédiat : un filtre sur le tag `widget:formulaire-devis` isole en un clic toutes les erreurs propres à ce widget précis, sans avoir à relire chaque message brut.

### Ce que les breadcrumbs ajoutent

- Un breadcrumb au rendu du widget permet de savoir si l'erreur est survenue à l'initialisation ou après une interaction du visiteur
- Un breadcrumb à chaque appel d'API externe (Stripe, Mailchimp, HubSpot selon le widget) situe l'erreur dans la chronologie exacte du parcours
- Le niveau de sévérité (`warning`, `error`, `fatal`) distingue une dégradation mineure d'un blocage complet du parcours

## Distinguer une erreur de widget d'une erreur de thème

Un second bénéfice de ce tri par tags est apparu rapidement : certaines erreurs, mal attribuées à un widget au premier coup d'œil, provenaient en réalité d'un script du thème actif interférant avec le DOM généré par Elementor. Le tag `emplacement`, couplé au tag `widget`, permet de repérer qu'une erreur survient systématiquement sur toutes les pages, quel que soit le widget présent, un signe fiable d'une cause côté thème plutôt que côté widget.

> Conseil maison : avant d'accuser un widget Elementor d'être la cause d'une erreur JavaScript, vérifier si l'erreur survient aussi sur des pages sans ce widget. Le tag d'emplacement, comparé entre plusieurs alertes, répond souvent à cette question en quelques secondes.

## Limites de cette recette

Cette organisation de tags ne remplace pas une configuration fine des alertes Sentry (seuils, notifications par canal), qui reste un réglage distinct côté interface Sentry, ni un audit complet des extensions du site : elle se limite à fournir, au moment de la capture, le contexte nécessaire pour trier rapidement une alerte parmi d'autres.

## En résumé

Un contexte riche, ajouté une fois pour toutes dans une fonction utilitaire partagée, transforme un flux d'alertes Sentry indifférencié en un outil de tri réellement exploitable, capable de distinguer en un coup d'œil une erreur de widget d'une erreur de thème sous-jacente.