- Is runroom/fos-elastica-bundle a Laravel package?
- No. It is a Symfony bundle, a maintained fork of FriendsOfSymfony/FOSElasticaBundle, and every integration surface assumes the Symfony HTTP kernel, DI container, Config component and Console. There is no service provider, no facade, and no Laravel configuration publishing. Installing it in a Laravel app pulls in a Symfony dependency chain to gain functionality you can reproduce with roughly 200 lines of client wiring.
- How do I install runroom/fos-elastica-bundle?
- Install it with Composer in a Symfony application and register the bundle in config/bundles.php, then configure indexes and clients under the fos_elastica configuration key. You will also need the Elastica client and a running Elasticsearch cluster the bundle can reach. Symfony Flex may handle the bundle registration automatically depending on your project setup.
- What Elasticsearch versions does this bundle support?
- This generation of bundle targets Elasticsearch 7.x semantics through ruflin/elastica, which means typed indices and _type configuration assumptions. Elasticsearch 8 removed mapping types and defaults to security on with TLS and authentication, so mappings and analyzers will usually need rework before they work against a modern cluster. Treat ES 8 and 9 as unsupported without a fork of your own.
- How does this fork differ from FriendsOfSymfony/FOSElasticaBundle?
- It is Runroom's continuation of the now-archived upstream bundle, kept alive for their own client work and publishing releases in 2025. The architecture is the same: a Config tree, compiler passes, IndexManager and Provider services, Doctrine lifecycle subscribers, and fos:elastica:* console commands. Before adopting it, diff it against the last upstream release and read the CHANGELOG to see whether it is a superset of fixes or a thin re-tag.
- The GitHub repo shows zero stars and an archived flag, is the package abandoned?
- Archived status plus zero dependents is the dominant signal, even though releases still appear. There is no external bug pressure, no third-party test coverage and no community CVE triage, so you become the maintainer the moment you adopt it. It is reasonable as a short-lived, internally owned fork for an existing Symfony app pinned to ES 7.x, and unreasonable as a long-term dependency.
- How do I use Elasticsearch in Laravel without this bundle?
- Use the official elasticsearch/elasticsearch 8.x PHP client behind a repository or service class, or wrap it as a custom Laravel Scout driver. Replace the bundle's populate and reset console commands with php artisan commands, and manage index creation and mappings from your own config files. That gives you the same capability with none of the portability debt.
- Can I use this bundle with Eloquent models instead of Doctrine?
- Not out of the box. The auto-indexing subscribers hook into Doctrine ORM and ODM lifecycle events, so Eloquent model events are not observed. You would have to write your own listeners or observers and wire them into the container yourself, at which point the bundle is providing little more than a client wrapper.
- How does automatic indexing of Doctrine entities work in this bundle?
- The bundle registers event subscribers on Doctrine lifecycle events and maps entities to indexes through its configuration, so inserts, updates and deletes trigger index writes via the IndexManager and Provider services. Population of existing data is handled by the fos:elastica:populate console command. Failures are typically soft, so a rejected mapping write can silently produce missing documents rather than a loud error.
- What should I check before running this in production against an ES 8 cluster?
- Confirm the cluster's major version and whether the team plans to move to 8.x or 9.x within twelve months, because a yes makes this package a dead end. Audit every mapping and analyzer for type-era assumptions, and verify how your app handles authentication and TLS now that ES 8 defaults to security on. Also add observability yourself, since stale aliases and rejected writes tend to return zero results instead of throwing.
- How do I test a Laravel application that talks to Elasticsearch?
- Keep search behind a small repository or service interface so tests can swap in an in-memory fake for unit coverage, and reserve real cluster assertions for integration tests. Spin up Elasticsearch in Docker or Testcontainers for those integration runs, then refresh indices and clean up between tests. Avoid asserting against production or shared clusters, since index state leaks make results flaky.