Layouts Ibexa Tags Query Laravel Package

Product Decisions This Supports

• Feature viability: Enables "tag-driven" dynamic blocks in Netgen Layouts — editors configure a block to auto-populate with Ibexa content matching given Tags, instead of hand-picking items. Directly supports decisions like "should our landing pages self-populate from taxonomy?"
• Build vs. buy: This is glue, not a platform. It's a single query type that bridges two things you already own (Netgen Layouts' query API and Ibexa's Tags field type). The decision is "integrate a small bundle" vs. "write a ~one-file query handler." Assess your team's appetite for owning a tiny custom query type against the cost of taking a dependency with no adoption signal.
• Roadmap / content operations: Useful input to whether tag-based automation (topic hubs, "all content tagged X" rails, campaign pages) is a roadmap item. If editors are manually curating blocks today, this quantifies the maintenance savings.
• Taxonomy strategy: Adopting it makes Ibexa Tags a first-class content signal rather than passive metadata. That's a governance decision — tag hygiene, naming conventions, and review workflows start to matter because bad tags now produce bad pages automatically.
• Stack commitment: Choosing this bundle reinforces the Netgen Layouts + Ibexa + Tags combination. It narrows future flexibility toward that ecosystem's query model.
• Licensing posture: GPL-2.0 is a real product decision if you distribute or embed the result in a proprietary offering; confirm with legal before it lands in a shipped product.

When to Consider This Package

Consider it when:

• You are already running Ibexa Platform CMS with Netgen Layouts, and the Tags field type is populated on relevant content.
• Editors repeatedly build blocks by hand and you want per-block, configuration-only automation — no custom PHP per use case.
• Your needs are straightforward "content tagged with X" selection; you want the smallest possible integration surface.
• You have a small team and would rather pin a version than maintain a query handler.

Look elsewhere when:

• You are not on Ibexa + Netgen Layouts, or your taxonomy lives in categories, a custom field, or an external system — this bundle won't read it.
• You need faceted search, ranking, relevance, or filtering at scale; use a search-engine-backed query (Solr/Elasticsearch) instead of tag matching.
• Adoption and maintenance risk matters: 0 stars, 0 dependents, no community safety net. Maintenance tracks Netgen Layouts' release cadence and nothing else. Pin versions, read the source (it's small), and budget a fallback.
• GPL-2.0 is incompatible with your distribution model.
• Tag data is inconsistent — automation will amplify the mess. Clean the taxonomy first.

How to Pitch It (Stakeholders)

Executives: A small, low-cost add-on that lets content-heavy pages keep themselves current — blocks fill automatically from content tags, cutting editorial busywork and stale pages. It only fits if we're already on Netgen Layouts and Ibexa, so treat it as a tactical efficiency win inside an existing stack, not strategic infrastructure. Two caveats worth a sentence: near-zero adoption (no community support) and a GPL-2.0 license that legal should sign off on.

Engineering: One query-type bundle exposing Ibexa Tags to the Layouts query system. Small integration surface, but it inherits two external APIs (Layouts query layer, Ibexa Tags field) and has no downstream users to catch regressions. Pin the version, review the source, add a smoke test around block rendering, and keep a trivial custom query handler as the fallback if upstream stalls.

Recommendation to frame the decision: Adopt only within an existing Netgen Layouts + Ibexa deployment, scoped to tag-driven blocks, contingent on license clearance and a pinned version. Otherwise, the honest alternative is a short custom query type — this package's value is convenience, not capability.