Layouts Ezplatform Tags Query Laravel Package

Product Decisions This Supports

• Dynamic content curation in layout-driven pages: Enables product/content teams to define reusable "blocks" in Netgen Layouts whose contents are resolved at render time by Netgen Tags (e.g., "show all articles tagged featured", "show products tagged summer-sale"). This is a build-vs-configure decision: instead of hard-coding editorial lists or building custom query endpoints, you delegate selection to a tag taxonomy editors already manage.
• Roadmap for editorial tooling: If your roadmap includes personalization, landing-page composition, or campaign microsites where marketing assembles pages without engineering, this package is a proof point that tag-driven dynamic zones are feasible on your Ibexa stack without a custom integration.
• Taxonomy as the product contract: Choosing this package is a commitment to Netgen Tags as the single source of truth for content grouping. That affects information architecture decisions (how tags are modeled, governed, and migrated) and downstream analytics (do tag-based impressions map to reporting dimensions you care about?).
• Use cases: editorial landing pages, campaign hubs, category/collection pages, related-content modules, and A/B-able content zones where the selection rule changes frequently but the layout does not.
• Build vs buy: The functional gap is small and well-defined (a query handler that translates tag selections into a Layouts query). For teams already on Netgen Layouts + Ibexa + Netgen Tags, adopting this is cheaper than building and maintaining a bespoke query type; for anyone else, it is a signal that the trio is viable, not a component to adopt in isolation.
• Risk flag for the roadmap: 6 stars, zero dependents, and a low opportunity score indicate a narrow, lightly validated tool. Treat it as ecosystem confirmation rather than a strategic dependency; do not let a product initiative hinge on its maintenance cadence without a fallback plan.

When to Consider This Package

Consider it when all of the following hold:

• You are running Ibexa/eZ Platform with Netgen Layouts as your layout/composition layer and Netgen Tags as your taxonomy.
• You have (or will have) editors who should control which content appears in a layout zone by tag, not by manual item picking or engineering releases.
• Your content model already expresses business groupings as tags, and those tags are governed (naming conventions, ownership, lifecycle).
• You accept GPL-2.0 licensing in your stack and can meet its obligations for distributed software.
• You are comfortable owning the integration: with zero dependents and a small community, expect to read the source, pin versions, and potentially fork or vendor it.

Look elsewhere when:

• You are not on the Netgen trio — the package is pure glue and offers nothing standalone.
• You need rich query semantics (booleans across multiple taxonomies, full-text scoring, faceted ranking) that a tag-based query handler does not express; a custom query type or search-service integration is a better fit.
• Vendor support, SLAs, or a large maintainer community are procurement requirements; the adoption signals here do not support that.
• You are standardizing on a different composition approach (headless page builders, block-based editors in the CMS itself), making Layouts redundant.
• You want manual curation with approval workflows rather than rule-based selection — tags give you dynamism, not editorial sign-off.

How to Pitch It (Stakeholders)

For executives: This is a small, free connector inside a specific CMS ecosystem. It lets marketing and editorial teams assemble pages and have content slots fill themselves based on tags, instead of filing engineering tickets for every content swap. The strategic value is speed of content iteration, not the package itself — the cost is near zero, but so is the vendor backing, so we should treat it as a low-risk experiment with a clear exit path, not a platform commitment.

For engineering: It is a Netgen Layouts query handler that resolves tag-based selections for eZ Platform/Ibexa. It is GPL-2.0, has minimal adoption, and no dependents, so we should validate it in a spike, pin the version, and keep our own thin abstraction over the query layer so we can replace it. Expect to read the source; do not expect upstream responsiveness. Confirm it works with our Layouts and Tags versions before it enters any customer-facing path.

For editorial/product: If we adopt it, the workflow becomes: tag content correctly, then compose pages freely. The tag taxonomy effectively becomes a product surface — mis-tagged content means broken pages. That argues for tag governance and an audit before rollout, which is a content-operations task, not an engineering one.