Layouts Core Laravel Package

Getting Started

The 1.4 line now ships as se7enxweb/layouts-core, a drop-in fork of netgen/layouts-core 1.4.13. It replaces the upstream package and widens the PHP constraint to ^7.4 || ^8.0, so Platform 2.5 (CJW Exponential Platform Nexus) installs on PHP 8.0 again.

1. Require the fork explicitly — do not mix it with netgen/layouts-core:

   composer require se7enxweb/layouts-core:^1.4
   

   Composer will report it as replacing netgen/layouts-core; any bridge/admin package that still lists netgen/layouts-core as a dependency is satisfied by the replacement.
2. Keep the existing Netgen bundles and namespaces — the PHP namespace is still Netgen\Layouts\*, only the Composer package name changed. Register the bundles in config/bundles.php exactly as before (Netgen\Layouts\CoreBundle, Netgen\Layouts\AdminBundle, plus the Ibexa/eZ bridge).
3. Import the bundle routing (@NetgenLayoutsAdminBundle/Resources/config/routing.yaml under your admin prefix) and let the bundles' migrations run (bin/console doctrine:migrations:migrate) — layouts, blocks, rules and collections live in the database, not in YAML.
4. Look first at config/packages/netgen_layouts.yaml (or se7enxweblayouts.yaml if your bridge exports that alias) for layouts, blocks, query_types and design settings, then at the admin UI.

First use case: create a layout with one or two zones, drop a text block into it, then add a layout resolver rule (target: content / section / path) so a page resolves to that layout. That loop — layout → block → rule → render — is the whole product.

Implementation Patterns

Custom blocks are the main extension point. Implement BlockDefinitionInterface and tag the service with netgen.layouts.block_definition (or register it in the bundle's blocks config when using the built-in definition class). Pair it with a handler (BlockHandlerInterface) for view-time logic and a Twig template under the configured design path, e.g. @NetgenLayouts/blocks/my_block.html.twig.

Blocks that show content should return ItemView objects from the handler rather than doing queries in Twig. Use ItemViewProvider/QueryType for the "which items" half and ItemViewType for the "how are they rendered" half, then let editors pick both in the admin UI.

Custom query types: extend QueryType (or the Doctrine-based one), implement QueryTypeInterface, tag netgen.layouts.query_type, and surface it in config so it appears in the block's item browser. Same shape applies to ItemViewType for manual collections.

Layout resolver rules should be treated as content: use target types + conditions rather than hardcoding template logic. Add custom targets/conditions only when the built-in set (content type, section, path, siteaccess) genuinely can't express the rule.

Rendering: use {{ nglayouts_render_result(result) }} from your controllers (via the LayoutResolver) or {{ nglayouts_render_rule(...) }} in Twig for rule-driven fragments. For embedded blocks inside content, use the provided Twig functions and pass the resolved layout, not a hand-built array.

Deployment: configuration is DB-resident, so promote layouts between environments with the bundle's serialisation commands (nglayouts:debug:* for inspection, the export/import commands for transfer) rather than by hand. Keep the exported YAML/PHP fixtures in the repo so a fresh environment is reproducible.

Gotchas and Tips

• Version detection is the headline fix. Bundles that read Composer\InstalledVersions::getVersion('netgen/layouts-core') get null because a replaced package carries no version — that's what broke the container build. If you write or maintain bundle code (or have a bridge that overrides it), read se7enxweb/layouts-core instead, and guard with InstalledVersions::isInstalled() plus a fallback so the code survives either package name.
• Don't require both packages. Requiring netgen/layouts-core alongside the fork creates a replacement conflict; if a third-party bridge pins upstream, override its constraint rather than installing both.
• Cache is king. Block definitions, query types and item view types are compiled into the container. After adding one: bin/console cache:clear, and re-check the admin UI block picker — a missing block is almost always a missing service tag or a stale cache.
• Templates resolve by convention. A block that "renders nothing" usually has a design/template path mismatch; verify the design config and the layouts/ directory name in your theme bundle before debugging PHP.
• PHP 8.0 vs 8.1: the widened constraint gets you onto 8.0, but 1.4-era code predates 8.1 readonly/enum ergonomics — expect deprecation notices under 8.1 and pin CI to the same minor you deploy.
• Namespaces unchanged: don't rewrite use Netgen\Layouts\... imports during the switch; only composer.json and any hardcoded package-name strings (version checks, health endpoints, container build scripts) need attention.
• Extension points worth knowing early: ParameterProvider / value converters for block parameters, LayoutType for restricting which zones a layout offers, and block/query/item-view Type compiler passes for bulk-registering types instead of one tag per service.