Core Search Laravel Package

Technical Evaluation

What this package actually is. ibexa/core-search is the search service contract layer of Ibexa DXP — the interfaces, criteria/aggregation/sort model, and indexing plumbing that engine-specific packages (Solr, Elasticsearch) implement. It is not a search product and not a library you adopt; it is a seam inside a platform you buy. Every TPM-level judgement below follows from that.

Architecture fit.

• Fits only one architecture: an application already running Ibexa DXP (Symfony-based, content repository + persistence + field type registry present).
• It has no meaning without the surrounding content model. The query objects operate on Content/Location value objects and content-type metadata owned by sibling packages; you cannot meaningfully index or query against them in isolation.
• It is not a Laravel package. Despite the generic "Laravel/PHP" framing, this is Symfony DI + Ibexa contracts. There is no Laravel service provider, no Eloquent/Scout bridge, no facade. A Laravel-first team would be porting service definitions and value objects into an alien container — a rewrite, not an integration.
• If your product is Laravel and search is a real requirement, the correct architectural answer is an anti-corruption layer: keep your domain model, push documents to the engine over HTTP or a queue, and never let Ibexa types leak into product code.

Integration feasibility.

• Composer-installable in principle, but the README's instruction is explicit: install Ibexa DXP. Standalone install will resolve dependencies and then fail at runtime on missing repository services, field type registry, and a configured backend.
• Backend selection is a separate, mandatory decision — the abstraction is only useful once a concrete engine package is chosen and provisioned.
• Effort is dominated by content modelling and index design, not by wiring. Budget accordingly: this is a modelling project wearing a dependency-management costume.

Technical risk.

• Licensing is the top risk, not code. Dual Ibexa Business Use License / GPLv2, surfaced as NOASSERTION. Commercial use is clean only under a valid DXP subscription. GPLv2 copyleft applies on the open-source path and can oblige source disclosure if you ship modifications — a procurement and legal gate before any engineering starts, especially for OEM/white-label distribution.
• Bus factor is the vendor. 1 star, 0 dependents, no community, no third-party tutorials. The low signal reflects internal consumption inside the DXP distribution rather than abandonment — but it does confirm there is no fallback support channel and no independent talent pool to hire from.
• Release signal reads as low churn, not instability. The bulk of releases are "No significant changes," which is consistent with a mature, vendor-controlled component. The real change vector is the platform release train (4.6.x and 5.0.x in parallel, plus a Symfony 7.4 LTS bump at 5.0.7), not this repo.
• Version coupling risk. You inherit the platform's cadence. A security fix in search arrives via a DXP upgrade, which may drag in unrelated platform changes.

Key questions for the vendor and your own team.

• Do we hold an active Ibexa DXP subscription, and does it cover the environments we intend to run?
• Which engine — Solr or Elasticsearch — and does our infrastructure team already operate it?
• Does our roadmap need custom index fields, custom handlers, or boosting rules that sit outside the abstraction's defaults?
• Are we comfortable binding product features to platform-specific search APIs, or do we need an internal abstraction above this one for exit optionality?
• What is the platform upgrade policy, and who owns reindexing windows during upgrades?

Integration Approach

Stack fit.

• Native home: Ibexa DXP, PHP 8.x, Symfony (5.0.7+ tracks Symfony 7.4 LTS). Greenfield DXP projects get this for free — no integration effort, only configuration and extension.
• Hostile home: Laravel, or any non-Symfony PHP app. Do not attempt to embed. Treat Ibexa as a separate bounded context reached over HTTP or via an index-sync job.
• Grey zone: an existing Symfony app without Ibexa. Technically closer, practically still an Ibexa adoption, not a package adoption — scope it as a platform decision.

Migration path.

• From naive search (SQL LIKE, database full-text): straightforward gain in relevance control, facets, and multi-language behavior; cost is a new indexable content model and a reindex pipeline.
• From a direct engine client (raw Solr/Elasticsearch calls scattered through the codebase): the abstraction consolidates them behind one query model and buys engine portability. This is the strongest migration case.
• From a SaaS search product (Algolia, Typesense, etc.): you trade operational simplicity and community support for control and vendor consolidation. Only do this if you already run DXP or are consolidating onto it.
• Off DXP entirely: no migration path exists. Route around the package.

Compatibility.

• Pin the package implicitly through the DXP metapackage version; never constrain it independently.
• Track the 4.6 (LTS-ish) and 5.0 lines separately — the Symfony 7.4 requirement at 5.0.7 is a hard floor for older runtime images.
• Engine version compatibility is a silent trap: the abstraction normalizes the API, not the engine's own version quirks. Verify the supported engine matrix per DXP release before provisioning.

Sequencing.

1. Commercial: confirm subscription/licence posture and redistribution rights.
2. Platform: install and baseline DXP; stand up the chosen engine in a non-production environment.
3. Modelling: define content types and the fields that must be searchable, facetable, or sortable — this drives index size and query cost.
4. Indexing: configure the indexing pipeline, verify consistency between repository writes and index updates.
5. Query layer: build criteria/sort/facet usage behind an internal search service interface of your own.
6. Relevance: synonyms, analyzers, boosting — the recurring-cost phase, not a one-off.
7. Hardening: load test facets and aggregations, rehearse a full reindex, document rollback.

Operational Impact

Maintenance.

• Nominal code maintenance is near zero — the vendor ships it. The real cost is forced maintenance: DXP upgrades, PHP/Symfony runtime bumps, and engine version upgrades, all of which land on your calendar whether or not your features changed.
• Plan an upgrade slot per platform minor, and a reindex window per major. The "No significant changes" release notes do not mean "no operational work."

Support.

• Single-vendor support. Escalation is commercial, not community. There is no Stack Overflow corpus, no third-party integrator ecosystem for this specific layer, and effectively no GitHub issue traffic to learn from.
• Internally, name one owner for search. This component fails the "many people can pick it up" test.

Scaling.

• Scaling characteristics belong to the engine, not the abstraction. The abstraction will happily emit a query the backend executes expensively.
• Watch: facet-heavy navigation over large catalogs, multi-language index blow-up, multi-repository topologies, and per-request query counts from listings that re-query per item.
• Full reindex time becomes a deployment constraint — it defines your worst-case recovery point and your maximum tolerable schema change.

Failure modes to design against.

• Index drift: content published but not indexed (queue failure, worker crash) — needs a reconciliation job and a freshness metric.
• Stale-after-upgrade: mapping changes silently ignored by the backend, producing wrong results rather than errors.
• Query timeout under facet load: degrades the whole listing page, not one widget — needs per-query budgets and degraded-mode fallbacks.
• Reindex outage: full rebuild blocks or serves stale results — pick an alias-swap strategy in advance.
• Licence exposure: shipping modified search code under the GPL path without review.
• Exit coupling: features written directly against platform search APIs are expensive to unwind if you ever leave DXP.

Ramp-up.

• A competent PHP/Symfony engineer needs roughly 1–2 weeks to be productive with the query model, plus 2–4 weeks of Ibexa content-model and repository fluency before they can tune relevance safely. Add engine-specific skills (Solr schema/analyzers) if you go that route.
• TPM implication: staff this as a platform competency with a named owner, not as a ticket anyone can pick up. Budget ongoing relevance-tuning capacity — relevance is a subscription, not a purchase.
• For a Laravel-only team, factor in the anti-corruption layer and the operational ownership of a search cluster; that is the honest cost comparison against a hosted search SaaS, and it is the decision this assessment should drive.