- How do I install netgen/layouts-core in a Laravel app?
- Install it with Composer using composer require netgen/layouts-core. The package is a domain library, so installation alone does not register routes, migrations, or an admin UI in Laravel. Expect to hand-wire services, persistence, and rendering before you can display a layout.
- Is netgen/layouts-core compatible with Laravel out of the box?
- No. The core model is portable, but the runtime wiring is Symfony-centric, relying on service definitions, an event dispatcher, a config tree, and Twig. There is no official Laravel bridge, so treating it as a drop-in package will fail. Plan an anti-corruption layer around its resolvers, renderers, and repositories.
- Can I store Netgen Layouts data with Eloquent instead of Doctrine?
- The project describes the core as storage-agnostic and ships Doctrine ORM support as the supported persistence path. Backing it with Eloquent requires implementing the repository ports yourself and owning the schema, migrations, and backups. Audit how much Doctrine DBAL is assumed before committing to an Eloquent adapter.
- How do I handle Symfony DI and configuration in a Laravel integration?
- You must bridge Symfony-style service definitions and config loading into Laravel's container and config repository. That means adapting event dispatching as well, since the core expects a Symfony event dispatcher. Keep these adapters behind your own interfaces so Netgen types do not leak into controllers or Blade views.
- Do I need Twig to render layouts with netgen/layouts-core?
- Rendering is built around a Twig pipeline, and Twig environment integration is effectively required in practice. Even if a renderer is technically swappable, running Twig alongside Blade creates two templating idioms, extension stories, and cache stories. Validate the renderer seam with a spike before assuming you can render entirely through Blade.
- Which PHP, Symfony, and Twig versions does netgen/layouts-core support?
- Check the composer.json constraints on Packagist and the GitHub repository for the current PHP, Symfony, and Twig matrix. Laravel already ships several symfony components, so major-version collisions are a realistic blocker. Run composer why-not against your target Laravel version and pin exact Symfony component versions before scoping.
- Do I need Netgen Layouts admin UI and Symfony bundle packages for a usable product?
- Yes, if you need an authoring experience. The core package provides the model, rule engine, and rendering pipeline, while the admin UI and REST surface live in sibling packages. Review their licenses, maintenance status, and required dependencies, because they expand the scope well beyond a rendering engine.
- How does the rule-based layout resolver target pages, and is it cached?
- The resolver uses rule-based matching to decide which layout applies to a given page, and resolvers are pluggable. Whether resolution happens per request, through a cache, or precomputed is a critical design question for your integration. Define the cache-invalidation contract on content publish before relying on it in production.
- How should I test a Netgen Layouts Core integration in Laravel?
- Start with an isolated Composer spike in a scratch Laravel app and render one layout containing two block types end to end. Treat successful container wiring, persistence of a layout, and rendering as the exit criterion before writing product code. Add integration tests around your adapter ports so upgrades and schema changes are caught early.
- Is netgen/layouts-core production-ready for Laravel, and what are the alternatives?
- Maintenance is concentrated in Netgen, adoption signals are thin, with no listed dependents and no official Laravel bridge, so budget for bugs you fix yourself. If the spike fails on DI, persistence, or Twig, fall back to Blade or Livewire block composition, a Laravel admin builder, or a headless CMS. Switching cost is far lower before you populate the anti-corruption layer.