Layouts Core Laravel Package

Product Decisions This Supports

• Build vs. buy for page composition. netgen/layouts-core is the domain engine for composing pages from layouts (zone definitions), blocks (reusable content units), and rules (which layout resolves for a given request). It answers "how much of a page builder do we have to invent?" — the modeling, resolution, and rendering pipeline already exists; what you still own is the editing UI, the block library, and the CMS integration.
• Roadmap: editorial autonomy vs. engineering throughput. The package's central value is moving page assembly out of deploy cycles and into editorial hands. That supports roadmap items like marketing landing pages, campaign microsites, multi-brand/multi-section templates, and per-content-type layout variation without bespoke controller and template work per page.
• Multi-site and multi-brand architecture. Rule-based layout resolution — layout A for section X on site Y, fall back to the default otherwise — is the hard part of any multi-tenant content platform. Committing to this decision space early saves a quarter of design debate later.
• CMS-agnostic positioning. Because the core is decoupled from any particular content source, it keeps CMS selection open: you can commit to a layout strategy before committing to a content backend. That is a de-risking decision, not just a technical one.
• Use cases it fits: editorial page composition over an existing CMS, template inheritance and fallback across large content catalogs, A/B or campaign variants of a shared page shell, and consolidating several bespoke "page type" implementations into one model.
• What it does not decide for you: there is no admin UI, no design theme, and no drop-in Laravel integration in this package. Selecting it is a decision to build on a foundation, not to ship a feature.

When to Consider This Package

Consider it when:

• You already have (or have chosen) a content source and need a composition/resolution layer on top of it — not another CMS.
• Your page structures are genuinely complex: multiple zones, reusable blocks shared across pages, per-section or per-content-type layout rules — and bespoke controllers are starting to duplicate each other.
• Your team is comfortable in PHP with domain-model-style code (value objects, repositories, resolvers) and can absorb a framework-agnostic library rather than a Laravel-native one.
• You want MIT-licensed, self-hosted, no-vendor-lock-in infrastructure and are prepared to own upgrades.
• You can afford a spike: the honest evaluation is 1–2 weeks wiring it to one real page type before committing.

Look elsewhere when:

• You need a visual, drag-and-drop builder for non-technical editors out of the box — this core ships no UI. The broader Netgen Layouts suite (admin UI, standard design, Symfony bundle) is where that lives; adopting the core means adopting that family or building your own.
• Your stack is Laravel-first and you expect first-class idioms — service providers, Eloquent, Blade. Netgen's documented path is Symfony-centric; treat Laravel as an integration project, not a supported configuration, until a spike proves otherwise.
• Your frontend is JS/headless-first: component-driven builders will fit the rendering model better than a PHP server-side resolution engine.
• Community support is a hard requirement. 36 stars and effectively zero dependent packages is a real signal: few public examples, few Stack Overflow answers, and a bug you hit is a bug you fix. Single-vendor stewardship means the roadmap is not yours to influence.
• Your page needs are simple — a handful of static templates and a rich-text field. The abstraction will cost more than it saves.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed foundation for letting marketing and editorial teams assemble and change pages without engineering tickets. The business case is cycle time: campaign pages and section redesigns stop queueing behind the sprint backlog. The cost is integration labor, not licensing — we'd be buying a head start on the hard modeling work, not a finished product. The risk to name openly is maturity: it's a niche, single-vendor, small-community library, so we should treat it as code we adopt and maintain, not a vendor we can escalate to. Recommendation: fund a two-week spike against one real page type before any roadmap commitment.

To engineering: You get a clean, CMS-agnostic domain model — layouts, zones, blocks, and a rule-based resolver with fallback semantics — instead of a fourth homegrown page-type controller. It's framework-agnostic PHP with a Symfony-first integration story; expect to write the Laravel glue (container bindings, storage adapter, Twig bridge alongside Blade) and to bring your own admin UI from the sibling packages. It's testable and well-separated, and it won't dictate your content model. The trade-offs are documentation debt, a thin public knowledge base, and a permanent adapter we own — so budget for reading source, pinning versions, and documenting the integration surface. Success criterion for the spike: one production-shaped page type composed, resolved by rule, and rendered end-to-end, with the adapter boundary written down.