- How do I install van-ons/filament-navigation in a Laravel Filament app?
- Run composer require van-ons/filament-navigation:^2.0, then php artisan migrate to create the package tables, then php artisan filament:assets to publish its front-end assets. Finish by registering the plugin in your panel provider with ->plugin(FilamentNavigation::make()). If your panel is still on Filament 3 or lower, you need the 1.x branch instead of 2.x.
- Does van-ons/filament-navigation support Filament v4 and Laravel 11?
- Version 2.0.0 and above requires Filament v4 or newer, while the 1.x line covers Filament 3 and below. It is a standard Laravel package with no external services or SaaS accounts, so it runs anywhere your Filament panel runs. The binding constraint is the Filament major version, not the Laravel version, so check the compatibility doc before committing.
- Is van-ons/filament-navigation a fork of ryangjchandler/filament-navigation?
- Yes. It is a maintained fork of ryangjchandler/filament-navigation, which was discontinued in August 2025. The design is therefore proven by inheritance, but the ongoing maintenance commitment is new and comes from a single agency with low adoption so far. Treat it as actively maintained but young, and plan a contingency.
- How do I register the Filament Navigation plugin in my PanelProvider?
- Add ->plugin(FilamentNavigation::make()) to the panel chain returned from your panel provider, typically AdminPanelProvider. That single call registers the Navigation resource and its drag-and-drop editor for authenticated panel users. No service provider edits or config publishing are required for a standard install.
- Can I change the navigation group, sort order, or icon of the Navigation resource?
- Yes. Call NavigationResource::navigationGroup(), NavigationResource::navigationSort(), and NavigationResource::navigationIcon() to reposition and rebrand the resource inside your panel. These static customizations cover the common cases; deeper structural changes may mean overriding the resource or its views, which is where the documentation thins out and you end up reading source.
- Does hiding a navigation menu item restrict access in Filament?
- No. Menu visibility is presentation only, not authorization, and hidden items do not stop anyone from reaching a page by URL. Keep access control in policies and gates, and make sure product and security stakeholders understand the distinction. This is the most commonly misread risk with menu-authoring packages.
- Can van-ons/filament-navigation render menus on my public-facing website?
- Not directly. The package is a menu-authoring tool for authenticated Filament panels, not a front-end navigation or routing system. To use the stored menus on a public site you need a separate render layer that reads the same database tables and maps items to your routes or URLs. If you need CMS-managed site menus, scope that as a distinct feature rather than assuming the package covers it.
- How do I test that Filament Navigation works in my application?
- The package ships its own suite, runnable with composer test, but for your app you should cover the resource pages with Filament's testing helpers and assert the migration ran cleanly. Realistically the whole adoption is one to three engineer-days including seed data and QA. Focus tests on any code that reads the navigation tables, since that is your integration surface.
- What are the alternatives to van-ons/filament-navigation?
- The main options are the original discontinued ryangjchandler/filament-navigation, other community Filament menu packages, or building a small Navigation resource in-house. Because the integration surface is narrow, a custom resource is a realistic fallback rather than a rewrite. If your menus are static and short, hardcoding them avoids schema and dependency overhead entirely.
- Is van-ons/filament-navigation safe for production and what is the upgrade risk?
- It owns database tables via published migrations, so it is a data-owning dependency you should review before every upgrade rather than bump and forget. Risk factors are low adoption, a bus factor of one or two people, and the need to track Filament major releases in lockstep. Accept it with a contingency plan: fork, pin, or replace if the package stalls, and include a data migration path if you later switch.