Dashboard Bundle Laravel Package

Product Decisions This Supports

• Internal admin tooling build-vs-buy. The package supplies the classic "dashboard as a container of blocks" abstraction: a dashboard service holds block services, each block renders a widget. That is a well-understood pattern you can reimplement in a few hundred lines, which makes it a useful reference point when scoping an internal admin console rather than a dependency to adopt.
• Roadmap decisions for legacy Sonata estates. If your product still runs Sonata Admin, this bundle defines how admin landing pages are composed. Any roadmap item touching admin UX, widget configuration, or per-role dashboards will run through it — so its archived status is a planning input, not just a maintenance footnote.
• Tech-debt and exit planning. Zero dependents, no release since March 2021, archived upstream. That combination is a clear signal for a "replace or vendor-in" decision on the roadmap rather than "upgrade."
• Platform-fit triage (data quality). This is catalogued as a Laravel/PHP package, but it is a Symfony bundle built for Sonata Admin. That mis-tagging is itself a product decision: fix the catalog filter or risk engineering evaluating it against a Laravel app where it cannot run.
• Not a differentiator. Nothing here supports customer-facing features or revenue. It is plumbing for back-office screens.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony, uses Sonata Admin, and is already pinned to a compatible PHP/Symfony generation from the 7.x/4.x–5.x era.
• You need to reproduce the existing Sonata dashboard behavior for continuity — for example, during an in-place upgrade or a short-lived maintenance window.
• You are willing to vendor the code into your repository and own it, because upstream is archived and will not take patches.
• The dashboard requirements are genuinely static: fixed blocks, config-driven, no need for modern UX expectations (async loading, drag-and-drop, per-user personalization).

Look elsewhere when:

• You are on Laravel. This package cannot serve you. Evaluate Filament, Laravel Nova, or Orchid instead — actively maintained, with comparable widget/dashboard primitives.
• You are on Symfony but not Sonata. EasyAdmin gives you a maintained dashboard with a fraction of the ceremony.
• You need a maintained dependency. Archived + 2021 + no releases means no security patches, no PHP 8.3+ guarantees, and no compatibility commitments. For anything with a multi-year horizon, that is disqualifying regardless of how well it fits today.
• You want the pattern, not the package. Read the source, copy the container/block concept, and implement it against your own service layer. This is the recommended path in nearly every case.

How to Pitch It (Stakeholders)

For executives: This is a small, archived Symfony admin-dashboard component that composes back-office screens out of configurable widgets. It is not a strategic dependency, it is not a Laravel package despite how it was catalogued, and it has had no releases since 2021. There is no adoption case: our recommendation is to not add it to any product, and to treat any existing usage as tech debt with a named owner and a removal path. Cost of leaving it in place is small but non-zero — no security patches and growing friction with each PHP upgrade.

For engineering: The value is conceptual, not code. The container-plus-block service model is a clean template for admin widget composition, and it is cheap to reproduce natively. If you inherit a Sonata codebase that depends on it, vendor the source in, pin the version, and schedule replacement alongside the next Symfony upgrade rather than attempting a fork-and-maintain. Also flag the catalog entry: the Laravel/PHP classification is wrong and should be corrected so it stops surfacing in Laravel package evaluations.