Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the content platform itself. ibexa/core is not a utility library — it is the engine of a full DXP: content repository, content-type/field modeling, versioning and drafts, locations/tree, multilingual, URL aliases, users/roles/permissions, notifications, and file/asset I/O. The decision it informs is "do we spend two to four quarters of platform engineering on a content backbone, or license/adopt one?"
• Roadmap scope for content features. The PAPI surface tells you what you can promise without writing it: custom content types, editorial drafts and version history, translation workflows, granular RBAC, per-site access rules (SiteAccess matchers), and programmatic content search. Anything on that list becomes a scheduling question, not a feasibility question.
• Multi-site and multi-language expansion. Recent work on HostText/UriText matchers, SiteAccess serializer factories, and multilingual field handling (e.g. empty multilingual selection options) signals that running many branded sites off one content tree is a supported, maintained path — relevant to geographic or brand-portfolio growth decisions.
• AI/semantic search as a roadmap bet. Embeddings-based search landed in both the 4.6 and 5.0 lines (IBX-9846), with follow-up fixes for default model inheritance and field-name fallback prefixes. That lets you put "semantic/vector content discovery" on a near-term roadmap as configuration + integration work rather than a research project.
• Infrastructure cost decisions for media. Deterministic image hashing to stop duplicate accumulation (IBX-11383) and reference-aware external storage (IBX-11437) are directly relevant to object-storage and CDN spend, and to whether you can move assets to S3-compatible storage without breaking references.
• Enterprise deal readiness. Permission model, access-denied vs. forbidden exception semantics, and a maturing notification API (filtering, mark-as-unread, bulk mark-as-read, typed renderers) are the features that unblock procurement reviews and editorial-adoption metrics in larger accounts.
• Upgrade/currency planning. Dual-track releases (4.6.x LTS and 5.0.x) with Symfony 7.4 LTS and PHP 8.3/8.4 support make "stay on LTS vs. move to 5.x" an explicit, schedulable product decision rather than an emergency.

When to Consider This Package

Consider it when most of these hold:

• You are genuinely building or replacing a content platform — hundreds to hundreds of thousands of content objects, several content types, an editorial team, not a five-page marketing site.
• You need multi-site and/or multilingual delivery from a single content repository; retrofitting i18n and site routing later is where rewrites come from.
• You need fine-grained permissions, versioning/audit trail, and scheduled publishing — the requirements that enterprise buyers put in questionnaires.
• Your stack is Symfony-oriented PHP with a platform team that can own a DXP-sized dependency, its search backend (Solr/Elasticsearch), and its database.
• You want a stable public API boundary (PAPI) so application code survives internal refactors and major upgrades.
• You are comfortable with a copyleft-leaning license and a commercial edition — legal review is mandatory, not optional.

Look elsewhere when:

• You are a Laravel shop. This is Symfony-first. There is no Eloquent, no native Laravel queue/event integration; you'd be running two frameworks side by side and integrating at HTTP/session/SSO level. The cost is real.
• You need a permissive license (MIT/Apache) for redistribution or a closed-source product. NOASSERTION on the repo plus GPL lineage means your counsel must sign off before this becomes architecture.
• Content volume is small and the team is small. A lightweight headless CMS or a Laravel-native option (e.g. Statamic) will get you live in weeks with a fraction of the operational surface.
• You need to launch in under a quarter with no prior Ibexa experience — onboarding, search infra, and content modeling will eat the schedule.
• You want a vendor-hosted SaaS with an SLA and no infrastructure ownership. That's the commercial Ibexa Cloud path, not this package.
• You're reading stars as a quality signal. 8 stars and 0 public dependents reflect that the ecosystem is commercial/private, not that the code is unused — but it also means thin public community support. Budget for vendor support.

How to Pitch It (Stakeholders)

To executives: "We are deciding whether to build a content platform or adopt one. This is the core of a mature, actively released DXP: monthly patch cadence, two maintained release lines (LTS 4.6 and 5.0), current Symfony 7.4 LTS and PHP 8.3/8.4 support, and recently shipped semantic-search capability we'd otherwise fund as an R&D line. Adopting it converts a multi-quarter platform build into integration and content-modeling work — the cost avoidance is measured in engineer-quarters, and the AI-search and external-storage work in recent releases is spend we don't have to duplicate. Two caveats we must resolve before committing: the license needs legal sign-off (it is not permissive), and the open-source repo's popularity metrics understate the ecosystem because most usage sits behind commercial editions — so we should price in vendor support rather than assume community support."

To engineering: "Treat this as a platform dependency, not a Composer utility. It's Symfony-native — expect a second framework alongside Laravel, integration at HTTP/session/SSO rather than ORM level, and real work in search backend configuration and content-type modeling. What you get in return: a documented public API (PAPI) as the stable boundary, mature content versioning/drafts/locations/URL aliases, RBAC, a findContentTypes criteria API that keeps expanding (most recently ContentTypeGroupName), and clean seams for external file storage and vector search. Watch the dual release track — pick LTS or 5.x deliberately and pin it. Also verify the release timeline in the repo; some published dates look ahead of today, which affects our upgrade calendar."