Phystrix Bundle Laravel Package

Getting Started

• Install as a dev dependency: composer require --dev barryvdh/laravel-debugbar. Package discovery registers the service provider and the Debugbar facade automatically.
• Publish the config once: php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider" → config/debugbar.php. Control it per environment with DEBUGBAR_ENABLED (defaults to APP_DEBUG).
• Open any page in the browser and the bar renders at the bottom: Timeline, Messages, Request, Views, Queries, Route, Logs, and — if the Twig bridge is present — Twig/profiler collectors.
• The first use case to learn is debugbar() in a controller or Blade view: debugbar()->info($payload); dumps into the Messages tab without breaking the response, and debugbar()->startMeasure('x') / stopMeasure('x') gives you a Timeline entry.
• Where to look first in config/debugbar.php: enabled, collectors (php, messages, time, memory, exceptions, views, route, queries, mails, auth, gates, session, request, logs, twig), and inject. Turning inject off while leaving enabled on is the documented way to collect without rendering the bar.

Implementation Patterns

• Scoped profiling. Wrap expensive blocks with Debugbar::startMeasure() / stopMeasure(), or use Debugbar::measure('label', fn () => ...). Prefer this over ->info() for anything you want to compare across requests.
• Custom collectors. Extend DebugBar\DataCollector\DataCollector (implement collect() and getName()), then register it in config/debugbar.php under collectors or at runtime with Debugbar::addCollector(new MyCollector()) — typically from a service provider's boot() guarded by config('debugbar.enabled').
• Twig-rendered templates. Register the package's Twig extension/function so debugbar calls inside .twig files reach the collector; this is the surface touched by 4.0.1 (profiler collector Twig template rendering). Validate with a template that loops over collector data, not just a scalar dump.
• Non-HTML responses. For JSON/AJAX, call Debugbar::enable() in middleware (or pass the query flag), then read Debugbar::getData() — the bar can't inject into a JSON body, so wire the payload into a header or a dedicated ?debugbar endpoint during development.
• Targeted debugging on demand. Keep enabled => false globally and flip it per request via middleware, a route group, or an IP allowlist in config/debugbar.php. This is the pattern that survives contact with a shared staging box.
• Test-time assertions. In feature tests, disable rendering (inject => false) and assert against Debugbar::getCollectors() / getData() instead of scraping HTML.
• Side-by-side with Telescope. Both can run, but you pay collection and storage twice; usually pick one as the always-on tool and gate the other.

Gotchas and Tips

• Config caching bites first. After editing config/debugbar.php, run php artisan config:clear. A cached config is the most common reason "the bar disappeared" or a collector you added never fires.
• Published views override vendor fixes. The 4.0.1 fix lives in the vendor Twig template for the profiler collector. If you previously published overrides, delete or re-publish resources/views/vendor/debugbar (and clear compiled views) — otherwise the patch is inert for you.
• Overhead is real. Every request collects, serializes, and (by default) writes to storage. Large result sets, big log bursts, or hundreds of queries will visibly slow pages and can exhaust memory. Cap what you collect rather than debugging performance with an unthrottled profiler.
• Storage growth. The file/SQLite storage driver accumulates rows and headers; prune it or switch to null/array storage in long-lived dev environments.
• inject => false ≠ disabled. Collectors still run and consume memory; only the render step is skipped.
• XHR and Livewire/Inertia. Requests that replace the DOM never show the bar. Use the phpdebugbar-id response header with the open-handler, or fall back to Debugbar::getData().
• Middleware ordering matters. If your Debugbar::enable() middleware sits after the response is generated (or inside a terminating callback for streamed responses), you get no data.
• Extension points to remember: custom collectors, Debugbar::addMessage() with a severity, and the debugbar.collect/storage hooks — these let you keep instrumentation while turning the visual bar off for other developers.
• Upgrade hygiene for 4.0.1. It's a patch-level template fix: no API changes, no deprecations. If you're on 4.0.0, upgrade and clear compiled views; nothing else in your integration should need to move.