Ezstatictemplatesbundle Laravel Package

Product Decisions This Supports

• Build vs. buy (adopt vs. write): this bundle does one narrow thing — map a URL on a SiteAccess in the static_group to a Twig template through the eZ/Ibexa design engine. That is a small, well-understood amount of code. The decision this informs is "adopt a convenience bundle vs. spend a day writing our own route + template resolver." Adoption wins only if we're already in the Novactive/Nova bundle ecosystem or want zero lift; otherwise in-house is comparable effort and fully owned.
• Delivery model / roadmap: supports a front-end-first cadence. Teams ship templates (styleguides, error pages, campaign landing pages, legal pages, prototypes) without waiting on content type modeling, editors, or route configuration. That directly affects how we sequence design-system work against CMS work.
• Feature scoping: clarifies which pages actually need content — if a page has no editorial inputs, it doesn't need a content type, an editor workflow, or a content migration. Deprecates planned content-modeling work for genuinely static pages.
• Use cases it unlocks: component/styleguide previews, seasonal microsites and one-off landing pages, static legal/support pages, print/email template previews, and rapid A/B or design prototypes — all served from the same Ibexa stack without new infrastructure.
• Platform strategy input: this is an Ibexa-specific affordance (SiteAccess + design engine are load-bearing). It's fine if Ibexa is the strategic platform; it's a non-factor otherwise. Minor, but it does deepen vendor-specific tooling.
• Team productivity metric: it removes a coordination dependency (front-end blocked on content/config) — worth weighing as cycle-time improvement rather than as technical capability.

When to Consider This Package

Consider it when:

• You are on eZ Platform / Ibexa with Twig, and SiteAccess groups and the design engine are already in active use.
• You are already consuming Novactive's Nova bundles — same maintainer, same support channel, consistent conventions.
• You need a fast, near-zero-config way to serve static Twig pages and want the smallest possible surface area.
• The pages are genuinely static and low-traffic-critical; convenience outweighs guarantees.

Look elsewhere when:

• You are not on Ibexa/eZ. The entire value is the SiteAccess + design engine integration; nothing transfers to Symfony standalone, Drupal, WordPress, or headless JS stacks.
• You need a real front-end tooling workflow — hot reload, versioned components, visual regression. Storybook, Fractal, or Histoire are the right tools; this bundle is not a component workbench.
• You need assurances for a business-critical path. Zero stars, zero dependents, a single-vendor subtree split, and issues routed to a monorepo mean no community safety net and no third-party validation. If it matters, budget for in-house ownership (pin, vendor/fork, add smoke tests) or build the thin resolver yourself.
• You need SEO, redirects, caching policy, or personalization on those pages — this is a bare URL-to-template mapper, and "static" is the whole point.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed convenience bundle for our Ibexa platform that lets the front-end team render Twig templates directly from a URL instead of waiting on content modeling and editor setup. Cost is near zero and risk is low, but so is strategic weight — treat it as a productivity convenience, not a platform bet. Adopt opportunistically if we're on Ibexa; do not build a roadmap around it or make it a dependency of a revenue-critical path.

Engineering: It registers a static_group SiteAccess group and resolves the request URL to a Twig template via the design engine — a convention-based static route. Pros: almost no configuration, tiny surface, consistent with Nova conventions, easy to hand to front-end devs. Cons: single-maintainer subtree split, no evident test or community signal, upstream issues live in the monorepo, no hot reload or tooling. Recommendation: pilot it for prototypes, styleguides, and static pages. If it lands in production, pin the version, vendor or fork it, and add our own smoke tests — otherwise a hand-rolled controller does the same job and stays under our control.