Ezfind Ls Laravel Package

Technical Evaluation

Architecture fit — unchanged, and now confirmed as terminal. ezsystems/ezfind-ls is not a Laravel package. It is an eZ Publish Legacy extension: extension/ezfind/ tree, INI settings (solr.ini, ezfind.ini), eZ autoload definitions, and PHP classes bound to the eZ Publish kernel (eZContentObject, eZPersistentObject, eZINI, eZCLI, eZDB). No service provider, no facade, no container binding, no publishable config, no PSR-4 autoloading. composer require will not produce a usable Laravel integration. v2017.12.0 does not change this and nothing after it will — the release is a maintenance fix on a platform that is itself end-of-life.

What v2017.12.0 actually is. A bugfix rollup, the first since 2015.01, and the last release in the archive. Two things matter for us:

1. A hard compatibility pairing was declared. The release "is meant to be used with legacy 2017.10 or newer" and its headline change is "Calling parent constructor correctly for 2017.10 / PHP7 compatibility" (EZP-21764 / #212). This raises the runtime floor from our prior "PHP 5.6–7.x" estimate to eZ Publish Legacy 2017.10+ on PHP 7.x. It does not deliver PHP 8 support, and no further release will.
2. It ships twelve search-correctness fixes. These are not cosmetic. EZP-24553 (no results for exact phrases with camelCase words), EZP-23878 (no result for one location across several languages on multicore), EZP-24739 (IndexBoost not working in some locales), EZP-24021 (subtree_array link wrong on non-main nodes), EZP-23644 (hidden nodes / multiple locations in subtree fetches), EZP-26804 (search with section id list filter). Each is a latent behavioural bug in every pre-2017.12 deployment.

Integration feasibility: unchanged. Low for Laravel, moderate-to-good for an eZ estate — but only a modern one. If we run eZ Publish Legacy, it must be 2017.10 or newer to take this release; anything older forces us onto the 2015.01 codebase, which is materially buggier on exactly the search paths we care about. Confirm the deployed legacy version before anything else — this release has turned "which eZ version" from a curiosity into a binary gate.

Technical risk: high, marginally better on runtime, unchanged everywhere else.

• Still archived, still no successor release. v2017.12.0 is the 2017-12-22 release referenced previously; it is now confirmed as the endpoint, not a sign of resumed activity. No security patches, no PHP 8, no Solr 9 work.
• License NOASSERTION, unresolved. GPL-2.0 is the likely reality. Copyleft contamination remains the top legal exposure for any code copied into a proprietary Laravel codebase. Reading as a reference spec carries different risk than vendoring.
• PHP 7 ceiling. Any Laravel host we run today is PHP 8.2+. The two cannot share a runtime — federation over HTTP or a full port remain the only options.
• Solr version coupling unchanged. Schema and request handlers are tuned to Solr 3.x–6.x era configs; modern Solr requires migration and re-validation of facets, elevate, spellcheck.
• Relevance correctness is invisible — and now we can enumerate part of it. The twelve fixes are a free, high-value checklist: they tell us precisely which behaviours a naive port will get wrong. Any reimplementation must reproduce post-2017.12 semantics, not the pre-2015 semantics that most documentation and blog posts describe.
• ACL-aware indexing remains the highest-severity failure mode. Nothing in this release touches permission filtering. Querying Solr directly from Laravel can still leak content across permission boundaries.

Key questions (revised).

1. Which eZ Publish Legacy version is in production? Below 2017.10, this release is unavailable to us and the bug list above is live in our search results today.
2. Is the license confirmed GPL-2.0, and does our distribution model tolerate that?
3. Which Solr version is deployed, and who owns it?
4. Are we consuming the Solr schema and boosting rules, or the PHP code? The former is most of the value and lifts cleanly.
5. Does our golden query set include cases for camelCase exact phrases, multicore multi-language locations, subtree_array with non-main nodes, and section-id filters? If not, our port acceptance test has known holes — patch it from the v2017.12.0 changelog.
6. Is there a funded exit plan from eZ Publish, and what is its date? Search should not outlive it by much.
7. Who has eZ Publish Legacy experience? Unchanged: if "no one," risk premium rises sharply.

Integration Approach

Stack fit. Zero fit with Laravel as a runtime dependency. Good fit only inside an existing eZ Publish Legacy 2017.10+ deployment. Treat it as a specification source — a battle-tested answer to "how should content search behave" — not a library.

Migration path — pick one deliberately:

1. Keep-and-federate (lowest effort, highest ops debt). Containerize legacy eZ Publish 2017.10+ with eZ Find v2017.12.0 plus Solr, expose search behind an anti-corruption layer, call it from Laravel. Preserves relevance exactly, including the twelve fixes; keeps a dead, PHP-7-only platform alive indefinitely.
2. Port the semantics (recommended when search quality matters). Extract the Solr schema, field definitions, boost/elevate configs, facet definitions, and query-building rules into a written spec, then reimplement on Laravel Scout plus a maintained Solr/OpenSearch driver. Dual-run both engines against a labelled query set and diff before cutover.
3. Replace outright (recommended when search quality is commodity). Scout + Meilisearch/Typesense. Cheapest to operate; expect measurable relevance regression versus eZ Find's tuned configuration.

Compatibility. eZ Publish Legacy 2017.10+ only, PHP 7.x only, Solr 3.x–6.x era. Not compatible with PHP 8.x, Laravel 9/10/11, or Solr 9. Upgrading the extension without upgrading legacy to 2017.10+ is unsupported by the release author.

Sequencing (updated).

1. License and legal review — gate everything.
2. Confirm the deployed legacy version is 2017.10+. If not, scope a legacy upgrade before anything else, or accept pre-fix search behaviour as the baseline.
3. Inventory dependencies: run the indexer in staging and capture generated Solr schema, request handlers, and field list.
4. Build the golden query set (20–50 queries) — and seed it directly from the v2017.12.0 changelog: camelCase exact phrases, single location across multiple languages on multicore, subtree_array on non-main nodes, subtree with hidden nodes and multiple locations, IndexBoost under non-default locales, section-id list filters, facet field_fields value shape. This is the acceptance test for any replacement.
5. Decide path 1/2/3 against that golden set and the exit-plan timeline.
6. Build the adapter or port; run dual-write/dual-query in staging.
7. Cut over read traffic, then indexing; decommission the legacy component.

Do not attempt a Composer-based install into the Laravel application under any scenario. Do not assume the extension can be upgraded independently of the legacy core.

Operational Impact

Maintenance. Effectively unmaintained, and now provably so: the project's final act was a bugfix rollup and a PHP 7 compatibility patch. Any defect becomes our fork's responsibility. Budget a named internal owner and a vendored branch, not community support.

Support. No vendor support. eZ Publish Legacy is end-of-life; Ibexa has moved on. Internal knowledge is the only channel, and it leaves with whoever built the system.

Scaling. Solr scales horizontally and is not the bottleneck. The constraint is the legacy PHP application servers (now pinned to PHP 7) and full-object indexing memory pressure — batch sizes and indexer concurrency need tuning, and a full reindex of a large content tree is a multi-hour, memory-hungry operation. The extension contributes no scaling story.

Failure modes.

• Permission leakage via direct Solr queries bypassing eZ Find's ACL filtering — highest severity; treat direct index access from Laravel as forbidden.
• Version-skew between extension and legacy core. v2017.12.0 assumes legacy 2017.10+; running it on older legacy produces undefined behaviour, including the constructor/PHP 7 path it was written to fix.
• Search-correctness regressions already present if we run pre-2017.12 — camelCase phrase queries, multi-language single locations, and locale-specific IndexBoost will silently return wrong results today.
• Schema drift after any Solr upgrade; facets and boosting silently stop matching.
• Index corruption or commit lag producing stale results; needs a documented, rehearsed full-reindex runbook.
• Runtime fatals on PHP upgrades — and there is no PHP 8 path, by design.
• License contamination if code is copied rather than reimplemented.
• Silent relevance regression after any port — invisible without the golden query set, which is why the changelog-derived cases matter.

Ramp-up. A PHP engineer fluent in eZ Publish Legacy reaches productivity in two to four weeks; the v2017.12.0 changelog is the fastest available onboarding document for how search is supposed to behave and should be read first. Without that background, expect one to two quarters before someone can safely modify indexing or relevance logic — most learning will come from reading the schema and experimenting, not from documentation. Staff a Solr operations owner separately from the application developer; they are different skills and both are required.