Layouts Ezplatform Site Api Laravel Package

Product Decisions This Supports

• Editorial self-service on Ibexa/eZ Platform. This package wires Netgen Layouts' layout-resolution engine into the Site API content layer, so marketing and content teams can compose landing pages, campaign pages, and reusable blocks from existing content items instead of filing a ticket for every template change. The core PM decision it unlocks is "do we build a page-composition tool or buy/assemble one?"
• Build vs. buy for a page builder. If you are already on Ibexa DXP or eZ Platform, the alternatives are (a) Ibexa's own Page Builder in the Experience edition, (b) a custom Symfony/Twig templating layer, or (c) Netgen Layouts plus this glue. This package is the cheapest path to (c); the decision hinges on edition/licensing cost of (a) versus long-term ownership of a bespoke layer.
• Architecture roadmap: Site API as the rendering contract. Adopting it commits you to Netgen's Site API as the read model for front-end rendering (content views, Twig functions, field accessors). That is a meaningful architectural bet — it simplifies templates but adds a layer you must keep in sync with Ibexa upgrades.
• Reusable block and zone strategy. Layouts' value is shared, mappable blocks (promos, hero units, CTA strips) resolved per content type. Product decisions about content modelling — how granular content types should be, which regions are editor-controlled vs. locked — flow directly from how you configure layout mappings here.
• Multisite and per-section variation. If the roadmap includes country/section variants of the same template, the layout-mapping model is the lever: one template, many configurations, no code forks.
• Licensing and distribution strategy. GPL-2.0 is a real product constraint. If any part of your delivery is distributed or you run a commercial multi-tenant SaaS with copyleft concerns, this must be settled before adoption, not after.

When to Consider This Package

Consider it when all of the following hold:

• You run eZ Platform / Ibexa and already use (or plan to use) Netgen Layouts — this package is glue, not a standalone product. It has no value without both sides.
• You use or intend to use Netgen's Site API bundle for front-end rendering rather than querying the repository directly.
• Your stack is Symfony + PHP + Twig + Composer, and you have engineers who can read a small integration bundle and debug its service wiring.
• You want editors composing pages from existing content rather than authoring new structured content per page.
• You accept GPL-2.0 obligations for this component and have cleared that with legal.

Look elsewhere when:

• You are not on Ibexa. There is no portability story here; the integration is specific to eZ Platform's Site API content views.
• You are on Ibexa DXP Experience/Commerce with Page Builder available. The native tool is supported, documented, and covered by your subscription — a materially lower product risk than a two-person-maintained integration.
• You need a decoupled/headless authoring layer. Site API helps, but layout resolution is a server-side rendering concern; a JSON:API/GraphQL-first front end will fight this design.
• Ecosystem adoption matters to you. Eleven stars and zero dependents is the signal: no third-party track record, no community troubleshooting, no vendor SLA. Treat it as code you will own.
• You cannot absorb maintenance risk. Your upgrade path is now Ibexa version × Site API version × Layouts version × this package. Each Ibexa major bump is a three-way compatibility check with no upstream guarantee.

How to Pitch It (Stakeholders)

To executives: This is a small, focused integration that lets our editors build and rearrange marketing pages themselves instead of waiting on engineering for each one. It reuses the layout tooling and content API we would otherwise have to build, so it trades a modest licensing/ownership constraint for a shorter path to self-service publishing. The honest caveats are support and provenance: it is a niche open-source component with almost no external adoption, licensed GPL-2.0, and maintained alongside — not by — the platforms it connects. Recommend a time-boxed spike, a written exit plan, and a legal check before it becomes load-bearing.

To engineering: Treat it as a thin adapter, not a framework. It bridges Netgen Layouts' layout resolution to Site API content views so that layout mappings can be driven by content rather than hard-coded templates. Review the service definitions and the content-view/layout resolution hook first — that is where the coupling lives and where Ibexa upgrades will break. Budget for pinning versions across Ibexa, Site API, and Layouts, and for owning the bundle if upstream goes quiet. Keep layout configuration in project config, not in the vendor tree, so a fork or replacement stays cheap.

To content/editorial leads: Editors get reusable blocks and page composition on top of content they already have. The constraint to design around is that what editors can control is bounded by the layout mappings engineering defines — agree the zone and block inventory up front, or you will recreate the ticket queue you were trying to remove.