Ezfind Ls Laravel Package

Product Decisions This Supports

• Search roadmap on a legacy estate. eZ Find is the Solr-backed search layer for eZ Publish Legacy. If any part of the portfolio still runs eZ Publish 4.x/5.x/Legacy, this package defines the search feature ceiling you can realistically ship: facets, sorting, boosting, synonyms, multilingual indexing, and spell-check — all of which the native eZ Publish search does not do well. Use it to answer "what search quality can we promise customers without a replatform?"
• Replatform sequencing and migration order. The package is archived with a final release tagged 2017.12.0 (December 2017) and no Packagist dependents. That makes it a frozen asset in the dependency inventory, and it gives you a concrete, defensible version and date to put in a migration plan. Choose whether search migrates first (highest user-visible value) or last (lowest coupling).
• Build vs. buy vs. inherit. The cheapest option is usually to inherit: Solr integration already exists, is battle-tested against eZ Publish content models, and costs nothing beyond legal sign-off and Solr operations. Compare that against a custom search adapter or a SaaS product (Algolia, Elastic Cloud, Coveo). This package is the "status quo" line item in that comparison — it is what you're replacing, not what you're choosing.
• Lockstep upgrade planning. v2017.12.0 is explicitly built for eZ Publish Legacy 2017.10 or newer and is the first release that carries the PHP 7 compatibility work shipped in that legacy version. The package therefore cannot be upgraded independently of the CMS: this is a coupled upgrade, and it should appear on the same workstream and the same ticket as the PHP 7 / 2017.10+ platform upgrade, not as a standalone search ticket.
• Risk and lifecycle decisions. Score 2.94 with an opportunity signal of 12.85 reads as high unmet value, low maintained value — real user benefit, no active investment. That justifies either a fork-and-maintain decision or a hard exit date. The 2015.01 → 2017.12.0 gap (roughly three years between releases) is the datapoint that makes the "no investment" reading defensible rather than speculative.
• Use cases it credibly covers at 2017.12.0: catalog/product search with faceting, multi-language content discovery across multiple Solr cores, editorial boosting and curated results (including locale-specific IndexBoost), section-restricted searches, and relevance tuning via Solr config rather than PHP changes. The 2017.12.0 fixes are precisely the ones that make the multilingual and faceting claims safe to promise: multi-core results across languages (EZP-23878), IndexBoost in non-default locales (EZP-24739), facet field name/value correctness (EZP-27738), section id list filtering (EZP-26804), subtree and multi-location/hidden-node correctness (EZP-24021, EZP-23644), and exact-phrase matching for camelCase terms (EZP-24553). Use cases it does not cover well: real-time indexing, vector/semantic search, personalization, and anything requiring a supported vendor.

When to Consider This Package

Consider it when:

• You are actively maintaining an eZ Publish Legacy installation (not Ibexa DXP / eZ Platform), on 2017.10 or newer, and search quality is a known complaint. On an older legacy version this release does not apply — you would be pinned to 2015.01 and lose the PHP 7 work entirely.
• You are moving to, or already on, PHP 7.x. v2017.12.0 is the only version in this line that carries the PHP 7 compatibility changes (the parent::__construct fix, EZP-21764 INI instantiation cleanup). If PHP 7 is a hosting requirement, this version is not optional — it is the entry ticket.
• You already run, or are willing to run, an Apache Solr cluster. Operational cost of Solr dominates the cost of this package, so the package itself is nearly free.
• You need a bridge that buys 12–24 months of acceptable search while a replatform is funded, and you can accept no upstream fixes.
• Your team has, or can contract, eZ Publish Legacy expertise at the 2017.10+ level. This release reduces but does not remove the skills risk: it is still a 2017-era PHP codebase with no forward-compatibility commitment beyond that platform version.
• You are scoping a migration and need to document exactly what search behavior must be preserved — the 2017.12.0 feature set (with its fixed edge cases) is your requirements baseline.

Look elsewhere when:

• You are on eZ Platform / Ibexa DXP or any modern PHP framework — use Ibexa's native Solr/Elasticsearch integration or a framework-appropriate search driver. This package is legacy-only.
• Your governance requires a maintained dependency with security patching, a support contract, or a current release cadence. Archived since 2017, with a three-year gap before its last release, fails that bar outright.
• You need semantic/vector search, personalization, or sub-second real-time indexing — Solr 4/6-era integrations are not the right foundation.
• The license status is unresolved. NOASSERTION means GitHub could not detect a license; eZ Find has historically been GPL-2.0, which has copyleft implications if you distribute or embed it. Do not adopt until legal has confirmed the actual license from the repository's own files.
• You would be the only consumer in any meaningful sense. Note the nuance: "zero dependents" reflects that eZ Find ships bundled inside eZ Publish Legacy distributions rather than being pulled from Packagist, so the downstream userbase is real but invisible to package metadata. Treat it as no community to lean on for patches and no third party to escalate to — not as nobody uses it. With no upstream fix path, the fork cost is the real cost of adoption.

How to Pitch It (Stakeholders)

For executives — one paragraph: eZ Find is the Solr search extension for our legacy eZ Publish platform. It is already-built, zero-license-cost capability that materially improves search relevance, faceting, and multilingual results over the CMS default. The December 2017 release (v2017.12.0) is the version to standardize on: it adds PHP 7 compatibility and clears a batch of long-standing defects in multilingual, faceting, and editorial-boosting behavior, so it is the first version where the search quality we would promise is actually reliable. The strategic framing is bridge, not destination: the project is archived, that was its final release, and there are no active maintainers, so it carries lifecycle risk and should be treated as frozen infrastructure. The recommendation is to adopt it only where the legacy platform is still revenue-bearing, upgrade it together with the legacy 2017.10+ / PHP 7 move rather than as a separate project, cap investment at configuration and operations, and attach a dated exit criterion tied to the replatform. It buys search quality now at near-zero build cost and creates a clean, documented requirements baseline for whatever search product we move to.

For engineering — the operating conditions:

• Pin v2017.12.0 exactly, and only on eZ Publish Legacy 2017.10+. The release notes state that coupling explicitly; do not deploy it against an older legacy tree. Containerize both the PHP extension and its Solr version; assume the Solr compatibility window is the one it shipped against.
• Treat the upgrade as a coupled change with the platform/PHP 7 upgrade, not an isolated dependency bump. Sequence and test them together — the PHP 7 constructor fix is only meaningful in that combination.
• Assume no security patching. Isolate it, restrict egress, and put it on the same refresh cadence as the rest of the legacy stack.
• Legal must confirm the license from the repository files before any distribution or embedding — NOASSERTION is a flag, not a clearance.
• Budget for a fork-and-own decision if a blocking defect appears. Absence of Packagist dependents tells you there is no upstream fix path; it does not tell you nobody runs it. The fork cost is the real cost of adoption.

The honest bottom line for both audiences: the package's low maintenance score and high opportunity score are the whole story — it delivers real search value that nobody is currently stewarding. v2017.12.0 makes it a better frozen asset (PHP 7, multilingual and faceting defects fixed) but not a maintained one. Fund it as a time-boxed bridge with a named owner and an expiry date, or don't fund it at all.