{"id":156,"date":"2023-02-14T00:00:00","date_gmt":"2023-02-13T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/fr\/wp-debug-mieux-deboguer-wordpress-avec-acorn-symfony-ignition-whoops\/"},"modified":"2026-01-20T06:32:41","modified_gmt":"2026-01-20T05:32:41","slug":"wp-debug-mieux-deboguer-wordpress-avec-acorn-symfony-ignition-whoops","status":"publish","type":"post","link":"https:\/\/helloblog.io\/fr\/wp-debug-mieux-deboguer-wordpress-avec-acorn-symfony-ignition-whoops\/","title":{"rendered":"WP_DEBUG, mais en mieux : d\u00e9boguer WordPress proprement avec Acorn (Symfony, Ignition, Whoops)"},"content":{"rendered":"\n

Sur un projet WordPress, activer WP_DEBUG<\/code> en d\u00e9veloppement est non n\u00e9gociable : tu rep\u00e8res plus t\u00f4t les notices PHP, les erreurs fatales, les appels d\u00e9pr\u00e9ci\u00e9s, et tu \u00e9vites d\u2019empiler des \u201cpetits soucis\u201d qui explosent plus tard en prod. Le probl\u00e8me, c\u2019est que l\u2019affichage par d\u00e9faut de WordPress est\u2026 minimaliste : un message en clair inject\u00e9 dans la page, souvent sans contexte exploitable.<\/p>\n\n\n\n

Si tu travailles avec Acorn<\/strong> (le runtime PHP de Roots qui apporte une couche \u201cLaravel-like\u201d \u00e0 WordPress), tu peux consid\u00e9rablement am\u00e9liorer cette exp\u00e9rience : pages d\u2019exception plus propres, stack traces plus lisibles, et possibilit\u00e9 d\u2019utiliser Ignition<\/strong> (la page d\u2019erreur moderne bien connue c\u00f4t\u00e9 Laravel).<\/p>\n\n\n\n

Rappel : ce que fait vraiment WP_DEBUG (et pourquoi \u00e7a ne suffit pas)<\/h2>\n\n\n\n

WP_DEBUG<\/code> est le mode debug natif de WordPress. Une fois activ\u00e9, WordPress et PHP te remontent plus facilement les warnings\/notices\/erreurs, ce qui est essentiel quand tu d\u00e9veloppes un th\u00e8me, un plugin, ou m\u00eame une int\u00e9gration \u201csimple\u201d.<\/p>\n\n\n\n

Mais l\u2019output par d\u00e9faut a deux d\u00e9fauts majeurs :<\/p>\n\n\n\n

    \n\n
  • Lisibilit\u00e9 limit\u00e9e : message brut au milieu du HTML, sans mise en forme ni hi\u00e9rarchie.<\/li>\n\n\n
  • Contexte pauvre : selon les cas, la trace est incompl\u00e8te ou peu exploitable, surtout quand plusieurs couches (plugins, MU-plugins, th\u00e8me) s\u2019empilent.<\/li>\n\n<\/ul>\n\n\n\n
    \"Sortie
    WP_DEBUG \u201cvanilla\u201d : utile, mais vite frustrant au quotidien. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    Avec Bedrock, WP_DEBUG est d\u00e9j\u00e0 dans les bons rails<\/h2>\n\n\n\n

    Si tu utilises Bedrock<\/strong> (le boilerplate WordPress moderne de Roots bas\u00e9 sur Composer), tu pars d\u00e9j\u00e0 avec une configuration d\u2019environnements plus propre. D\u2019apr\u00e8s la documentation Roots, WP_DEBUG<\/code> est activ\u00e9 par d\u00e9faut en environnement de d\u00e9veloppement dans Bedrock, ce qui \u00e9vite l\u2019oubli classique du \u201cj\u2019ai d\u00e9bogu\u00e9 sans debug\u201d.<\/p>\n\n\n\n

    \n\n

    \u00c0 retenir<\/h4>\n\n\n

    Active WP_DEBUG<\/code> en local en permanence. Le co\u00fbt est faible, le gain est \u00e9norme (et l\u2019\u00e9cosyst\u00e8me WordPress n\u2019est pas r\u00e9put\u00e9 pour sa sobri\u00e9t\u00e9 en notices\u2026).<\/p>\n\n<\/div>\n\n\n\n

    Acorn : am\u00e9liorer l\u2019affichage des erreurs quand WP_DEBUG est activ\u00e9<\/h2>\n\n\n\n

    Acorn am\u00e9liore l\u2019output d\u2019erreur lorsque WP_DEBUG<\/code> est activ\u00e9 et<\/strong> que l\u2019affichage est autoris\u00e9 c\u00f4t\u00e9 WordPress (typiquement via WP_DEBUG_DISPLAY<\/code>). Concr\u00e8tement, au lieu d\u2019un message brut, tu obtiens une page d\u2019exception structur\u00e9e.<\/p>\n\n\n\n

    1) Par d\u00e9faut : le handler d\u2019exceptions Symfony<\/h3>\n\n\n\n

    Sans rien installer de plus, Acorn s\u2019appuie sur le gestionnaire d\u2019exceptions Symfony pour rendre les erreurs plus lisibles. Tu as une mise en forme claire, une trace plus exploitable et, globalement, une exp\u00e9rience plus proche de ce qu\u2019on attend d\u2019un projet PHP moderne.<\/p>\n\n\n\n

    \"Page
    Acorn + Symfony : une base solide et lisible pour les exceptions. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    2) Le confort maximal : Ignition (l\u2019erreur page \u201cLaravel\u201d)<\/h3>\n\n\n\n

    Si tu viens de Laravel, Ignition<\/strong> te parlera tout de suite : c\u2019est la page d\u2019erreur par d\u00e9faut de Laravel depuis la v9. La nouveaut\u00e9 c\u00f4t\u00e9 Roots, c\u2019est qu\u2019avec Acorn v3<\/strong>, le support du routing \u201cfa\u00e7on Laravel\u201d implique aussi la compatibilit\u00e9 avec Ignition sur WordPress.<\/p>\n\n\n\n

    Le r\u00e9sultat : une page d\u2019erreur tr\u00e8s riche, des stack traces bien pr\u00e9sent\u00e9es, et une ergonomie nettement sup\u00e9rieure quand tu dois comprendre vite pourquoi une requ\u00eate part en erreur.<\/p>\n\n\n\n

    \"Page
    Ignition sur WordPress via Acorn : on se rapproche d\u2019une DX (developer experience) de framework. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    Pour l\u2019installer (en d\u00e9pendance de dev), Roots recommande simplement d\u2019ex\u00e9cuter la commande Composer suivante depuis le dossier o\u00f9 Acorn est install\u00e9 :<\/p>\n\n\n\n

    <\/circle><\/circle><\/circle><\/g><\/svg><\/span>