Core Search Laravel Package

Product Decisions This Supports

• Search and discovery roadmap within Ibexa DXP. This package is the search abstraction layer of the Ibexa platform — the query model, criteria/sort/aggregation building blocks, and indexing pipeline that backend implementations plug into. It frames decisions such as whether to invest in faceted catalog navigation, relevance tuning, suggestions, or multi-language/multi-repository search, and what each would cost in configuration versus custom code.
• Build vs. buy vs. extend. Because the contracts live here and engine-specific behavior lives in sibling packages, the real decision is almost never "adopt this package" — it is "extend the platform's search abstraction, tune the backend, or swap engines." That keeps options open: changing the search engine or adding an index field does not require rewriting content controllers.
• Feature scoping and cost-tiering. It helps separate capabilities that are native and cheap (filtered listings, criteria-based queries, sorting), those that are configuration work (analyzers, synonyms, boosting, facets on existing metadata), and those that need bespoke engineering (merchandising rules, custom relevance signals, cross-repository federation). Useful input to sprint-level estimation and roadmap sequencing.
• Upgrade and lock-in planning. The package versions in lockstep with the DXP (parallel 4.6 and 5.0 lines, many releases with "no significant changes"). That informs release cadence expectations, deprecation exposure, and how tightly product features should bind to platform-specific search APIs versus an internal abstraction of our own.
• Sizing ongoing relevance investment. Search quality is a recurring operational cost, not a launch deliverable. The existence of this package means the vendor owns the mechanics; the PM decision is how much internal effort goes into tuning, query design, and relevance measurement versus accepting defaults.
• Procurement and licensing posture. The dual arrangement (Ibexa Business Use License under a DXP subscription, or GPLv2) is a commercial input affecting redistribution, OEM/white-label scenarios, and whether modifications to the search layer carry source-disclosure obligations.

When to Consider This Package

Consider it when all of the following hold:

• You are building on, or already subscribe to, Ibexa DXP and need to understand, configure, or extend platform search behavior.
• Requirements are content-search shaped — listings, filters, facets, relevance, suggestions over a CMS/PIM content model — not general-purpose search.
• You accept working through the platform's search service abstraction and its release cadence rather than pinning an independent library.
• You want engine portability (e.g., Solr vs. Elasticsearch) behind one query model.
• Your legal/procurement team is comfortable with the license posture: commercial terms via subscription, or GPLv2 obligations on the open-source path.

Look elsewhere when:

• You are not on Ibexa DXP. The README explicitly routes installation through the DXP; this is an internal component, not a standalone dependency. The 1-star / 0-dependent signal is not evidence of abandonment — it is consumed inside the DXP distribution — but it does confirm there is no independent community to lean on for support, examples, or third-party fixes.
• You need a self-serve, standalone search library with in-repo documentation and a public contract. Here you get a README pointing at vendor docs plus release notes, most of which read "no significant changes."
• Your search needs are non-content: log analytics, large-scale vector/semantic retrieval, geospatial, or high-QPS consumer search that warrants a dedicated engine and team.
• License risk is unacceptable or the "NOASSERTION" classification will stall a security/procurement review — plan for legal review up front rather than discovering it at ship time.
• You need community velocity as a signal of health. Releases exist and are current, but the changelog is thin and issue tracking is vendor-internal; treat maturity as "vendor-maintained, stable, low public transparency."

How to Pitch It (Stakeholders)

To executives: This is not a product we buy — it is the search engine room inside Ibexa DXP, which we already license. Its value is strategic optionality: one query model across multiple search backends means we can change engines or tune relevance without rebuilding content pages. The decision it enables is how much we invest in search quality — facets, relevance tuning, suggestions — versus accepting platform defaults. Two caveats worth flagging: licensing is commercial-or-GPLv2 and needs a legal read before we build anything differentiating on top of it, and the component is vendor-maintained with little public documentation, so our dependency is on the Ibexa relationship, not on an open-source community.

To engineering: Treat this as the search contract layer, not a library to vendor in. Extend through the provided interfaces — custom handlers via dependency injection, additional index fields, query and aggregation composition — rather than forking, which would put us on the wrong side of both the license and the upgrade path. Keep any product-specific search logic behind our own thin abstraction so a future engine swap or DXP upgrade does not ripple through controllers. Note the parallel 4.6/5.0 release lines and Symfony 7.4 LTS alignment when planning upgrades, and expect thin changelogs: budget for reading source and vendor docs, not release notes.