Statamic Widget Collection Count Laravel Package

Getting Started

This addon surfaces per-collection entry counts in the Statamic control panel. v2.0.0 is a Statamic 6-only release — confirm your app is already on Statamic 6 before touching anything else, because 3.x/4.x/5.x are no longer supported and Composer will refuse the install alongside them.

Minimal path in:

1. composer require the addon on a Statamic 6 site (check the statamic/cms constraint Composer resolves against your composer.json).
2. Publish the config if you intend to customise anything: php artisan vendor:publish and pick the addon's tag.
3. Drop the widget onto a CP dashboard — either via CP → Dashboard → Edit (drag the widget into a column) or by adding it to the widgets array in config/statamic/cp.php.
4. Load /cp and confirm the counts render.

The first use case worth wiring up is the plain one: give editors a dashboard that answers "how much content is waiting in each collection?" without them clicking through the Collections nav. If your users only care about a subset of collections, get the visibility rules right on day one (see below) — the widget is far more useful when it shows three relevant collections than thirty irrelevant ones.

If you were on v1, do the upgrade on a branch and diff the dashboard visually before merging; the default presentation changed (see Gotchas).

Implementation Patterns

Widget registration in config/statamic/cp.php. Declare the widget explicitly when you want a fixed dashboard layout that ships with the site rather than something each user arranges:

'widgets' => [
    [
        'type' => 'collection_counts',
        'width' => 100,
    ],
    // ...
],

Users can still add/remove it from the dashboard editor unless you've locked the dashboard down; treat the config entry as the default, not a guarantee.

Card mode vs. flat list. v2.0.0 flips the default to a compact list without cards, with an opt-in for individual cards. Adopt the flat list where dashboard real estate is contested (most editorial dashboards), and reserve card mode for smaller dashboards where the counts are the primary content and you want each collection to read as a discrete tile. Set this once in config rather than per-user so screenshots, docs and onboarding stay consistent.

Lean on permission-aware hiding instead of curating a list. The addon now hides collections the current user cannot view. That means a single widget definition serves admins and contributors correctly, and you should not hardcode a collection allowlist per role unless you have a genuinely different dashboard per role. This is the pattern that pays off day to day: one dashboard config, many audiences.

Pair it with your content model, not your taxonomy. The counts are per collection. Use them as a prompt to go and edit ("12 entries in Articles, 0 in Case Studies") rather than as a reporting tool. If you need "entries pending review" or "entries missing a thumbnail", that belongs in a custom widget or a saved CP query — don't try to bend this addon into a metrics dashboard.

Multi-site and localisation. On multi-site installs, check which site's counts are being surfaced and whether that matches what editors expect. If your editors work in a single site, document it; if they switch sites, verify the counts follow the selected site before you hand the dashboard over.

Deployment checklist integration. Because the widget is dashboard-visible, add a line to your deploy smoke test: load /cp as a low-privilege user and confirm no counts for collections they shouldn't see. It's a thirty-second check that catches permission regressions early.

Gotchas and Tips

• Upgrading is a hard break, not a soft one. Dropping Statamic 3/4/5 means the v2 constraint won't resolve on older sites. If you maintain several Statamic installs on different majors, pin v2 to the Statamic 6 projects only and keep the old constraint for the rest — a single composer.json across projects will bite you.
• The default visual output changed. Counts now render without cards by default. Any documentation, onboarding video, or custom CSS targeting the card markup will look wrong until you either enable card mode or update the docs. Diff the CP on a staging environment; this is a cosmetic break, but a very visible one to clients.
• "Hidden" is not "secure". Permission-aware hiding is a UX affordance. Verify that the underlying collections are actually protected by Statamic's permissions — the addon hiding a row must never be the only thing stopping a user from reaching that content via a direct URL.
• Stale counts after bulk imports. After a large import or a queue worker run, dashboard counts can lag or look frozen. If a client reports "it says 0 but there are entries", check caching and re-check the collection's expectations before assuming a bug — reproduce by loading the CP in a fresh session first.
• Large collections are a query cost. Counts on a dashboard are cheap individually and less so multiplied. On sites with many collections or big datasets, prefer the flat list (fewer DOM nodes, less layout work) and consider whether the widget belongs on every user's dashboard or just the editorial one.
• Focus styles. The improved focus styles in this release are a genuine accessibility win — but if you've overridden CP styling with custom CSS, re-test keyboard navigation through the widget. Custom outline: none rules are the usual culprit when focus becomes invisible again.
• Extension point worth knowing. The widget is registered through Statamic's widget system, so overriding its view from your own theme/addon is possible when you need a bespoke layout — but prefer config options first. Forking the view means re-testing it on every addon release, and this addon has just demonstrated it will make breaking changes across majors.