Layouts Core Laravel Package

Technical Evaluation

Architecture fit

• netgen/layouts-core is a domain library, not a product: it provides the Layout / Zone / Block / BlockDefinition model, a rule-based targeting/resolution engine, and a Twig rendering pipeline. The authoring UI and REST surface live in sibling packages (layouts-admin, Symfony bundle), so adopting core alone gets you a rendering engine without an editor.
• The model is portable; the runtime wiring is Symfony-centric (service definitions, event dispatcher, config tree, Twig environment). It assumes a container-driven, bundle-oriented host.
• For a Laravel codebase this is an anti-corruption-layer integration, not a drop-in. The model is reusable; the bootstrapping is not.

Integration feasibility

• Feasible but non-trivial. Four adapter seams must be stitched: service container (Symfony DI ↔ Laravel container), configuration loading, event dispatching, and persistence (Doctrine DBAL/ORM vs. Eloquent).
• Twig is effectively mandatory for rendering; running Twig alongside Blade is workable but creates two templating idioms, two extension stories, and two cache stories.
• No official Laravel bridge exists. A TPM should fund a 1–2 sprint spike against one real production-shaped page type before any roadmap commitment, and treat "we can wire the container, persist a layout, and render it end-to-end" as the exit criterion.

Technical risk

• Vendor concentration: maintenance is concentrated in a single vendor (Netgen); bus factor and roadmap sit outside the team.
• Adoption signal: 36 stars and 0 listed dependents is thin for a platform-level dependency — sparse examples, sparse Stack Overflow answers, and every bug you hit is a bug you fix.
• Dependency conflict surface: Laravel already ships several symfony/* components (console, http-foundation, finder, process, error-handler). Constraint collisions on Symfony majors are a realistic blocker and should be audited before scoping.
• Schema ownership: the persistence tables become yours to migrate, back up, and evolve; upgrade migrations may not be Laravel-migration-native.
• Scope creep: the useful capability (page composition + targeting) pulls in admin UI, asset/design handling, and caching concerns, each of which is a project of its own.

Key questions

• What is the supported PHP / Symfony / Twig version matrix, and how frequently is it bumped?
• Is persistence pluggable enough to back it with Eloquent, or is Doctrine DBAL a hard requirement?
• Is the Twig renderer swappable behind RendererInterface, or is the Twig environment a hard dependency?
• Which sibling packages (admin UI, Symfony bundle) are required for a usable product, and what are their license and maintenance status?
• Is commercial support or an SLA available from Netgen? What does an upgrade between minor versions typically break?
• How does the targeting engine resolve layouts — per request, cached, or precomputed — and what is the cache-invalidation contract on content publish?

Integration Approach

Stack fit

• Strong fit for Symfony or Ibexa/eZ Platform estates — that is the designed path, and it is where documentation, examples, and the bundle live.
• Weak-to-moderate fit for Laravel. The TPM should position it as a bounded domain library behind your own interfaces: expose LayoutResolver, BlockRenderer, and repository ports, and keep Netgen types out of controllers, models, and Blade views so the decision remains reversible.

Migration path

1. Isolated Composer spike in a scratch Laravel app: install core, hand-wire the container, render one layout containing two block types.
2. If the spike passes, define the ACL boundary (your interfaces, Netgen implementations) before writing product code.
3. If it fails on DI, persistence, or Twig, fall back to Blade/Livewire block composition or a headless CMS — switching cost is far lower before the ACL is populated.

Compatibility

• Run composer why-not audits against the target Laravel version before scoping; pin exact Symfony component versions.
• Lock the PHP minor version in CI and verify Twig alignment with any existing Twig usage.
• Confirm the database schema is created via migrations you control, not vendor-side auto-DDL in production.

Sequencing

1. Dependency and conflict audit (throwaway branch, no product code).
2. Container/config/Twig adapter — the make-or-break layer.
3. Persistence adapter plus Laravel migrations for the layout schema.
4. Block definition registry mapped to your product's content blocks.
5. Targeting rules (locale, section, device, campaign) and layout resolution.
6. Authoring path — admin UI package or a thin internal editor.
7. Caching, preview, and cache invalidation on publish.
8. Rollout behind a feature flag on one low-traffic section.

Operational Impact

Maintenance

• You own the Laravel adapter permanently; every Symfony/Twig bump becomes your upgrade project. Budget recurring maintenance, not just build cost.
• Track upstream release cadence for at least a quarter before committing; sparse releases mean long-lived forks whenever you need a patch.

Support

• MIT gives no support obligation. Verify whether Netgen offers paid support and whether the sibling admin package carries the same license.
• Plan for self-sufficiency: no Laravel-ecosystem answers exist, so internal documentation of the adapter is mandatory, not optional.

Scaling

• Rendering is CPU-bound on Twig and block resolution; cache resolved layouts keyed by targeting context (locale, path, segment) rather than resolving per request.
• Block collections and queries are the N+1 hotspot — enforce eager-loading at the adapter layer and measure query counts in CI.
• Persistence is relational and small; scaling pressure comes from render throughput and cache invalidation, not storage.

Failure modes

• Layout resolution returns nothing or the wrong layout → silent blank regions. Require an explicit fallback template and log unresolved requests with the targeting context.
• A block render exception takes down the whole page → wrap each block in an isolation boundary with per-block error capture.
• Missing or renamed Twig template after a deploy → fail loudly in staging with a template-existence check at boot.
• Stale cache after content publish → tie invalidation to the publish event, not a TTL.
• Container wiring failure at boot → smoke-test the service graph in CI, not just at runtime.

Ramp-up

• 1–2 weeks for a mid-level developer to internalize layouts, zones, placements, block definitions, targeting, and value types.
• Add roughly a week for teams that are Blade-native and new to Twig.
• Build and own the adapter layer with one engineer end-to-end; splitting it across people early produces inconsistent abstractions and a much harder upgrade path.