- Can I install gl3n/http-query-string-filter-bundle in Laravel?
- No. It is a Symfony bundle that hooks Symfony's kernel.request event, reads Doctrine annotations on controllers, and delegates to Symfony Validator and Security. Laravel has no bundles, kernel.request listener, or annotation-driven controller metadata, so the package cannot be installed and used as intended in a Laravel app; only its design pattern transfers.
- What does this package actually do?
- It turns HTTP query-string parameters into safe Doctrine filters, letting API clients filter, sort, and paginate entities through URLs. Filter definitions are configurable per entity and support operators. Validation, type casting, and per-parameter authorization are handled through Symfony's Validator and Security layers.
- Is this package still maintained?
- No. The last release was 2016-03-08, roughly nine years ago, targeting PHP 5.5–7.0 and Symfony 2.8/3.x. It has about 5 stars, zero dependents, and a single maintainer, so there is no downstream usage to validate it and no realistic path to upstream fixes.
- Does it work with PHP 8 or Symfony 4 and newer?
- Almost certainly not. The code targets PHP 5.5–7.0 and Symfony 2.8/3.x, so it likely uses APIs removed in Symfony 4+ and language constructs deprecated or removed in PHP 8.x. Even in a Symfony shop it would not install cleanly today without a rewrite.
- What Laravel versions does this package support?
- None. There is no Laravel version support because this is not a Laravel package. For Laravel you would need to rewrite the concept as middleware or FormRequest::prepareForValidation(), with Laravel Validator rules, casts, and per-parameter authorization.
- How would I replicate this bundle's behavior in Laravel?
- Map each Symfony piece to a Laravel equivalent: kernel.request listener to middleware or FormRequest::prepareForValidation(), Doctrine annotations to PHP 8 attributes or a rules()/casts() pair, Symfony Validator constraints to Laravel Validator rules, and annotation-declared authorization to authorize() or a policy call per parameter. The cleanest shape is a QueryParameter object or FormRequest that validates, casts, and authorizes each parameter explicitly.
- What are the security risks of using this package?
- Treat it as high risk. Abandoned input-handling code has no CVE monitoring or patching path. Specific hazards to assume until disproven include loose type coercion such as '1abc' becoming 1, incomplete handling of array-vs-scalar parameter pollution like ?page=1&page=2, and authorization checks that fail open on unrecognized annotation shapes. A fork inherits those risks plus the burden of auditing code no one on your team wrote.
- Is this package suitable for production?
- No, not as a dependency. For Laravel it cannot run as intended; even for Symfony its age, abandoned status, and security-relevant input surface make it unsuitable for production. Use the repository as a design reference and cite it as prior art in an internal build.
- What alternatives should I consider for Laravel query-string filtering?
- For Laravel, build the capability natively with middleware, FormRequest::prepareForValidation(), casts(), rules(), authorize(), and policies. Packages like spatie/laravel-query-builder can cover filter, sort, and pagination mechanics, but per-parameter authorization (for example, 'may this caller filter by cost_center?') usually still needs hand-built, reviewed code. If you have no Symfony surface, this bundle has no applicable runtime.
- Should I fork this bundle for Laravel or build fresh, and how should I test it?
- First decide whether you need a dependency or a pattern; the recommendation diverges sharply and a pattern is the likely real need. If you have no Symfony surface now or planned, there is no runtime to adopt. If you fork, name a maintainer with Symfony annotation experience and budget an audit for coercion, parameter pollution, and fail-open authorization; a fresh Laravel-native implementation is often cheaper and easier to test with focused unit tests for casting, array-vs-scalar inputs, and per-parameter authorization.