Download the PHP package ptplugins/filament-auto-filters without Composer

Filament Auto Filters

Automatic table filters for FilamentPHP v3, v4, and v5 based on your column definitions. Stop writing repetitive filter code - just define your columns and get smart filters for free.

Single codebase across all three Filament major versions - same trait, same API.

🎯 Try it live · ptplugins.com/demo/auto-filters - no signup, click any column, see filters generate themselves.

The Problem

Every Filament resource needs filters. For a typical table with 10 columns, you end up writing 10 filter definitions - most of which follow the same patterns. Date columns get date pickers, text columns get search inputs, relationships get whereHas queries.

Before (manual filters for each column):

After (one line):

Installation

The package auto-discovers its service provider. No manual registration needed.

Publish Configuration (optional)

Quick Start

Add the trait to your Filament resource and call autoFilters():

That's it. Every TextColumn in your table now has a filter.

Full Example: Employee Management

Let's walk through a real-world scenario. You're building an HR module with an Employee model that has direct columns, a department relationship, and a JSON data column for flexible fields.

The Model

The Resource

What Gets Generated

The plugin inspects each column and generates the right filter type. Detection rules:

For our Employee example (8 columns), all 8 filters are generated from zero lines of filter code. Same applies to a table mixing IconColumn and SelectColumn - they get their right filter automatically.

Overriding Specific Filters

Auto-generated filters are great for most columns. But sometimes you need a SelectFilter with specific options, or custom logic. Pass your explicit filters as overrides - they replace any auto-generated filter with the same name:

Result: department.name and salary use your custom filters. The remaining 6 columns still get auto-generated filters.

Overrides get inline labels too. When inline_labels is true (the default), autoFilters() applies inlineLabel() to your overrides as well, so the whole panel keeps one uniform Label [input] rhythm - you don't have to inline each override by hand. This works for SelectFilter / TernaryFilter overrides (like the SelectFilter::make(Employee::SALARY) above). An override you build with ->form([...]) is the one exception - inline those yourself (see the note below).

Skipping Columns

Some columns don't need filters. Pass their names in the skip array:

Combining Overrides and Skips

Rules:

1. Filters come out in column order - the panel mirrors the table header
2. An override takes the slot of the column it replaces (matched by original name or filterName() slug); overrides matching no column are appended last
3. Columns in the skip list are skipped
4. Everything else gets an auto-generated filter

Distinct-Value Select Filters

A text filter is the safe default, but users often want a dropdown of the values that actually exist - e.g. a multi-select of the cost amounts present on one event. Opt in with distinct:

How it behaves:

• Options are the distinct, non-null values from the table's own query - scopes and constraints (e.g. a relation manager's owner record) are kept, ordering and eager loads are dropped. Values are sorted naturally and used as both key and label.
• Date columns are never converted.
• A column with no values, or with more than distinct_max_options (default 50) distinct values, silently stays a text filter - a 5000-row list never gets a 5000-option select.
• Options are resolved when the filters are built (one SELECT DISTINCT per column). On large tables name a few columns instead of distinct: true, or supply your own resolver:

The resolver receives the original column name and returns either a flat list of values (sorted naturally, value doubles as label) or a ready value => label map when you want formatted labels (order and labels kept as-is). null / empty values are dropped and the threshold still applies.

Panel Order and Grouping

Column order is a good default - the panel mirrors the table header. But a panel people use every day usually wants its own order, and the filters a team reaches for first rarely sit first in the table.

Pass order with the labels (or filter names) in the order you want:

• Entries are matched against the filter's label first, then its name, so either works - and a stakeholder can hand you the list as they read it on screen.
• Date range filters are one filter with two fields, so they appear once in the list.
• The list does not have to be exhaustive: filters you leave out keep their relative order and follow the listed ones, so a column added later shows up at the end instead of disappearing.
• Labels are compared with whitespace collapsed, so a column label broken across lines for the table header ("Sent to payment\non") still matches 'Sent to payment on'.

Collapsed groups

Fifty filters bury the handful people actually use. Fold the long tail behind a heading with groupFilters():

• Each section lands where its first member sat, so the order from order: carries over; everything else stays at the top level.
• Sections are collapsed by default - pass collapsed: false to have them open.
• A group whose members are all missing from this table produces no section, so one shared schema can serve several resources.
• Override makeFilterSection() to restyle the wrapper.

API Reference

autoFilters(Table $table, array $overrides = [], array $skip = [], bool|array $distinct = false, array $except = [], ?Closure $distinctOptionsUsing = null, array $order = []): array

The main method. Inspects every column in the table, in column order, and generates an appropriate filter for TextColumn, IconColumn->boolean(), and SelectColumn. Other column types are skipped - pass them explicitly via overrides. See Panel Order and Grouping for order.

orderFilters(array $filters, array $order): array

Reorders a filter array against a list of labels and/or filter names. Unlisted filters keep their relative order and follow the listed ones. Called for you when autoFilters() receives order.

groupFilters(array $filters, Table $table, array $groups, bool $collapsed = true): array

A filtersFormSchema() callback that folds the named filters into collapsible sections. $groups maps a section heading to the labels and/or filter names it holds.

makeFilterSection(string $heading, array $components, bool $collapsed): Section

The section wrapper used by groupFilters(). Override to restyle it.

makeDistinctSelectFilter(Table $table, string $name, string $label, ?Closure $optionsUsing = null): ?SelectFilter

Builds a multi-select of a column's distinct values, or returns null (caller falls back to a text filter) when there are none or more than distinct_max_options.

distinctColumnValues(Table $table, string $name): array

Distinct non-null values of a direct / JSON / relationship column in the table's current query.

makeTernaryFilter(string $name, string $label): TernaryFilter

Creates a yes/no/all ternary filter for a boolean column. Handles direct, JSON, and relationship columns the same way as the other helpers.

makeSelectFilter(string $name, string $label, array|Closure $options): SelectFilter

Creates a select dropdown filter that automatically handles:

• Direct columns - standard whereIn query
• JSON columns (data.xxx) - uses attribute() with arrow notation
• Relationship columns (rel.col) - uses whereHas query

By default, select filters are multiple-choice and searchable (configurable).

makeDateRangeFilter(string $name, string $label): Filter

Creates a date range filter with "from" and "until" date pickers. Handles relationship and JSON columns the same way.

makeTextFilter(string $name, string $label): Filter

Creates a text search filter (LIKE contains). Handles relationship and JSON columns automatically.

resolveColumn(string $name): array

Resolves a column name into its type and query components. Used internally, but available if you need to build custom filters with the same column-detection logic.

Returns:

• ['type' => FilterType::Direct, 'query_column' => 'name']
• ['type' => FilterType::Relationship, 'relationship' => 'department', 'column' => 'name']
• ['type' => FilterType::Json, 'query_column' => 'data->position']

Configuration

Publish the config file to customize defaults:

Optional: Pikaday date picker

Date range filters use Filament's native DatePicker by default. If you install the lightweight ptplugins/filament-pikaday package (no jQuery, no moment.js), you can route every auto-generated date filter through it instead - set prefer_pikaday => true:

The flag is a no-op when Pikaday isn't installed - auto-filters falls back to the native DatePicker automatically, so it's safe to enable in shared config.

inline_labels defaults to true because that's what pairs best with the recommended slide-over panel below. Set it to false if you keep the default Filament dropdown layout (the dropdown is narrow and inline labels can look cramped) or if you simply prefer stacked labels.

Recommended UX: Slide-Over Panel + Inline Labels

Out of the box Filament renders filters as a dropdown attached to a small "Filter" button - fine for one or two filters, cramped once a table has six or more. With auto-generated filters every column suddenly has a filter, so the dropdown stops scaling.

By default the trait applies inlineLabel() to every form field it generates (label on the left of the input, single row per filter - controlled by inline_labels in the config). That layout is tuned for a wide panel - pair it with a slide-over on the Resource and you get a "Linear / Notion"-style filter sidebar like our live demo:

What changes for the user:

• Click Filter → panel slides in from the right.
• Each filter is one row: Label [input] (from inlineLabel()).
• Apply / Reset live in the panel footer; close = Esc or click outside.
• Table reclaims the vertical space the old dropdown took.

This is purely Filament's Table API - no extra CSS, no Livewire plumbing. The trait stays focused on filter generation; this snippet is the matching presentation.

Uniform inline labels across every filter type

When inline_labels is true (the default), every auto-generated filter renders with an inline label on the left and the input on the right, including the awkward cases that don't accept inlineLabel() directly:

Result: every row in the slide-over reads as [Label] [input] - same vertical rhythm whether the column behind it is text, date, boolean, select, JSON, or a relationship, and whether it was auto-generated or supplied as an override.

Set inline_labels => false in the published config to skip all of the above and get stacked labels instead - better suited to the default dropdown layout.

The one case autoFilters() can't inline for you: an override built with Filter::make()->form([...]). Filament returns a user-supplied form schema verbatim and never runs modifyFormFieldUsing on it, so applyInlineLabel() (and therefore the override pass) is a no-op there. Add ->inlineLabel() to every form component in the schema yourself - exactly as the package's own text and date filters do.

How Column Detection Works

The plugin uses a simple naming convention to detect column types:

• Dot notation with a data. prefix → JSON arrow notation
• Dot notation without data. prefix → Eloquent relationship
• No dots → direct database column
• Date/DateTime detection uses Filament's built-in isDate() / isDateTime() methods on TextColumn

Requirements

• PHP 8.2+
• FilamentPHP 3.x, 4.x, or 5.x (single codebase across all three)
• Laravel 10, 11, or 12

License

MIT