Laravel Admin Bar Laravel Package

Getting Started

Install the package with Composer and publish its config:

composer require murdercode/laravel-admin-bar
php artisan vendor:publish --tag=admin-bar-config

The bar itself is rendered by a service provider/middleware, so there is no Blade work required to see it. Once installed, load any page in a local (or otherwise enabled) environment and the bar appears — usually docked to the bottom of the viewport.

Where to look first:

1. config/admin-bar.php — this is the single source of truth for what is shown and where. Confirm the enabled flag and the environment list before troubleshooting anything else.
2. The middleware registration — if the bar doesn't appear, verify the middleware is actually attached to the web group (or wherever the package registers it).
3. composer.json — check the required Laravel/PHP versions match your stack before assuming a rendering bug.

First real use case: you spin up a new Laravel app, install the package, and immediately get a persistent strip showing environment, PHP/Laravel version, current route, and query count — handy for "am I actually on staging?" and "how many queries did this page just fire?" without opening the debug toolbar.

Implementation Patterns

Environment gating. The most common pattern is to leave the package enabled only for local/development and rely on the config's environment whitelist rather than wrapping it in your own if (app()->isLocal()). This keeps the check in one place and avoids "why is the bar missing in staging?" confusion.

Config-driven customization. Rather than editing vendor Blade views, override the items list in the published config. If you want to add a link to your own dashboards or a "current user" segment, look for the items/sections array in the config — this is the extension point the package intends you to use.

Pairing with Debugbar. Admin Bar and Barryvdh Debugbar serve different roles: the bar is a lightweight always-visible status strip, Debugbar is a deep dive. A common setup is both enabled locally, with the bar providing the "quick glance" and Debugbar for query/profile exploration.

Middleware-based integration. Because rendering is hooked into the response pipeline, the bar is compatible with standard Blade-rendered responses. If you have custom response transformations or a global middleware that rewrites the response body, check ordering so the bar's injection isn't stripped or duplicated.

Multi-tenant / per-route toggling. If you need the bar on some routes but not others, use the config's enabled flag plus a small middleware or a per-request toggle (if exposed) rather than editing views. Keep the "is the bar visible" decision out of Blade.

Gotchas and Tips

• It will leak into production if misconfigured. The package is designed to be harmless, but a bar advertising your environment and query counts on a public site is still noise/attack surface. Explicitly set enabled to something like app()->isLocal() in production-facing configs.
• CSP and inline assets. The bar injects its own styles/scripts. On sites with a strict Content-Security-Policy (no unsafe-inline), the bar may render unstyled or not at all. Whiten-list the package's asset domain or loosen CSP in the environments where the bar is enabled.
• SPA front-ends (Inertia/Livewire/Vue). The bar hooks into the HTML response, so a full-page-reload Blade layout is the happy path. With Inertia or Livewire navigation, the bar may not refresh its values (e.g., query count) on client-side transitions — treat it as a page-load indicator, not live telemetry.
• View/config caching. After changing config/admin-bar.php, run php artisan config:clear. If you've cached config in a deployed environment and the bar behaves oddly, this is almost always the cause.
• Middleware order matters. If the bar silently disappears, check for middleware that terminates or rewrites the response (compression, custom error handling, API-only responses). The bar needs the final HTML response to inject into.
• Publishing overwrites. Re-publishing the config after a package upgrade will clobber your customizations — diff before overwriting, or keep customizations in a separate config key if the package supports it.
• Extending items. The config's items array is the safest extension point. Avoid editing the vendor views directly; those changes disappear on composer update and are the most common source of "it broke after upgrade" reports.
• Version bump (v1.2.0) caveat. The release notes are only a changelog link, so treat any upgrade from v1.1.x as "read the diff first." Even a minor bump can rename a config key or change a default (e.g., environment gating). Pin the version in composer.json and test the bar renders after upgrading in a local environment before deploying.
• Debugging absence. If the bar doesn't show: confirm environment is in the enabled list, config is not cached, the package service provider is auto-discovered (check bootstrap/providers.php / config/app.php), and that the response is HTML (not JSON/redirect/streamed).