- Does smoked/filter-manager-bundle work with Laravel?
- No. It is a Symfony bundle (FilterManagerBundle) built around bundle bootstrapping, a DI extension, and Doctrine queries, so there is no package discovery, service provider, or Eloquent integration for Laravel. In a Laravel app the realistic path is to read the filter-definition model and re-implement it as an internal module or Eloquent scopes. Treat it as a design reference, not a drop-in dependency.
- How do I install smoked/filter-manager-bundle?
- In a Symfony app you would add it with composer require smoked/filter-manager-bundle and register the bundle in config/bundles.php, but there are no tagged releases, so pin it to a commit SHA or fork it privately. In Laravel there is nothing to install; copying classes into app/Support/Filtering and stripping the Symfony plumbing is the only sensible route. Check composer.json for PHP and symfony/* constraints before attempting anything.
- Which PHP and Symfony versions does it support?
- There are no published releases, no CI signal, and no documented constraints in the repository overview, so the supported PHP and Symfony ranges are unknown until you read composer.json. Zero stars and zero dependents mean there is no downstream evidence of which versions actually work. Assume pre-Symfony-6 APIs until proven otherwise and budget time for compatibility work if you adopt any code.
- Can I use it with Eloquent instead of Doctrine?
- Not directly. The bundle is built to compose Doctrine query criteria, so its output is tied to Doctrine's query builder rather than Eloquent's builder. Porting means keeping the filter-set and registry concepts and rewriting the execution layer as Eloquent scopes or a query-builder integration. That is an adaptation, not a configuration change.
- How are filters defined and registered in this bundle?
- The bundle centers on named filter definitions grouped into reusable filter sets, registered through Symfony service configuration and applied through a service-based API. Filter types are extensible, which is the part worth studying for a per-category catalog. Whether registration is config-driven or hardcoded should be verified in the source before you plan a Laravel equivalent.
- Does it validate filter and sort fields against an allowlist?
- That cannot be assumed. A filter manager converts user-supplied parameters into predicates by design, and with no visible test suite there is no evidence that column names and sort keys are allowlisted rather than interpolated into DQL. Audit the query-construction path before it touches a revenue page. In a Laravel rebuild, validate every filter and sort key against an explicit allowlist at the request boundary.
- Does it support faceted search, counts, or price ranges?
- The overview describes boolean query criteria for product lists and advertises extensible filter types, with no mention of aggregation, facet counts, or range filters. Multi-select attributes, price bands, variant-level attributes, and stock or visibility predicates are exactly the cases with no downstream usage evidence. Assume you will build those filter types yourself on top of the abstraction.
- Is it safe to use in production on a product listing page?
- The dominant risk is provenance: a single-maintainer, zero-adoption component sitting directly in the query path of a revenue page. Add unversioned releases, no CI, and unknown security posture around user-supplied parameters, and direct adoption is hard to justify. If you reuse any code, fork or vendor it, pin a commit SHA, and wrap it behind a single resolver interface you control.
- What are good Laravel alternatives for filtering product lists?
- spatie/laravel-query-builder is the usual baseline for allowlisted filtering and sorting on Eloquent, and it has real adoption and tests. Custom filter value objects plus Eloquent scopes, or a dedicated ProductFilterResolver seam, give you the same registry-and-filter-set shape without a Symfony dependency. Copy the abstraction from this bundle and take the implementation from a maintained Laravel package.
- How do I port the filter model from this bundle into Laravel?
- Vendor the filter classes into app/Support/Filtering, discard the bundle bootstrapping and DI extension, and expose them behind one ProductFilterResolver interface applied at the request boundary. Preserve upstream history and pin to a commit SHA so a future revival stays mergeable. Keep the engine swappable, SQL scopes today and Scout or Meilisearch later, so the filter contract survives a search backend change.