- Can I use atoolo/graphql-search-bundle in a Laravel application?
- No. This is a Symfony bundle that extends the GraphQL schema of an Atoolo application (SitePark's CMS/DXP); it ships no service provider, no Illuminate bindings, and no Laravel-side configuration surface. It assumes a host app that already runs the Atoolo GraphQL interface, atoolo/search-bundle ^1, and a populated search index. Laravel teams realistically have two options: run a minimal Symfony/Atoolo sidecar exposing /graphql and call it over HTTP, or reimplement the query design using the published GraphQL docs as a specification.
- How do I install and register atoolo/graphql-search-bundle?
- Install it with Composer inside an existing Atoolo/Symfony application and register the bundle in your bundle configuration, then confirm the new search queries appear by introspecting the GraphQL schema. You must already have the Atoolo GraphQL interface and atoolo/search-bundle in place, plus a populated search index, or the resolvers have nothing to work against. Setup steps and the available queries are documented at sitepark.github.io/atoolo-docs under develop/bundles/graphql-search and develop/graphql/search.
- Which PHP versions does this bundle support?
- The bundle supports PHP 8.2, 8.3, and 8.4. PHP 8.1 is listed in the README badge but is no longer checked automatically, so treat 8.1 as unsupported. Note that PHP version parity is the only real common ground with a Laravel stack — everything above that (Symfony DI, Atoolo conventions) diverges.
- What does this bundle actually add to the GraphQL schema?
- It contributes search queries, filter and facet input types, and resolvers for resources, teasers, dates, and image/asset data into an existing GraphQL type map. The design is purely additive, so it layers onto the Atoolo GraphQL interface rather than replacing it. The result is a queryable search API rather than a PHP service you call directly from application code.
- Does it support facets, geo filters, and relative date ranges?
- Yes. The search features are fairly domain-specific and non-trivial: facets, spatial/geo filters, relative date ranges with base offsets, more-like-this queries, teaser feature filters, and custom sort criteria. That depth is exactly why reimplementing it outside Atoolo is a build project rather than a glue task. If you only need basic full-text search, this bundle is likely more than you need.
- What search backend does this bundle require?
- It sits on top of atoolo/search-bundle ^1 and expects a populated search index maintained by the Atoolo platform, so the engine (Elasticsearch, OpenSearch, or otherwise) is determined by your Atoolo installation rather than by this bundle. Confirm which backend your Atoolo deployment uses and whether you already operate it before planning an integration. If you do not run that infrastructure, hosting this bundle means standing up the whole search stack.
- How tightly coupled is it to other Atoolo bundles?
- Very tightly. Releases routinely pin atoolo/search-bundle to an exact minor version (for example 1.17.3) and also depend on atoolo-rewrite-bundle for URL rewriting, so consumers must upgrade the Atoolo bundle set in lockstep. Expect to move several packages together rather than bumping this one alone. Plan for coordinated upgrades in your release process.
- How stable is the GraphQL schema between releases?
- The package is pre-2.0 and the public GraphQL contract has churned across minor versions: symbolicImage became symbolicAsset, actions became teaser features, the headline sort criterion was removed, geoLocatedFilter became geoLocated, and opensNewWindow was removed then reinstated. Because these are GraphQL field changes, they are frontend-breaking by definition. Server-side/persisted query execution (added in 1.9.0) helps freeze the wire contract for your frontends, but you still need a policy for field renames.
- Is this package actively maintained and safe to use in production?
- Code quality signals are genuinely good: PHPStan level 9, Codecov coverage, an external E2E suite, MIT licensing, and consistent conventional-commit releases. The risk is not hygiene but ecosystem concentration — a single vendor (SitePark), roughly 2 stars, and zero dependents, so you would be an early adopter with no community safety net. Also verify the release date metadata before treating cadence as a health signal, and decide whether your SitePark relationship implies commercial support.
- What are the alternatives for a Laravel team that wants this search API?
- The lowest-cost realistic option is a sidecar: run a minimal Symfony/Atoolo container that exposes /graphql, let Laravel call it over HTTP, and treat the schema as a remote contract. That preserves the vendor's search logic, isolates the PHP/Symfony runtime, and keeps your Laravel codebase clean. The other option is reimplementing the search in Laravel using the published GraphQL query documentation as a specification rather than as a dependency, which is a real build effort given facets, geo filters, and relative date handling.