- Is leapt/elastica-bundle a Laravel package?
- No. It is a Symfony bundle, not a Laravel package. It registers through Symfony's dependency injection extension (Leapt\ElasticaBundle\DependencyInjection\LeaptElasticaExtension), is enabled in config/bundles.php, and is configured with YAML under the leapt_elastica key. There is no ServiceProvider, no config/*.php file, no facade, and no Laravel container binding.
- Can I use LeaptElasticaBundle in a Laravel application?
- Only by writing a bespoke service provider and reimplementing the YAML configuration handling yourself, which discards most of the bundle's value. The console commands, Doctrine persistence providers, and finder/repository layer are all built around Symfony's DI and event system. For Laravel the practical answer is to use the official elasticsearch/elasticsearch client directly or Laravel Scout with an Elasticsearch driver instead.
- Which Symfony and PHP versions does version 2.0.0 require?
- Version 2.0.0 raises the floor to Symfony 4.4 or later and PHP 7.2 or later, and drops support for Symfony below 4.4 and PHP 7.0/7.1. Composer resolution is the first concrete blocker to check against a modern symfony/* constraint or a PHP 8.2 runtime, because the release does not extend support to PHP 8.x. If you are on Symfony 3.4 or PHP 7.1, you must stay pinned to the 1.x branch, which is effectively unmaintained.
- How do I install and configure LeaptElasticaBundle?
- Install it with Composer, register the bundle in config/bundles.php, then define your connections, clients, and indexes under the leapt_elastica key in YAML. The bundle turns each declared client and index into a container service, so you inject them by service id rather than constructing Elastica clients by hand. Index mappings and settings are also declared in the same configuration and applied through the bundle's console commands.
- Does LeaptElasticaBundle support Elasticsearch 8?
- No. The bundle is a configuration and orchestration layer over ruflin/elastica, which targets the Elasticsearch 6/7 API surface. Elasticsearch 8 removed multi-type support and changed several transport assumptions that Elastica relies on, and the two 2.0.0 housekeeping releases added no client upgrade or Elasticsearch 8 work. A client-to-cluster version mismatch typically surfaces at runtime in production rather than in CI.
- How do I populate indexes and search documents with this bundle?
- The bundle ships console commands for creating, populating, and resetting indexes, which you run after changing mappings. Persistence providers keep Doctrine entities in sync with Elasticsearch, and the finder/repository abstraction gives you query building and pagination on top of the Elastica client. This lets you index and query documents without writing transport-level code.
- What is a better-maintained alternative to LeaptElasticaBundle?
- For Symfony, FOSElasticaBundle is the better-supported comparison point and the project this bundle derives from. If you are not tied to Elastica, the official elasticsearch/elasticsearch client is the actively maintained option and tracks modern Elasticsearch releases. For Laravel, look at Laravel Scout with an Elasticsearch driver rather than any Symfony bundle.
- Is leapt/elastica-bundle still maintained and safe for production?
- Treat maintenance as episodic rather than active. Adoption signals are essentially absent, and the repository shows one release since 2020 that adds CI tooling, phpstan, php-cs-fixer, and return types rather than features or client upgrades. There is no published security response process, so the realistic remediation for a future vulnerability is forking. Verify the repository and issue activity yourself before committing, since a tag being cut does not mean pull requests are being accepted.
- Will upgrading from 1.x to 2.0.0 break my application?
- It can, in two ways. Dropping Symfony below 4.4 and PHP below 7.2 blocks the upgrade outright for older applications, and the added native return types on finder, repository, and provider classes will fatal any local subclass that overrides those methods without matching signatures. Inherited implementations commonly have such subclasses, so audit them before upgrading.
- How should I test an Elasticsearch integration built on this bundle?
- Mock the Elastica client for unit tests and keep a small set of integration tests that run against a real cluster of the same major version you deploy. Test the container wiring, the index create/populate commands, and mapping application, because the bundle does not detect query DSL, analyzer, or mapping drift between versions. Add an explicit assertion that the client and cluster versions are compatible so mismatches fail in CI rather than in production.