Content Browser Ibexa Laravel Package

Product Decisions This Supports

• Feature: repository-wide editorial content browsing and picking. The concrete capability this enables is the "find any content in the CMS, then select/relate/embed it" workflow — the plumbing behind content relation pickers, page/block composition, and cross-location or cross-site content reuse. It does not invent that workflow; it connects Ibexa DXP's content repository to Netgen Content Browser's picker UI so selected items resolve to real content objects and locations.

• Build vs. buy for content discovery UX. The real decision is whether to buy a content browser plus its Ibexa integration, or build a bespoke finder on Ibexa's search/GraphQL APIs. Buying means accepting two upstream vendors; building means owning search UX, filtering, previews, permissions, and multi-language handling indefinitely. This package is the cheap connector that makes the "buy" option viable on Ibexa.

• Platform gating, not a platform bet. This package is only meaningful after Ibexa DXP has been chosen or is under active evaluation. It is a downstream consequence of a CMS decision that should be made on other grounds, and it has zero value outside the Ibexa ecosystem.

• Use cases it plausibly unlocks: editorial "insert existing content" flows, cross-location and multi-language content search, relating content to Netgen Layouts blocks, and admin tooling for locating content during migrations or audits.

• Licensing and distribution decision (GPL-2.0). This is a product and legal input, not a technical footnote. If you ship a proprietary or closed distribution, copyleft obligations on a linked integration can become a commercial blocker. That call needs to happen before architecture, not during diligence.

• Support-model and ownership decision. The adoption footprint is effectively nil (0 stars, 0 dependents). The "who supports this?" answer is a vendor contract or an internal owner — not a community. That is a resourcing commitment a PM has to fund, not just an engineering detail.

• Upgrade-cadence commitment. Every Ibexa, Symfony, or PHP upgrade becomes a three-way compatibility exercise: Ibexa, the Content Browser core, and this shim. Roadmaps that assume smooth platform upgrades need to budget for that.

When to Consider This Package

Consider it when:

• You are running Ibexa DXP (Symfony-based) and have a concrete, articulated editorial gap that Ibexa's native relation, embed, and query tooling does not close. Start from the gap, not the package.
• You would otherwise build a content finder in-house, and the scope is large enough that an off-the-shelf browser is cheaper than 1–2 engineers for a quarter.
• You accept two dependencies, not one: this integration and netgen/content-browser core. Evaluate the upstream's release cadence, support terms, and upgrade path first — this repo inherits all of its risk.
• Your team is comfortable with Symfony bundle/DI configuration and can map your content model (content types, locations, languages, versions, permissions) onto the browser's item abstraction.
• You can pin and audit the dependency: confirm whether this repo is a read-only split of a vendor monorepo, check commit recency, tags, CI, and whether fixes land here or upstream.
• GPL-2.0 is acceptable for your distribution model, or alternative vendor terms are obtainable.
• Legal, security, and support questions are answered before the spike, not after: does the browser enforce Ibexa's content-level permissions (a bypass is a security finding), and does it honor multilingual/multisite semantics?

Look elsewhere when:

• Your stack is Laravel. Despite the "Laravel/PHP" framing, this is a Symfony/Ibexa-native integration with no Laravel service provider, no Eloquent, no Blade. There is no reason to pull Ibexa-flavored Symfony wiring into a Laravel product. The only sane pattern is a separate Ibexa deployment with this package installed CMS-side, consumed headlessly — at which point it is an editorial tool, not an application dependency.
• Your CMS is anything other than Ibexa DXP — WordPress, Drupal, Strapi, Contentful, or custom. There is no adapter for you, and writing one means taking on this package's job.
• You need community-validated, actively adopted OSS. With no stars, no dependents, and a very low health signal, assume you are the maintainer of last resort.
• GPL-2.0 is a hard no and no commercial license is available.
• Your need is narrow — a single "related content" field or simple embed. Ibexa's native capabilities will be lower-risk and lower-cost than adding two libraries.
• You cannot accept coupling to two upstream release cycles. The package's surface area is small, but its breakage surface is the intersection of both vendors' roadmaps.

Decision sequencing if you proceed: (1) editorial requirements and gap analysis; (2) GPL-2.0 legal review against the distribution model; (3) timeboxed technical spike on a pinned Ibexa sandbox including a permission-bypass test; (4) go/no-go versus Ibexa native tooling and versus a thin in-house browser; (5) if go, vendor-fork the package, add CI against a pinned Ibexa/Symfony/PHP matrix, and pilot with a small editor group.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, single-purpose integration library, not a platform bet. Its only job is to let an Ibexa DXP site use Netgen's Content Browser, which gives editors a proper "find and reuse content" experience. The strategic commitment is the two upstream products and their support contracts; this package is the inexpensive connector between them. Two caveats drive the recommendation. First, it is GPL-2.0 licensed, which matters if we ship proprietary code. Second, it has essentially no public adoption, so support will come from the vendor or from us — not from a community. Recommendation: approve a short, timeboxed spike to prove the editorial workflow on one site, and do not commit it to the roadmap as a capability until the license question and the upstream support arrangement are settled.

For engineering — the short version: Treat this as glue, not a framework. Expect a thin adapter that maps Ibexa's content repository (content types, locations, languages, versions, permissions) onto Content Browser's item/backend interface, plus Symfony bundle wiring and configuration. Code volume will be low; coupling will be high, because every meaningful change touches two upstream APIs. Before adopting: confirm whether this repository is a generated split of the vendor monorepo (fixes may belong upstream, not here), pin exact versions of both dependencies, and write a contract test around the mapping layer so upgrades fail loudly rather than silently. Budget for owning the mapper — if the vendor relationship lapses, that mapping code becomes ours to maintain, and a vendored fork is the realistic exit. Do not attempt to port this into a Laravel codebase; the value is inseparable from Ibexa's repository and permission model.