Weave Code
Search Bundle Laravel Package
rollerworks/search-bundle
Symfony bundle integrating Rollerworks Search: build user-friendly search forms, parse complex query strings, and translate them into Doctrine ORM/DBAL queries with reusable field definitions, validation, and extensible conditions.
[READ-ONLY] The Symfony bundle of Rollersearch
Frequently asked questions about Search Bundle
- What does rollerworks/search-bundle do?
- It is a Symfony bundle that integrates Rollerworks Search, letting users build search forms, parse complex query strings, and translate the results into Doctrine ORM or DBAL queries. It provides reusable field definitions with validation, Symfony form types such as SearchFieldSetType and SearchFormType, request-to-condition wiring, and a Twig-rendered search form. The bundle is the Symfony host layer; the actual parsing and condition model live in the underlying rollerworks/search core library.
- Is rollerworks/search-bundle compatible with Laravel?
- No. It is a Symfony bundle built around a DI extension, a configuration tree, Symfony form types, and Twig rendering, and none of that host layer exists in a Laravel application. The only genuinely portable piece is the rollerworks/search core, which parses a query string into a normalized SearchCondition object validated against a declared field set. For Laravel you would adopt the pattern or fork the core library, not install the bundle.
- Which Laravel and PHP versions work with rollerworks/search-bundle?
- None officially. The package targets Symfony 2.8/3.x-era APIs and PHP 7.x, and its Doctrine bridge is written for DBAL 2.x and ORM 2.x. Installing it alongside laravel/framework 10 or 11 and Symfony 6/7 components produces Composer conflicts. There is no supported path to a modern Laravel 10/11 plus PHP 8.2 codebase.
- Can I install rollerworks/search-bundle in a Laravel app with Composer?
- Composer resolution is the first blocker: the bundle's Symfony 3.x constraints collide with the Symfony 6/7 components Laravel 10/11 ships, forcing conflicts or --ignore-platform-reqs hacks that you should not accept in production. A realistic path is fork-and-patch: strip the Symfony bundle, pin a forked core library, fix PHP 8 issues such as implicit nullable parameters and Serializable implementations, and upgrade the Doctrine translation layer to DBAL 3/ORM 3. That is engineering ownership, not a dependency install.
- Is rollerworks/search-bundle still maintained?
- No. The last release was 2017-10-23, the repository has roughly 10 stars and zero dependents, and there is no security response capability or PHP 8.x support guarantee. If you adopt it you become the primary consumer and de facto maintainer, including writing any CVE fix yourself. The scope is small and bounded, so forking is feasible, but the risk is that you own it forever.
- What is the Rollerworks field-set allowlist pattern and why should Laravel developers care?
- Rollerworks requires you to declare a field set with field names, types, patterns, and allowed values before a user query string is parsed, and the parsed condition is validated against that allowlist before any backend translation happens. That ordering is exactly what hand-rolled Laravel dynamic-filter code usually lacks, and it is the property that keeps unvalidated field names away from the query builder. The pattern, not the bundle, is the valuable part for Laravel.
- How do I translate Rollerworks conditions to Eloquent instead of Doctrine?
- The core library produces a normalized SearchCondition and delegates translation to a backend-specific condition optimizer or processor, so an Eloquent backend means writing a new translator rather than reusing the Doctrine one. The assessment estimates 2 to 4 engineer-weeks for a spike that handles about 80 percent of field types with a working WHERE clause. The long tail is date ranges, patterns, negation with ! or -, and sub-groups, plus the parser's edge cases.
- Is rollerworks/search-bundle safe to use with untrusted user input?
- Treat it as security-sensitive code. The library sits directly on user input and emits database queries, so a parser bug or a field-set misconfiguration that permits unvalidated field names is an injection vector, and deeply nested conditions are a DoS vector through parser recursion and expensive generated SQL. A near-zero-adoption package with one historical maintainer gives you no community scrutiny, so any adoption needs code review and fuzzing.
- How should I test a forked Rollerworks Search integration in Laravel?
- Fuzz the parser with malformed and deeply nested query strings, and assert that field validation rejects names outside the declared field set before translation runs. Build golden tests that turn representative conditions into expected SQL or query-builder bindings, and cover the tail cases: date ranges, patterns, negation, and sub-groups. Round-trip tests from query string to condition to SQL catch semantic drift from the 2017 documentation.
- What are the alternatives to rollerworks/search-bundle for Laravel?
- Implement the allowlisted field-set to normalized condition to backend translator pattern directly in Laravel; the scope is small enough that a focused implementation of a few hundred lines is realistic. Alternatively, evaluate Laravel query-filter packages that already produce query-builder clauses, or fork the rollerworks/search core and write an Eloquent backend. What you should not do is try to make the Symfony bundle run inside Laravel.
Weaver
How can I help you explore Laravel packages today?