Trente-deux extensions actives, un thème sur mesure, et une pile Sentry qui reçoit une centaine d’événements par jour : sans contexte additionnel, chaque nouvelle alerte impose de rouvrir la stack trace complète pour savoir si le problème vient d’un plugin tiers, du cœur WordPress ou du thème lui-même. Sur ce genre de site, le tri manuel devient vite le principal coût du monitoring.
La solution ne consiste pas à ajouter plus de filtres côté Sentry, mais à enrichir chaque événement, au moment où il est capturé côté PHP, avec des informations que seul le code source connaît : quel fichier de template était en cours de rendu, quel hook exécutait la fonction fautive, quelle est la couche réellement responsable.
Le tag « source » : la première ligne de tri
WordPress expose get_stylesheet_directory() et la liste des extensions actives via get_option( 'active_plugins' ). En croisant le chemin du fichier présent dans la stack trace avec ces informations, on détermine la couche responsable avant même d’ouvrir l’événement :
add_action( 'init', function() {
if ( ! function_exists( '\Sentry\configureScope' ) ) {
return;
}
\Sentry\configureScope( function ( \Sentry\State\Scope $scope ): void {
$scope->setTag( 'wp.theme', get_stylesheet() );
$scope->setTag( 'wp.theme_version', wp_get_theme()->get( 'Version' ) );
$scope->setContext( 'wordpress', [
'is_admin' => is_admin(),
'is_ajax' => wp_doing_ajax(),
'multisite' => is_multisite(),
] );
} );
} );Ce tag seul ne suffit pas à identifier la source d’une erreur donnée, mais il permet déjà de filtrer les événements par version de thème dans le tableau de bord Sentry, un premier niveau de tri précieux après une mise à jour.
Un middleware qui inspecte la stack trace
Pour aller plus loin, un gestionnaire d’exception personnalisé peut inspecter le chemin du fichier fautif et poser un tag error.origin automatiquement :
function determiner_origine_erreur( \Throwable $exception ): string {
$trace_file = $exception->getFile();
$theme_dir = get_stylesheet_directory();
$plugin_dir = WP_PLUGIN_DIR;
if ( str_starts_with( $trace_file, $theme_dir ) ) {
return 'theme';
}
if ( str_starts_with( $trace_file, $plugin_dir ) ) {
return 'plugin';
}
if ( str_starts_with( $trace_file, ABSPATH . 'wp-includes' )
|| str_starts_with( $trace_file, ABSPATH . 'wp-admin' ) ) {
return 'core';
}
return 'inconnu';
}
add_action( 'init', function() {
\Sentry\configureScope( function ( \Sentry\State\Scope $scope ): void {
$scope->setTag( 'error.origin', 'a-determiner-au-vol' );
} );
} );En pratique, ce tag se pose au moment de la capture de l’exception, pas à l’initialisation, car c’est seulement à ce moment que le fichier fautif est connu. Une intégration Sentry personnalisée via before_send est le point d’accroche le plus fiable pour cette logique.
Les breadcrumbs de template : savoir quel fichier était rendu
Une erreur peut survenir dans une fonction du thème appelée depuis un plugin, ou l’inverse. Le tag de fichier source ne suffit alors pas : il faut aussi savoir quel template était en cours de rendu au moment du plantage. Un breadcrumb posé sur le hook template_include répond à ce besoin :
add_filter( 'template_include', function( $template ) {
if ( function_exists( '\Sentry\addBreadcrumb' ) ) {
\Sentry\addBreadcrumb( new \Sentry\Breadcrumb(
\Sentry\Breadcrumb::LEVEL_INFO,
\Sentry\Breadcrumb::TYPE_DEFAULT,
'template',
'Template chargé : ' . str_replace( ABSPATH, '', $template )
) );
}
return $template;
}, 999 );Ce simple ajout transforme une stack trace opaque en un fil narratif lisible : « template chargé : archive-produit.php » puis « exception dans functions.php ligne 214 » suffit souvent à confirmer que le thème est bien en cause, sans dérouler la trace complète.
Ce que le tri automatique n’élimine pas
Ce dispositif accélère le triage mais ne remplace pas la lecture attentive des cas ambigus : une fonction du thème qui appelle un hook exposé par un plugin, et qui plante à cause d’un paramètre inattendu fourni par ce plugin, reste un cas où l’origine réelle du bug est partagée. Le tag error.origin pointera alors vers le thème, alors que la cause première est ailleurs — d’où l’intérêt de toujours garder le breadcrumb de template et la stack trace complète accessibles en un clic.
Un tag de tri n’a de valeur que s’il fait gagner du temps sur 90 % des cas ; les 10 % restants méritent toujours un vrai regard humain.
En résumé
Trois ajouts suffisent à transformer une liste d’alertes Sentry indifférenciée en un flux triable au premier coup d’œil : un tag de version de thème posé à l’initialisation, un tag d’origine calculé au moment de la capture d’exception, et un breadcrumb de template posé sur template_include. Sur le site à quarante extensions mentionné plus haut, ce dispositif a réduit d’environ un quart d’heure par semaine le temps passé à rouvrir des stack traces pour la seule question « c’est le thème ou pas ».
