On reçoit un mail client un mardi matin : « Le checkout ne marche plus depuis hier. » On ouvre wp-admin — tout semble normal. Personne n'avoue avoir activé un plugin. Les logs hébergeur montrent des 500 sans auteur. On greppe debug.log — des notices PHP, pas de lien avec l'utilisateur qui a cliqué « Mettre à jour » sur une extension marketing à 23 h 14.
On n'est pas seul. Chaque semaine, des agences écrivent après avoir passé des heures à désactiver des plugins un par un « pour voir » — sans savoir qui a changé quoi, ni depuis quel fichier PHP l'action part. Simple History dit « Plugin activé ». Query Monitor aide sur une requête live. WP Activity Log facture l'export JSON. Et le client répète : « Ce n'est pas nous. »
Ce guide existe parce qu'on voit deux extrêmes : aucune traçabilité (blâme, suppositions, rollback aveugle), ou des journaux illisibles sans stack ni contexte AJAX. La bonne réponse est au milieu : timeline horodatée, stack trace PHP attachée, presets métier, export JSON sans compte, et une liste claire de quand croiser Query Monitor ou PUD.
Pourquoi lire cet article ? Vous comprendrez ce que fait Debug Tracker (DTB), comment lire une stack trace frame par frame, comment mener une investigation agence en 7 étapes, quels 4 presets choisir (Developer, Agency audit, WooCommerce, Security), et comment DTB se compare honnêtement à Stream, Simple History, WP Activity Log, Query Monitor et DebugPress. Tableaux comparatifs, playbook d'erreurs, checklist de la semaine, FAQ issue de tickets support.
Ce que vous allez apprendre : catégories auth/content/ajax/rest · profondeur stack 5/8/12 frames · hook watchlist · complémentarité avec Plugin Usage Detector, PHP Compatibility Checker et Heartbeat Control Manager · export JSON · WP-CLI wp dtb tail.
Commençons par le fond — puis passons à l'action.
Creez un compte et debloquez le pack debug complet
Export JSON, timeline avancee et runbook agence — ressources membres.
Sans carte bancaire · Les checklists publiques restent gratuites.
Pour qui — et quand un autre outil suffit
Debug Tracker est fait pour vous si vous héritez d'un site avec 40 plugins et un comportement bizarre (emails envoyés deux fois, redirections fantômes, REST appelé par un plugin inconnu), si vous déboguez un incident WooCommerce en production, ou si vous êtes en agence et devez prouver quel plugin déclenche un hook — pas deviner.
Query Monitor suffit si vous savez déjà quelle page est lente et voulez profiler requêtes SQL live. PUD suffit si le problème est « trop de plugins morts » sans comportement mystérieux. DTB complète QM et PUD : il journalise qui a appelé quoi sur une période, avec stack trace — idéal pour les bugs intermittents.
Le cas classique : un client dit « parfois la commande part en double ». Vous activez DTB preset WooCommerce, vous reproduisez une commande test, vous filtrez woocommerce_checkout_order_processed — frame 0 pointe vers un plugin de fidélité mal configuré. Sans journal, vous auriez passé six heures à désactiver des plugins au hasard.
— Agence WooCommerce — Paris (11 boutiques, retour anonymisé, juin 2026)Incident « emails de confirmation envoyés deux fois » après une MAJ vendredi. DTB preset WooCommerce + filtre
woocommerce_order_status_completed: stack trace vers un plugin email marketing activé par le client à 22 h. Export JSON envoyé au client — fin du débat « ce n'est pas nous ». Investigation : 45 min au lieu de la journée prévue.
— Studio maintenance — Lille (retour anonymisé, mai 2026)On avait Simple History — suffisant pour savoir qu'un plugin a été activé, pas quel hook AJAX déclenchait un 500 intermittent. DTB + 8 frames de stack ont pointé un mu-plugin oublié. Simple History reste installé ; DTB est notre outil d'incident.
Ce que fait Debug Tracker — et pourquoi la stack trace change tout
Avant d'installer quoi que ce soit, nommons le mécanisme. Debug Tracker n'est pas un « pare-feu » qui bloque les mauvaises actions. C'est un journal d'investigation : chaque événement capture qui (utilisateur WordPress), quoi (catégorie + message), quand (horodatage), contexte (post_id, action AJAX, route REST) et d'où dans le code (stack trace PHP).
Comment fonctionne la capture
- Vous activez DTB depuis Outils → Debug Tracker (ou menu Volade) et appliquez un preset.
- DTB écoute les hooks WordPress configurés : auth, contenu, plugins, thèmes, options, AJAX, REST, watchlist.
- Chaque événement est stocké en BDD avec gravité (
infoàerror) et stack trace si activée. - Vous filtrez la Timeline par catégorie, utilisateur, gravité — ou exportez JSON pour le dossier client.
- Vous corrigez sur staging, puis basculez vers un preset moins bruyant en prod si besoin.
Outils → Debug Tracker → preset WooCommerce → reproduire bug → filtrer ajax → lire stack → corrigerLes catégories — définition rapide
| Catégorie | Ce qu'elle capture | Exemple typique |
|---|---|---|
| auth | Connexions, échecs, rôles | login_failed à 3 h du matin |
| content | Création, MAJ, suppression posts | Page accueil modifiée sans prévenir |
| plugin | Activation / désactivation | Extension cache activée vendredi soir |
| theme | Changement de thème | Thème enfant basculé par erreur |
| option | Options sensibles (Security) | users_can_register modifié |
| ajax | Requêtes admin-ajax | woocommerce_checkout en échec |
| rest | API REST | Route /wc/v3/orders |
| hook | Watchlist personnalisée | save_post_shop_order déclenché |
| php | Erreurs shutdown (V+) | Fatal error post-MAJ PHP |
Ce que DTB protège (ne cassez pas ça)
- Traçabilité agence : export JSON horodaté = livrable contractuel « qui a fait quoi ».
- Stack transparente : frames fichier + ligne — pas une boîte noire « plugin X ».
- Ignored users : exclure vos comptes internes du bruit client.
- Prune automatique : rétention selon tier — pas de BDD qui grossit sans limite.
Ce que DTB ne fait pas
- Pas de remplacement Query Monitor pour profiler SQL/hooks sur la requête en cours.
- Pas de blocage — observation seulement ; pas de rollback automatique.
- Pas d'audit parc plugin — pour ça, Plugin Usage Detector ; DTB dit qui a activé le plugin, PUD dit s'il sert encore.
- Pas de stack infinie en gratuit — 5 frames suffisent souvent ; 8–12 pour AJAX WooCommerce profond.
Exemple concret
Une agence gère une boutique WooCommerce. Checkout KO depuis samedi. Preset WooCommerce activé vendredi matin. Timeline filtre ajax : douzaine d'appels woocommerce_update_order_review. Stack frame 2 pointe vers un mu-plugin client qui hook woocommerce_cart_calculate_fees — activé la veille via événement plugin_activated à 22 h 03, utilisateur « staging-freelance ». Correctif en 40 min — sans désactiver half le stack « pour tester ».
Exporter le JSON avant de corriger et l'annexer au ticket. Le client voit la preuve ; on évite le « ce n'était pas moi » six mois plus tard. Ce geste simple transforme une suspicion en élément factuel et protège la relation client en cas de récidive.
DTB = timeline + contexte + stack trace + presets. Investigation oui ; suppression aveugle de plugins non. Filtrez avant d'accuser.
« Est-ce que je suis concerné ? » — 5 signes
- Vous héritez d'un site sans documentation et des régressions « fantômes ».
- Le client demande « qui a modifié la page d'accueil ? » sans réponse.
- Vous debuggez WooCommerce checkout ou admin-ajax sans auteur clair.
- Vous devez livrer un rapport d'incident facturable (sécurité, changement non autorisé).
- Simple History ou Stream ne suffisent plus — il manque la stack ou le détail AJAX.
Si au moins deux points vous parlent : lisez le guide stack trace — puis le workflow 7 étapes.
La stack trace PHP — comment la lire sans se tromper
La stack trace est la signature de Debug Tracker. Chaque frame = un appel de fonction PHP : fichier, ligne, fonction. Lire une stack, c'est remonter du symptôme à l'auteur code.
Anatomie d'une stack DTB
| Élément | Signification |
|---|---|
| Frame 0 | Point le plus proche de l'événement (callback hook, handler AJAX) |
| Frames intermédiaires | Thème, plugins, mu-plugins empilés |
| Dernier frame visible | Limite profondeur (5 / 8 / 12 selon accès) |
| Contexte JSON | action, post_id, route — métier, pas code |
Profondeur selon accès Volade
| Accès | Frames | Cas d'usage |
|---|---|---|
| Sans compte | 5 | « Qui a activé ce plugin ? » — souvent suffisant |
| Connecté | 8 | Checkout AJAX, builders, admin complexe |
| V+ Premium | 12 | Mu-plugins, conflits profonds, erreurs PHP capturées |
Interprétation pratique — scénarios
| Symptôme timeline | Frame à regarder en premier | Action |
|---|---|---|
plugin_activated | Frame 0 — souvent wp-admin/plugins.php | Identifier l'utilisateur + heure |
ajax_request checkout | Frame 1–3 — plugin WooCommerce ou custom | Désactiver ce plugin sur staging |
post_updated page accueil | Contexte post_id + user | Contacter l'auteur ou restaurer révision |
login_failed répété | Catégorie security | Preset Security · blocage IP / 2FA |
hook_watch watchlist | Nom hook dans message | Ajuster le plugin qui accroche ce hook |
Stack vs message — lequel écouter ?
Le message dit quoi (Plugin activated: foo/bar.php). La stack dit comment on y est arrivé (mu-plugin, cron admin, AJAX). Pour un correctif, la stack prime ; pour un livrable client, le message + utilisateur + heure suffisent souvent.
Quand ne pas s'arrêter à DTB seul
La timeline est une aide, pas l'unique outil. Voici les cas où nous recommandons de croiser avec d'autres signaux.
Liste — compléter DTB avec
| Besoin | Outil | Pourquoi |
|---|---|---|
| Requêtes SQL lentes maintenant | Query Monitor | DTB = historique ; QM = requête live |
| Plugin inutilisé mais suspect | Plugin Usage Detector | PUD = audit parc ; DTB = qui l'a activé |
| Erreur PHP post-MAJ 8.x | PHP Compatibility Checker | PCC = blockers code ; DTB (V+) = capture runtime |
| admin-ajax / Heartbeat bruyant | Heartbeat Control Manager | HCM = réduire bruit ; DTB = identifier l'action |
| Conformité lourde / SIEM | WP Activity Log (payant) | Intégrations enterprise — DTB = agence WP pragmatique |
Presets à traiter avec prudence en prod continue
- Developer : bruit AJAX élevé — réservé staging ou incident actif.
- Security avec log_options : options sensibles — documentez RGPD et durée rétention.
- Hook watchlist
woocommerce_*: volume élevé — fenêtre d'observation limitée (24–48 h).
Complémentarité PUD, PCC et HCM
| Outil | Rôle dans l'investigation | Lien |
|---|---|---|
| Plugin Usage Detector | Après identification plugin — audit usage avant suppression | DTB trouve l'auteur ; PUD valide le risque |
| PHP Compatibility Checker | Erreur php capturée (V+) — scan stack restant | PCC avant nouvelle MAJ |
| Heartbeat Control Manager | Bruit AJAX récurrent sans action métier claire | HCM allège ; DTB explique la source |
Workflow agence type : DTB incident → correctif → PUD si plugin douteux → PCC avant PHP → HCM si admin-ajax lourd.
Page lente now → Query Monitor. Qui a changé quoi → DTB. Supprimer plugin safe → PUD. MAJ PHP → PCC.
Guide pas à pas — investigation agence (7 phases)
Cette section est le tutoriel central. Bloquez 1 à 3 h pour un incident checkout ou audit « qui a touché quoi ». Ne sautez pas l'export JSON.
Étape 1 — Cadrage (15 min)
- Définir l'objectif : incident / audit / WooCommerce / sécurité.
- Noter fenêtre temporelle du bug (depuis quand ?).
- Installer Debug Tracker by Volade sur staging ou prod si urgent.
- Créer dossier client
/client-debug/YYYY-MM-DD/.
| Signal cadrage | Preset recommandé |
|---|---|
| Bug checkout / commande | WooCommerce |
| « Qui a modifié le site ? » | Agency audit |
| Tentatives login / rôle | Security |
| Debug dev / AJAX obscure | Developer |
Étape 2 — Appliquer le preset (5 min)
- Outils → Debug Tracker → preset en 1 clic.
- Vérifier capture enabled.
- Reproduire le bug (ou attendre trafic représentatif 30 min).
- Confirmer premier événement dans Timeline.
Sans compte Volade, logging, stack 5 frames, export JSON, 4 presets fonctionnent. Compte gratuit : filtres avancés, CSV, watchlist, 2 000 événements. V+ Premium : 50 000 événements, capture PHP, digest planifié, multisite central.
Étape 3 — Filtrer la timeline (30 min)
- Filtre catégorie :
ajaxpour checkout ;contentpour pages ;authpour accès. - Filtre gravité :
securityetwarningen priorité. - Filtre utilisateur si suspect identifié.
- Ouvrir l'événement le plus proche de l'heure du bug.
Documenter dans un tableur : Heure · Utilisateur · Catégorie · Message · Frame 0 stack · Hypothèse. Cette discipline transforme une investigation dispersée en un rapport structuré, réutilisable pour le livrable client et pour les incidents futurs. C'est aussi un gain de temps considérable : on ne refait pas cinq fois la même analyse.
Étape 4 — Lire la stack trace (20 min)
- Noter frame 0 — fichier + ligne.
- Identifier plugin ou thème (chemin
wp-content/plugins/outhemes/). - Croiser contexte JSON (
action,post_id,route). - Si stack tronquée à 5 frames — connecter compte Volade ou V+ pour 8–12.
Étape 5 — Correctif staging (30 min – 2 h)
Ordre recommandé :
- Désactiver ou corriger le composant identifié — pas half le stack.
- Reproduire le parcours (checkout, formulaire, page clé).
- Vérifier Timeline — plus d'événement
error/warninglié. - Si faux positif — élargir filtres, watchlist ciblée (connecté).
Étape 6 — Export et stack Volade (20 min)
- Export JSON : bouton admin ou
wp dtb export --file=client.json. - Si plugin douteux : scan Plugin Usage Detector avant suppression.
- Si erreur PHP : PHP Compatibility Checker sur stack restant.
- Optionnel : Heartbeat Control Manager si bruit AJAX persistant.
Étape 7 — Livrable client et surveillance (30 min)
- Rapport : chronologie, auteur, cause, correctif, stack résumée.
- JSON DTB archivé + preset final (souvent Agency ou Security).
- Surveillance 7 jours : nouveaux
login_failed,plugin_activated. - Facturez en forfait investigation — livrable reproductible.
— Équipe support VoladeLes tickets qui traînent 90 % du temps manquent l'export JSON du moment T. Sans snapshot, le client nie l'événement une semaine plus tard. Exportez avant correctif.
Cadrage → preset → filtres → stack → correctif → export → surveillance. Ne désactivez pas dix plugins « pour voir » si la stack pointe un fichier.
Presets DTB — Developer, Agency, WooCommerce, Security
Debug Tracker propose quatre presets dynamiques pour les workflows agence les plus demandés.
Preset Developer — « Debug technique »
Pour qui : développeurs, staging, incidents AJAX/REST obscurs.
| Paramètre | Comportement |
|---|---|
| Icône | 🛠️ |
| Auth, content, plugins, themes | Oui |
| AJAX + REST | Oui |
| log_options | Non |
| Watchlist | save_post, admin_init, wp_ajax_* |
Workflow : reproduire bug → filtrer ajax → stack → corriger → basculer Agency en prod.
Preset Agency audit — « Qui a changé quoi »
Pour qui : sites client, livrables lisibles, maintenance récurrente.
| Paramètre | Comportement |
|---|---|
| Icône | 🏢 |
| Auth, content, plugins, themes | Oui |
| AJAX + REST + options | Non — moins de bruit |
| Watchlist | Vide |
Preset WooCommerce — « Stack boutique »
Pour qui : checkout, commandes, admin boutique, webhooks WC.
| Paramètre | Comportement |
|---|---|
| Icône | 🛒 |
| AJAX + REST | Oui |
| log_themes | Non |
| Watchlist | woocommerce_, save_post_shop_order, wp_ajax_ |
Preset Security — « Accès et intégrité »
Pour qui : post-incident, audits accès, changements rôles.
| Paramètre | Comportement |
|---|---|
| Icône | 🛡️ |
| log_content + log_ajax | Non |
| log_options sensibles | Oui |
| REST | Oui (API admin) |
Bonus : export JSON preset Developer
Importez le preset JSON fourni dans les ressources de cet article pour aligner toute l'équipe sur les mêmes flags capture.
Vos options en 2026
Chaque site n'a pas besoin du même outil. Voici les approches honnêtes.
Option 1 — Logs serveur + debug.log
Pour qui : équipe sysadmin, erreurs PHP pures.
| Avantages | Inconvénients |
|---|---|
| Pas de plugin | Pas d'utilisateur WordPress |
| Gratuit | Pas de timeline admin |
| — | Corrélation manuelle |
Option 2 — Stream
Pour qui : équipes déjà sur l'écosystème Stream, connecteurs.
| Avantages | Inconvénients |
|---|---|
| Connecteurs tiers | Stack PHP limitée |
| Interface connue | Moins orienté preset agence WP |
| — | Export JSON souvent payant |
Option 3 — Simple History
Pour qui : petits sites, journal lisible minimal.
| Avantages | Inconvénients |
|---|---|
| Gratuit, simple | Pas de stack trace |
| Léger | Pas d'AJAX/REST structuré |
| — | Investigation checkout difficile |
Option 4 — WP Activity Log
Pour qui : enterprise, conformité lourde, intégrations SIEM.
| Avantages | Inconvénients |
|---|---|
| Profondeur conformité | Coût, complexité |
| Rapports avancés | Stack moins centrale que DTB |
| — | Surdimensionné pour agence boutique |
Option 5 — Query Monitor
Pour qui : debug runtime — requêtes, hooks, perf page par page.
| Avantages | Inconvénients |
|---|---|
| Standard industrie | Pas d'historique « qui hier » |
| SQL + hooks live | Courbe d'apprentissage |
| — | Ne remplace pas journal actions |
Option 6 — DebugPress
Pour qui : développeurs habitués au panneau debug intégré.
| Avantages | Inconvénients |
|---|---|
| Stack et hooks | Orienté dev session, pas audit client |
| Gratuit | Pas de presets WooCommerce / agence |
| — | Pas d'export JSON agence standard |
Option 7 — Debug Tracker by Volade (recommandé agence)
Pour qui : agences, WooCommerce, livrable JSON — stack + 4 presets + timeline.
| Avantages | Inconvénients |
|---|---|
| Stack trace gratuite 5 frames | Pas profiler SQL live |
| 4 presets maintenus | Watchlist = compte connecté |
| AJAX + REST + export JSON sans compte | Capture PHP = V+ |
WP-CLI : wp dtb tail | Complète QM, ne le remplace pas |
| Gratuit sans compte pour l'essentiel | — |
Nous avons construit Debug Tracker parce que les agences méritent de prouver qui a cassé quoi — pas de deviner un vendredi soir.
Tableau comparatif complet
| Critère | Stream | Simple History | WP Activity Log | Query Monitor | DebugPress | Debug Tracker |
|---|---|---|---|---|---|---|
| Timeline actions admin | Oui | Oui | Oui | Non | Partiel | Oui |
| Stack trace PHP | Non | Non | Partiel | Partiel | Oui | Oui — gratuit |
| Capture AJAX / REST | Partiel | Non | Partiel | Oui (live) | Non | Oui (historique) |
| Hook watchlist | Non | Non | Non | Oui (live) | Partiel | Oui — connecté |
| Presets agence / WC | Non | Non | Non | Non | Non | 4 presets |
| Export JSON sans compte | Non | Non | Payant | Non | Non | Oui |
| Debug requêtes SQL live | Non | Non | Non | Oui | Oui | Non |
| Investigation « qui hier » | Oui | Oui | Oui | Non | Non | Oui + stack |
| WP-CLI | Non | Non | Partiel | Non | Non | Oui |
| Maintenance 2026 | Variable | Actif | Actif | Actif | Variable | Actif |
| Prix | Variable | 0 € | Payant | 0 € | 0 € | Gratuit (V+ optionnel) |
Page lente now → Query Monitor. Qui a changé quoi → DTB. Audit parc → PUD. MAJ PHP → PCC. Ne confondez pas historique et profiler.
Sans carte bancaire · Les checklists publiques restent gratuites.
Erreurs fréquentes et comment les éviter
Même avec un bon preset, ces problèmes reviennent dans la plupart des investigations.
« Timeline vide — DTB ne marche pas »
Pourquoi : capture désactivée, ou votre compte agence dans ignored_users par erreur, ou preset Security sans l'événement attendu.
Comment éviter :
- Vérifier enabled et statut
wp dtb status - Tester une action simple (save brouillon) — événement
contentattendu - Retirer temporairement ignored_users en staging
« Trop d'événements — je n'y vois plus rien »
Pourquoi : preset Developer en prod Black Friday, ou watchlist woocommerce_* sans fin.
Comment éviter :
- Basculer Agency audit ou Security post-incident
- Limiter watchlist à hooks précis (
save_post_shop_order) - Filtres catégorie + gravité avant lecture
« La stack s'arrête au milieu »
Pourquoi : profondeur 5 frames — mu-plugin plus profond.
Comment éviter :
- Compte Volade connecté (8 frames) ou V+ (12)
- Croiser Query Monitor sur reproduction live
- Chercher frame 0 — souvent déjà le plugin coupable
« J'ai désactivé dix plugins — le bug est toujours là »
Pourquoi : investigation sans stack — roulette russe.
Comment éviter :
- Lire frame 0 avant toute désactivation
- Un plugin par hypothèse sur staging
- Export JSON preuves pour le client
« Client refuse la journalisation RGPD »
Pourquoi : pas de cadrage contractuel maintenance.
Comment éviter :
- Preset Agency limité, durée rétention documentée
- Export JSON = preuve incident, pas archive permanente
- Accès restreint admin — clause contrat maintenance
Enabled · preset adapté · filtres · stack frame 0 · export JSON. Developer ≠ prod permanente.
Votre plan d'action cette semaine
Utilisez cette checklist comme couche d'exécution — imprimez-la, partagez-la en interne.
Checklist Debug Tracker WordPress
- Objectif investigation documenté (incident / audit / WC / sécurité)
- Debug Tracker installé — staging d'abord si possible
- Preset appliqué : Developer / Agency / WooCommerce / Security
- Ignored_users configurés (comptes agence)
- Bug reproduit ou fenêtre observation 24 h
- Timeline filtrée (catégorie + gravité + utilisateur)
- Stack trace lue — frame 0 identifié
- Correctif staging testé (checkout / formulaires si WC)
- Export JSON archivé dossier client
- Plugin Usage Detector si plugin suspect à auditer
- PHP Compatibility Checker si erreur PHP (V+ / logs)
- Preset prod ajusté (Agency ou Security)
- Rapport client + surveillance 7 jours
Outils recommandés
- Debug Tracker by Volade
- Plugin Usage Detector by Volade
- PHP Compatibility Checker by Volade
- Heartbeat Control Manager by Volade
- Query Monitor — complément debug runtime
- Tarifs V+ Volade — historique 50k, capture PHP, multisite
Ressources & guide PDF
Téléchargez les checklists publiques et le preset Developer JSON dans le panneau ressources de cet article. Les membres débloquent le guide complet 10 pages avec matrices stack, workflow 7 phases et FAQ technique.
Creez un compte et debloquez le pack debug complet
Export JSON, timeline avancee et runbook agence — ressources membres.
Sans carte bancaire · Les checklists publiques restent gratuites.
FAQ — Debug Tracker WordPress : qui a cassé quoi — stack trace et timeline agence (
Qu'est-ce que Debug Tracker WordPress : qui a cassé quoi — stack trace et timeline agence ( ?
On reçoit un mail client un mardi matin : « Le checkout ne marche plus depuis hier. » On ouvre wp-admin — tout semble normal. Personne n'avoue avoir activé un plugin. Les logs hébergeur montrent des 500 sans auteur. On greppe debug.log — des notices PHP, pas de lien avec l'utilisateur qui a cliqué « Mettre à jour » sur une extension marketing à 23
Pour qui — et quand un autre outil suffit : quels sont les points clés ?
Debug Tracker est fait pour vous si vous héritez d'un site avec 40 plugins et un comportement bizarre (emails envoyés deux fois, redirections fantômes, REST appelé par un plugin inconnu), si vous déboguez un incident WooCommerce en production, ou si vous êtes en agence et devez prouver quel plugin déclenche un hook — pas deviner. Query Monitor suffit si vous savez déjà quelle page est lente et vou
Ce que fait Debug Tracker — et pourquoi la stack trace change tout
Avant d'installer quoi que ce soit, nommons le mécanisme. Debug Tracker n'est pas un « pare-feu » qui bloque les mauvaises actions. C'est un journal d'investigation : chaque événement capture qui (utilisateur WordPress), quoi (catégorie + message), quand (horodatage), contexte (post_id, action AJAX, route REST) et d'où dans le code (stack trace PHP).
La stack trace PHP — comment la lire sans se tromper
La stack trace est la signature de Debug Tracker. Chaque frame = un appel de fonction PHP : fichier, ligne, fonction. Lire une stack, c'est remonter du symptôme à l'auteur code.
Quand ne pas s'arrêter à DTB seul : quels sont les points clés ?
La timeline est une aide, pas l'unique outil. Voici les cas où nous recommandons de croiser avec d'autres signaux. ### Liste — compléter DTB avec Outil Query Monitor Plugin Usage Detector PHP Compatibility Checker Heartbeat Control Manager WP Activity Log (payant) ### Presets à traiter avec prudence en prod continue
Developer : bruit AJAX élevé — réservé staging ou incident actif.
Guide pas à pas — investigation agence (7 phases) : quels sont les points clés ?
Cette section est le tutoriel central. Bloquez 1 à 3 h pour un incident checkout ou audit « qui a touché quoi ». Ne sautez pas l'export JSON.
Presets DTB — Developer, Agency, WooCommerce, Security : quels sont les points clés ?
Debug Tracker propose quatre presets dynamiques pour les workflows agence les plus demandés. ### Preset Developer — « Debug technique »
Pour qui : développeurs, staging, incidents AJAX/REST obscurs. Comportement 🛠️ Oui Oui Non save_post, admin_init, wp_ajax_ Workflow : reproduire bug → filtrer ajax → stack → corriger → basculer Agency en prod.
Vos options en 2026 : quels sont les points clés ?
Chaque site n'a pas besoin du même outil. Voici les approches honnêtes. ### Option 1 — Logs serveur + debug.log
Pour qui : équipe sysadmin, erreurs PHP pures.
Erreurs fréquentes et comment les éviter
Même avec un bon preset, ces problèmes reviennent dans la plupart des investigations. ### « Timeline vide — DTB ne marche pas »
Pourquoi : capture désactivée, ou votre compte agence dans ignored_users par erreur, ou preset Security sans l'événement attendu. Comment éviter :
Vérifier enabled et statut wp dtb status
Tester une action simple (save brouillon) — événement content attendu
Retirer tempor
Par où commencer après avoir lu cet article ?
Utilisez cette checklist comme couche d'exécution — imprimez-la, partagez-la en interne. ### Checklist Debug Tracker WordPress
Objectif investigation documenté (incident / audit / WC / sécurité)
Debug Tracker installé — staging d'abord si possible
Preset appliqué : Developer / Agency / WooCommerce / Security
Ignored_users configurés (comptes agence)
Bug reproduit ou fenêtre observation 24 h
Timeli
Conclusion — prouver avant d'accuser
Les sites cassent parce que WordPress facilite les changements — pas la traçabilité. Quand le client dit « ce n'est pas nous », vous n'êtes pas condamné au grep de logs ou à la désactivation en masse.
Ce n'est pas une fatalité. Timeline, stack trace, presets métier, export JSON, workflow 7 étapes — et vous reprenez la main sur l'investigation, sans brûler un vendredi soir.
Notre recommandation finale : cette semaine, installez DTB sur un site pilote staging, appliquez preset Agency audit, provoquez un changement test (brouillon + activation plugin dummy), lisez la stack, exportez le JSON. Puis gardez Developer en réserve pour le prochain incident WooCommerce.
Si vous choisissez Volade : bienvenue. On a construit cet outil parce que les agences méritent de montrer la preuve, pas de supposer.
Bonne investigation. Votre timeline vous remerciera.
Article mis à jour le 30 juin 2026. Sources : tests terrain Volade, comparaison Stream / Simple History / WP Activity Log / Query Monitor / DebugPress, documentation DTB 1.0.
Deboguez WordPress avec Debug Tracker
Journal d'actions utilisateur avec stack traces PHP — timeline, hooks, AJAX/REST et export JSON.
Tout pour aller plus loin
FAQ, glossaire, comparatif, scripts et diagnostic — en complément de l'article, pas à la place.
4
Presets DTB
Developer, Agency, WooCommerce, Security
22
Points checklist
Ressource publique incluse
7
Phases agence
Workflow investigation client
12
Frames stack max
Profondeur V+ Premium
Guide complet Debug Tracker 2026
La version longue et imprimable de cet article — stack trace PHP, 4 presets, workflow agence 7 phases et stack PUD/PCC/HCM.
- ✓9 catégories d'événements : auth, content, ajax, rest, hook, php
- ✓Stack trace 5/8/12 frames selon accès Volade
- ✓4 presets commentés : Developer, Agency, WooCommerce, Security
- ✓FAQ technique des cas investigation les plus fréquents
Inscrivez-vous et debloquez le pack complet
Chronologie migration
- Phase 0
Cadrage & preset
Objectif incident/audit, ignored_users, dossier client /client-debug/.
- Phase 1
Activation & reproduction
Preset DTB appliqué, bug reproduit ou observation 24 h.
- Phase 2
Filtres timeline
Catégorie, gravité, utilisateur — événement proche de l'heure bug.
- Phase 3
Lecture stack
Frame 0 identifié, contexte JSON, plugin ou thème responsable.
- Phase 4
Production
Correctif staging, export JSON, preset Agency/Security, surveillance 7 jours.
Comparatif des approches
| Critère | Stream | Simple History | WP Activity Log | Query Monitor | DebugPress | Debug Tracker |
|---|---|---|---|---|---|---|
| Timeline actions admin | Oui | Oui | Oui | Non | Partiel | Oui |
| Stack trace PHP | Non | Non | Partiel | Partiel | Oui | Oui — gratuit |
| Capture AJAX / REST | Partiel | Non | Partiel | Oui (live) | Non | Oui (historique) |
| Hook watchlist | Non | Non | Non | Oui (live) | Partiel | Oui — connecté |
| Presets agence / WC | Non | Non | Non | Non | Non | 4 presets |
| Export JSON sans compte | Non | Non | Payant | Non | Non | Oui |
| Debug requêtes SQL live | Non | Non | Non | Oui | Oui | Non |
| Maintenance 2026 | Variable | Actif | Actif | Actif | Variable | Actif |
| Prix | Variable | 0 € | Payant | 0 € | 0 € | Gratuit |
Glossaire TikTok Shop × WooCommerce
- Stack trace
- Liste des appels PHP menant à l'événement — fichier, ligne, fonction par frame.
- Frame 0
- Frame le plus proche du hook ou callback — premier suspect investigation.
- Hook watchlist
- Patterns de hooks surveillés (ex. wp_ajax_*, woocommerce_*) — compte connecté.
- Ignored users
- IDs utilisateur exclus du journal — comptes agence internes.
- Preset
- Configuration capture 1 clic — Developer, Agency audit, WooCommerce, Security.
- Prune
- Purge automatique événements au-delà de la rétention (100 / 2000 / 50000).
FAQ étendue
Extraits scripts emails
Annonce client — investigation Debug Tracker
Objet : Investigation WordPress — journalisation temporaire admin (aucun impact public)
Bonjour, Suite à [INCIDENT], nous activons un **journal d'actions admin** le [DATE] sur [ENVIRONNEMENT]. Votre site public reste inchangé. Livrable : chronologie + cause identifiée + export JSON archivé. Durée journalisation : [DURÉE]. Accès restreint équipe technique. Cordialement, [L'ÉQUIPE]
Brief équipe interne
Objet : [INTERNE] Incident client [NOM] — Debug Tracker J-0
Équipe, Incident [NOM] le [DATE]. Preset : [PRESET]. • Technique : [NOM] — timeline + export JSON • Support : surveiller tickets checkout / accès • Rollback si : checkout KO > 15 min post-correctif Export dans /client-debug/. Stack frame 0 = priorité. Stack post-incident : PUD si plugin douteux · PCC si PHP · HCM si ajax bruyant.
Snippets techniques
WP-CLI — status et export investigation
wp dtb status
wp dtb tail --limit=30
wp dtb export --file=debug-$(date +%Y%m%d).jsonIgnorer comptes agence du journal
Outils → Debug Tracker → Paramètres → Ignored users
Saisir les IDs WordPress des comptes agence (ex. 1, 42)
Trouver l'ID : Utilisateurs → survoler le compte → id-user-X dans l'URLAuto-diagnostic rapide
Timeline vide après activation DTB. Première cause ?
Checkout KO — stack frame 0 pointe vers mu-plugin client.
Liens officiels & utiles
Vidéo à venir
Walkthrough Debug Tracker (à venir)
Vidéo pas à pas : preset WooCommerce, filtres ajax, lecture stack trace et export JSON client.
~10 min
Inscrivez-vous pour être notifié à la publication — les membres Volade y auront accès en premier.
Votre avis compte
Commentez « Debug Tracker WordPress : qui a cassé quoi — stack trace et timeline agence (guide 2026) » ou notez cet article pour aider la communauté.
personnes ont partagé cet article