- Does ite/filtration-bundle work with Laravel?
- No. It is a Symfony bundle built on the Symfony dependency injection container and Bundle registration, and it filters Doctrine QueryBuilder objects and ArrayCollections rather than Eloquent models or the Laravel query builder. Running it in Laravel would mean adding a Doctrine persistence layer and rebuilding the bundle's service configuration by hand, which is a port rather than an install. For Eloquent applications, Laravel-native filter packages are the realistic choice.
- How do I install ite/filtration-bundle?
- Install it with Composer using composer require ite/filtration-bundle, then register the bundle in your Symfony kernel, or in bundles.php under Symfony Flex, so its service definitions are loaded. Filter definitions are then attached to Doctrine entities via annotations or attributes and applied to a query builder from a controller or service. On a current Symfony application expect the version constraints to block installation unless you fork.
- Which Symfony and PHP versions does this bundle support?
- Bundles of this vintage typically pin Symfony 2.x or 3.x and PHP 5.6 through 7.x constraints, so Composer will usually refuse installation on a modern Symfony 6/7 or PHP 8.3 stack. Check the composer.json constraints before planning anything around it. Any workaround on a current stack means maintaining your own fork.
- How do I define a filter on a Doctrine entity?
- Filters are declared declaratively, through annotations or attributes on the Doctrine entity, as a whitelist of fields with per-field operators instead of query code scattered through repositories. The bundle reads those definitions and translates incoming request parameters into query builder conditions. This keeps controllers and repositories clean, but ties the filter configuration tightly to Doctrine entities.
- What filter types does the bundle support?
- The bundle ships filter classes for text, choice, date, and boolean fields, plus relation filters for associations. Each type maps a request value to an operator on the underlying query. Custom logic is supported by extending the filter classes, and the filter set is fixed at configuration time rather than assembled ad hoc per request.
- Can I apply one filter definition to both Doctrine queries and in-memory collections?
- Yes. The bundle targets Doctrine QueryBuilder and ArrayCollection, so the same filter definitions can run in tests against in-memory data and in production against the database. That dual-source capability is the most interesting property of the package. Be aware that the two code paths can diverge in their results, which produces hard-to-diagnose bugs, so pin the behavior with tests that exercise both.
- Are request-driven filter and sort parameters safe from SQL injection?
- Filter and sort parameters are user-controlled by definition, so safety depends entirely on field names being strictly whitelisted against a server-side schema before any dynamic query builder interpolation. An unmaintained package with no realistic CVE response path should not be trusted with that by default. Audit the whitelisting yourself, or implement the filtering layer in-house where you control it.
- How do I test the filtering logic without a database?
- Because the bundle can filter ArrayCollections, you can build collections in a unit or integration test and assert the filtered output without touching a database. That keeps filter tests fast and lets you cover the same definitions used by production queries. Add at least one test against real SQL to catch divergence between the in-memory and query code paths.
- What are the Laravel alternatives to this bundle?
- For whitelisted filter, sort, and include parsing against Eloquent, spatie/laravel-query-builder covers the same feature set with active maintenance and a security response process. If you need human-typed search strings, lorisleiva/laravel-search-string is a closer match. Both avoid the Doctrine dependency entirely.
- Is ite/filtration-bundle actively maintained?
- The repository shows essentially no adoption, around one star and zero dependents, with a single maintainer and no realistic path to a PHP 8.3 compatibility patch or a security response. Treat the repository as a specification for a filtering pattern rather than a dependency you can rely on. If you need the behavior, a vendored fork with a named owner and a sunset date is the only responsible option.