Nova Datepicker Filter Laravel Package

Getting Started

adtention/nova-datepicker-filter is a Laravel Nova filter that swaps the default date filter UI for a datepicker, so you can filter a resource index by a date/datetime column without hand-rolling a custom filter. Version 1.1.0 only ships “Improved date parsing,” so there are no breaking changes or new APIs to account for — treat this as a patch-level upgrade you can pull in safely.

Minimal steps:

1. Install and update:

   composer require adtention/nova-datepicker-filter
   php artisan vendor:publish --tag=nova-datepicker-filter   # only if the package exposes config/assets
   

   If you are already on 1.0.0, just run composer update adtention/nova-datepicker-filter and clear Nova’s compiled assets (php artisan nova:publish if you publish assets).

2. Look first at the package’s filter class (typically under vendor/adtention/nova-datepicker-filter/src) to confirm the exact class name and its apply() / options() signatures. That is the contract you wire into your resource.

3. Register the filter on a Nova resource:

   use Adtention\NovaDatepickerFilter\DatepickerFilter; // confirm exact namespace
   
   public function filters(Request $request)
   {
       return [
           DatepickerFilter::make('Created At')
               ->column('created_at'),
       ];
   }
   

4. First use case: filter an index (e.g. Orders, Users, Posts) by a single date or date range on created_at. Open the resource index, click Filter, pick a date, and confirm the query is scoped as expected.

Because changelog detail is thin, verify behavior on your own Nova version before rolling beyond staging.

Implementation Patterns

Single-column date filtering. The common pattern is one filter per date column you care about:

DatepickerFilter::make('Created At')->column('created_at'),
DatepickerFilter::make('Published At')->column('published_at'),

Multiple filters on one resource. Nova filters are additive; register several datepicker filters and let users combine them. Keep labels distinct so the filter panel reads cleanly.

Scoping to a related column. Pass a qualified column (e.g. orders.created_at) when the index query joins tables, and confirm the package builds a whereDate/whereBetween against that qualified name.

Pairing with other filters. A datepicker filter composes naturally with status/ownership filters. Document the intended combinations in your team’s Nova usage notes, since Nova applies filters sequentially.

Integration tips:

• Keep the filter logic in the package class and avoid overriding apply() unless you need custom boundaries (e.g. inclusive end-of-day handling on datetime columns).
• If your resource uses a custom index query, test the filter against it — date filters are a common source of timezone-boundary surprises.
• Add a simple feature test that hits the Nova index endpoint with the filter’s query string to lock in behavior across Nova upgrades.

Upgrading from 1.0.0. The only change is improved date parsing, so no code changes should be required. Re-run your date-filter tests specifically around formats like Y-m-d, ISO datetimes, and ambiguous inputs — that is where “improved parsing” will show up.

Gotchas and Tips

• Timezone and boundary behavior. Date-only filters against datetime columns frequently exclude records late in the day. Confirm whether the package uses whereDate (day-level) or whereBetween (exact boundaries), and normalize the user’s timezone if your app stores UTC.
• Parsing changes are the 1.1.0 risk surface. “Improved date parsing” can mean previously tolerated formats now behave differently. Check any saved filter URLs, bookmarked index links, or hard-coded filter values in tests.
• Namespace and class name. Confirm the exact class from vendor/ rather than assuming — filter classes are the one thing you must get right at registration.
• Nova asset cache. After upgrading, stale compiled assets can mask changes. Run php artisan nova:publish (or your asset pipeline) and hard-refresh the browser.
• Filter persistence. Nova can persist filters per user; users may not see new behavior until they reset their active filters.
• Custom apply() overrides. If you subclassed or overrode the filter, re-test after the update — parsing changes can shift how $value arrives at your code.
• Extension point to watch. The filter’s options/config (default column, format, range vs. single date) is where you’d customize behavior; keep those settings centralized if multiple resources share the filter.
• Debugging: temporarily log the resolved $value and the generated SQL (DB::listen) when a filter returns unexpected results — it quickly distinguishes a parsing issue from a query/column issue.

Given the scope of 1.1.0, this is a low-risk update: bump the dependency, re-run date-related filter tests, and watch for any parsing-format regressions.