Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Awesome Filter Bundle

Awesome Filter Bundle Laravel Package

netbull/awesome-filter-bundle

Netbull AwesomeFilterBundle is a Symfony bundle that adds reusable filter types for building flexible, query-driven filter forms. Simplify filtering logic in your admin panels and listings with configurable, ready-to-use filters that plug into your existing Symfony stack.

View on GitHub
Deep Wiki
Context7

At a glance

Frequently asked questions about Awesome Filter Bundle
Is netbull/awesome-filter-bundle a Laravel package?
No. It is a Symfony bundle, indicated by the Bundle suffix, the netbull vendor namespace, and its integration surface built around Symfony's kernel, service container config tree, and Doctrine bridge. Laravel has no bundle concept, no config/packages YAML, and no autodiscovery hook this package registers against, so there is no integration path, only a rewrite if your target stack is Laravel.
How do I install netbull/awesome-filter-bundle?
It is installable with Composer, but confirm its composer.json constraints against your pinned Symfony LTS and Doctrine ORM major before running a spike. A successful composer require proves dependency resolution only, not runtime behavior against your query layer. Check the README and bundle registration steps for the exact service container configuration it expects.
Does AwesomeFilterBundle support Doctrine ORM 3?
This is the single highest technical risk and is not answered in the available materials. Doctrine ORM 3 changed QueryBuilder and Expr behavior and removed deprecated APIs, so a filter builder written against ORM 2 will fail at runtime rather than at install time. Verify ORM 3 explicitly in the bundle's composer constraints and in its CI test matrix before adopting.
What license does netbull/awesome-filter-bundle use?
AGPL-3.0 is the reported license and is a probable hard blocker for many teams. For network-served products, AGPL section 13 obliges you to offer corresponding source to users interacting over the network, including your modifications. Many enterprises carry a blanket AGPL ban, so legal review is a gating step and must happen before any technical spike.
How does AwesomeFilterBundle bind filter parameters to DQL?
This is unknown from the package signal set and must be read directly in source. Parameter binding discipline matters: if the bundle assembles DQL from request input via string interpolation instead of bound parameters, you inherit an injection surface. Ask the maintainer to show the query-construction path before evaluating further.
Can AwesomeFilterBundle filter nested or related entities?
Nested and relation filtering support is not documented in the available materials. Ask the maintainer directly whether it handles multi-level relation filters and request the emitted SQL for a three-level filter case. Without that evidence, assume simple scalar criteria are the safe scope.
How do you define a filter with AwesomeFilterBundle?
The bundle advertises declarative filter definitions with sensible defaults and composable filters for multi-criteria queries. What is not established is the definition mechanism: attributes, PHP configuration, or YAML each carry different adoption cost. Attribute-driven filtering bleeds into entity classes and is painful to remove later, so confirm this before committing.
Is netbull/awesome-filter-bundle actively maintained?
Treat it as unvalidated: zero stars, zero dependents, and no downstream users to surface bugs, with a bus factor of one. A recent tag on a zero-adoption repository can mean active upkeep or a single commit after dormancy. Check commit cadence, tag cadence, CI configuration, and issue response times directly rather than inferring from release recency.
Does AwesomeFilterBundle work with API Platform custom providers or Elasticsearch?
No, reject it for those persistence layers. The value proposition is Doctrine query construction, so a non-Doctrine stack such as API Platform custom providers, Elasticsearch, or raw DBAL gets none of the benefit and all of the dependency risk. It is viable only on Symfony with Doctrine ORM.
What is a safer alternative to AwesomeFilterBundle for Symfony filtering?
If legal does not clear AGPL and the vendor offers no permissive or commercial license, build a small in-house filter layer. The domain surface is narrow enough that a bespoke FilterCollection to QueryBuilder implementation is a few days of work and carries none of the licensing or bus-factor risk. That path also lets you control parameter binding and Doctrine ORM 3 compatibility directly.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console