Fieldtype Query Laravel Package

Technical Evaluation

Architecture fit

• This is not a general-purpose Laravel package. It is an Ibexa DXP Field Type that extends the Ibexa content model and Repository API; it only makes sense inside an Ibexa DXP installation.
• The architectural value is real where Ibexa is already the CMS: query definitions move from hardcoded templates/controllers into content structure, letting editors own reusable repository queries alongside content.
• Fit is excellent for Ibexa-centric content platforms and poor-to-none for Laravel-only stacks. A Laravel application would need Ibexa DXP as a headless content service before this package becomes relevant.

Integration feasibility

• Inside Ibexa DXP, integration is low-effort: install via Composer, enable the Field Type, add it to a content type, and configure query settings through the editor UI.
• Outside Ibexa DXP, integration is not feasible without a port or reimplementation. Treat it as an Ibexa DXP capability, not a standalone library.
• Version alignment matters: 5.x targets PHP 8.3 and Symfony 7.x and removes deprecated REST code; 4.6.x remains the older line. GraphQL support exists but has had field-resolution fixes.

Technical risk

• Primary product risk: editor-authored executable queries shift performance and correctness risk from engineering to content operations. Without limits, previews, approval, and query-cost guardrails, a single broad query can degrade page performance.
• Security and governance risk: query fields execute against the Repository API; permissions, content visibility, and query scope must be modeled deliberately. The package does not remove the need for platform-level authorization and auditing.
• Upgrade risk: major-version changes include PHP/Symfony jumps, removal of REST-related code, rebranded field type identifiers, and GraphQL resolver changes. These are manageable inside the Ibexa upgrade cycle but require regression testing.
• Commercial/licensing risk: metadata reports NOASSERTION; the README describes dual Ibexa BUL or GPLv2 terms. Procurement and legal must confirm subscription entitlement or GPL obligations before adoption.
• Community signal is weak — 3 stars and 0 dependents — but this is a vendor-owned subpackage of a commercial DXP. GitHub popularity is not a reliable production-fitness indicator here; vendor release cadence and support entitlement are.

Key questions

• Are we an Ibexa DXP customer, and which major line are we on: 4.6 or 5.0?
• Which queries currently live in templates/controllers, and which are safe to expose to editors?
• What guardrails will exist: result limits, pagination, query allowlists, preview-only roles, approval workflow, timeouts, and audit logs?
• How will query fields be cached and invalidated: field-level, block-level, HTTP, or repository cache?
• Do any downstream consumers rely on REST field data that 5.x removed?
• Who owns editor training and query review, and what is the escalation path for a slow or broken query field?
• Has legal confirmed BUL subscription coverage or GPLv2 compliance?
• How will content staging and deployment handle query field definitions across environments?

Integration Approach

Stack fit

• Adopt only if Ibexa DXP is already the content platform. In that case the package is a native field type and fits the existing content model, editor UI, GraphQL layer, and Repository API.
• Do not introduce it into a Laravel application as a dependency. If Laravel must consume Ibexa content, keep this package server-side in Ibexa and resolve query results through Ibexa’s API/GraphQL.
• If the organization is standardizing on Laravel, treat this as an argument for a separate Ibexa content service, not as a Laravel package evaluation.

Migration path

• Inventory hardcoded queries in templates, controllers, and blocks; classify by ownership, frequency, cost, and editor value.
• Pilot on one low-risk content type with three to five queries; keep existing template/controller fallbacks until editor workflows and caching are proven.
• Migrate query-by-query, not content-type-by-content-type, so regressions are isolated.
• Version the field type configuration and content fixtures; query definitions are content and must move through staging and deployment like content.
• Choose the package line to match the DXP line: 5.x for PHP 8.3/Symfony 7 environments; 4.6.x where the platform has not upgraded.

Compatibility

• Confirm PHP 8.3+ for 5.x, Symfony 6/7 alignment, and psr/log >= 2 support.
• Check GraphQL schema and resolver behavior if query fields are exposed through GraphQL; test empty-field and permission-filtered cases.
• Audit 5.x removals: deprecated REST code, loadRelations replacement, and rebranded field type identifiers can affect existing data and integrations.
• Validate editor role permissions, content visibility, and language/translation behavior before broad rollout.

Sequencing

1. Confirm license entitlement and DXP version.
2. Upgrade or align the Ibexa environment to the target package major.
3. Install and enable the Field Type in a non-production environment.
4. Define query guardrails and editor permissions before enabling authoring.
5. Pilot one content type and migrate a small query set.
6. Measure performance, cache hit rates, and editor error rates.
7. Train editors and support, then expand migration.
8. Deprecate hardcoded queries only after stable operation and rollback validation.

Operational Impact

Maintenance

• Maintenance is tied to the Ibexa DXP release cycle. Expect frequent small releases, dual 4.6/5.0 maintenance lines, and periodic Symfony/PHP upgrades.
• The package itself is small, but operational ownership includes content model changes, query governance, cache configuration, and regression tests for editor-authored queries.
• Budget for license compliance review and periodic field type/data migration checks, especially around rebranded identifiers and REST removal.

Support

• Support should come from Ibexa’s commercial channels where subscribed; community support is thin given negligible GitHub adoption.
• Internal support needs a runbook for common failures: empty results due to permissions, malformed queries, slow pages, and missing GraphQL fields.
• Editors need a named owner for query review and a documented escalation path when a content change causes performance issues.

Scaling

• Query execution happens at render or API resolution time; scaling depends more on query design and caching than on the package code.
• Enforce result limits, pagination, timeouts, and cache TTLs. Broad repository queries across large content trees are the main scaling hazard.
• Plan for cache invalidation when content changes; query fields can create hidden dependencies between content, permissions, and rendered output.
• Monitor query latency, cache hit rates, and page-level performance by content type, not just platform-wide averages.

Failure modes

• An editor publishes an expensive or unbounded query and degrades page/API latency.
• A query returns no results because of permission filtering, language, or content visibility; editors interpret this as a package bug.
• Stored query configuration becomes invalid after a schema or field identifier change.
• GraphQL or API consumers receive empty or missing field data if resolver behavior is not tested.
• Upgrading to 5.x breaks integrations that depended on removed REST behavior.
• License non-compliance creates a release or audit blocker.

Ramp-up

• Developers need Ibexa Field Type configuration knowledge, Repository Query API familiarity, and cache/performance testing practices.
• Editors need training on query concepts, content visibility, result limits, and the difference between a saved query and a rendered result.
• Support staff need triage guidance for “empty field,” “slow page,” and “query changed but output did not” incidents.
• Directional effort: low engineering setup inside Ibexa; moderate governance and training effort; high organizational effort if hardcoded query ownership must shift from developers to content teams.