Statamic Livewire Filters Laravel Package

Product Decisions This Supports

• Build vs. buy for faceted filtering. This package supplies the full loop a PM would otherwise scope as a multi-sprint feature: filter UI components, URL-shareable filter state, faceted value counts, and a Livewire round trip that returns the filtered collection. For a Statamic site with attribute-rich content, that is a large chunk of a discovery/search epic bought instead of built.
• Shipping a security fix without a custom project. v4.6.0 closes a real class of defect — client-supplied filter state being able to smuggle Statamic query controls (status, from, site, limit, paginate, since/until, filter) and change which entries are returned rather than how they are filtered. It ships on by default with no configuration, which means the PM decision is "schedule the upgrade," not "fund a remediation effort."
• Risk register and launch gating. If faceted filtering is on the roadmap for a launch, this release is the version to gate against: locked identity properties, setParameters() made protected, rejection of :-prefixed keys (Antlers expression injection), and URL state sanitized on load all reduce the surface a security review would flag.
• Differentiation on listing UX. Opt-in dynamic range bounds narrows price/date/size sliders to values that still match the other active filters, without moving the visitor's own selection and disabling a slider with no room left. That is a visible, demoable UX improvement for catalog and directory products; it is opt-in, so it can be trialed on one listing page.
• Cheap performance polish. Removing a filter tag and "Clear all" now complete in one Livewire round trip instead of two; no-op events skip re-rendering; faceted counts are computed from the same filtered state as the entries query, so counts and results stop disagreeing. These are free wins to fold into a "listing performance" line item.
• Prioritization signal from the upgrade list. The upgrade path is mechanical but not zero-touch: clear config/static caches, allowlist any control key visitors legitimately change via URL, listen for clear-all-filters in custom filter components, add the new optional $boundsSelection = null parameter to subclass overrides of filterUpdated() / clearFilter() / clearFilters(), and re-publish customized range views if enabling dynamic bounds. Estimate it as a small, checklistable ticket — and note the one real behavioral risk: a filter targeting a field named like a control key (e.g. status:is) will silently stop working unless the key is removed from blocked_query_params or allowed via allowed_filters. Audit existing filters before upgrading.
• Representative use cases: property and real-estate listings, product catalogs, directories, job boards, editorial archives — Statamic collections with many filterable attributes and a server-rendered front end.

When to Consider This Package

Adopt when most of these hold:

• The stack is Statamic + Livewire + Blade, and the front end is server-rendered rather than a SPA.
• Filter state must be shareable and restorable via URL (campaign links, saved searches, SEO landing pages) — the release notes show URL hydration is a first-class, now-sanitized path.
• You want faceted counts, range/dual-range, toggle and tag filters without maintaining component internals; published views can be customized when the defaults run out.
• Dataset size is moderate — this is query-level filtering against Statamic's data layer, not a dedicated search engine.
• Someone owns the upgrade: this release rewards teams that will actually run config:clear/static:clear and read the upgrade list. Skipping those steps leaves the blocklist unset and nothing protected.

Look elsewhere when:

• The front end is headless/SPA (Next, Nuxt, etc.) — Livewire is the delivery mechanism, so the package does not apply.
• The catalog needs relevance ranking, fuzzy matching, synonyms, typo tolerance, or very large indexes — that is Algolia/Meilisearch/Elastic territory, and filtering here would become a bottleneck.
• You need a rich nested boolean query builder or arbitrary end-user query composition; the blocklist direction in this release is explicitly the opposite posture.
• The team cannot absorb the upgrade checklist now and would run a pre-4.6.0 version in production — in that case do not adopt yet rather than adopt and pin to a version with the injection issue.
• You are not on Statamic, or your filter requirements are trivial enough that a handful of query scopes and a Blade form would do.

How to Pitch It (Stakeholders)

To executives: This is a filtering layer for our Statamic listings, and the new version closes a security hole where a crafted URL could change which entries a page returned — not just how they were filtered. The fix is on by default, so the cost is an upgrade ticket, not a project. It also buys us a feature we would otherwise build: URL-shareable filters, live faceted counts, and sliders that adapt to the other active filters. Net: one small upgrade, lower security exposure, and a catalog UX we don't have to staff from scratch.

To engineering: v4.6.0 is primarily hardening. blocked_query_params ships pre-populated with Statamic's query-control keys (status, from, site, limit, paginate, since/until, filter, and more), matched on the segment before the first colon so status also blocks status:is. Tag-set and init-hook parameters are always preserved, and allowed_filters is the escape hatch. Filter identity properties are #[Locked], setParameters() is protected, :-prefixed keys are rejected, and URL state is sanitized on load with tag-only params never read from the URL. The event contract was kept compatible — one-argument params-updated listeners still work — and the opt-in enable_dynamic_range_bounds flag means no behavior change unless we ask for it. Required steps: clear config and static caches, audit filters on fields named like control keys, allowlist any control key visitors legitimately set via URL, add clear-all-filters listeners to custom filter components, add the optional $boundsSelection = null parameter to subclass overrides, and re-publish or merge the range-bounds-updated listener into customized range views if we enable dynamic bounds.