ulff/elasticsearch-php-client-bundle
A Symfony bundle that integrates the official Elasticsearch PHP client, providing service configuration and convenient client access for building Elasticsearch-powered search features in Symfony applications.
The bundle is a thin Symfony dependency-injection wrapper around elasticsearch-php 2.x: a DependencyInjection extension, a service definition exposing Elasticsearch\Client, and configuration for hosts/connection params. That is the entire product surface. For a TPM this means the abstraction is easy to fully audit in an hour, but it also means the bundle contributes almost no value beyond service wiring — the real dependency is the client library, which the bundle binds to a specific, now end-of-life major version.
Architecture fit. Poor for any current design. It targets Symfony 3 (EOL November 2021) and elasticsearch-php 2.x (aligned to ES 2.x, EOL February 2018). Adopting it anchors your search integration to two stacked EOL chains. It is only defensible inside a legacy, already-frozen Symfony 3 estate where the ES cluster is also 2.x, and even then only as a temporary shim.
Integration feasibility. Mechanically trivial — composer require, register the bundle, configure hosts. Practically constrained: the 2018 release predates PHP 8, so you should expect compatibility breakage (deprecations in Symfony 4.4+, each()-era patterns, untyped signatures against newer PSR/HTTP interfaces). There is no test matrix, no CI badge of consequence, and zero dependents, so no field evidence of it working anywhere but the author's machine.
Technical risk. High and concentrated in three places: (1) the pinned elasticsearch-php 2.x major, which is unmaintained and receives no security patches; (2) Symfony 3's removal from the framework's own support window, meaning the bundle's extension patterns may already be incompatible with the Symfony versions you can actually get support for; (3) bus-factor one — three stars and no dependents indicates no reviewer pool, so a single maintainer disappearing (already effectively true) is total abandonment.
Key questions to answer before any decision:
elasticsearch-php service definition, which is roughly the same amount of code?Stack fit. It fits exactly one stack: Symfony 3.x with Symfony's old bundle registration, PHP 5.6–7.x, and an Elasticsearch 2.x cluster. Outside that overlap it does not fit — a current LTS Symfony with ES 7/8 requires elasticsearch-php 7/8, an entirely different client API (Elasticsearch\ClientBuilder with different transport, no Client service signature this bundle exports).
Migration path. Do not adopt greenfield. If forced to, treat the bundle as a disposable adapter: define your own SearchClientInterface in application code, have the bundle's configured Elasticsearch\Client satisfy it via one thin implementing class, and forbid direct injection of Elasticsearch\Client elsewhere. That single seam turns a future swap from a rewrite into a class replacement. Concurrently, budget the underlying stack migration — Symfony 3 to a supported version and ES 2.x to a supported cluster — as the real project; the bundle disappears at the end of it.
Compatibility. Verify concretely rather than by reading the README: install into the actual application skeleton, run composer why-not against target PHP, confirm the DI extension loads under the framework version in use, and smoke-test against the exact ES server build in the target environment. Expect the package's composer.json constraints to be the first blocker.
Sequencing. (1) Confirm EOL exposure and get an owner; (2) if the integration is net-new, build it directly against elasticsearch-php at the version matching your server, skipping the bundle; (3) if it is inherited legacy, freeze — no upgrades, no new consumers — and put the interface seam in place; (4) fund the Symfony/PHP/ES upgrade as a tracked initiative; (5) retire the bundle when the client major changes.
Maintenance. Effectively zero upstream. Last release March 2018, no recent commits, no releases since, no dependents to piggyback on. Every fix — including any security fix in the pinned client — becomes an internal fork obligation. Assign that cost explicitly; unowned forks rot.
Support. No vendor, no community, no issue-triage evidence. Internal engineers will be supporting the Elasticsearch client semantics themselves, which is a search-engineering skill, not a Symfony skill. Staffing this is the dominant ongoing cost.
Scaling. The bundle is not in the scaling path — connection pooling, retries, and cluster behavior all live in elasticsearch-php and the ES cluster. However, you are locked to whatever transport and connection-pool behavior shipped in client 2.x; newer clients added materially better retry, sniffing, and connection-selection defaults that you forgo. At high query volume this shows up as harder-to-diagnose tail latency rather than a hard ceiling.
Failure modes. (1) PHP/runtime upgrade breaks the client or the bundle with no fix available; (2) ES cluster upgrade to 5+ silently breaks the client protocol with no supported path forward; (3) security exposure from an unpatched HTTP/transport dependency in the client chain; (4) bus-factor: the sole maintainer is already inactive, so any issue is permanent; (5) configuration drift where teams bypass bundle config and instantiate clients ad hoc, defeating the point of the bundle.
Ramp-up. Low for the bundle itself — a competent Symfony engineer understands the wiring in under a day. The non-obvious cost is the reverse: nobody ramps into the EOL stack comfortably, and new hires will not have seen this combination. Onboarding friction sits in the surrounding legacy, not in this package.
How can I help you explore Laravel packages today?