Layouts Ezplatform Relation List Query Laravel Package

Product Decisions This Supports

• The stack-fit decision, first and foremost. Despite being catalogued as a "Laravel/PHP package," it is a Symfony bundle for eZ Platform/Ibexa that plugs into Netgen Layouts. The primary product decision it supports is a negative one: do not add it to any Laravel service. If a roadmap item reads "dynamic related content," this package is not the delivery vehicle — scope it as a CMS-side capability consumed over REST/GraphQL, and record the decision so it isn't re-litigated next quarter.

• Where it does earn its place — editorial self-service. In the legacy eZ Platform estate, it lets editors compose "related content," "more from this section," and topic/tag hub modules by configuring a relation-list query instead of filing a ticket for hardcoded content IDs. That is a direct reduction in small, recurring development requests, and the value compounds with content volume.

• Build vs. buy for content aggregation. If the native relation list already covers the need on the installed version, adopt this thin query handler rather than commissioning a custom module. If you are on or heading to Ibexa DXP 4.x, native query types largely supersede it — buying here manufactures migration debt for no durable gain.

• Roadmap and migration framing. Classify it as tactical capability on a legacy boundary, carried by the migration rather than invested in. It should never sit on the critical path of a platform upgrade, and it should not be presented as a strategic dependency.

• Use-case fit. Hub and landing pages, topic and tag aggregation, related-content modules across hundreds to thousands of items where manual curation stops scaling.

• Release hygiene as a standing decision input. v1.4.2 is a patch bump whose changelog is an auto-generated compare link with no described changes, fixes, or deprecations. That supports a process decision — patch releases on a content-rendering dependency require a diff review and an owner, not a rubber stamp — rather than any product or feature decision.

When to Consider This Package

Consider it when:

• You are running eZ Platform 2.x/3.x with Netgen Layouts installed and a genuinely large, growing content set with many relation-list attributes. Confirm the stack before scoping; Laravel anywhere in the path is a stop sign, not a caveat.
• Editors are already asking for configurable dynamic relation lists and manual curation has become a measurable bottleneck.
• You want a small, low-integration-surface add-on — Composer requirement plus bundle registration — and you are willing to pin the version and own the upgrade review yourself.
• A tactical win on the current platform is worth more than architectural purity, and the CMS is not being replaced within the planning horizon.

Look elsewhere when:

• The stack is Laravel or any non-eZ PHP framework. Wrong fit entirely; the integration cost (standing up a Symfony/eZ kernel beside Laravel for one query handler) dwarfs the benefit. Consume the data over the CMS API instead.
• You are on Ibexa DXP 4.x or migrating to it, where native query types cover most of this. Adding a single-maintainer fork to a platform you are exiting raises exit cost for no durable return.
• You need search-backed relevance, ranking, personalization, or A/B-tested recommendations. This is query configuration, not a relevance engine.
• You require vendor SLA, LTS guarantees, a security response policy, or predictable maintainer turnaround. Community-only support with a likely bus factor of one is a real availability consideration for anything in the content-rendering path.
• Your compliance process depends on reviewable releases. An empty changelog on a patch bump is a weak signal and should trigger a manual diff review every time.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a low-cost, low-risk capability that lets editors build dynamic content listings — related articles, topic hubs, "more like this" — without a ticket per page, shortening editorial cycle time and cutting small development requests. The caveat is strategic rather than technical: it is a legacy-platform add-on, not a Laravel component, so fund it as a tactical win inside the existing CMS and keep it off the critical path of the platform migration. No new infrastructure, no licensing spend, minimal security surface — but it comes with community-only support and a single-maintainer risk, which we mitigate by pinning the version and owning the upgrade review.

To engineering (summary): Treat this as an eZ Platform/Ibexa bundle, not a Laravel package — no service provider, no package discovery, no contract with Laravel's container or Eloquent. Integration is conventional where a matching eZ/Ibexa + Netgen Layouts install exists: require via Composer, register the bundle, configure the relation-list query type, expose the field and limit options to editors. Before adopting, confirm PHP/Symfony/eZ/Netgen version constraints and run composer audit plus a transitive license inventory in a scratch branch. For v1.4.2 specifically, the release notes contain only a compare link — review the 1.4.1→v1.4.2 commit diff and confirm whether it touches query construction, result ordering, pagination, or visibility filtering before upgrading; then diff rendered layout output in staging and roll out behind a flag on a low-traffic layout. Assume a 1–2 week ramp for a competent mid-level developer, doubling for confidence in modifying query behavior; Laravel-only engineers do not transfer. Name an owner for quarterly dependency review and track the upstream project this fork derives from.