Solr Laravel Package

Technical Evaluation

Architecture fit

• This is not a Laravel package. ibexa/solr is a Symfony bundle (Ibexa\Bundle\Solr\IbexaSolrBundle) and a first-party component of Ibexa DXP. It implements the Ibexa search engine SPI (SearchService, Criterion/SortClause visitors, facet and aggregation builders) against Apache Solr over HTTP.
• It therefore has zero addressable fit in a Laravel codebase. It has no service provider, no Laravel contracts, no Eloquent/Query Builder bridge, and its public API is expressed entirely in Ibexa domain objects (Content, Location, ContentType, RepositoryConfigurationProviderInterface). Pulling it into Laravel is not a "glue code" problem — it is a category error.
• Where it does fit: an existing Ibexa DXP 4.6 LTS or 5.0 deployment that has outgrown the built-in legacy/Legacy Search Handler and needs scalable faceting, spellcheck, geospatial/country aggregation, and vector/semantic retrieval.
• Relevant capability surface for a roadmap conversation: Solr 9.8+ support, dense-vector dynamic fields with dimension-based embedding suffixes, an embedding visitor for vector search, spellchecking, image and content-name criteria, IsBookmarked / IsUserEnabled / IsContainer criteria, and configurable HTTP client timeout and retry counts.

Integration feasibility

• Trivially feasible inside Ibexa DXP: composer require ibexa/solr, enable the bundle, point it at a Solr connection, create cores, run a full reindex. The README's only prerequisite is "install Ibexa DXP".
• Infeasible standalone: unit tests run against a bootstrap, but integration tests require ibexa/core and a live Solr instance (CORES_SETUP="single" or multi-core). There is no meaningful "use this library for Solr search in your app" path.
• Extension points are clean but Ibexa-shaped: criterion and sort-clause visitors are injected via a tagged iterator (v4.6.29/v5.0.7), which is the correct place to add custom query semantics — but you are extending an Ibexa bundle, not a generic search abstraction.

Technical risk

• Note the 4.6.x and 5.0.x release lines are maintained in parallel — a genuine LTS pattern that de-risks upgrade timing, but it also means you must track two branches and pin deliberately.
• Several releases ship "No significant changes," which reads as stability rather than abandonment; substantive work (Solr 9.8+, vector fields, Symfony 7.4 LTS) is landing on a steady cadence.

Key questions for the vendor / team

1. Is there an Ibexa DXP subscription in place, and does it cover ibexa/solr under the BUL — or are we accepting GPLv2 obligations?
2. What is the supported Solr version window and the configset upgrade procedure between DXP minors?
3. What are the documented RPO/RTO expectations for index rebuild, and is there a supported zero-downtime reindex path (dual-core swap)?
4. Which branch do we pin (4.6 LTS vs 5.0), and what is its published EOL?
5. Are the vector/embedding features production-supported or preview, and who supplies the embedding model?
6. What is the vendor's SLA and escalation path for search-specific defects?

Integration Approach

Stack fit

• Target stack is PHP 8.3+, Symfony 6.4/7.x, Ibexa DXP 4.6 LTS or 5.0, Apache Solr 9.8+. If the stack is Laravel, this package is out of scope — the correct analogues are Laravel Scout with a Solr driver (e.g. Solarium-based) or Meilisearch/Typesense/OpenSearch. Recommend rejecting this package for any Laravel roadmap item and recording the rationale.
• If Ibexa DXP is already the CMS, ibexa/solr is the sanctioned and lowest-risk search backend; the alternative (custom Solr integration) means reimplementing the entire visitor/aggregation layer.

Migration path (Ibexa context)

1. Confirm licensing and Solr version; provision Solr 9.8+ (single core for non-prod, multi-core or SolrCloud for prod).
2. Deploy the matching configset/schema from ibexa/core — schema is owned upstream, not by this bundle.
3. composer require ibexa/solr on the matching 4.6.x/5.0.x line; enable the bundle; configure connection(s), basic auth, timeout, and max retries.
4. Switch the search handler to Solr in configuration behind a feature flag.
5. Full reindex during a maintenance window; validate with the integration test suite against a real Solr host.
6. Enable incremental indexing (content events) and verify sync lag and delete/unpublish propagation.

Compatibility and sequencing

• Treat DXP upgrade and Solr bundle upgrade as a single atomic change; the bundle's major version is aligned to the DXP major.
• Solr major upgrades (e.g. 8 → 9.8+) require a schema/configset migration and a full reindex — sequence as its own release, not bundled with a DXP upgrade.
• Facet/aggregation API changed materially in 5.0 (deprecated Facets API removed); any custom facet code must be ported before the 5.0 cutover.
• Custom criterion visitors must be re-validated against the tagged-iterator injection change; service definitions that were manually ordered may silently drop out.
• Sequence: licensing sign-off → Solr provisioning → configset → bundle install → parallel run (old handler vs Solr, compare result sets) → cutover → decommission old handler.

Operational Impact

Maintenance

• Two active branches (4.6.x, 5.0.x) require patch tracking; releases are mostly small and low-churn, so monthly triage is sufficient, but security-adjacent items (e.g. credentials removed from error output in v5.0.8) must not be skipped.
• Schema/configset is upstream-owned: every DXP minor may require a reindex. Budget reindex windows as recurring operational cost, not a one-off.
• Upstream dependency floor moves (PHP 8.3, Symfony 7.4 LTS) — plan an annual platform-currency review.

Support

• Support runs through Ibexa's commercial portal (IBX issue keys), not GitHub issues. Without a subscription, you are on GPLv2 self-support with a single-vendor upstream and a very small public community — that is the dominant support risk.
• Bus factor: one vendor. Institutional knowledge must be built in-house (configset, reindex runbook, query tuning).

Scaling

• Solr scales horizontally (shards/replicas) independently of PHP; this is the main reason to adopt it over the legacy handler for large content repositories and heavy faceting.
• Watch: facet cardinality on high-cardinality fields, dense-vector field memory footprint (vector fields are RAM-hungry — size heap accordingly), and HTTP client retry behaviour under Solr latency (timeout/retries are configurable, so tune rather than accept defaults).
• Indexing throughput matters more than query throughput for editorial-heavy sites; batch/bulk indexing was explicitly optimised upstream.

Failure modes

Ramp-up

• Do not plan a ramp-up for a Laravel team — there isn't one. This should be closed out at triage.
• For an Ibexa team: ~1–2 weeks for a PHP/Symfony developer to operate it (config, reindex, log reading); ~3–4 weeks to extend it (custom criterion visitors, aggregation builders, vector field mapping). Add Solr administrator skills (core topology, schema, heap sizing, GC tuning) — that is the scarcer competency and should be sourced or contracted explicitly.
• Deliverables to require before go-live: reindex runbook, schema upgrade checklist, monitoring dashboards (query latency, error rate, index lag, JVM heap), and a documented rollback to the prior search handler.