- Is enhavo/search-bundle a Laravel package?
- No. enhavo/search-bundle is a Symfony bundle and a subtree split of the Enhavo CMS monorepo, written against Symfony's Bundle, DependencyInjection, and HttpKernel conventions. It ships no Laravel service provider, facade, config publish tag, or package auto-discovery entry, so there is no framework seam for it to occupy in a Laravel application. For Laravel search needs, use Laravel Scout with a supported driver instead.
- Does enhavo/search-bundle support Laravel 10 or Laravel 11?
- There is no Laravel version support to speak of, because the package never targets Laravel at any version. Its runtime assumptions are Symfony kernel and container based, and it likely depends on Enhavo's own resource and entity abstractions. Installing it alongside Laravel 10 or 11 will not give you working search, so the Laravel version is effectively irrelevant here.
- Can I install enhavo/search-bundle with Composer in a Laravel app?
- Composer may resolve and download the package, but that is where the compatibility ends. Laravel has no bundle registration mechanism, no Symfony DI container, and no Enhavo domain model, so the bundle's classes have nothing to bind to. Making it work would mean rewriting the Symfony plumbing around classes that assume a Symfony runtime, which is a port rather than an integration.
- What does enhavo/search-bundle actually do?
- It provides search functionality for the open source Enhavo CMS, which is built on the fullstack Symfony framework for flexible, complex data structures. The published README is only a short project blurb and a pointer to the main Enhavo repository. Indexing behavior, configuration options, and the search API contract are not documented on this split repository.
- Does enhavo/search-bundle require Enhavo CMS and enhavo/enhavo core?
- Almost certainly yes, at least indirectly. Search indexing in Enhavo is typically wired to Enhavo resource definitions, Doctrine entities, and CMS configuration, so the bundle is unlikely to run as a standalone add-search-to-my-app component. The split artifact does not publish a dependency contract, so verify the exact requirements in the main Enhavo repository before considering it.
- Which search backend does the bundle use — Elasticsearch, Doctrine full-text, or Meilisearch?
- This is not stated anywhere in the published artifact. There is no documented backend, no pinned engine dependency declared in the README, and no compatibility matrix. If the choice of backend matters to your architecture, you must inspect the upstream Enhavo monorepo source and configuration instead of relying on this package's documentation.
- Which Symfony and PHP versions does enhavo/search-bundle support?
- There is no README-level statement of supported Symfony, PHP, Doctrine, or search engine versions, and the package has zero dependents to infer from. Because this is a subtree split, the authoritative answer lives in the main Enhavo repository's composer constraints and CI configuration. Pin your constraint carefully and test against your exact Symfony and PHP combination.
- Why is the README empty and where are the docs, changelog, and issue tracker?
- This repository is a READ-ONLY subtree split generated from the main Enhavo monorepo, so the README is intentionally minimal. Documentation, changelogs, and issue tracking all live in the parent repository at github.com/enhavo/enhavo. Reading the split repository alone will not tell you how the bundle behaves or what changed between releases.
- How do I add search to a Laravel application instead of using this bundle?
- Use Laravel Scout with a first-class driver such as Meilisearch, Typesense, Algolia, or Elasticsearch, and keep the CMS out of the critical path. Define your own searchable models and indexer interfaces so the backend can be swapped without touching domain code. If you genuinely need Enhavo content search, stay within a Symfony and Enhavo host and consume the bundle natively rather than porting it.
- Is enhavo/search-bundle maintained, tested, and safe for production?
- The public signals are weak: very few stars, no dependents, no independent security advisory history, and no test or coverage information on the split artifact. The split-repo pattern adds risk because fixes and breaking changes arrive from upstream without semantic-version signals on this package, so a composer update can change behavior unexpectedly. Treat it as a high-risk dependency and pin versions if you must use it inside an existing Enhavo installation.