Pumukit Template Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for portal theming. This bundle is a reference implementation of "let non-developers change how the video portal looks." Use it to price the alternative: adopting/forking it versus building your own theming layer on top of Twig/config. Its existence proves the problem is real (hence an elevated opportunity score); its 2 stars and 0 dependents prove nobody has validated it for you.
• Self-service branding vs. professional services. If today every institutional customer's logo, colors, and layout changes go through an implementation engineer, a template editor converts recurring services hours into a one-time capability. That is a margin decision, not a feature decision — model it as reduced customization backlog per new WebTV deployment.
• Multi-tenant / multi-brand roadmap. A per-tenant template editor is a prerequisite for serving several broadcasters, faculties, or channels from one PuMuKIT install. If multi-branding is on the roadmap, this is a component of that bet and should be scoped alongside it, not purchased in isolation.
• Scope containment for "basic." The package self-describes as a basic editor. That supports a decision to ship a constrained v1 (logo, palette, layout slots) rather than promise a full page builder — and to say no to design-token, responsive, and accessibility requirements until a second iteration.
• Platform-fit due diligence. Note the mismatch with the brief: this is a Symfony bundle for PuMuKIT's WebTVBundle, not a Laravel package. It cannot be dropped into a Laravel or generic PHP application. That single fact should kill or confirm the initiative before any estimate is written.
• Maintenance-ownership budget. With 0 dependents, you are the de facto maintainer the moment you install it. The decision this supports is "fork and own" versus "depend and hope," which has a headcount and upgrade-path cost attached.

When to Consider This Package

Adopt-consideration criteria — all should hold:

• You are running PuMuKIT and have WebTVBundle in the stack today. This is a hard gate; outside that ecosystem the package has no value.
• Your theming needs are genuinely basic and stable: branding assets, palette, and layout arrangement — not bespoke per-page composition or interactive components.
• You can accept effectively zero community: 2 stars, 0 dependents means no third-party bug reports, no security review, no upgrade guarantees across PuMuKIT/Symfony majors.
• You are willing to vendor/fork it into your own repository and assign a named owner, rather than treat it as an external dependency with an implicit support contract.
• You have a PuMuKIT-savvy engineer who can read the bundle quickly and judge whether it is a usable base or merely a design reference.
• The cost of a two-to-three day spike is small relative to the customization hours it might remove.

Look elsewhere — or build in-house — when:

• Your application is Laravel or any non-PuMuKIT PHP stack.
• You need actively maintained dependencies, published security posture, or vendor support.
• Requirements include modern theming depth: design tokens, responsive breakpoints, WCAG conformance, i18n of template strings, or preview/rollback workflows.
• You are a small team with no capacity to own a forked Symfony bundle through future upgrades — in that case a config-plus-Twig theme layer you fully control is the safer product.
• You only need one or two fixed themes. A template editor is a capability investment; two static themes are a configuration task.

How to Pitch It (Stakeholders)

For executives (one paragraph). We have an option to give customers a self-service editor for the look of their video portal, instead of routing every logo and colour change through our implementation team. The candidate component is small and free, but it is a niche Symfony bundle inside the PuMuKIT platform with essentially no user base — two stars, no downstream projects — so it is not a supported product we can lean on. The right framing is a low-cost experiment: a short engineering spike to decide whether to adopt it as a base, fork it and own it, or simply mine it for design guidance and build our own. Total exposure is days of engineering, not a licence or a vendor commitment. The upside is measurable — fewer customization tickets per new deployment and the groundwork for running multiple branded channels on one install. I recommend approving the spike and nothing beyond it.

For engineering (summary).

• What it is: a Symfony bundle providing a basic template editor for PuMuKIT's WebTVBundle frontend — a theming surface for the web TV portal, not a general templating engine.
• What it is not: a Laravel package, an actively maintained library, or something with a support path. Treat any external fixes as non-existent.
• Ask: a timeboxed spike — read the bundle, stand it up against a current PuMuKIT/WebTVBundle instance, and report on three things: does it still work with our Symfony version, how invasive is the integration into WebTVBundle's rendering path, and what would ongoing ownership cost us per PuMuKIT upgrade.
• Assumption to test: that "basic" is sufficient for our customers' branding requests. If the spike shows we would immediately need to extend it substantially, the build-versus-adopt answer flips to build, and the package becomes a reference for UX and data model only.
• Default posture if approved: fork into our own repository, pin to our Symfony line, name an owner, and make no promises to stakeholders about upstream fixes.