Filament Topbar Menu Laravel Package

Product Decisions This Supports

• Admin panel information architecture. Decides whether "quick links to our other tools" lives in panel navigation, a custom Blade partial, or a managed menu. This package makes it a data-driven, CMS-managed concern instead of a code change per link.
• Build vs. buy for internal-tool chrome. The scope is narrow but non-trivial: a Filament resource, migration, model, caching layer, render-hook integration, two-level dropdowns, per-item visibility, favicons, mobile slide-in panel, and 13 locales. Realistic in-house cost is days of engineering plus ongoing maintenance every Filament major bump; buying is a composer require and a migration.
• Roadmap for multi-service consolidation. If the strategy is "one admin panel as the front door to Grafana, the marketing site, support tooling, and internal apps," this is the cheapest way to ship that front door without building a bespoke navigation system.
• Feature prioritisation for internal tooling. Because items are database rows with an active toggle and drag-and-drop sort, non-engineers (ops, support leads) can curate the menu. That converts a recurring engineering request ("add this link") into a self-service admin task — a support-load reduction, not just a UI feature.
• Panel-scoping decisions. Plugin options (resource(false), ->mobileSidebar(), renderHook(), mobile(false)) let one codebase serve an admin panel with full management and a public/light panel that only displays the menu. That supports decisions about whether to split panels.
• Localisation commitments. Ships 13 locales; if we claim multi-language admin support, this removes one blocker for that claim.
• Governance decisions. The embedded-favicon/favicon-URL/icon precedence, role restriction that fails closed, and "route missing → skip item rather than error" behaviours are policy choices we inherit. Reviewing them is a security/UX decision, not a code one.

When to Consider This Package

Consider it when all of the following hold:

• We are on Filament 5 / PHP 8.2+. This is Filament-5-only; it is not a backport candidate and gives us nothing on Filament 3/4.
• We need a small set of top-level links (external services or named Laravel routes) with at most one level of dropdown. Two levels is a hard limit; deeper structures silently drop off the menu.
• The menu is chrome, not a core workflow. It is navigation sugar — useful, visible, but a broken link costs minutes, not revenue.
• We want ops-editable navigation and are comfortable with a new DB table plus a migration in our app.
• We value zero build step (no published assets, no npm) and Filament-native styling that inherits dark mode and theme — relevant if we have thin frontend capacity.
• We are willing to pin the version, read the CHANGELOG on upgrade, and be prepared to fork — MIT licence makes that viable.

Look elsewhere (or build) when:

• We need more than two menu levels, mega-menus, or per-item permission matrices. Role restriction exists but is a raw roles key not editable in the form and depends on a hasAnyRole() method on the user model (e.g. spatie/laravel-permission). If our authorisation story is different, this is friction.
• We need auditing, approval workflows, or scheduled publishing of menu items. There is a read-only View page and timestamps, but nothing more.
• We require vendor support, SLAs, or a security review trail. Ten stars, zero dependents, and a README/changelog-only maturity signal mean no third-party validation. A prior SSRF issue in favicon resolution is documented in the repo's own agent notes — that is a sign of diligence, but also a reminder that this is a single-maintainer surface that fetches external URLs.
• Our user model has no roles method and we need restricted items — the package fails closed, so restricted items would be invisible to everyone.
• We run a panel with navigation(false) and want the in-sidebar mobile variant — there is no sidebar to render into.
• We need menu rendering outside Filament panels (public marketing site, emails, API-driven clients) — this is a panel render-hook plugin.
• We have a strict dependency policy for packages with no dependents and no independent adoption evidence; the risk is concentration, not licence.

Diligence to complete before adoption: confirm Filament 5 is actually our target; run the demo seeder in a staging panel; verify the mobile behaviour on a long-navigation panel (this is where the second-button UX either delights or confuses); review the favicon fetching path against our SSRF/egress policy; check ext-intl presence since two behaviours degrade silently without it; and check CI matrix expectations (MySQL/Postgres, PHP 8.2–8.4) against our infrastructure.

How to Pitch It (Stakeholders)

For executives — one paragraph. We have a decision to make about how our admin panel links out to the rest of our internal tools. Rather than hard-coding a navbar and paying engineering every time a link changes, we can adopt a small, MIT-licensed Filament plugin that turns that menu into an admin-managed list: our ops team adds, reorders, and hides links themselves, with sensible visibility rules and full theme consistency. It is cheap to try, cheap to remove, and it converts a recurring engineering chore into a self-service task. The trade-off is that it is a young, single-maintainer package with limited public adoption, so we should treat it as a low-criticality component, pin the version, and be ready to fork it — which the licence permits.

For engineering — the case. It is a thin, well-bounded plugin: one table, one Filament resource, one render hook (TOPBAR_LOGO_AFTER), no layout overrides, no compiled assets, and it reuses Filament's own topbar, dropdown, and sidebar classes so it inherits our theme and dark mode for free. It handles the awkward parts we would otherwise get wrong: cached rendering with automatic invalidation, route resolution that skips missing routes instead of throwing, per-item target semantics that don't get silently overridden by config, favicon resolution kept out of the render path, and a mobile presentation that doesn't bury the menu under the panel's own navigation. It ships with tests, PHPStan, Pint, a changelog with a documented release process, and a CI matrix covering PHP 8.2–8.4, prefer-lowest, MySQL/Postgres, and the no-ext-intl case — unusual rigour for a package this size. Known limits: two levels only, no rich permission UI, and a single-maintainer bus factor. Recommended posture: adopt behind a pinned constraint, exercise it in one panel first, and keep the migration/config publishable so we retain an exit path.

For the design/UX partner. The desktop menu is rendered with Filament's own top-navigation components, so it is pixel-identical to what users already see, including active-item highlighting and spacing. On mobile it becomes its own slide-in panel with its own button next to the hamburger — a deliberate choice so the menu isn't lost beneath a long sidebar — with an in-sidebar variant available via one method call if a panel's navigation is short.