Statamic Widget Cache Controller Laravel Package

Product Decisions This Supports

• Dashboard/CP performance investment: Gives the PM a low-cost lever to improve Statamic control-panel responsiveness without a custom build — relevant when editors complain about slow dashboard loads caused by expensive widgets (stats, API-backed, report widgets).
• Build vs. buy for control-panel polish: This is a small, single-purpose addon. The decision it informs is "do we spend engineering days building widget cache handling ourselves, or adopt a maintained package?" — the answer leans adopt unless there are hard vendor constraints (see below).
• Dependency/vendor-risk tracking (new in v3.0.0): The package was renamed from webographen/statamic-widget-cache-controller to stoffelio/statamic-widget-cache-controller. No behaviour change, but it is a major version bump driven purely by a vendor rename, which is a signal for the roadmap: track maintainer/handle continuity and budget a small migration ticket wherever the addon is installed.
• Upgrade planning: v3.0.0 is only breaking if the addon was customised — PHP namespace moved to Stoffelio\CacheController\ and the view namespace moved to stoffelio:: (overridden views must move from resources/views/vendor/webographen/ to resources/views/vendor/stoffelio/). This is a scoping input for any maintenance sprint, not a feature decision.
• Use cases it unblocks: editorial dashboards with heavy or third-party-backed widgets, multi-site installs where CP load time is a recurring support ticket, and teams standardising Statamic addons for CP performance.

When to Consider This Package

Adopt when:

• You run Statamic and the CP dashboard has widgets whose rendering cost (queries, external API calls) is a visible drag on editor experience.
• You want a configuration-level fix rather than owning custom caching code in your own codebase.
• You are on a Statamic version the addon supports and can accept a small, single-maintainer dependency.

Look elsewhere / defer when:

• You don't use CP dashboard widgets, or CP performance is not a pain point — there is no product value to capture.
• Your caching needs are really full-page, response, or CDN caching — this is a widget-scoped tool, not a caching strategy.
• You require vendor SLAs, security review depth, or guaranteed long-term maintenance; a single-maintainer addon with a recent namespace/handle change carries continuity risk.
• You have overridden the addon's views or referenced its PHP namespace directly and cannot schedule the v3 migration work now — pin the old package name and plan the swap rather than adopting mid-sprint.
• Composer hygiene matters and you cannot yet standardise on the new package name across environments/CI.

How to Pitch It (Stakeholders)

To executives: It's a small, low-cost addon that makes the Statamic editing dashboard feel faster by managing how dashboard widgets are cached. No new infrastructure, no custom development. The v3.0.0 release is a rename only — behaviour is unchanged — so there is no functional risk, but it does mean a short, well-scoped migration task (swap the Composer package, move any customised views) which we should ticket rather than absorb silently.

To engineering: Package renamed webographen/statamic-widget-cache-controller → stoffelio/statamic-widget-cache-controller; effectively composer remove + composer require. Not a behaviour change. Breaking only for customisations: PHP namespace is now Stoffelio\CacheController\ and views resolve from stoffelio::, so move overrides from resources/views/vendor/webographen/ to resources/views/vendor/stoffelio/. Recommend pinning the new package name in composer.json, auditing for any webographen references in views/config, and doing the swap as an isolated PR so it doesn't ride along with feature work.