Weave Code
Nova Detached Filters Laravel Package
outl1ne/nova-detached-filters
Nova Detached Filters lets you pull Laravel Nova filters out of the default filter dropdown and render them detached elsewhere on the page, keeping frequently used filters visible and one click away for faster resource browsing.
This Laravel Nova package allows you to detach filters from the filter dropdown
Frequently asked questions about Nova Detached Filters
- What does outl1ne/nova-detached-filters actually do?
- It lets you take filters that Laravel Nova normally renders inside the filter dropdown and display chosen ones as detached panels on the resource index page. The filters still run the same query logic as before, so nothing changes about how results are filtered. It is purely a presentation layer for admin ergonomics.
- How do I install nova-detached-filters in a Laravel Nova app?
- Install it with composer require outl1ne/nova-detached-filters. The service provider is auto-discovered, so no manual registration or asset build step is required. You then opt in per resource using the package's trait, base class override, or filter flag, depending on the version.
- Which Laravel and Nova versions are supported?
- The package targets Laravel Nova 4.x and 5.x applications, which means Vue 3 based Nova and Laravel 10 or 11 with PHP 8.1 and above. Release 3.0.1 from February 2025 exists specifically to fix type issues for Nova 5. Pin the package version together with an explicit Nova constraint in composer.json so upgrades stay predictable.
- Does detaching a filter break Nova's URL filter state, pagination, or bookmarks?
- Detached filters are meant to keep participating in Nova's URL-serialized filter state alongside pagination, sorting, and reset. In practice you should verify this yourself on each resource, because any desync produces shared or bookmarked index URLs whose visible controls contradict the rendered data. Test pagination, sort changes, reset, and copying the URL into a new tab before rolling out.
- Do I need database migrations or config changes to use it?
- No. There is no migration, no schema change, no new route, and no persistence involved. The package only changes where existing Nova filters are rendered, and filter query logic is untouched.
- Is nova-detached-filters safe to use in production?
- It is a thin presentation adapter with no data path, so a failure degrades an internal convenience rather than a customer-facing transaction. The main production risk is coupling to Nova's closed-source filter and toolbar internals, which can shift with any Nova major release. Treat it as a pinned, owner-assigned convenience layer with a documented rollback rather than a structural platform dependency.
- Will it conflict with other packages that customize the Nova index toolbar?
- Possibly. Anything else touching the index toolbar or filter menu, such as page managers, theme packs, or other filter plugins, can produce duplicated or missing controls that only appear at runtime. Audit what currently modifies your Nova index toolbar and smoke test the resource index page after installing.
- What happens when Nova releases a new major version?
- Expect to re-verify the package on every Nova major upgrade, because it hooks Nova's internal filter and toolbar components and cannot self-heal. The 3.0.1 release fixing types for Nova 5 is direct evidence that package-side patches are needed. Budget a small re-verification task per Nova bump, or be ready to fork and vendor the roughly 100 lines involved.
- Is nova-detached-filters actively maintained, and what are the alternatives?
- It is an MIT package with a single maintainer and a modest star count, so treat it as a pinned experiment with a fork plan rather than an adopted platform dependency. If you want to avoid a third-party dependency, you can achieve similar results by overriding the resource index toolbar in your own Nova code. For non-Nova admin panels such as Filament, this package does not apply.
- How do I decide which filters are worth detaching?
- Detach only filters your team uses constantly on a given resource, such as status, owner, tenant, or date range, so they stay one click away. Measure the friction first instead of assuming it, and avoid detaching filters that are rarely touched since each one adds toolbar clutter. Keep the change scoped to the specific resources where the benefit is clear.
Weaver
How can I help you explore Laravel packages today?