Content Browser Ezplatform Laravel Package

Product Decisions This Supports

• Editorial tooling investment (back-office UX). This package wires Netgen Content Browser into eZ Platform so editors can search, filter, and pick content from the repository instead of navigating the raw content tree. It supports a roadmap decision on whether content discovery/curation inside the admin UI is worth funding versus leaving editors on native tree navigation.
• Build vs. buy vs. integrate for content browsing. Rather than specifying a bespoke "content picker" (relation fields, landing-page block composition, cross-section content reuse), this is a candidate to integrate off the shelf. It shifts the question from "how do we build a browser?" to "how much glue and risk do we accept for a pre-built one?"
• Landing page / block composition capability. Content Browser is typically the input layer for page-building and content-relation features. Adopting it is a prerequisite decision for any roadmap item like "assemble pages from reusable content blocks" or "curate collections across sites/languages."
• Licensing and distribution posture. GPL-2.0 is a genuine product decision input: acceptable for internally hosted editorial tooling, but it constrains any plan to redistribute the platform or ship a derivative product. This belongs in the buy-vs-build conversation, not just legal review.
• Dependency and support risk budgeting. 13 stars, zero dependents, and a very low composite score (0.095) mean this is an unproven, thinly adopted component. That supports a decision to treat it as vendored code we own rather than a dependency we consume — with the corresponding maintenance line item.
• Platform version strategy. It's an eZ Platform integration (Symfony-based, not Laravel). Its existence is a data point in the "stay on legacy eZ Platform vs. migrate to Ibexa DXP" decision, because migration invalidates this integration.

When to Consider This Package

Consider it when all of the following hold:

• You are running eZ Platform (legacy line) — not Ibexa DXP 4.x, and not a Laravel application. This package will not drop into a Laravel stack; the "PHP package" framing is accurate only at the language level, not the framework level.
• Editors have a concrete, voiced pain point: finding and relating content is slow, or you have a roadmap item that needs content picking/curation that native eZ admin doesn't cover well.
• You are comfortable with GPL-2.0 for internal, non-distributed use, or you have cleared the copyleft implications for your distribution model.
• You have in-house PHP/Symfony capacity to read, pin, and patch a small, low-traffic repository — assume no upstream SLA and no community to lean on.
• You can vendor or fork it deliberately and track the diff, rather than pull it in as a normal Composer dependency you expect to stay healthy.

Look elsewhere when:

• Your stack is Laravel, Symfony standalone, or headless/API-first with a JS front end — you need a different content-browsing layer entirely.
• You are on or moving to Ibexa DXP 4.x+; evaluate Ibexa's native content browsing/search and Netgen's commercially supported offerings instead.
• You need a support contract, security response commitments, or an active maintainer — that is a procurement requirement this repository does not satisfy.
• Your product is distributed or resold and GPL-2.0 is incompatible with your licensing model.
• The need is thin (a handful of relation fields) — native eZ features or a small internal implementation will be cheaper than owning this dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a small, focused open-source component that gives editors a proper content browser — search, filter, and pick content from the repository — inside our eZ Platform admin. It would let us ship editorial curation and page-composition features without building a content picker from scratch. The trade-off is maturity: it has minimal adoption and a single maintainer, and it's GPL-2.0 licensed, so it's fine for our internal platform but constrains any plan to redistribute. My recommendation is to treat it as code we adopt and own, budget a small amount of engineering to vendor, pin, and patch it, and gate the decision on confirming we're staying on eZ Platform rather than migrating to Ibexa.

For engineering: This is an eZ Platform/Symfony integration, not a Laravel package. It's GPL-2.0, 13 stars, zero dependents — assume we may be the only ones running it in anger. Plan to fork or vendor it, pin the version, add it to our patch-maintenance rotation, and write an ADR covering the licensing position and the exit path if we migrate platforms. Validate against our exact eZ version before committing to a roadmap dependency.

Framing to avoid: don't present this as a strategic platform bet or a "solution." It's a tactical build-vs-buy shortcut with a known ownership cost — useful if we're staying put and need editorial tooling now; a distraction if the platform itself is in question.