Statamic Widget Collection Count Laravel Package

Technical Evaluation

Architecture fit: This is a Statamic control-panel addon (Laravel package with a service provider, config, and Vue-based CP components) that surfaces content counts, most likely as a dashboard widget. The v2.0.0 release is a deliberate alignment release: it moves the package onto Statamic 6's addon conventions and drops 3/4/5. That is the right call for a small addon — supporting four major Statamic versions in one codebase is a maintenance tax with little payoff — but it converts the package from "broadly compatible utility" into a "version-locked companion" to Statamic 6. The feature work (card-less default display, opt-in cards, permission-based hiding, focus styles) is low-risk presentation and authorization polish rather than architectural change.

Integration feasibility: Installation remains a standard Composer require plus widget registration; no new infrastructure, queue, or storage requirements are implied. The one hard gate is the breaking change: v2.0.0 requires Statamic 6, so the package cannot be adopted on its own merits — it is only installable as part of a Statamic major upgrade. Teams on Statamic 5 must pin to the 1.x line, which now becomes a legacy branch with no forward feature development.

Technical risk: Low in absolute terms, moderate in coupling terms.

• Version coupling: Dropping Statamic 3–5 means this addon becomes another constraint in the Statamic 6 upgrade calculus. It is no longer a neutral dependency.
• Authorization correctness: "Hide collections the user cannot view" is the highest-value change here — it closes an information-disclosure gap where editors could infer the existence and size of content they had no access to. The key risk is whether the check delegates to Statamic's own authorization (collection/entry view permissions) rather than a bespoke role comparison. If it is bespoke, it will drift from Statamic's permission model.
• Behavioural change for existing users: Switching from cards to a plain count list by default is visually breaking even though it is not semver-breaking in the API sense. Dashboards will look different after upgrade, and anyone who relied on card layout for scannability must now opt in.
• Ecosystem timing: Statamic 6 is new. Other addons in a typical stack (SEO, forms, caching, search) may not yet declare 6.x support, which will gate adoption of this package regardless of its own readiness.
• Performance: Counts are cheap on small sites and expensive on large multi-site installs; a per-collection count on every dashboard load is a plausible N+1. Worth confirming whether counts are cached or lazily fetched.

Key questions:

1. Is the collection-visibility check implemented via Statamic's native authorization (e.g. Collection::can('view') / user permissions) or custom logic? Does it cover entry-level and multi-site permission variations?
2. Is the 1.x branch on Statamic 5 receiving security fixes, or is it frozen?
3. What are the minimum PHP/Laravel versions for Statamic 6, and does this package declare them explicitly in composer.json?
4. Are counts cached, and is there a config knob for cache TTL or manual refresh? What is the query cost on a site with 50+ collections?
5. Does the card/no-card toggle have a global config default (so it can be set once for a team) or is it per-user only?
6. Who maintains the package — first-party Statamic or community? What is the historical turnaround for Statamic major-version support?
7. Do the new focus styles bring the widget to WCAG 2.2 AA, or is it a partial improvement?

Integration Approach

Stack fit: Laravel + Statamic 6 control panel, no separate runtime. Standard composer require and widget registration; config publish if the team wants to pin the card default. Nothing here touches the front-end delivery path, so production content rendering is unaffected — blast radius is limited to the CP dashboard.

Migration path: Adopt as part of a Statamic 6 upgrade, not before it. Two viable tracks:

• Upgrade track: Branch, bump statamic/cms to ^6.0, resolve other addon constraints, then bring this package to ^2.0. Treat the two as a single change set with one rollback point.
• Hold track: Stay on Statamic 5 with the package pinned to ^1.x. Explicitly accept that the permission-hiding fix and a11y improvements are unavailable, and note the disclosure gap as a known, accepted risk if editors have partial collection access.

Compatibility: Before committing, audit the full addon inventory for Statamic 6 declarations — this package is rarely the blocker, but it is never the only dependency. Confirm PHP and Laravel floors, confirm multi-site behaviour (counts per site vs. aggregate), and confirm the CP asset build works under the project's Vite/build setup.

Sequencing:

1. Inventory addons and their Statamic 6 support; identify the true critical path.
2. Stand up Statamic 6 in a staging branch with this addon at ^2.0.
3. Validate permission behaviour with a non-superuser role that has access to only some collections — verify hidden collections are truly absent, not merely greyed out.
4. Confirm the card-less default with the editorial team; set the config default to match their preference so the upgrade does not silently change everyone's dashboard.
5. Ship to staging, then production, with a short comms note to editors explaining the layout change and why some collections may no longer appear (they were never permitted).
6. Record the 1.x pin as technical debt with a target date if the team defers.

Operational Impact

Maintenance: Small, presentation-layer addon with a low change rate; v2.0.0 is essentially one compatibility bump plus UI polish. The maintenance burden is not in the code but in the release cadence: this package will likely ship a major version for every Statamic major, so the team should expect and budget a v3 at Statamic 7. Two active branches (1.x for Statamic 5, 2.x for 6) is sustainable only if the maintainer keeps 1.x patched.

Support: Expect support limited to the current Statamic major. If the package is community-maintained by a single author, response time on Statamic 6 edge cases (multi-site, custom permission setups) is the main unknown. For a dashboard widget, "broken" degrades to a missing panel rather than a site outage, which keeps severity low.

Scaling: The widget is per-user and per-dashboard-load. On large installs — many collections, many sites, large entry volumes — count queries are the scaling concern, not user concurrency. Multi-site multiplies query counts if counts are computed per site. Recommend confirming caching behaviour before rolling out to a large editorial team; if uncached, this is a candidate for a lazy or cached wrapper rather than a reason to reject the package.

Failure modes:

• Statamic upgrade drift: Pinned to Statamic 6 only; an eventual Statamic 7 upgrade blocks until this package ships. Low severity, but it lands on the critical path of the next platform upgrade.
• Permission regression: If the visibility logic diverges from Statamic's permission model after a future Statamic permissions change, the widget could over- or under-display collections. Under-display is a usability annoyance; over-display is a disclosure issue. Worth a periodic spot-check.
• Silent hiding confusion: Editors who previously saw a collection and now do not may report "missing content." This is correct behaviour but needs a support note, or the helpdesk will absorb it as an incident.
• Cosmetic breakage: The card-less default and focus-style changes alter the CP appearance; any internal screenshots, onboarding docs, or training material referencing the old widget need updating.
• Asset build mismatch: CP components built for Statamic 6's asset pipeline will not load on 5 and vice versa — a stray 1.x/2.x mix in a monorepo or a stale lockfile produces a blank widget with a console error, which is diagnosable but not self-evident.

Ramp-up: Minimal for developers — Composer install and widget registration, under an hour. The real ramp-up is editorial: a short note explaining the new compact count view, where the card option lives, and why some collections no longer appear. Budget that communication as part of the Statamic 6 upgrade rather than as a separate change.