Weave Code
Core Search Laravel Package
ibexa/core-search
Core search package for Ibexa DXP, providing the search engine abstraction, indexing, and query infrastructure used to power content search and filtering across the platform. Install as part of Ibexa DXP.
At a glance
Frequently asked questions about Core Search
- Is ibexa/core-search a Laravel package, and can I use it in my Laravel app?
- No. This is a Symfony-based Ibexa DXP component built on Ibexa contracts and Symfony dependency injection, with no Laravel service provider, facade, config file, or Eloquent/Scout bridge. Its query objects operate on Ibexa Content and Location value objects plus content-type metadata owned by sibling DXP packages, so there is no meaningful way to index or query your Eloquent models with it. Embedding it in a Laravel app means porting service definitions and value objects into an alien container, which is a rewrite rather than an integration. The sane pattern is an anti-corruption layer: keep your Laravel domain model, push documents to Solr or Elasticsearch over HTTP or a queue, and never let Ibexa types leak into product code.
- How do I install ibexa/core-search with Composer?
- The upstream README is explicit: install Ibexa DXP, not this package in isolation. Running composer require ibexa/core-search on its own may resolve dependencies, but the application will fail at runtime because the content repository services, field type registry, and a configured search backend will be missing. Backend selection is a separate and mandatory step, since the abstraction only becomes useful once a concrete engine package is installed and provisioned. Within a real DXP install you get this package for free, so your effort goes into content modelling and index design rather than wiring.
- Which search engines does ibexa/core-search support?
- The package itself is engine-agnostic: it defines the search engine abstraction, the criteria, aggregation, and sort model, and the indexing and query infrastructure. Concrete engines are supplied by separate implementation packages, with Solr and Elasticsearch being the practical choices in the Ibexa DXP ecosystem. You must pick one, provision it in your infrastructure, and configure it before any search feature works. Treat engine choice as an infrastructure decision your operations team owns, not a purely technical detail.
- What PHP and Symfony versions does ibexa/core-search require?
- It targets PHP 8.x and Symfony, with the 5.0.x platform line tracking Symfony 7.4 LTS as of 5.0.7. Ibexa DXP currently ships 4.6.x and 5.0.x in parallel, so the exact constraint you inherit depends on the platform release you adopt. That constraint comes from the platform, not from this repository, so always check the DXP release notes for the version you plan to run. If your Laravel app is on a different PHP or Symfony baseline, expect framework-level friction on top of the architectural mismatch.
- What is the license for ibexa/core-search, and can I use it commercially?
- It is dual-licensed under the Ibexa Business Use License 2.4 or later and the GNU General Public License version 2, which Composer surfaces as NOASSERTION. Commercial use is clean only if you hold a valid Ibexa DXP subscription that covers the environments you intend to run. On the open-source path, GPLv2 copyleft applies and can oblige source disclosure if you ship modifications, which matters for OEM and white-label distribution. Get procurement and legal sign-off before any engineering work begins, because licensing here is a bigger risk than the code itself.
- Can ibexa/core-search be used standalone without the Ibexa content repository?
- No. The package is a seam inside a platform, not a standalone search library, and it has no meaning without the surrounding content model. Its criteria, aggregation, and sort objects query Content and Location value objects and content-type metadata owned by sibling packages. Without the repository services and field type registry present, you cannot index or query anything meaningful. If you need a portable search layer, look at Laravel Scout or a direct engine client instead.
- How do I add custom index fields, custom handlers, or boosting rules in ibexa/core-search?
- The abstraction ships sensible defaults for indexing and querying, but custom index fields, handlers, and boosting typically require extension work that sits outside those defaults. Whether that work lives cleanly in supported extension points or pushes you into platform-specific engine code is the key question to settle early. Scope this during design, not after launch, because it determines how bound your product features become to Ibexa search internals. If exit optionality matters, keep an internal abstraction above this one so a future engine swap does not ripple through your domain code.
- Is ibexa/core-search actively maintained, and what happens if I hit a bug?
- It is vendor-controlled and low churn: most releases read 'No significant changes,' which signals a mature component rather than an abandoned one. The real change vector is the platform release train, with 4.6.x and 5.0.x in parallel and Symfony 7.4 LTS landing at 5.0.7. There is essentially no community around the repo, so the vendor is your bus factor and there is no independent talent pool or third-party tutorial fallback. Security and bug fixes arrive through a DXP upgrade, which may drag in unrelated platform changes, so plan your upgrade policy and reindexing windows in advance.
- How do I test search functionality built on ibexa/core-search?
- Because the package is primarily interfaces plus a criteria, aggregation, and sort model, you can unit test your query-building logic by implementing those contracts with fakes or in-memory doubles. End-to-end verification still needs a provisioned Solr or Elasticsearch instance, so budget for integration environments and realistic fixtures. Expect to manage reindexing as part of test setup and platform upgrades, since index state is operational, not just code. There are no Laravel-style test helpers here, so any testing harness is something your team builds.
- What are the alternatives to ibexa/core-search for a Laravel application?
- For a Laravel-first product, use Laravel Scout with Meilisearch, Typesense, or Algolia, or talk directly to Elasticsearch or Solr through their official clients with a queued indexing pipeline. TNTSearch is a reasonable lightweight option for small datasets, and Eloquent observers plus a queue keep indexing decoupled from request handling. These options let you keep your domain model intact and preserve exit optionality, which ibexa/core-search explicitly does not. Choose ibexa/core-search only when you are already running Ibexa DXP and get it as part of the platform.
Weaver
How can I help you explore Laravel packages today?