Dashboard Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin surfaces — scope corrected. v2.0.0 settles the framework question: this is a Symfony bundle for the Kalamu CMS, not a Laravel package. The breaking major drops Symfony 2.* and targets Symfony 4 with Bootstrap 4. Its value as a reference implementation of config-driven admin layout holds; its value as an adoptable dependency drops further, because the release pins the pattern to a 2017–2018-era stack.
• Feature scoping for internal tooling. Unchanged and still the strongest use: declarative widget configuration, Bootstrap grid layout, no bespoke frontend build step. That remains a legitimate floor for scoping an MVP ops console, moderation view, or status dashboard.
• Roadmap sequencing. Because dashboard composition is declarative, adding a panel is a config change rather than a UI project — still a valid argument for deferring admin-UI investment until core product features land.
• Buy-side risk assessment — updated facts. Three stars, zero dependents, and a major version bump that is a compatibility catch-up rather than a capability release. The decision-relevant read is not "unmaintained" alone but "maintained toward a stack that is itself out of upstream support": Symfony 4 and Bootstrap 4 have both passed end of life. The reject-as-dependency call stands, with a sharper rationale.
• Upgrade-path signal. A maintainer jumping a major version to reach Symfony 4 in the Bootstrap 4 era tells you the project trails upstream by roughly a full framework generation. There is no evidence of a Symfony 5/6/7 path, so plan for no future upgrade rather than a slow one.
• Use cases it genuinely fits: teams already on Kalamu running Symfony 4.x who need an admin shell today, internal tools with a small trusted audience, throwaway demos, and anyone mining the config pattern for an in-house build.
• Use cases it does not fit: anything on Laravel or Symfony 5+, anything needing a maintained security posture, anything on a Bootstrap 5 design system, and anything customer-facing or revenue-adjacent.

When to Consider This Package

Consider it only when all of the following hold:

• You are already on Kalamu, and specifically on Symfony 4.x. v2.0.0 drops Symfony 2.* — if you are coming from an older install this is a mandatory breaking upgrade, not an optional one.
• The dashboard is internal and low-stakes — a handful of trusted users, no PII exposure beyond what the team already sees.
• Bootstrap 4 is your styling baseline. If you are on Bootstrap 5 or a modern design system, this is a conflict to resolve, not a tweak.
• You can vendor, fork, or pin the dependency and accept ownership of it — including security patching for Symfony 4 and Bootstrap 4 underneath it.
• You have verified PHP/runtime compatibility for Symfony 4.x on your target stack.

Look elsewhere when:

• You are on Laravel, or on Symfony 5/6/7. v2.0.0 moves the package to Symfony 4, which is the wrong direction on any modern stack — integration cost is glue code plus a framework downgrade. The MIT license does not offset that.
• You need active maintenance or security guarantees. A compatibility catch-up release does not restore an upstream safety net; the package's own target frameworks are past end of support, and it still has three stars and zero dependents.
• You need authentication, RBAC, audit logging, or multi-tenancy in the admin layer. None of that is implied by a dashboard shell; you would be building it anyway.
• You need community support. Zero dependents means no tutorials, no Stack Overflow corpus, no fellow travelers.
• You have existing forks or pins. A major version bump means a rebase; budget that work explicitly rather than absorbing it.
• The dashboard is customer-facing or revenue-adjacent, where an unmaintained dependency is an unacceptable concentration of risk.

How to Pitch It (Stakeholders)

To executives: The new v2.0.0 is a maintenance catch-up, not a modernization. It drops Symfony 2 and moves the package to Symfony 4 with Bootstrap 4 — a stack that was current around 2018 and is now past upstream support on both layers. The project still has three GitHub stars, zero downstream dependents, and no vendor or support contract. My recommendation is unchanged and firmer: mine it for its configuration-driven layout pattern, do not adopt it as infrastructure. Any roadmap item that assumes this package is a maintained foundation should be re-scoped now, before it becomes a rewrite.

To engineering: v2.0.0 is a breaking major. It is Symfony-only — it drops Symfony 2.* support, targets Symfony 4, and requires Bootstrap 4. That closes the "could we use this on Laravel" question: no, and the gap widened. On a Kalamu/Symfony 4 codebase it is a cheap admin shell; anywhere else it is a framework downgrade plus glue code. If we fork, we now own a v2 rebase and we inherit end-of-life Symfony 4 and Bootstrap 4 — schedule that risk explicitly instead of discovering it during a security review. For a Laravel admin panel, evaluate maintained alternatives first; for a Symfony 5+ codebase, this package is not on the path at all.