Statamic Filter Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for content filtering UI. This package provides a ready-made Statamic control-panel fieldtype that lets editors compose filter/sort rule sets visually (drag-and-drop cards, collapsible groups, duplicate prevention, Collapse/Expand All). That is typically 4–8 weeks of custom CP work plus ongoing Statamic-version maintenance — so the default decision shifts toward adopting it rather than building in-house, provided you are on the supported stack.
• Roadmap gating on CMS/platform upgrades. v2.0.0 is a hard fork-and-rewrite targeting Statamic v6 / Laravel 12 / PHP 8.2+ with a new namespace (Cbox\FilterBuilder). Any planned Laravel 12 or Statamic 6 upgrade should now list this dependency as an explicit line item with a migration task, not an incidental Composer bump.
• Feature parity decisions for end-user filtering. The release adds capabilities that directly map to product asks: dark mode (accessibility/editor satisfaction), validation error surfacing (reduces support tickets from misconfigured filters), collection-switch memory (editor efficiency on multi-collection sites), and read-only empty states (cleaner permissions story for non-editor roles).
• Scope semantics alignment. "Scope field alignment" now intersects fields across collections to match fieldtype behavior — this is a correctness fix that affects what results editors can produce. Relevant if you have QA/test cases asserting on scope behaviour; those expectations likely need revisiting.
• Localisation commitments. Full Danish translations mean the CP experience can ship to Danish editorial teams without custom translation work — usable as evidence for Nordic-market roadmap items.
• Maintainability/quality signal for a dependency review. PHPStan level 9 and a Pest 3 suite (19 tests across scopes, variable parsing, collection tag hooks) are credible signals of maintained code, useful when justifying the dependency to an architecture review or security questionnaire.
• "Dynamic Values" repositioning. Renaming "Variables" and adding inline Antlers syntax examples plus an instructions block is a product decision about who the feature is for: it lowers the floor for editors who know a little Antlers, but signals the feature is still developer-adjacent rather than fully abstracted.

When to Consider This Package

Adopt when:

• You are on (or committed to) Statamic 6, Laravel 12, PHP 8.2+ — these are hard requirements in v2.0.0, and there is no supported path on older versions.
• Your editors need self-service, structured filtering and sorting on front-end listings (search results, archives, catalogues) without a developer writing a query each time.
• You already accept Statamic as your CMS; this is an addon, not a framework-agnostic library.
• You value the CP-native UX — Vue 3 Composition API components, Statamic v6 UI primitives (DragHandle, Combobox, SortableList, PublishFields), dark mode — over a bespoke admin UI.
• You can absorb a one-time namespace migration (Tv2regionerne\StatamicFilterBuilder → Cbox\FilterBuilder) and re-test any custom code referencing the old namespace, published config, or stored field data.

Look elsewhere or defer when:

• You are still on Statamic 4/5 or Laravel ≤11 — v2.0.0 will not install, and v1.x is now effectively legacy with no stated support window.
• You are not on Statamic (WordPress, Craft, headless-only, custom Laravel admin) — the value is almost entirely the Statamic CP integration.
• You need vendor-backed SLAs, security disclosure processes, or long-term support commitments. This is a fork of tv2regionerne/statamic-filter-builder, redistributed under a new namespace. Forks carry real risk: upstream divergence, bus-factor of one, and unclear ownership of future fixes. Treat it as a community dependency and mirror it internally if it becomes load-bearing.
• Your filtering needs are trivial and static (one or two hardcoded sort options) — the CP surface area is more than you need.
• You require full front-end rendering ownership — the package gives you the rule-building UI and query scoping, but templates/Antlers output remains your responsibility.
• Version ambiguity is unresolved. The release notes simultaneously state "rewrite for Statamic v6" and "Requires Statamic 5.x (v6 addon API)." Confirm the actual supported Statamic version in composer.json before committing a platform upgrade timeline around it — this is the single blocking question to close.

How to Pitch It (Stakeholders)

Executives / sponsors (one paragraph): We evaluated a Statamic addon that gives editors a drag-and-drop interface for building content filters and sorts, replacing what would otherwise be several weeks of custom admin development. The new v2.0.0 release modernises it for our target stack (Statamic 6, Laravel 12, PHP 8.2+), adds dark mode, inline validation feedback, and Danish localisation, and ships with static analysis at the strictest level plus an automated test suite — meaningful evidence of quality for a free dependency. The trade-offs are that it is a community fork rather than vendor-supported, it locks us to the newest Statamic major, and it requires a one-time code migration due to a namespace change. Recommendation: adopt for editorial filtering, budget the migration explicitly in the platform-upgrade plan, and keep an internal fork as contingency.

Engineering: The upgrade is a breaking change, not a drop-in. Action items: (1) confirm the true Statamic requirement — the notes say both "v6 rewrite" and "requires Statamic 5.x (v6 addon API)"; resolve against composer.json before sequencing; (2) update the namespace Tv2regionerne\StatamicFilterBuilder → Cbox\FilterBuilder anywhere we reference it, including published config and any container bindings; (3) budget a regression pass on scope behaviour, since scope now intersects fields across collections to match fieldtype semantics; (4) PHP 8.2+ and Laravel 12 are baseline prerequisites — verify CI images; (5) the Vue 3 Composition API rewrite means any local overrides of published views/composables must be re-applied, not merged.

Editorial / content ops: The interface now matches Statamic's own replicator card pattern with drag handles, collapsible cards and preview text, so it should feel familiar with no training. Already-added fields disappear from the dropdown (prevents duplicates), invalid items get a red border so editors can self-correct, switching collections and back preserves work, and the "Dynamic Values" field now carries an inline Antlers example. Read-only users see explanatory empty states instead of a blank panel.

Product recommendation: Adopt, conditional on closing the Statamic version ambiguity and confirming we are on the Laravel 12 / PHP 8.2 baseline within the current planning horizon. If the upgrade window slips, stay on v1.x and revisit — do not attempt to run v2.0.0 on an unsupported stack.