Pmk2 Stats Ui Bundle Laravel Package

Technical Evaluation

Architecture fit — primary disqualifier. This is not a Laravel package. teltek/pmk2-stats-ui-bundle is a Symfony bundle, and more narrowly a plugin for PuMuKIT, Teltek's Symfony-based video management platform. It provides the presentation layer — Twig templates, controllers, routes, menu entries — for statistics generated elsewhere in the PuMuKIT stats subsystem (e.g., PumukitStatsBundle and an underlying stats database). It is a UI add-on to a specific platform, not a general-purpose library. If the target stack is Laravel, there is no integration path; if the target stack is PuMuKIT (Symfony 3.x/4.x-era), it is a thin view module.

Integration feasibility — conditional and narrow. Composer installation requires matching Symfony bundle conventions (Kernel registration, routing, config tree) plus PuMuKIT's service container and security model. It will not run standalone; it presumes the PuMuKIT application, its user/session context, and the stats backend it renders. Realistic options are: (a) run PuMuKIT end-to-end and add this bundle, (b) run a separate Symfony app alongside and feed it the same stats data, or (c) reimplement the views in our own stack against the underlying data source.

Technical risk — high, dominated by abandonment signals. Two stars, zero dependents, a last release of 2022-01-04, and a composite score of 0.04 all point to a single-vendor, low-ceremony artifact. Risks: PHP/Symfony version lock to an obsolete baseline; no visible community to absorb upgrades; unclear CI/test posture; security patching dependent on one organization's release cadence; vendor lock-in to the PuMuKIT data model. The functional surface is small, which limits blast radius, but "small and unmaintained" is still a maintenance liability if it sits in a production path.

Key questions to resolve before any commitment:

• Do we actually operate PuMuKIT today, or is that an assumption? This is the single gating question.
• What Symfony and PHP versions does composer.json constrain, and does that survive our supported runtime?
• Is the stats backend (PumukitStatsBundle or equivalent) maintained and deployed? A UI without data is worthless.
• What license applies (AGPL/MIT?), and what are the obligations for a network-served app?
• Is there a commercial support agreement with Teltek, and who is the named maintainer?
• What precisely does the UI render (counts, time-series, per-video views, transcoder throughput)? If it is a handful of charts, rebuilding is likely cheaper than adopting the platform.

Integration Approach

Stack fit — incompatible with Laravel by construction. Laravel's extension unit is a service provider; Symfony's is a bundle. There is no adapter layer that makes a Symfony bundle a Laravel package. Treat any framing of this as a "Laravel/PHP package" as a metadata error. If someone proposes it for a Laravel codebase, the correct response is "no, unless we are adopting PuMuKIT."

Migration path — choose one of three, in cost order:

1. Reimplement the views (lowest cost, default recommendation). The deliverable is charts over stats data. Read this repository as a reference specification for what the stats UI should show and which queries back it, then build the equivalent in the existing stack. Avoids a new runtime, a new platform, and an orphaned dependency.
2. Sidecar Symfony service (medium). Deploy PuMuKIT's stats UI as an isolated Symfony app sharing the stats database or API, surfaced via reverse proxy or iframe. Preserves the vendor implementation but introduces a second runtime, a second auth model, and cross-app session friction.
3. Full PuMuKIT adoption (highest, only if already committed). Deploy PuMuKIT, register the stats backend, then register this bundle. Justified only when the organization is standardizing on PuMuKIT for video management independent of this feature.

Compatibility. Pin exact versions. Expect Symfony 3.4/4.x and PHP 7.x-era constraints; modern PHP 8.2+/Symfony 6/7 is almost certainly out of scope without a fork-and-upgrade effort. Verify against our supported-runtime matrix before any pilot.

Sequencing. (1) Confirm PuMuKIT footprint and stats backend existence. (2) Inventory the stats data model and the queries this UI depends on. (3) If pursuing path 1, extract the view requirements and discard the code. (4) If pursuing path 2/3, stand up the backend first, validate data freshness and volume, then add the UI and only then test against our supported PHP/Symfony baselines.

Operational Impact

Maintenance. One organization, two stars, no dependents: there is no community backstop. Any Symfony or PuMuKIT upgrade becomes our project or a paid engagement. The 2022 release date implies a slow-to-dormant cadence; budget for owning the code if it enters production.

Support. No evident public support channel or issue triage. Assume best-effort vendor contact or nothing. For a TPM, that means no SLA and no external escalation path — support burden lands on the internal team.

Scaling. Inherits PuMuKIT's PHP/Symfony monolith characteristics. Stats aggregation over a video catalog is query-heavy; expect to need read replicas, pre-aggregation, or caching rather than relying on the bundle. The UI layer itself does not change infrastructure sizing, but the queries behind it can.

Failure modes to plan for: PHP/Symfony version drift breaking the bundle; stats backend absent, renamed, or schema-changed; route/menu collisions inside a shared PuMuKIT admin; unpatched CVEs with no upstream release; growing data volume degrading page-load times; total loss of vendor continuity.

Ramp-up. The code surface is small, but onboarding cost is dominated by niche domain knowledge: PuMuKIT's bundle/config/service model, its security and menu extension points, and the video-stats data model. Documentation is likely thin; plan for source reading. A single engineer can own it, which is both the upside and the bus-factor risk.

Recommendation. Treat this as a reference implementation, not a dependency. Unless PuMuKIT is already the platform of record, reimplement the stats views in the existing stack against the same data source — that captures the value, eliminates the runtime mismatch, and removes a two-star, single-vendor, 2022-dated artifact from the critical path.