Debugbar Laravel Package

Getting Started

Minimal steps:

1. Check compatibility first. This plugin is archived (last release 2021-09-25) and targets an older October CMS / Laravel pair. Note your October version before installing; on newer releases expect a Composer conflict with barryvdh/laravel-debugbar and plan on a fork.
2. Install with composer require bedard/debugbar (or drop it into plugins/bedard/debugbar if you need to patch it locally).
3. Ensure APP_DEBUG=true in .env, and confirm the plugin's own enabled flag is on in its config/config.php.
4. Load any CMS page or backend page in dev — the bar injects into the HTML response footer.

Where to look first:

• Plugin.php — service provider registration, middleware wiring, and any October-specific collectors.
• config/config.php — enable/disable switch, collector list, storage options.
• The injection middleware — this is what decides whether the bar renders for a given request/response.

First use case: open a CMS page you suspect is slow, check the Queries tab for N+1s coming out of component/partial loops, then the Timeline tab to see which Twig/component render is dominant. That's the 90% daily use: "why is this page slow and which queries are firing."

Implementation Patterns

• Environment gating. Keep it enabled in local dev only. APP_DEBUG plus the plugin's enabled config is your two-switch safety; disable it in staging so it can't leak into anything shared.
• Custom collectors. Implement Barryvdh's DataCollectorInterface (or extend the base DataCollector) in your own plugin, then register it via the debugbar container binding or facade from your Plugin::register(). This is the main extension point for showing domain-specific data (e.g., a custom cache, queue, or search payload) next to the standard panels.
• Manual instrumentation. Debugbar::startMeasure('key', 'Label') / Debugbar::stopMeasure('key') around expensive blocks; Debugbar::addMessage($data, 'label'), Debugbar::info(), Debugbar::error() for ad-hoc inspection. Wrap component onRender() or a specific handler to attribute render time to a component rather than to "the page."
• Twig and component debugging. dump() / dd() from templates and components flow into the messages panel; this is the least intrusive way to inspect context without breaking the response.
• AJAX and backend handlers. The bar does not inject into JSON responses. For October AJAX handlers and backend list refreshes, either send the debugbar request header or call Debugbar::enable() in the handler, then inspect the request via the debugbar endpoint or the ajax panel.
• Targeted disabling. Debugbar::disable() on a hot route or inside a specific component keeps the bar from adding overhead and noise where you don't need it.
• Storage workflow. Requests are persisted as JSON under storage/debugbar. Use the bar's "Open" picker to compare a slow and a fast request, and clear that folder periodically; it grows quietly.

Gotchas and Tips

• Archived means version-pinned. The plugin's Composer constraint on barryvdh/laravel-debugbar almost certainly predates current Laravel. On newer October versions, expect conflicts — either pin the underlying debugbar to what the plugin expects, or fork and bump the constraint. Do the compatibility spike before adopting it in a project.
• Bar not appearing — check in this order: APP_DEBUG, the plugin's enabled setting, whether the middleware actually ran for that route, whether storage/debugbar is writable, and whether the response is HTML (not JSON, not a redirect, not a streamed/download response).
• Frontend vs backend. The middleware may only be registered for one request area. If you want the bar in the October admin panel, check the middleware groups in Plugin.php rather than assuming it's global.
• Overhead is real. Full query collection plus render timings on a query-heavy page adds measurable latency; the debugbar can easily become a large fraction of the response time you're trying to measure. Watch for that when profiling, and never leave it on in production.
• Response modification fails silently. Strict CSP headers or streamed responses can prevent the injected footer from rendering with no error — page looks fine, bar is just gone.
• Duplicate panels. If you register a collector from your own plugin and the package also registers one, you'll see the panel twice. Trace registrations in Plugin.php and your own register().
• Extension points to lean on: custom DataCollectors, custom widgets, overriding the plugin's views, and the debugbar facade for one-off logging. If the archive state blocks you, the fallback is barryvdh/laravel-debugbar plus a small middleware that renders and injects it — which is essentially what this plugin is doing, and a few dozen lines to own outright.