Filament Admin Bar Laravel Package

Getting Started

The package is a frontend "admin bar" for Filament: a slim toolbar rendered on your public-facing pages so an authenticated panel user can jump back into the admin, open the panel dashboard, or (depending on configuration) edit the record behind the current URL.

Install

composer require wotz/filament-admin-bar
php artisan vendor:publish --tag="filament-admin-bar-config"
php artisan vendor:publish --tag="filament-admin-bar-views"   # optional, only if you plan to restyle

Register the panel context (if the package does not auto-detect it) in config/filament-admin-bar.php — the essentials are the panel ID, the guard used by that panel, and whether the bar is enabled outside local.

Render it once, in your public layout, immediately before </body>:

{{-- resources/views/layouts/app.blade.php --}}
@auth
    <x-filament-admin-bar::bar />
@endauth

First use case to validate the install: log into /admin, open any frontend page in the same browser session, and confirm the bar appears with a working link back to the panel. If it does not render, the guard/panel mismatch is almost always the cause — see Gotchas.

Where to look first, in order: the README's config table, config/filament-admin-bar.php after publishing, then src/ for the service provider (to see what it registers and whether it hooks a render event) and resources/views/ for the Blade entry point you are including. With zero stars and no dependents, treat the source as the primary documentation and budget an hour to read it end to end before committing to it.

Implementation Patterns

Gate the bar on the panel guard, not Auth::check(). A user can be logged into your app's web guard and not into the Filament panel guard (or vice versa). Resolve against the panel's guard explicitly:

@if (filament()->auth()->check())
    <x-filament-admin-bar::bar :panel="'admin'" />
@endif

Contextual "Edit this page" is the highest-value integration. Rather than a static link, map the current route to a Filament resource edit URL. Keep the mapping in a small dedicated class so it is testable and does not leak into layouts:

// app/Support/AdminBarContext.php
public static function editUrl(): ?string
{
    $post = request()->route('post');          // route-model-bound

    return $post instanceof Post
        ? PostResource::getUrl('edit', ['record' => $post])
        : null;
}

Then pass it in, or bind it through the package's link registration if it exposes one:

<x-filament-admin-bar::bar :links="[
    ['label' => 'Dashboard', 'url' => filament()->getUrl('admin')],
    ['label' => 'Edit post', 'url' => AdminBarContext::editUrl(), 'visible' => (bool) AdminBarContext::editUrl()],
]" />

Compose links from a service provider, not from Blade. If the package supports registering links (config array or a fluent FilamentAdminBar::link(...) in a provider's boot), do it there. It keeps every layout call site identical and lets you gate links by policy:

public function boot(): void
{
    FilamentAdminBar::link('Horizon', '/horizon', fn () => Gate::allows('viewHorizon'));
}

Multi-panel apps. If you run admin and app panels, render a distinct bar per panel and pin the panel explicitly rather than relying on Filament's current-panel resolution — filament()->getCurrentPanel() returns null on non-panel routes, which is exactly where the bar lives.

Cache-safe rendering. If you use full-page caching (response cache, CDN, spatie/laravel-responsecache), the bar must not be in the cached payload. Either render it via an ESI/edge include, or exclude authenticated requests from the cache, or inject the markup client-side. Never let a cached HTML response carry another user's admin bar.

Livewire wire:navigate / SPA mode. A bar rendered server-side in the layout survives the initial load but can end up stale or duplicated after navigation events. If your frontend uses wire:navigate, either render the bar outside the navigating container or re-evaluate contextual links after livewire:navigated.

Extend by overriding the view, not by forking. Publish views, then edit resources/views/vendor/filament-admin-bar/bar.blade.php. Keep your diff small — a package at this maturity level will change shape, and a heavy override becomes a rewrite on the next tag.

Gotchas and Tips

Guard and panel mismatch is the #1 failure mode. The bar silently renders nothing when the panel's guard does not match the session you think you have. Debug by dumping filament()->getCurrentPanel(), filament()->auth()->check(), and config('filament-admin-bar.panel') on the frontend route. If getCurrentPanel() is null, that is expected — the bar is designed to work there — but the package's guard config must then be explicit.

Config and view caching. After changing the config or Blade, run php artisan config:clear && php artisan view:clear. If config is cached in a deploy pipeline and the package reads config at boot in a register() method, you can get stale values that survive a config:cache cycle. Read config lazily (inside the render path) if you hit this.

CSS collisions and z-index. The bar injects markup into arbitrary frontend pages: Tailwind purges it (it is in vendor/, not your content paths), and theme CSS may override its positioning. Fix by publishing the views into resources/views so Tailwind sees the classes, and by giving the bar an explicit high z-index in your own stylesheet rather than fighting the package's default.

Tailwind purge in production is a real trap. Locally the bar looks correct; in a production build the styling collapses. Add the published view path to content in tailwind.config.js.

Path exclusions. The bar frequently shows up in places it must not: emails previews, PDF generation, API JSON responses, Filament's own panel pages (you get a bar inside the admin). Configure an exclusion list of route names or patterns, and verify /admin is excluded by default.

Health-check endpoints and JSON routes. If your layout is reused in any non-HTML response, the bar will corrupt the output. Gate it on request()->expectsJson() being false.

Maturity risk. Zero stars, zero dependents, a single maintainer, and a release date that reads as aspirational. Practical consequences: no community answers when something breaks, no downstream projects to diff against, and an API that may break between tags. Pin the exact version in composer.json, keep the published views in version control so you can review upstream diffs, and write one feature test asserting the bar renders for an authenticated panel user and not for a guest — that test is your upgrade safety net.

Debugging checklist, in order: (1) is the component in the rendered HTML at all — curl the page and grep for the bar's root class; (2) is the config published and cached; (3) does the panel guard resolve; (4) is the route excluded by path rules; (5) does the view exist at the published path shadowing the vendor one.

Extension points worth confirming in src/ before you build on them: a link-registration API, a render event or hook, the view namespace, and whether the config is read at boot or per-request. If links are only configurable through the published config array, wrap that in your own provider so you are not spreading package-specific arrays across layouts.