Layouts Ezplatform Laravel Package

Product Decisions This Supports

• Build vs. buy for page composition. The core question this package answers is whether to buy a layout engine instead of building one. If the stack is eZ Platform / Ibexa (Symfony-based), netgen/layouts-ezplatform is the adapter that turns "license Netgen Layouts" into a shippable capability. Building a bespoke block-based page composer — block registry, layout resolution rules, editor UI, preview, cache invalidation — is typically a multi-month effort; this reduces the decision to "license + integrate + train editors."
• Roadmap: editorial autonomy without deploys. A recurring roadmap line is "marketing ships campaign and landing pages without filing an engineering ticket." This package supports that goal concretely: editors compose pages from reusable blocks and rule-driven layouts inside the CMS admin, with blocks reading live eZ content items, fields, and locations rather than hardcoded templates.
• Feature scoping and time-boxed spikes. Because it is a thin bridge (integration glue, not a feature surface), it is a low-commitment experiment. Stand it up behind one siteaccess or one content type, measure editor adoption and time-to-publish, then decide whether layout management becomes a platform capability or stays a one-off.
• Multi-site and content-reuse strategy. The engine resolves layouts by rules (per siteaccess, content type, section, location) rather than per-page templates. That directly informs decisions like "can three brand microsites run off one content repository and one editorial team?" — the layout engine gives a cheap, testable yes/no.
• Platform investment validation. The decision-relevant output is not code: it is evidence about whether rule-based composition matches editorial mental models. That evidence feeds roadmap, headcount, and vendor-contract decisions.
• It does not justify a stack choice. With 14 stars, zero dependents, and a GPL-2.0 core, this can never be the reason to adopt eZ/Ibexa or to stay on it. Critically, this is not a Laravel package — it is a Symfony bundle. For a Laravel product it supports exactly one decision: "stop evaluating this and look at a headless or standalone alternative." It only follows a platform decision already made.

When to Consider This Package

Consider it only when all of the following hold:

• The platform is already eZ Platform / Ibexa and the target version is supported. This is glue; outside that CMS there is zero partial value. Verify the exact Ibexa major (3.3 LTS / 4.x) against the bridge's supported matrix before anything else — the eZ→Ibexa rename means "supported" is narrower than the README implies.
• There is a funded, concrete need for rule-based or block-based composition — cross-content-type, multi-site, editor-authored — not a hypothetical one.
• Legal has resolved GPL-2.0. This is the gating item. Copyleft obligations are material for closed-source or distributed products; Netgen's model generally pairs the OSS core with a commercial license. Price the commercial path before adoption, not after.
• A commercial support conversation with Netgen is acceptable. Confirm whether this adapter is in scope, plus SLA and supported-version matrix. The bus factor here is the vendor relationship, not the community.
• We accept we own maintenance. Zero dependents means no Stack Overflow safety net and no upstream urgency on our bugs. We need a named owner, a quarterly dependency review, and in-house Symfony fluency to fork if upstream goes quiet.
• We have confirmed the native Ibexa page builder genuinely does not meet the need — specifically around rule-based, cross-content-type, multi-site layouts. Otherwise we would be adding a second layout system to the estate for no differentiated reason.

Look elsewhere when:

• We are on Laravel, or any non-Ibexa PHP stack. The integration points are Ibexa-specific (content repository, view layer, siteaccess, DI container). Porting it means rewriting the adapter against Netgen Layouts core; that is a different project with a different budget.
• The target is legacy eZ Platform 2.x (EOL). The package is moot until a platform upgrade lands — treat that as a prerequisite program, not a task.
• We want a headless or SaaS page builder (Contentful, Storyblok, Builder.io). This presumes server-rendered Symfony and will not help a decoupled front end.
• Composition needs are simple. A handful of hardcoded templates plus a couple of content fields is cheaper than adopting and maintaining an engine, its schema, its editor training, and its cache invalidation design.
• We need vendor SLA and security-patching evidence that a 14-star repository cannot demonstrate and no contract exists to back.

How to Pitch It (Stakeholders)

To executives. This is not a new platform bet. It is the adapter that lets us use a page-layout engine on top of the CMS we already run, converting a recurring engineering cost — every campaign page is a ticket and a release — into an editor-driven workflow. Three caveats belong in the same breath. First, the license is GPL-2.0; legal must confirm our distribution model or we budget for a commercial license, and that answer needs to arrive before commitment. Second, this is a small, thinly adopted open-source component with no community; we should fund it as "we own the maintenance," ideally backed by a Netgen support contract. Third, it is Symfony/eZ-Ibexa only — if any part of the roadmap assumes Laravel, the answer is a different product. Recommendation: a time-boxed spike on one site section with a licensing answer in hand, judged on editorial adoption and time-to-publish rather than on technical novelty.

To engineering. Netgen Layouts is the layout/zone/block engine with rule-based resolution; this repository is only the bridge that wires it into the eZ/Ibexa content model, view layer, and admin UI. It is Symfony-native and additive — we can layer layout rules on existing templates without rewriting them. Plan for three-way version lockstep (bridge ↔ Layouts major ↔ Ibexa major, which pins Symfony and PHP); skew shows up as a DI container compile failure on deploy, not a clean Composer conflict, so add a CI job that resolves the matrix and boots the kernel. The integration surface is small — good for a spike, bad for anyone expecting upstream to grow features. Two hard requirements before rollout: a cache topology and invalidation design (full-page HTTP cache with correct Vary/tags, block-level caching for expensive handlers, ESI where zones vary by user context — and explicit invalidation-under-load testing, because publish-then-stale bugs are subtle and user-visible), and a pinning and vendoring strategy on the assumption we may need to fork. Budget 2–4 weeks for a competent Symfony developer to be productive, longer to be safe on caching; editors need training because rule-based layout is a different mental model from per-page authoring.