Content Browser Ezplatform Laravel Package

Product Decisions This Supports

• Build vs. buy for admin content navigation. The package is an off-the-shelf tree browser with search/filter, metadata previews, and configurable views for eZ Platform/Ibexa admins. If we operate an Ibexa estate, this is a credible "buy/consume" answer to a common editorial-UI need — cheaper than building tree traversal, filtering, and preview surfaces in-house. If our estate is Laravel-first, it answers nothing directly; it is instead a reference design for a capability we would still have to build.
• Roadmap sequencing for editorial tooling. Content discovery friction is a real productivity tax for editors managing large content trees. This package bounds the scope of a "content browser" epic down to configuration and integration work rather than greenfield UI development — conditional on stack fit.
• Feature-level decision: in-admin browsing vs. separate tooling. The package's premise is embedding browsing inside the existing admin UI. That is a product stance worth adopting or rejecting explicitly: do we invest in editor-facing in-context navigation, or push content discovery into a separate internal tool/API? This package only supports the former.
• Reference for UX patterns, not code reuse. Tree navigation, contextual metadata, and workflow-configurable views are well-understood patterns. Even in a non-adoption outcome, the package is a low-cost input to design discovery for our own admin experience — read it, don't depend on it.
• Licensing decision (GPL-2.0). This is a product-legal gate, not an engineering detail. GPL-2.0 copyleft obligations can constrain how we distribute or bundle a product. If our admin tooling is internal-only, exposure is typically contained; if it ships to customers, this needs legal sign-off before it enters the roadmap at all.
• Not a decision this supports: any Laravel-side capability. There is no service provider, facade, config publish tag, or Laravel version constraint. Routing this in as a "PHP package" is a keyword match, not a fit.

When to Consider This Package

Consider it when:

• We operate eZ Platform or Ibexa and need faster editorial content discovery in the admin UI — the intended, low-friction use case.
• The capability is scoped to read-path browsing: locate, filter, preview. No auth, payment, or data-integrity boundary is involved, so worst-case failure is a degraded admin experience rather than a security or data-loss incident.
• We can tolerate a small-maintainer project: acceptable only if we are willing to pin exact versions, review every diff manually, and hold a fork-and-vendor fallback.
• GPL-2.0 is compatible with how we ship (internal tooling: usually fine; distributed product: legal review first).
• We have (or can borrow) Ibexa-fluent engineering: Symfony bundle/DI, content model (locations, content types, permission policies), Twig, Composer constraint resolution.

Look elsewhere when:

• The target application is Laravel. There is no integration surface. Bridging it is a multi-quarter custom-adapter commitment, not an integration task — build a thin native browser against our own content API instead.
• We need a supported dependency with a legible release history. v1.4.2 ships a release note consisting of a single compare URL — no changelog body, no migration notes, no compatibility statement. Patch-level bumps in small CMS extensions routinely carry dependency and behavioural changes; we cannot currently state what changed.
• We need vendor accountability: no commercial support path, no verified CI/test-coverage signal, no documented security disclosure process, unverified release cadence and bus factor.
• We need a declared compatibility matrix. Nothing supplied states supported PHP/Symfony/Ibexa versions, so we cannot assert it runs on any environment we operate.
• Our licensing posture cannot absorb copyleft, or we would be forced to fork to get support — at which point we own maintenance outright.

Gating question before anything else: is there an Ibexa estate in scope? If yes, this becomes a routine, plausibly acceptable patch upgrade pending diff review. If no, the evaluation closes here.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a content-browsing extension for the eZ Platform/Ibexa CMS. It delivers a familiar, low-risk editor productivity feature — tree navigation, search/filter, previews, configurable views — and its blast radius is small: it is an admin UI component, not a security or data-integrity surface. However, two things block adoption today. First, stack fit: it targets Ibexa, not our Laravel estate, so unless we run Ibexa it delivers no direct value and any bridge would be a multi-quarter build. Second, release opacity: the current version's notes contain only a link, with no statement of supported versions, no changelog, and no commercial support or security disclosure process. Recommendation: do not adopt on current material. Escalate the stack-fit question first; if Ibexa is genuinely in scope, re-scope and re-assess, at which point this is likely a routine upgrade. The licence (GPL-2.0) also needs legal confirmation if anything we ship distributes it.

For engineering (the ask):

• Step 0 — answer the stack question. Laravel or Ibexa. Everything downstream differs. Do not spend further cycles until this is settled.
• If Ibexa: retrieve and classify the 1.4.1...v1.4.2 diff (bugfix / dependency / behavioural), pull the composer require block and supported-versions declarations, confirm our runtime satisfies each, then run a ≤5-day timeboxed spike in a disposable environment. Upgrade on a branch pinned to v1.4.2, gated on diff review and green tests — never a direct-to-main bump, never auto-merged.
• If Laravel: do not integrate. Options in ascending cost are (a) decline, (b) treat as a UX/architecture reference and build natively, (c) bridge only if we already run Ibexa alongside Laravel and expose the browser over an API — scope that as a product with its own owner, test suite, and framework-compatibility matrix, because the shim becomes a permanent standing tax between two release trains.
• Regardless of path: pin exact versions, budget roughly one engineer-day per release for review-and-verify (disproportionate for a UI component but unavoidable given the changelog quality), document a fork-and-vendor fallback in advance, and confirm licence terms before that fallback is needed.
• Ramp-up reality: 2–3 weeks before productive contribution for a Laravel-only team (Symfony bundle registration/DI, Ibexa content model, Twig, Composer constraints). Factor that into any timeline that assumes this ships quickly.