Statamic Widget Collection Count Laravel Package

Product Decisions This Supports

• Statamic 6 upgrade planning. v2.0.0 is the first line that supports Statamic 6 and is explicitly incompatible with Statamic 3–5. This package effectively becomes a gate item in the CMS upgrade checklist: it must be upgraded in lockstep with the platform, and any environment still on Statamic 5 or earlier must stay pinned to the prior major.
• Dashboard information architecture. The default is now counts without cards, with cards as an opt-in. This is a product-level decision about how much visual weight content counts get on the control panel — lighter by default, richer on request. Choose the default for editorial dashboards; opt into cards where counts are a primary KPI surface.
• Permission-aware reporting. Hiding collections a user cannot view aligns dashboard content with existing role/permission policy. This supports decisions about what editors, freelancers, and clients see on login, and reduces the risk of surfacing collection names or volumes to users who shouldn't know they exist.
• Accessibility as a roadmap commitment. Improved focus styles are a small but concrete item to cite when tracking keyboard-navigation and WCAG-related work on admin surfaces.
• Build vs. buy for CP widgets. A small, single-purpose addon that handles counts, permissions, and Statamic version support is generally cheaper to adopt than to build and maintain in-house — provided the maintained feature set matches what the dashboard actually needs.
• Not a decision driver for: analytics, editorial workflow, or content performance. This is a visibility widget, not a reporting platform; scope roadmap bets accordingly.

When to Consider This Package

Consider it when:

• The project is on, or actively migrating to, Statamic 6 — v2.0.0 is the only release line that supports it.
• Stakeholders want at-a-glance content counts in the control panel without building and maintaining a custom widget.
• The site has multiple collections and differentiated roles, so permission-aware hiding has real value rather than being a no-op.
• You want a low-footprint dependency with a narrow surface area and an upgrade path already aligned to the platform's major version.
• Accessibility on admin screens is a stated requirement and small wins like focus styling are worth taking for free.

Look elsewhere (or stay on v1.x) when:

• You are on Statamic 3, 4, or 5. v2.0.0 drops these entirely — this is a hard breaking change, not a soft deprecation. Do not attempt the upgrade before the platform move.
• You need trends, time-series, or exportable reporting rather than current totals.
• You need counts across non-Statamic data sources or custom KPIs the addon does not model.
• You have a strict dependency policy and the default visual change (cards off) would require design or training work to restore expected dashboard appearance for existing users.
• The count widget is the only reason you would upgrade the CMS — sequence the platform upgrade on its own merits, then adopt this.

How to Pitch It (Stakeholders)

For executives: This release is primarily an upgrade-readiness milestone. The package now supports Statamic 6, which unblocks or de-risks the CMS platform upgrade; the trade-off is that it no longer supports Statamic 3–5, so the upgrade must be sequenced with the platform, not run ahead of it. Alongside that, two low-cost UX improvements — lighter default dashboard presentation with optional card view, and hiding collections users aren't permitted to see — tighten the editorial experience and reinforce existing permission policy. No new infrastructure, no data migration, no vendor commitment.

For engineering: Treat v2.0.0 as a major-version bump tied to the Statamic 6 upgrade. Verify the platform version first; on Statamic 5 or below, stay pinned and expect no further updates on this line. Budget for a visual QA pass because counts now render without cards by default — confirm this is acceptable or explicitly enable card mode to preserve the current look. Confirm permission mappings resolve as expected for restricted roles, and spot-check keyboard focus states. The change surface is small and contained; the main risk is sequencing, not complexity.