Layouts Ibexa Relation List Query Laravel Package

Technical Evaluation

Architecture fit. The package is a thin, additive Symfony bundle that plugs into Netgen Layouts' query-type extension point. Both Ibexa Platform (DXP, formerly eZ Platform) and Netgen Layouts run on Symfony, and Layouts deliberately exposes a plugin surface for resolving a block's item collection. This bundle occupies exactly that slot: given a content item with a relation-list field (the ezobjectrelationlist-family field type), it returns the referenced content as block items. It introduces no schema, no persistence, no content model, and no admin UI of its own — it is pure glue. Fit is therefore excellent for one architecture, and zero for any other: Ibexa DXP + Netgen Layouts + editors who already curate lists through relation-list fields. Teams using taxonomies, search-backed collections, or a custom query type gain nothing.

Integration feasibility. High and low-effort in the happy path: composer require, register the bundle in bundles.php, clear cache, then select the query type when configuring a block in the Layouts admin. There is no data migration and no backfill. The genuine friction is not installation but version alignment across three independently versioned components.

Technical risk. Concentrated and mostly non-technical. Zero stars and zero dependents means no external validation, no observable issue traffic, and effectively single-vendor maintenance. Version coupling is the sharp edge: Ibexa majors, Netgen Layouts majors, and Symfony majors all move, and a bridge package must track all three. GPL-2.0 is a copyleft license — fine for internal or GPL-compatible deployments, but a legal review trigger if the product is distributed commercially or combined with incompatible licensed code. The metadata gives no signal of CI, test coverage, or release cadence; a TPM should plan on the assumption that you may need to fork.

Key questions.

• Which Ibexa and Netgen Layouts version ranges does the current composer.json actually permit, and is there a maintained branch per major?
• Does the query resolve relations from the current content/location context (dynamic blocks) or only from a fixed content ID? Context support determines whether one block definition can serve a whole section.
• Does it filter by content status, visibility, and subtree permissions, or does it return raw relation IDs that may include hidden, trashed, or unpublished targets?
• Does it respect relation-list ordering, and does it support offset/limit for pagination?
• Which field-type identifiers are handled — legacy ezobjectrelationlist, the newer prefixed identifiers, or both?
• Are results cached by Layouts, and is there any invalidation hook when a relation field is edited?

Integration Approach

Stack fit. Target stack is PHP 8.x on Symfony (5.4/6.x depending on Ibexa generation), Ibexa DXP 4.x, and Netgen Layouts 1.x/2.x. Confirm the bundle's constraints against your exact Ibexa–Layouts–Symfony matrix before committing; this is the single highest-probability blocker.

Migration path. Only relevant if blocks are currently populated by hardcoded IDs or a bespoke query type. The move is a configuration change per block, not a data migration: define relation-list fields on the relevant content types, populate them editorially, then point the block at the new query type. Existing rendered output is preserved, so migration can be incremental block-by-block.

Compatibility. Verify three things in a spike: (1) field-type identifier handling across your Ibexa version, (2) whether single-value relation fields are supported or only lists, and (3) the query parameter schema exposed to the Layouts admin, so editors see a form they can actually use. Also confirm GPL-2.0 is acceptable to legal for your distribution model before writing code.

Sequencing.

1. Stand up Ibexa baseline + Netgen Layouts and prove a static block renders.
2. Model relation-list fields on the target content types and populate representative content.
3. Require the bundle, register it, clear cache, confirm the query type appears in the Layouts UI.
4. Configure one block against real content; validate item order, permissions, and unpublished-content behavior.
5. Test cache invalidation explicitly: edit a relation field, confirm the block updates without a manual cache clear.
6. Roll out editor guidance, then widen to remaining blocks.

Operational Impact

Maintenance. Small surface area, but no maintenance guarantee. Pin the version, track upstream releases, and budget a fork-and-patch contingency — the code volume is low enough that a competent Symfony developer can own it internally if upstream goes quiet. Re-validate on every Ibexa or Layouts major upgrade; that is where the recurring cost sits.

Support. Assume no community. Netgen's commercial support is the realistic escalation path; otherwise the owning team is the support tier. Assign a named internal owner before rollout, not after the first incident.

Scaling. Relation lists are editorially bounded, so item counts stay small and raw query cost is modest. The real risks are N+1 loading of related content when a block renders many items and cache behavior at the page level. Because Layouts caches rendered block output, throughput is largely a caching question rather than a query-performance one — but that makes invalidation correctness the scaling concern, not speed.

Failure modes.

• Related content hidden, unpublished, or trashed while still referenced — items either leak to the front end or silently vanish, depending on filtering.
• Stale block output after an editor edits a relation field, if invalidation isn't wired to the field.
• Silent empty blocks after an upgrade changes field-type identifiers or query parameter names.
• Permission gaps: related content from a restricted subtree rendering in a public block.
• Version drift breaking the bundle on an Ibexa or Layouts upgrade with no upstream fix available.

Ramp-up. For a Symfony developer, half a day to install, wire, and configure the first block; one to two days including the compatibility spike and cache-invalidation testing. The longer ramp-up is editorial and organizational: content teams must understand that a block's contents are now governed by a relation field on a content item, so changing that field changes the page. That mental model shift — and the review process around it — is where adoption succeeds or stalls.