digital-creative/nova-mega-filter
Digital Creative's Nova Mega Filter adds powerful, customizable filter panels to your Laravel Nova resources, with date, range, and custom filters in a clean UI so you can build advanced search forms and quickly narrow down long resource lists.
Verify the package name before installing. The repository is dcasia/nova-mega-filter, the package is listed as digital-creative/nova-mega-filter. Same org, almost certainly a rename, but confirm the exact Packagist name and the latest tag — the recorded release date (2026-09-19) is anomalous and should be checked against the real tag list.
Read three things, in this order, before you write any code:
composer.json. The require block answers the whole go/no-go question: what Nova constraint does v1.1.0 declare (^4.0|^5.0 or ^5.0 only), and what PHP/Laravel floor does it pull in? Nova 5 implies PHP 8.2+ and a modern Laravel — if that constraint jumped to ^5.0 only, adopting v1.1.0 is a silent platform bump even if you never touch a Nova 5 feature.src/. Find the service provider and the filter class. You need the namespace, whether it publishes config/views, and whether it registers a custom Nova filter component (which is what tells you it's coupled to Nova internals).Pin exactly, and keep a rollback pin. Until dual Nova 4 support is confirmed:
composer require digital-creative/nova-mega-filter:1.1.0
If the package publishes assets, run the publish step and read what lands in config/ and resources/ before committing any of it.
First use case: one low-traffic, non-sensitive resource. Internal Tickets or Users — not Orders, not anything finance reconciles. Register the filter in that resource's filters() method, load the index, and immediately reconcile the filtered result set against the equivalent hand-written query. You are validating that the filter applies at all before you validate that it's pleasant.
// Namespace and constructor signature: confirm in src/ before copying.
public function filters(Request $request)
{
return [
// new \Dcasia\NovaMegaFilter\MegaFilter,
];
}
Then validate on realistic volume. A panel that looks right on 500 seeded rows and silently no-ops on 500k production rows is exactly the failure you're insuring against. Do the pilot in staging against a production-shaped dataset.
Ramp-up for a Laravel-fluent engineer is roughly half a day — the learning curve is the Nova filter API itself, not this package.
Whitelist columns per resource; never auto-expose. The single most important day-to-day decision is which columns each resource offers to the panel. Exposing everything produces a UI ops users can't navigate and a database that scans. Start with three to five columns per resource — the ones that show up in real support tickets — and add only when someone asks.
Model the UI tree as a query tree, and keep it shallow. Users build nested groups; each leaf should map to one of exactly two things:
WHERE column op value, indexed columns onlywhereHas('relation', fn ($q) => ...), one level deep, never twoCap relationship depth deliberately. A three-level nested whereHas across a large pivot table is the most expensive thing an internal user can accidentally do to your admin panel.
Run the new panel alongside native filters first. Don't rip out existing Nova filter classes on day one. Register both on the pilot resource, have a power user run the same query through each, and diff the result sets. That diff is a free correctness test. Consolidate only once they match.
Pair every exposed column with an index, and prove it. Before a column goes into the config, confirm it's indexed; before a relationship goes in, confirm the foreign key is indexed. Then run EXPLAIN on the largest filtered table with the filter active, not on the bare query. An unexplained sequential scan is a blocker for that column.
Treat saved presets as data you own. Presets are what make this package worth adopting — reusable slices ops users save themselves instead of filing engineering requests. But presets are persisted state and they rot: a preset pointing at a renamed or removed column becomes a confusing empty result rather than an error. Keep a documented inventory of presets per resource in the repo (seed the defaults worth standardising), and re-verify them whenever the resource's columns change. Decide up front whether presets are per-user or shared — that determines whether a bad preset is one person's problem or the whole team's.
Test authorization with a restricted user, not an admin. Filters shape result sets, so the question is whether the resource policy still constrains rows once a filter is applied. Log in as a user scoped to one team or region, apply a broad filter, and confirm they can't widen visibility to rows the policy would otherwise hide. Re-run after any policy change and after every Nova upgrade. A filter that widens visibility is a security bug, not a UX bug.
Roll out per-resource, staggered, and document as you go. Staging resource → production resource → next resource. Write down each resource's filter definitions in the internal repo: the panel's behaviour is defined entirely by configuration that isn't visible from the resource class alone, and the person debugging this in six months won't be you.
v1.1.0 is a compatibility release, not a feature release. Its only substantive change is Nova 5 support from a first-time contributor. On Nova 4 with no near-term Nova 5 plan, it's functionally a no-op — don't adopt it for its own sake. On Nova 5 it's the required floor; v1.0.5 won't run there.
The Nova 4 constraint is unconfirmed. The changelog says "Nova 5 Support" but never says what was dropped. If composer.json at the tag became ^5.0 only, you've taken a silent platform bump. Thirty seconds of reading one file prevents the most expensive mistake available here.
Coupling to Nova internals means loud, wide failures. When a Nova major ships without a matching package release, expect a service-provider or class-not-found fatal that takes down the entire admin UI, not just the filter panel. Mitigate with a pinned version, staged Nova upgrades, an entry on the Nova-major-upgrade checklist, and a one-to-two-day fork reserve each cycle.
Silent no-ops are worse than outages. After config drift or an upgrade, a filter can stop applying while the UI renders fine and results still look plausible. Users then trust unfiltered output — exporting "unpaid invoices" that includes paid ones. Guard with a golden-query regression check in staging after every upgrade: a known filter must return the same row count it did before.
Exercise the edge cases explicitly. Groups with zero conditions, groups with one condition, and nested AND-inside-OR-inside-AND are where query builders emit vacuously-true or vacuously-false clauses. Verify each against a hand-written query; the wrong result here is subtly wrong, not obviously broken.
Debug by isolating, not by reading the UI. Start from generated SQL: dump the filter's query with toSql() / getBindings(), then remove definitions from filters() one at a time to find the culprit. Nova's request/query logging (or Telescope) is far more reliable here than inspecting the panel's serialized state.
Extension points, in increasing commitment: publish and override views/config if exposed → subclass the package's filter class to change predicate generation → fork. Under MIT the fork is available; confirm your org's fork policy now, while there's no pressure, rather than during an incident. Write the escalation path somewhere executable — upstream issue → in-house patch/fork → hand-rolled Nova filter classes. This is community-supported software with no SLA and effectively one maintainer; it should never sit on a critical-path runbook without that path defined.
Name an owner. The real risk is ownership concentration upstream; it needs a matching owner on your side who tracks tags and tests Nova upgrades. That person also owns the preset inventory and the golden-query checks.
How can I help you explore Laravel packages today?