Search Laravel Package

Technical Evaluation

What this package actually is. ibexa/search is not a general-purpose search library. It is the search-and-faceted-navigation subsystem of Ibexa DXP (formerly eZ Platform), published as a read-only split of the vendor monorepo. It supplies the global search UI, search suggestions/autocomplete, facets, sorting, spellchecking, and the mapping layer between Ibexa's SearchService criteria and paged result DTOs. The actual indexing and query execution live in the underlying search engine (Solr/Elasticsearch) and in ibexa/core; this package is the orchestration and presentation layer above it.

Architecture fit. Fit is high only inside an Ibexa DXP installation and effectively zero outside it. The package is bound to Ibexa contracts (RepositoryConfigurationProviderInterface, PagerSearchDataMapper), Ibexa's content model, and the Ibexa admin/back-office UI. It assumes the Symfony full-stack runtime (the 5.0 line requires Symfony 7.x and PHP 8.3+). It is not a drop-in for a Laravel application, and nothing in the repository suggests Laravel service-provider integration, framework-agnostic adapters, or a standalone facade.

Integration feasibility. Adoption is transitive, not direct. Zero Packagist dependents and 4 GitHub stars confirm the package is consumed almost exclusively through the ibexa/* metapackages, never as an independently versioned dependency. Realistic integration paths are therefore: (a) you are deploying Ibexa DXP and this comes along, or (b) you are not, and this package is out of scope. The dual licence compounds this: the Ibexa Business Use Licence requires an active DXP subscription, and the GPLv2 alternative is copyleft and unsuitable for proprietary distribution without legal review. The "NOASSERTION" licence signal in the metadata reflects that dual/compound licence, not a missing licence.

Technical risk.

• Licence risk (high): commercial subscription dependency or GPLv2 copyleft; must be cleared by legal before any commercial use.
• Coupling risk (high): breaks follow Ibexa core API changes, not semantic-versioned public APIs. The v5.0 line deliberately dropped class_alias BC layers and added type hints — an explicit signal that minor upgrades can be breaking at the code level.
• Abandonment risk (low): vendor-maintained with a steady, parallel release train across 4.6.x and 5.0.x.
• Bus-factor risk (medium): the release notes are almost entirely "No significant changes," which means the meaningful engineering happens upstream in the monorepo. There is little publicly visible issue traffic or community contribution to lean on when you hit an edge case.
• Version-skew risk (medium): the current 5.0 line assumes PHP 8.3 and Symfony 7, which may collide with an existing platform's PHP/Symfony baseline.

Key questions for the vendor and engineering.

1. Is a valid Ibexa DXP subscription already held, and does it cover this component in production?
2. Which search backend is supported and licensed for our scale (Solr vs. Elasticsearch), and where is the index schema owned?
3. Is the internal API surface (PagerSearchDataMapper, criteria builders) covered by any backward-compatibility guarantee across 5.x minors?
4. Does the GPLv2 branch ship feature-parity with the BUL branch, or is it a subset?
5. Which DXP release does this package version pin to, and what is the supported upgrade window between 4.6 and 5.0?
6. Why does the recorded latest release date sit in the future relative to today? Confirm whether releases are scheduled/automated or the metadata is unreliable — this affects how we plan upgrade windows.

Verdict. Do not evaluate this as a candidate library. Evaluate it as one component of an Ibexa DXP platform decision. If Ibexa DXP is already the chosen CMS, this package is a reason to keep the platform current; if it is not, this package should not be a reason to adopt it.

Integration Approach

Stack fit. The framing of this package as a "Laravel/PHP package" is the first thing to correct. It is a Symfony bundle family with Ibexa-specific service wiring; there is no documented path for registering it inside a Laravel container, and doing so would mean reimplementing Ibexa's repository, configuration provider, and content model — a multi-quarter effort with no vendor support. Stack fit is therefore binary: full DXP stack, or no fit.

Migration path.

• Greenfield: deploy the Ibexa DXP metapackage at the target major (5.0 for PHP 8.3 / Symfony 7, 4.6 for legacy environments) and take ibexa/search transitively. Do not pin it independently.
• Existing Ibexa 4.6 estate: the 4.6.x line is still receiving releases, so this is a maintenance-only posture. Plan the 5.0 jump as a platform upgrade (PHP 8.3, Symfony 7, removal of class_alias shims), not as a package bump.
• Existing Laravel estate: no migration path exists. Search capability should be sourced from a Laravel-native option (Scout plus a driver, or a direct engine client) and this package closed out.

Compatibility. Hard constraints: PHP 8.3 minimum on 5.x, Symfony 7.x (7.3/7.4 LTS as of the recent bumps), and a matching Ibexa DXP core version. The 4.6 line is the compatibility escape hatch for older PHP/Symfony baselines. Confirm the search engine version matrix (Solr/Elasticsearch) independently — that is a separate operational dependency with its own upgrade cadence.

Sequencing.

1. Legal/licence clearance on BUL vs. GPLv2 before any code is written.
2. Confirm DXP major and PHP/Symfony baseline; freeze the platform version.
3. Stand up the search backend and index schema in a non-production environment; validate index rebuild time against the real content volume.
4. Integrate search UI, facets, sorting, and suggestions against a representative content model — facets are content-type-driven, so they cannot be designed until the content model is stable.
5. Load and relevance-test before cutover; relevance tuning is the long pole, not the wiring.
6. Only then schedule the 4.6→5.0 upgrade if starting on the older line.

Operational Impact

Maintenance. Low effort but non-zero, and it is vendor-paced. Expect frequent releases that are mostly "No significant changes" (version-alignment bumps and CI workflow tweaks) punctuated by the occasional real fix — the date-criteria builder fix and the search-suggestion breadcrumb fix are the pattern. Budget for routine platform patch upgrades rather than a bespoke maintenance backlog. The absence of community dependents means no ecosystem of patches, forks, or Stack Overflow answers to fall back on; the vendor documentation and support channel are the only safety net.

Support. Depends entirely on the commercial relationship. With an active Ibexa subscription you get vendor support and the BUL grant; without it you are on GPLv2 with community-only (effectively none, given 4 stars and no dependents) assistance. This is the single largest operational differentiator and should be modelled as a recurring cost, not a one-off.

Scaling. This package does not scale; the search engine behind it does. Capacity planning belongs to Solr/Elasticsearch (heap, shard count, index size) and to PHP-FPM/web tier for the UI. Two scaling-relevant behaviours to watch: autocomplete/suggestion endpoints are high-frequency and benefit from caching or throttling, and facet-heavy result pages multiply query cost per request.

Failure modes.

• Index drift: content changes not reflected in search; needs a rebuild runbook and monitoring on index lag. Highest-impact failure, and it is invisible until users report missing results.
• Search backend unavailability: because search is a first-class navigation path in Ibexa, backend downtime degrades the whole site experience, not just a search page. Requires a defined degraded-mode behaviour.
• Relevance regressions: the changelog shows a history of subtle query-construction changes (partial-word matching removed, date criteria building corrected, "all text fields" over-matching). Each is a silent behavioural change to user-visible results; regression testing on relevance is mandatory per upgrade.
• Upgrade breakage: the explicit removal of BC class_alias layers and added type hints in 5.0 means custom extensions touching these classes will break. Inventory any local overrides before upgrading.
• Licence lapse: losing the DXP subscription invalidates the BUL grant — a governance failure mode rather than a technical one, but it is the one that can force a re-platform.

Ramp-up. The learning curve is Ibexa domain knowledge, not search theory: content model, content types, criteria builders, facets, and the DXP configuration layer. A competent Symfony/PHP developer needs several weeks to become productive inside Ibexa, and relevance tuning is an ongoing specialist activity rather than a one-time setup. Budget for at least one engineer to own search as a named responsibility, and plan knowledge transfer around platform upgrades specifically — that is when the coupling to Ibexa core is felt.