Layouts Ibexa Laravel Package

Getting Started

netgen/layouts-ibexa wires Netgen Layouts into Ibexa (formerly eZ Platform): Netgen Layouts gives you a visual "zones + blocks" page composition layer, and this package teaches it about Ibexa content, locations, content views and search.

Minimal setup:

composer require netgen/layouts-ibexa

1. Check versions before anything else. The repo has very low adoption (2 stars), so treat the composer.json constraints as the source of truth for which Ibexa (ibexa/core) and PHP versions are supported. Pin Ibexa to the minor the package was released against and don't casually upgrade.
2. Register the bundles. You'll need Netgen Layouts core + standard blocks + this integration:

   // config/bundles.php
   Netgen\Layouts\Bundle\NetgenLayoutsBundle::class => ['all' => true],
   Netgen\Layouts\StandardBundle\NetgenLayoutsStandardBundle::class => ['all' => true],
   // plus the Ibexa integration bundle shipped by this package
   

3. Configure it under the netgen_layouts root key — point the DB connection at Ibexa's Doctrine connection so layouts live beside your CMS tables, and set up the design/theme section.
4. Create the schema. Netgen Layouts has its own tables; run the migration/schema step the package docs describe (it uses Doctrine, so it will coexist with Ibexa's schema — back up first on an existing DB).
5. Open the admin UI (typically under a route like /admin/netgen-layouts). Confirm the route exists with bin/console debug:router | grep -i layout. You will need to allow it through your firewall/security config.

First use case: create one layout ("Homepage") with a header / main / footer zone set, drop in a Text block, a Menu block and a Content List block that pulls Ibexa articles via a search query, then create a rule targeting the homepage content view (or the / location) so the layout is chosen for that request. Load the page — if nothing renders, that is almost always a rule/target mismatch, not a block problem.

Implementation Patterns

Composition through rules, not controllers. The day-to-day model is: layout (zones + blocks) → rule (matches a request) → target (Ibexa content view, location, content type, section, siteaccess…). You spend most of your time in the rule/target config rather than in PHP. Rules have priorities; the first matching rule wins, so order specific rules above generic fallbacks.

Content List blocks are your main Ibexa integration point. They combine three extension concepts:

• a query type (e.g. an Ibexa search query, filtered by content type / subtree / section),
• an item view type (which template renders each result),
• pagination and offset settings on the block itself.

If a list is empty, check these three before touching templates.

Template overrides via themes. Netgen Layouts resolves block/zone/item templates through its design → themes config. Override by dropping a template into your own theme namespace rather than editing vendor files; configure the theme list in netgen_layouts.design.themes.

Embedding in Ibexa pages. The integration lets an Ibexa content view render a layout. Practically, you either (a) let a rule fully own the content view, or (b) render a specific block/layout inside an existing Twig template using the nglayouts_* Twig helpers. Use (b) when only part of a page should be CMS-managed.

Reusable configuration, not copy-paste blocks. Keep block types small and composable (Text, Title, Content, Content List, Menu, Template). For repeated chrome, create a layout fragment once and reference it rather than rebuilding zones across every layout.

Custom block types are the main extension point: implement a block definition handler and register it under netgen_layouts.block_definitions. Custom query types, item view types and rule target types follow the same service-tagging pattern — this is how you expose domain-specific Ibexa queries or bespoke targets to editors without giving them raw templates.

Multi-siteaccess. Treat rules and theme config as per-siteaccess where the integration allows it; a layout built for one site's content tree will produce empty zones on another.

Gotchas and Tips

• License is GPL-2.0. This is a real constraint for closed-source commercial products. Confirm with legal before shipping; Netgen Layouts' licensing is frequently the deciding factor on whether a project adopts it.
• Low adoption = version drift. With ~2 stars this package trails Ibexa releases. Pin exact versions, read the open issues before upgrading Ibexa, and be prepared to patch a Composer constraint or two.
• Caching bites. Netgen Layouts caches layout/rule resolution and blocks aggressively. After changing rules, block config or templates, clear the app cache and the Layouts cache pool. If changes "don't apply" in dev, this is the usual culprit.
• Rule priority is silent. Two overlapping rules won't error — the higher-priority one just wins. Use the rule list ordering as your debugging tool; keep a "default/fallback" rule at the bottom.
• Ibexa HTTP/view cache won't know layouts changed. Editing a layout does not invalidate Ibexa's content view cache. Wire up your own invalidation or you'll serve stale pages long after the editor hit save.
• Admin UI needs security wiring. Registering the bundle doesn't grant access; the admin routes need a firewall rule and the right role, otherwise you get 403s or a redirect loop.
• Schema on an existing database. The Layouts tables are additive but live in the same Doctrine connection as Ibexa. Always run the schema step on a copy first and keep migrations in version control.
• Debugging order: debug:router (route exists?) → firewall (403?) → rule matched? (nglayouts_*/profiler info) → block resolved? → template found? Work down that list; it saves a lot of time versus editing Twig blindly.
• Extension points to learn early: custom block definitions, query types, item view types, rule target types, and event subscribers under Netgen\Layouts\Event\*. These are stable and are what make the package worth adopting over hand-rolled page builders.
• Watch template resolution. Theme/namespace mistakes produce blank zones with no exception — always debug:twig when a block renders nothing but data is clearly there.