Layouts Ibexa Site Api Laravel Package

Product Decisions This Supports

• Build vs. buy for page composition. Informs whether to hand-roll a landing-page/block system or adopt Netgen Layouts as the layout/block layer for an Ibexa (formerly eZ Platform) site. This package is the glue that lets layouts render content fetched through Ibexa Site API rather than the legacy repository API.
• Editorial tooling roadmap. Supports decisions on whether marketing/content teams get drag-and-drop layout management, reusable blocks, and per-content-type layout rules — capability typically requested by content-heavy portals, intranets, and campaign sites.
• Standardization on the Ibexa Site API. If product direction is "modern Ibexa DXP stack," this package signals that the Site API path is supported end-to-end (content retrieval → layout resolution → block rendering) without custom bridging work.
• Migration sequencing. Relevant when planning a move from legacy eZ/Ibexa content API to Site API: it defines whether layout templates need rewriting or can be served unchanged.
• Vendor/tech-stack diligence. Its near-zero adoption signals (0 stars, 0 dependents) mean it should be treated as a glue component under evaluation, not a de facto standard — a data point for dependency-risk and support-model decisions.

When to Consider This Package

Consider it when all of the following hold:

• You run (or are committed to) Ibexa DXP / eZ Platform as the CMS.
• Netgen Layouts is already adopted or shortlisted as the layout/block engine.
• Templates or block definitions query content via Ibexa Site API (not the legacy repository API).
• You want to avoid writing and maintaining the layout↔content-API adapter yourself.
• GPL-2.0 is acceptable for your deployment model (self-hosted, no proprietary redistribution of derived code) — otherwise require legal review, as copyleft can constrain closed-source distribution.

Look elsewhere when:

• You are not on Ibexa, or you're using Ibexa's native Page Builder / Flex rather than Netgen Layouts — this package provides no value.
• You need a commercially supported, SLAs-backed component: with 0 stars, 0 dependents, and a 0.03 composite score, community support and bug-fix latency are unproven. Plan for in-house ownership of the integration.
• You need guaranteed compatibility matrices across Ibexa/Netgen major versions — pin versions and verify against your upgrade cadence before committing.
• A short pilot cannot be funded: the low adoption makes an internal spike the only responsible way to validate fit.

How to Pitch It (Stakeholders)

Executives (one paragraph): This is a small, free integration layer that connects two established Symfony/Ibexa building blocks — Netgen Layouts (page layout and block management) and Ibexa Site API (content delivery) — so our editors can compose pages without bespoke engineering. It is a cost-avoidance lever for editorial tooling, not a product in itself. Two caveats drive the recommendation: it is GPL-2.0 licensed (legal must clear it against our distribution model), and it has effectively zero public adoption, so we would own the code path. Proposal: a time-boxed technical spike on a sandbox Ibexa instance; adopt only if the spike passes and legal signs off.

Engineering (summary): A Composer dependency bridging Netgen Layouts and Ibexa Site API — the layout/block resolution layer queries Site API content instead of the legacy repository. Expect a thin surface area but no upstream community; we should pin versions, add integration tests around layout resolution and block rendering, and confirm the supported Ibexa/Site API version range before rollout. Treat it as vendored glue we maintain, and document the upgrade path for every Ibexa and Netgen Layouts bump.