Dashboard Bundle Laravel Package

Technical Evaluation

Architecture fit. kunstmaan/dashboard-bundle is a Symfony bundle, not a framework-agnostic PHP library. Its entry point is a Bundle subclass with a DI extension, compiler passes, and Twig template overrides, all of which are meaningless to Laravel's service container, routing, or view layer. It is purpose-built as a plugin for KunstmaanCMS's admin area: dashboard pages, a widget registry (WidgetManager-style service), and widget classes rendered into the CMS admin layout. The only reusable asset is the domain pattern — a widget abstraction, a per-user dashboard layout store, and an analytics data adapter — not the code itself.

Integration feasibility. Effectively zero as a drop-in. The package was last released 2014-07-29, in the Symfony 2.x / PHP 5.4–7.0 era; its Composer constraints will hard-conflict with Laravel 10/11 on PHP 8.2+. Even if you forced resolution under a legacy stack, Laravel does not boot Symfony bundles, so nothing would register. Two viable paths exist:

1. Port the concepts (recommended). Reimplement the widget contract, registry, and layout persistence as native Laravel services, Blade/Livewire views, and Eloquent models. Roughly 3–5 developer-days for the framework layer; the analytics adapter is separate work.
2. Co-host as a separate Symfony service. Only defensible if the client already runs KunstmaanCMS and merely wants the dashboard surfaced next to a Laravel app — then iframe or proxy over HTTP.

Technical risk. High and largely non-technical in nature:

• Abandoned: no maintainer, no release in ~11 years, 4 stars, 0 dependents — no path to upstream security patches. You are permanently on the hook for the fork.
• Dead headline feature: the "large Google Analytics integration" targets Universal Analytics / Core Reporting API v3, which Google sunset (UA stopped processing data in July 2023). The most valuable 80% of the bundle is non-functional against GA4 regardless of framework fit.
• Era-locked internals: old Twig syntax, Bootstrap 2/3 markup, inline JS, hardcoded container IDs, and likely a stale google/apiclient pin with known CVEs.
• Licensing is the one clean dimension: MIT permits forking, porting, and commercial redistribution with attribution.

Key questions for stakeholders.

• Is the goal dashboard capability or this specific dashboard? If the former, the bundle is a spec, not a dependency.
• Which analytics source actually matters — GA4, Matomo, internal metrics — and who owns that contract?
• Do we need per-user dashboard customization (the bundle's real differentiator) or a fixed ops page?
• Is there an existing KunstmaanCMS footprint, or is this greenfield Laravel?
• Who absorbs long-term ownership of a ported fork?

Integration Approach

Stack fit. Poor at the package level, good at the pattern level. Laravel already provides the primitives the bundle invented for Symfony: a container for widget registration, Blade components for rendering, Cache for API response buffering, Schedule for nightly analytics pulls, and authorization policies for per-role dashboards. Nothing is gained by importing the bundle; several things (DI extension, Twig overrides) are actively in the way.

Migration path.

Compatibility. Assume PHP 5.x-era syntax ([] short arrays at best, no scalar type hints, no ??), Symfony 2 DI semantics, and a GA client library that no longer authenticates. Treat every file as reference source, not as copy-paste code: audit for deprecated crypto, hardcoded credentials patterns, and unsafe HTML interpolation before lifting anything. Do not add the Composer package to any lockfile — vendor-by-fork only if legal review insists on literal code reuse.

Sequencing.

1. Spike (1 week): read the bundle, extract the widget contract and layout model as a short design note; confirm GA4 credentials and quota.
2. Framework layer (1 week): widget registry, Blade components, per-user layout persistence, admin gate.
3. First widget (1–2 weeks): GA4 adapter with queued fetch, Redis cache, staleness indicator.
4. Parity check: reproduce the bundle's original widget set as a feature checklist, explicitly marking which ones are obsolete.
5. Cutover/retire: document the fork relationship for attribution; archive the vendored source.

Operational Impact

Maintenance. The bundle itself is zero-maintenance because it is dead — there is no upgrade treadmill, no changelog to track, no CVE feed to monitor. The cost transfers entirely to whatever you build from it. Budget ownership explicitly: a ported dashboard is a small internal product, not a dependency.

Support. No vendor, no community (0 dependents, 4 stars), no issue triage. Any bug is yours. This should be stated plainly in the ADR so future maintainers don't assume upstream fixes are coming.

Scaling. The bundle's model is request-time rendering with synchronous external API calls — the classic failure pattern. In a Laravel port, move all analytics fetching to queued jobs writing into cache/dashboard_metrics tables, render from cache, and let widgets degrade to "last updated N hours ago" rather than blocking the admin page. This removes the Google API from the request path entirely and makes the dashboard scale with your queue workers, not your admin traffic.

Failure modes.

• Silent staleness: GA4 token expiry or quota exhaustion produces blank/zero widgets that look like real data. Require an explicit freshness timestamp and an error state per widget.
• API drift: Google changes the Data API or OAuth scopes; an unmaintained client library fails opaquely. Pin the client, wrap it behind an interface, and add a contract test against a recorded fixture.
• Template injection: legacy Twig partials interpolating analytics values into markup — sanitize on port.
• Abandoned-fork drift: the ported code diverges from the reference and no one remembers why. Keep the design note next to the code.

Ramp-up. Low for the framework layer — a mid-level Laravel developer reproduces the widget registry and layout persistence in days, and the bundle's code is small enough to read end-to-end in an afternoon. The real ramp-up cost is analytics domain knowledge (GA4 dimensions/metrics, quotas, property structure), which the bundle cannot supply because its implementation predates GA4. Plan for one developer to own that adapter, and treat the bundle purely as a UI/UX reference for what the original dashboards displayed.