Pmk2 Stats Ui Bundle Laravel Package

Getting Started

Important framing: this is not a Laravel package. teltek/pmk2-stats-ui-bundle is a Symfony bundle built for PuMuKIT 2 (pmk2), Teltek's Symfony-based video platform. If you are working in a Laravel codebase, there is no supported integration path — there is no service provider, no facade, no config publish. Composer will happily install it into a Laravel project, but nothing will boot. Treat this assessment as "how would I use this if I inherited a PuMuKIT installation."

Minimal steps to get it running:

1. Confirm you already have a working PuMuKIT 2 install. This bundle is a UI layer only. It renders stats that are computed elsewhere (the companion stats backend bundle in the PuMuKIT suite). Installing it standalone gives you Twig templates and routes with nothing to display.
2. composer require teltek/pmk2-stats-ui-bundle
3. Register the bundle in the kernel — PuMuKIT 2 is a Symfony 3.x/4.x-era application, so this means app/AppKernel.php (new Teltek\PumukitStatsUIBundle\PumukitStatsUIBundle()) or config/bundles.php on newer Symfony. Check composer.json for the symfony/* constraint and match it.
4. Import routing, typically in app/config/routing.yml:

   pumukit_stats_ui:
       resource: "@PumukitStatsUIBundle/Resources/config/routing.xml"
       prefix: /admin/stats
   

5. Clear cache (bin/console cache:clear) and inspect the routes with bin/console debug:router | grep stats.

Where to look first: Resources/config/ (routing, services, the bundle's DI wiring), Resources/views/ (the Twig templates you'll almost certainly override), and Controller/. Those three directories are the entire bundle in practice.

First realistic use case: an admin wants a statistics dashboard showing usage/playback activity for the media library. This bundle supplies the pages; the backend supplies the numbers.

Implementation Patterns

Template-override-first customization. Like all Symfony bundles, this one is designed to be customized by inheritance rather than by forking. Override individual templates under app/Resources/PumukitStatsUIBundle/views/ (or templates/bundles/PumukitStatsUIBundle/ on Symfony 4+). Verify the exact path convention against your Symfony version — this is the single most common source of "my override is being ignored."

Wire it into the admin menu. PuMuKIT's admin has its own menu configuration. The realistic integration is not touching this bundle's controllers at all, but adding a menu entry that points at the stats route, plus the correct role/ACL so only admins see it. Check how other PuMuKIT admin bundles register their menu items and copy that pattern.

Treat the controller as a thin read layer. The pattern this bundle follows is: request comes in with filter parameters (date range, series/category), controller validates and forwards to the stats service from the backend bundle, controller hands an array to Twig, Twig renders charts. If you need a new dimension of stats, add it in the backend service and pass it through — do not put aggregation logic in the template.

Service decoration for behavior changes. If you need different filtering, caching, or export behavior, decorate the stats service in your app's services.yml rather than editing the bundle. This survives composer update.

Routing-level reuse. If you want the stats UI available outside the admin (e.g., a public read-only dashboard), import the same routing resource under a different prefix and add your own firewall rule, rather than duplicating the controllers.

Consistent styling. The templates assume PuMuKIT's admin theme CSS/JS. If your install has customized the admin theme, budget time for the charts to look wrong — this is cosmetic but always comes up.

Gotchas and Tips

• It is effectively unmaintained. Last release January 2022, 2 stars, 0 dependents. There is no community to ask, and no upstream fixes coming. Read the source before you rely on it — the whole bundle is small enough to audit in an afternoon.
• Do not install this into a Laravel app. Even if you're tempted to lift the Twig templates, they depend on PuMuKIT-specific variables and helpers. Port the charts, not the bundle.
• Version pinning is essential. The Symfony constraint in its composer.json will conflict with anything modern. Pin the bundle and your Symfony version together, and be prepared for composer update to break the install.
• Empty dashboards are a dependency problem, not a bug. If pages render with zeroes or blank charts, check that the backend stats bundle is installed, its tables are migrated, and data is actually being recorded. Check the backend's log channel before debugging this bundle.
• Route not found after install almost always means the routing import was skipped or the cache wasn't cleared. bin/console debug:router first, always.
• Debugging: use the Symfony profiler's request/route panel to confirm which template actually rendered (the toolbar shows the resolved template name), which instantly tells you whether your override path is correct.
• Permission mistakes are silent. A 403 or a missing menu item usually means the role isn't granted, not that the bundle failed. Check security.yml role hierarchy for the PuMuKIT admin roles.
• Extension points to prefer, in order: template overrides → service decoration → event listeners → forking. Forking is last resort because you inherit maintenance of a dead package.
• If you're evaluating this for new work, the honest answer is no. It's a UI bundle for a specific, aging platform with no dependents and no recent activity. If you control the platform, budget to replace the stats UI with your own controllers and templates against the same backend data — you'll get a maintainable result for very little extra effort.