{"id":152,"date":"2023-02-14T00:00:00","date_gmt":"2023-02-13T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/pt\/debug-wordpress-com-acorn-melhorando-wp-debug\/"},"modified":"2026-01-20T06:32:53","modified_gmt":"2026-01-20T05:32:53","slug":"debug-wordpress-com-acorn-melhorando-wp-debug","status":"publish","type":"post","link":"https:\/\/helloblog.io\/pt\/debug-wordpress-com-acorn-melhorando-wp-debug\/","title":{"rendered":"Debug no WordPress sem sofrimento: como o Acorn melhora o WP_DEBUG"},"content":{"rendered":"\n

Se desenvolves temas ou plugins para WordPress, h\u00e1 uma regra simples que evita perder horas a adivinhar: no ambiente local, WP_DEBUG<\/code> tem de estar ligado. O problema \u00e9 que o output padr\u00e3o do WordPress \u00e9\u2026 funcional, mas pouco amig\u00e1vel. Mostra notices e erros diretamente na p\u00e1gina, sem grande contexto, stack trace decente ou uma apresenta\u00e7\u00e3o que ajude mesmo a localizar a origem do problema.<\/p>\n\n\n\n

Neste artigo vou explicar como o Acorn<\/strong> (a camada Laravel-friendly do ecossistema Roots) melhora significativamente a experi\u00eancia de debugging quando WP_DEBUG<\/code> est\u00e1 ativo \u2014 e quais s\u00e3o as alternativas quando n\u00e3o est\u00e1s a usar Acorn.<\/p>\n\n\n\n

O essencial do WP_DEBUG (e porque deve estar sempre ligado em desenvolvimento)<\/h2>\n\n\n\n

O WordPress tem um modo de debug controlado pela constante WP_DEBUG<\/code>. Quando est\u00e1 ativo, o runtime passa a expor notices<\/strong>, warnings<\/strong> e fatal errors<\/strong> que muitas vezes ficam silenciosos em produ\u00e7\u00e3o. Isto \u00e9 especialmente importante no ecossistema WordPress, onde \u00e9 comum encontrar c\u00f3digo de terceiros a emitir notices \u2014 e isso pode mascarar problemas reais no teu c\u00f3digo.<\/p>\n\n\n\n

Se trabalhas com Bedrock<\/strong> (o boilerplate moderno da Roots que organiza o WordPress com Composer), a boa not\u00edcia \u00e9 que, por defeito, o debug j\u00e1 vem preparado para ambientes de desenvolvimento, o que ajuda a manter consist\u00eancia entre projetos e m\u00e1quinas.<\/p>\n\n\n\n

Porque o output padr\u00e3o do WP_DEBUG n\u00e3o chega para projetos mais s\u00e9rios<\/h2>\n\n\n\n

O comportamento t\u00edpico do WordPress, com WP_DEBUG<\/code> e WP_DEBUG_DISPLAY<\/code> ligados, \u00e9 despejar a mensagem do erro diretamente no HTML da p\u00e1gina. \u00c9 melhor do que nada, mas na pr\u00e1tica tens tr\u00eas dores recorrentes:<\/p>\n\n\n\n

    \n\n
  • Pouco contexto: muitas mensagens aparecem sem um stack trace realmente \u00fatil.<\/li>\n\n\n
  • Baixa legibilidade: erros misturam-se com o markup e quebram a leitura.<\/li>\n\n\n
  • Diagn\u00f3stico lento: entre includes, hooks e templates, encontrar a origem exata pode ser penoso.<\/li>\n\n<\/ul>\n\n\n\n
    \"Exemplo
    O WP_DEBUG padr\u00e3o \u00e9 direto, mas pouco leg\u00edvel e com contexto limitado. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    O que o Acorn muda quando o WP_DEBUG est\u00e1 ativo<\/h2>\n\n\n\n

    O Acorn<\/strong> melhora o output do WP_DEBUG<\/code> quando WP_DEBUG && WP_DEBUG_DISPLAY<\/code> est\u00e3o ligados. Na pr\u00e1tica, ele substitui aquela experi\u00eancia \u201craw\u201d por um handler de exce\u00e7\u00f5es mais moderno, com p\u00e1ginas de erro bem estruturadas.<\/p>\n\n\n\n

    Isto \u00e9 particularmente interessante em projetos onde j\u00e1 existe uma cultura Laravel: o Acorn permite trazer padr\u00f5es e ergonomia do Laravel para dentro do WordPress (incluindo helpers e uma organiza\u00e7\u00e3o de c\u00f3digo mais \u201caplica\u00e7\u00e3o\u201d).<\/p>\n\n\n\n

    Output por defeito do Acorn: handler do Symfony<\/h3>\n\n\n\n

    Por defeito, o Acorn utiliza o Symfony exception handler<\/strong>, que apresenta erros e exce\u00e7\u00f5es de forma muito mais leg\u00edvel do que o output nativo do WordPress. Ganha-se rapidamente em clareza: mensagem, localiza\u00e7\u00e3o, stack trace e um layout que n\u00e3o te obriga a vasculhar HTML partido.<\/p>\n\n\n\n

    \"P\u00e1gina
    Com Acorn, o output do WP_DEBUG torna-se mais informativo e f\u00e1cil de ler. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    Com Ignition: uma experi\u00eancia ao estilo Laravel (Acorn v3)<\/h3>\n\n\n\n

    Se vens do Laravel, provavelmente j\u00e1 conheces o Ignition<\/strong> \u2014 a p\u00e1gina de erro padr\u00e3o do Laravel desde a vers\u00e3o 9. A partir do Acorn v3<\/strong>, com suporte a routing no estilo Laravel, o Ignition tamb\u00e9m passa a ser suportado em sites WordPress que usam Acorn. Para muitos workflows, \u00e9 a melhor experi\u00eancia de tratamento de erros dispon\u00edvel neste contexto.<\/p>\n\n\n\n

    \"P\u00e1gina
    Ignition no WordPress via Acorn v3: uma experi\u00eancia muito pr\u00f3xima do Laravel. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

    Para come\u00e7ares a usar Ignition num projeto WordPress com Acorn, instala-o via Composer (nota: como depend\u00eancia de desenvolvimento) a partir da mesma diretoria onde o Acorn est\u00e1 instalado:<\/p>\n\n\n\n

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