- Can I use ongr/filter-manager-bundle in a Laravel application?
- Not directly. This is a Symfony bundle whose coupling points are Symfony dependency injection (compiler passes, service tags, configuration tree), HttpKernel request handling, and the ONGR Elasticsearch bundle stack. Installing it in Laravel effectively means adopting Symfony's container and that entire search stack alongside your framework. For a Laravel target, fork and extract the domain layer, or reimplement the filter-to-query compilation against your existing client.
- Is ongr/filter-manager-bundle still maintained?
- The last release was May 2022, and the repository has roughly 26 stars and zero dependents. There is no documented security patching path, and several transitive dependencies are themselves dormant. The zero-dependents signal matters because no downstream community is exercising this code against current PHP, Symfony, or Elasticsearch versions. Treat it as a reference architecture rather than a dependency you inherit.
- Which Elasticsearch versions does the bundle target, and does it work with OpenSearch?
- The ONGR Elasticsearch bundles target the Elasticsearch 5, 6, and 7 era through ongr/elasticsearch-bundle and ongr/elasticsearch-dsl. Elasticsearch 8 and OpenSearch support are not established and should be verified before any design commitment. If the pinned client major is one you cannot run in production, extraction becomes mandatory rather than optional. Confirm the exact DSL constraints and whether there is a clean seam to swap the client.
- What does ONGR FilterManagerBundle actually do for product listings?
- It adds configurable filtering, sorting, pagination, and aggregations to Symfony applications backed by Elasticsearch. Filter types such as choice, range, boolean, and multi-select are registered as tagged services, a manager service collects active filter definitions per request, and the result is compiled into Elasticsearch query and aggregation DSL. The practical payoff is faceted search and product listing pages without repetitive query-building code in every controller.
- How do I install and configure the bundle in a Symfony app?
- You require ongr/filter-manager-bundle via Composer, register the bundle in your Symfony kernel, and define filters in YAML configuration. Filter types are wired as tagged services so the compiler pass can collect them, and the manager resolves active filters from the request. There is no Laravel service provider, config publishing, or facade, so none of this transfers to a Laravel skeleton without rewriting the wiring.
- Which PHP and framework versions are supported?
- The package targets Symfony 4 and 5 with a PHP constraint from that generation, not Laravel. There is no declared support for Laravel 10 or 11, and no Laravel integration code exists in the repository. Check the exact php and symfony/* constraints in composer.json before assuming compatibility with your runtime. If you prototype, do it in a throwaway Symfony skeleton so version conflicts do not contaminate your main application's dependency graph.
- Will it cause Composer dependency conflicts in a modern Laravel project?
- Very likely. The package pulls the ONGR Elasticsearch bundle and DSL packages, which pin older Symfony components and an older Elasticsearch client. Modern Laravel applications run newer PHP and Symfony component versions transitively, so constraint conflicts are the expected failure surface. Isolate any experiment in a separate project rather than adding it to your application's composer.json.
- How long does it take to extract the filter logic into a Laravel package?
- Roughly two to four engineer-weeks to fork the repository, strip the Symfony DI and HttpKernel coupling, re-target the DSL layer to a maintained Elasticsearch or OpenSearch client, and build a test suite around the compilation output. The scope shrinks dramatically if you only need choice and range filters, which shifts the build-versus-borrow calculus toward building natively. Reading the filter type contracts and DSL compilation first usually reduces the estimate further.
- How should I test the extracted filter-to-DSL compilation?
- Test the compiler as a pure function: feed filter definitions and request parameters in, assert the generated query and aggregation DSL out. Snapshot or golden-file assertions catch regressions cheaply, and a small integration suite against a real cluster in CI validates that the DSL actually behaves. Because the original code has no dependents exercising it against current stacks, you cannot rely on upstream tests as a safety net.
- What is the best alternative for faceted search and product filtering in Laravel?
- In descending order of preference: implement a native filter manager against your existing search client, fork and extract the ONGR domain logic into an internal Laravel package with a service provider and config file, or run the bundle as-is in a small Symfony service that exposes filter resolution over HTTP. The third option preserves the package intact but adds a network hop, a second runtime, and operational surface for what is fundamentally a query-building concern. Most Laravel teams are better served by the first route.