Dashboard Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin analytics surfaces. This bundle is a data point for the "buy/reuse" side of the ledger — but a negative one. It demonstrates that a third-party dashboard layer carries the full maintenance burden of the host CMS, the analytics vendor's API, and the auth model simultaneously. Useful for arguing for a thin, in-house widget layer over adopting an inherited bundle.
• Dashboard architecture pattern (the one thing worth harvesting). The bundle's real contribution is a composable widget model: register a widget, place it in a dashboard container, render it in the admin area, gate it by role. That abstraction maps cleanly onto decisions like "do we build a pluggable widget registry for our internal admin, or hardcode each panel?" Reading the source answers that with evidence rather than a spike.
• Scope of embedded analytics in the admin. It shows a concrete answer to "how much Google Analytics belongs inside our own product UI?" — and the answer it encodes (full GA reporting surface inside the CMS admin) is now the wrong one. Supports a roadmap decision to link out to GA4 rather than embed it.
• Legacy maintenance triage. If the org inherits a Kunstmaan CMS installation, this feeds the "replatform vs. patch" decision by quantifying how stale the dependency graph is (2014-era Symfony bundle, GA Universal Analytics-era integration, zero dependents).
• Use cases in scope if adopted at all: a reference implementation for an internal ops dashboard, a fork candidate for a legacy Symfony admin, and a teaching artifact for junior engineers on widget composition. Not a production dependency for anything new.

When to Consider This Package

Consider it only under these narrow conditions:

• You are already running Kunstmaan CMS / KunstmaanAdminBundle on a Symfony 2.x-era stack, and you need to keep an existing GA panel alive during a migration window. Even then, fork and vendor it — do not pull it from Packagist.
• You want a read-only architectural reference for widget registration and admin-area dashboard composition. Clone it, read it, cite it, discard it.
• You need a cost baseline to justify building your own dashboard layer ("this is what the maintained option looks like after eight years of drift").

Look elsewhere — decisively — when:

• You are on Laravel. The package prompt frames this as a Laravel/PHP package, but it is a Symfony bundle. There is no Laravel integration, no service provider, no facade. That mismatch alone should end the evaluation.
• You need Google Analytics. The integration targets the Universal Analytics Reporting API, which no longer collects data. GA4 uses a different data model and API surface; this bundle's GA code is not portable, only replaceable.
• You need maintained dependencies. Last release July 2014, four stars, zero dependents, no security response path. There is no vendor to escalate to and no community to absorb a CVE.
• You need modern auth, multi-tenancy, or async data loading. None of it is here; the era is wrong.
• Timeline or compliance pressure exists. An unmaintained bundle in an admin surface with analytics credentials is an audit finding waiting to happen.

How to Pitch It (Stakeholders)

To executives: We evaluated a reusable dashboard component for the admin area. It is not adoptable — the last release was 2014, it has no downstream users, it targets a discontinued analytics API, and it is built for a different PHP framework than ours. My recommendation is not to take on the dependency. The residual value is architectural: roughly one to two engineering days to extract the widget-composition pattern as a design reference, after which we build a small in-house dashboard layer on our current stack. That approach keeps us on supported dependencies, avoids an eight-year-old security surface sitting next to our analytics credentials, and costs less than a modernization fork would.

To engineering: Treat this as a pattern donor, not a dependency. The transferable idea is the widget registry — a way to declare dashboard panels as discrete, permission-gated units rather than hand-built views. Everything else (the Symfony bundle wiring, the GA client, the templating) is stack-specific and dated. Concretely: timebox a read-and-summarize pass, capture the widget contract in a short design note, and build the equivalent against our framework and the GA4 API. If anyone is running a legacy Kunstmaan install, flag it now so we can plan the exit rather than patch around it.