Core Laravel Package

Technical Evaluation

Architecture fit ibexa/core is not a drop-in library — it is the core bundle of Ibexa DXP, a full-stack Symfony 7.4 application framework. It ships its own kernel integration, DI compiler passes, SiteAccess matching/routing layer, RBAC engine, field-type registry, Public API (PAPI), and persistence built on Doctrine DBAL. Every one of those layers competes with, rather than complements, Laravel's container, router, and Eloquent/DBAL stack. Installing this into a Laravel composer.json is not a realistic integration path; the only defensible fit is a headless boundary: Laravel consumes Ibexa's REST/GraphQL PAPI as a content service, with Ibexa running as an independently deployed application. Treat it as a third-party platform integration, not a package adoption.

Integration feasibility Three options, ranked:

1. Separate Ibexa instance + PAPI over HTTP — feasible; contract is HTTP + PSR-18/PSR-7, so framework version drift is contained.
2. Symfony sidecar service behind a Laravel gateway — feasible but doubles the runtime footprint for no clear gain over (1).
3. Embed ibexa/core inside Laravel — not feasible; reject early to avoid a wasted spike.

Technical risk

• License: NOASSERTION is a hard gate. Ibexa core is distributed under GPL-2.0 for the community edition with a commercial tier for enterprise functionality. GPL-2.0 copyleft is incompatible with closed-source distribution, and NOASSERTION means automated scanners cannot clear it. Legal review must complete before engineering commits.
• Dual release track. v4.6.x (LTS, currently through .27+) and v5.0.x are maintained in parallel, and 5.0.7 explicitly merged the 4.6 branch. Choosing a track is a product decision with an EOL consequence, not an engineering one.
• Platform coupling. 5.0.7 bumped Symfony to 7.4 LTS and CI to PHP 8.3/8.4. This forces our own runtime baseline even though the deployments are separate.
• Vanity-metric distortion. 8 stars / 0 dependents / score 33.1 vs. opportunity 82.1 is an artifact of this being a split repo of a commercial product, not a signal of weak adoption — but it does mean there is no public issue surface, no Stack Overflow depth, and vendor-gated trackers (issues.support.ibexa.co, ibexa.atlassian.net).

Key questions before approval

1. Which track — 4.6 LTS or 5.0 — and what are the contractual EOL and security-patch commitments for our horizon?
2. What does NOASSERTION resolve to, per package, for the specific composer dependencies we would require? Any commercial entitlement needed?
3. Do we require Solr/Elasticsearch, or does the DFS/DBAL fallback meet our latency and volume targets?
4. Is semantic/embedding search (added in 4.6.26/5.0.4) in scope? If so, who hosts the model?
5. Who owns upgrades — internal team or a paid support entitlement?

Integration Approach

Stack fit Laravel remains system of record for application domain data; Ibexa is system of record for content. The boundary is a thin Laravel adapter package that wraps PAPI endpoints with typed DTOs, HTTP caching, retry/backoff, and circuit breaking. Keep it isolated behind an interface so the backing CMS can be replaced without touching domain code. Authentication via JWT/OAuth to Ibexa; caches and queues stay separate per system.

Migration path

1. License clearance and track selection (week 0, blocking).
2. Content audit and model mapping — existing content types to Ibexa content types and field types.
3. Stand up Ibexa independently (official Docker images), selecting storage (DFS vs. S3-backed external storage) and search backend.
4. Build the adapter against a read-only vertical slice to prove the contract.
5. Backfill legacy content via PAPI plus ibexa:io:migrate-files for binaries; validate dedupe behavior given the deterministic image hashing change in 5.0.7.
6. Cut over reads, then writes, then decommission legacy paths.

Compatibility PHP 8.3/8.4 on both sides is workable. Symfony 7.4 inside Ibexa vs. Laravel's Symfony constraints is a non-issue because the systems are separately deployed — only the HTTP contract crosses. Pin the Ibexa minor version and run an integration suite against a staging instance; do not float ^5.0.

Sequencing License → spike (2–3 weeks, read path only) → go/no-go → build → migrate → cutover. Do not let the vendor procurement and the engineering spike run serially beyond the spike.

Operational Impact

Maintenance The patch cadence is high — 5.0.4 through 5.0.9 landed in a short window, with Symfony and PHP baseline bumps inside minor releases. Each bump requires a staging regression run against our adapter contract, not just a dependency update. Budget recurring upgrade capacity, not a one-time integration cost.

Support Primary support is vendor-gated. There is no public issue tracker or community answer base for this repo. For anything business-critical, a paid support entitlement is effectively mandatory; otherwise we absorb breakage on our own timeline.

Scaling Cost centers are persistence, search, and object storage. Solr/Elasticsearch and the external storage backend are new operational components with their own runbooks and on-call surface. Embedding-based search adds a model-hosting or third-party inference dependency — an additional latency and failure boundary. Caching must be reasoned about per SiteAccess, which is a concept the Laravel team will not have prior intuition for.

Failure modes

• Search backend unavailable → degraded PAPI search; Ibexa fallback behavior differs by engine, so degraded UX must be designed explicitly.
• External storage (S3) failure → media 404s and upload backlog; the dedupe hashing change means migration-time validation is required.
• Legacy storage DB latency → the entire content API slows. Recent releases made several services lazy (ProxyDomainMapperFactory, CriteriaConverter, SerializerFactory) specifically to avoid early connection initialization — misconfiguration here manifests as boot-time connection storms.
• RBAC regressions are silent and high-severity; 5.0.7 altered _access_control_attributes propagation, so authorization tests belong in the adapter contract suite.
• Destructive admin flows have known edge cases (user/group deletion vs. assigned roles in 5.0.8) — test them before trusting the admin surface.

Ramp-up This is not learnable in a sprint. A Laravel-fluent team needs roughly 4–8 weeks to become productive on read paths alone, and considerably longer for content modeling, field types, and permissions. Recommendation: contract or hire one Ibexa specialist to own platform and upgrades, paired with an internal Laravel engineer who owns the adapter — rather than training a team from zero on a stack this wide.