Fieldtype Query Laravel Package

Product Decisions This Supports

• Content-driven listings without engineering tickets. The field type lets a content editor attach an executable Repository Query (latest news, related items, filtered collections) to a field. Product decisions such as "should the homepage rail be editorially curatable?" or "who owns the related-content block?" shift from a backend backlog item to a content-model decision.
• Build vs. buy on query plumbing. If the platform is Ibexa DXP, this ships as part of the product; buying/inheriting it is strictly cheaper than a bespoke "content list builder" bundle. A custom equivalent (stored query config + resolver + editor UI + GraphQL exposure + upgrade maintenance) is a multi-sprint build with permanent upgrade tax against every DXP major.
• Roadmap: reduce cost of change, not add features. The value proposition is fewer deploys per content change. Useful for roadmaps framed around editorial autonomy, campaign velocity, and lowering the number of "please hardcode this list" requests per release.
• Feature scope for landing pages, hubs, and personalization-adjacent blocks. Good fit for curated collections, "more from this author," related-article modules, and product/resource listings where the selection logic is content-shaped and changes seasonally.
• Headless/API delivery decisions. GraphQL resolver changes in the release history (deprecated @=resolver syntax replaced, empty-field GraphQL resolving fixed) indicate supported API-surface delivery — relevant when deciding whether merchandising logic lives in the CMS or in the front end.
• Upgrade and platform-lifecycle budgeting. Dual 4.6.x and 5.0.x release tracks, PHP 8.3 minimum on 5.x, Symfony 7 LTS, and psr/log ≥2 support are planning inputs for platform upgrade windows.

Signals to weigh honestly: 3 GitHub stars and 0 dependents are not a quality signal here — this is a vendor-split subpackage of a commercial DXP, distributed and versioned with the parent product. Judge it by the parent's release cadence and support contract, not by community traction. Conversely, do not treat it as an independent open-source dependency you can adopt à la carte.

When to Consider This Package

Consider it when all of the following hold:

• You are running Ibexa DXP (4.6.x or 5.0.x) with a current subscription, and this package is already in your dependency graph — enabling it is configuration and content-model design, not procurement.
• Editors repeatedly request list/collection changes that currently require template edits and releases. The ticket volume is the business case.
• Your content model can tolerate query definitions living in content: they are versioned with content, editable by non-developers, and reusable across pages.
• You can govern it: roles/permissions restricting who can author queries, a review step for query definitions, and performance guardrails (limits, pagination, caching) so an editor cannot accidentally ship an unbounded query against production.
• Delivery happens through the standard Repository API / GraphQL / Twig stack, so the field resolves in your existing rendering path.

Look elsewhere or defer when:

• You are not on Ibexa DXP. There is no standalone use; the package is a field type for that repository and content model. Migrating to it is not a portable decision.
• Query logic must be code-reviewed, unit-tested, and CI-gated. Editor-authored queries bypass your test suite. If listing logic is business-critical or regulated, keep it in code and use the field only for bounded, non-critical merchandising.
• Licensing is unresolved. The repository reports NOASSERTION and the README describes a dual Ibexa BUL / GPLv2 grant. GPLv2 is copyleft; BUL requires a valid subscription. Route this through legal before it appears in an architecture diagram — it is the single most likely blocker in a procurement review.
• You need community support or third-party ecosystem. Zero dependents, minimal external documentation beyond vendor docs; support flows through Ibexa's issue tracker, not the open web.
• Performance is already tight. Editor-controlled queries add an unpredictable workload class; if you cannot add caching and query-cost limits, the risk/benefit inverts.
• You want a portable, vendor-neutral content platform. This deepens Ibexa coupling at the content-model layer, which is the hardest layer to migrate away from.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a capability already included in our Ibexa DXP subscription that moves routine "change this list on the site" work from engineering to the content team. It converts a recurring release-cycle cost into a content operation: fewer deploys for editorial changes, faster campaign turnaround, and no bespoke software to build or maintain. The decision is not whether to buy it — we already have it — but whether to standardize on it for curated listings, with the governance needed to keep it safe. Primary risk is licensing clarity (dual BUL/GPLv2) and editor-authored query performance; both are manageable and should be confirmed before we commit it to the content model.

For engineering: Adopt the vendor field type instead of a custom list-builder. It attaches a serialized Repository Query to a field and resolves it through the standard Repository API, with GraphQL support maintained upstream (including a fix for empty-field resolution and migration off deprecated resolver syntax). Cost avoided: query-config UI, resolver, serialization, and the upgrade maintenance across Symfony 6 → 7 and PHP 8.3 that upstream has already absorbed. Requirements from us: define which content types may carry the field, cap result sizes and mandate pagination, ensure view caching covers resolved queries, lock down the editor permission, and confirm the license path with legal. Non-goal: replacing code-owned, tested query logic in critical paths.

For the content/editorial lead: You get direct control over what appears in collection-style components and can change it without a ticket, with the query definition living and versioning alongside the content it belongs to. This comes with responsibility — query definitions affect site performance and are visible to visitors — so a short authoring standard and a lightweight review for high-traffic placements are part of the rollout, not an afterthought.

Ask: approve a scoped pilot on two to three low-risk placements, with legal clearance on licensing and a performance baseline captured before and after, so we can quantify reduced change-request volume and deploy frequency before broadening adoption.