Layouts Ibexa Relation List Query Laravel Package

Product Decisions This Supports

• Editorial curation without developer tickets. The bundle registers a Netgen Layouts query type that pulls block items from an Ibexa relation list field on any content item. That means an editor can curate a block (“Related articles”, “Editor’s picks”, “You may also like”, product cross-sell lists) simply by maintaining a relation field in the CMS, instead of requesting a new query, tag, or hard-coded template each time.
• Build vs. buy / adopt. The functional surface is small (one query type plus bundle wiring). You could build this in-house in a day or two, but there is nothing to buy here either — it is GPL-2.0 and freely available. The real decision is adopt, fork, or reimplement, and it should be framed as a maintenance-cost decision rather than a feature-gap decision.
• Complements dynamic query types. Netgen Layouts excels at rule-driven, dynamic blocks (search/filter-based). This package covers the opposite editorial need — hand-picked, editorially ordered lists — and lets you ship a mixed layout strategy: dynamic blocks for evergreen/automated regions, relation-list blocks for curated/merchandised regions.
• Roadmap enabler for content merchandising. Once block content can be sourced from CMS relationships, you can iterate on curation workflows (who owns which relation field, editorial sign-off, campaign landing pages) without further engineering work.
• Migration/decommissioning support. If you are consolidating legacy hard-coded “related content” templates into Netgen Layouts, this is a low-effort way to preserve existing editorial behaviour during migration and avoid a big-bang rewrite.
• Feature-flag candidate, not a platform bet. Given 0 stars, 0 dependents, and a narrow scope, treat it as a small, reversible dependency to trial on one or two block types rather than a foundational component of the content platform.

When to Consider This Package

Consider it when:

• You are already running both Netgen Layouts and Ibexa Platform (v3/v4-era) and your editors or integrators already use relation list fields to express content relationships.
• You want editorial control over block contents without building a custom query type or bespoke Symfony bundle.
• Your curated lists map cleanly to “items referenced by a single content item’s relation field” — e.g. an article with a hand-picked related-articles list, a brand page with a manual product selection, a campaign landing page with editorially ordered teasers.
• You are comfortable taking a GPL-2.0 dependency and can accept vendor-aligned, low-community-traffic code (Netgen publishes it alongside their own product line, which mitigates — but does not eliminate — abandonment risk).
• You want to validate the approach cheaply before investing in a custom or richer implementation.

Look elsewhere when:

• You are not on Ibexa, or not on Netgen Layouts — there is no partial-value use case here.
• You need aggregation across many content items, faceting, filtering by attributes, sorting rules, or personalisation. That is the job of a search/query-based query type (e.g. an Ibexa search query type), not this package.
• You need multi-source or multi-field merging (relations + tags + manual overrides). This bundle does one thing; combining sources will require custom work regardless.
• You require commercial support, SLAs, or security patching guarantees. Zero dependents and zero stars mean no community safety net; plan to vendor/fork and own it.
• Licensing is a constraint: GPL-2.0 is fine for internal use, but distribution of derivative work carries copyleft obligations your legal team should sign off on if you ship a product built on it.
• Version drift is a concern: confirm the bundle supports your exact Ibexa and Netgen Layouts versions before committing; small packages like this often track a narrow compatibility window.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source connector that lets our editors build curated content blocks — “related articles”, “editor’s picks”, merchandised landing pages — directly from relationships they already maintain in the CMS, without raising engineering tickets. It costs nothing to license, requires no procurement, and is scoped narrowly enough to trial on a couple of block types and back out cheaply if it does not fit. The trade-off is reduced community traction and a copyleft licence, so we should treat it as an internal, reversible dependency and plan to own a fork if the upstream project goes quiet.

For engineering: It is a thin Symfony bundle that registers one Netgen Layouts query type, resolving block items from an Ibexa relation list field. Integration effort is configuration plus a compatibility check against our Ibexa and Netgen Layouts versions; the code surface is small enough to audit and fork in under a day. Adopt it as a dependency behind normal version pinning, keep our own tests around the block rendering path, and be prepared to vendor it. It does not replace our search-driven query types — it fills the editorial-curation gap beside them.

For editorial/product: You get a direct, no-code lever over what appears in curated blocks: maintain a relation field, and the block updates. This shortens the loop between an editorial decision and the live page, and removes the “file a ticket to change the homepage list” bottleneck for the block types we wire up.