Statamic Widget Cache Controller Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon, not a general-purpose Laravel package, and it sits at the shallowest possible layer of the stack: a service provider that registers one Control Panel dashboard widget, plus a view and a handful of cache-clear calls. It does not touch the content repository, the Stache indexing pipeline, routing, or the Eloquent layer. Functionally it is a thin UI wrapper over commands the operator would otherwise run in a terminal (cache:clear, statamic:stache:clear, glide:clear, and possibly view:clear/config:clear). That means the architectural footprint is negligible by design — it neither constrains nor improves the surrounding application. The value proposition is operator convenience for users who lack SSH access, not capability.

Integration feasibility. Installation is a standard composer require plus a widget entry in config/statamic/cp.php, which is a well-trodden and reversible path. Two concerns temper the "trivial to adopt" read:

• Supplier identity is inconsistent. The package namespace is webographen/* while the repository URL resolves to stoffelio/*. This may be a legitimate fork or transfer, or it may be an unattributed republish. Either way it must be resolved before the package enters a dependency graph — provenance ambiguity in a component with CP-level privileges is a supply-chain question, not a cosmetic one.
• Adoption signals are effectively null. Zero stars, zero dependents, and a single release. A release timestamped 2026-09-21 is also anomalous relative to the present and should be treated as metadata that cannot be trusted until verified against Packagist.

Technical risk. Moderate relative to the code's size, because the risk is concentrated in what the widget is allowed to do, not in how much code it adds. Cache-clearing is a privileged, potentially disruptive operation: a Stache rebuild on a large site is I/O- and CPU-intensive and can take tens of seconds, and a full application-cache flush under load invites a stampede against the origin datastore. Granting that capability to any CP user who can see a dashboard widget is a meaningful authorization decision that must be audited rather than assumed. Secondary risks are an unmaintained dependency (bus factor of one) and the absence of a visible test suite, version matrix, or CI signal.

Key questions.

1. Which caches are actually cleared — Stache, application cache, static/asset cache, Glide, views, config, routes? The blast radius differs by an order of magnitude between these.
2. Is the widget gated by Statamic permissions/super-user status, or merely by CP access? Can the gate be configured?
3. What Statamic major versions and Laravel/PHP combinations are declared in composer.json, and is there a compatibility matrix?
4. Does Statamic's own Utilities → Cache panel already cover this? If so, the addon is redundant and the correct decision is to decline it.
5. In a multi-node deployment, does clearing propagate? File-based Stache and file-based cache are per-node, so a CP request against node A may leave node B serving stale content.
6. Is the clear operation synchronous within the request? If the Stache rebuild exceeds the PHP/Gateway timeout the widget returns a 500 while the work continues or aborts mid-flight.
7. Is the license OSI-approved and does it permit an internal fork?

Integration Approach

Stack fit. The package presumes a Laravel + Statamic application on a supported PHP 8.x runtime. Because the widget renders inside the CP, it inherits Statamic's front-end stack (Vue components in v3/v4-era CP, Blade-rendered widget views), so there is no separate asset pipeline to reconcile — but that also means the widget must track Statamic's CP API across majors, which is precisely where single-maintainer addons decay.

Migration path. There is nothing to migrate. This is a purely additive, easily removed dependency: uninstalling is a composer remove plus deleting one config array entry. The realistic decision is therefore build vs. adopt, not migrate vs. stay. Given the narrow surface, an internal equivalent — a small custom widget class invoking the same artisan commands behind an explicit Gate::define('clear-caches') check — is on the order of a day's work and eliminates the third-party and provenance risk entirely. I would default to that unless the addon is confirmed to be first-party, maintained, and version-pinned.

Compatibility. Verify against Packagist rather than the repository listing: confirm the statamic/cms constraint, the illuminate/* constraint, and whether the widget registration API used matches the target Statamic major. Older Statamic 3 addons frequently fail silently on 4/5 because the widget contract or CP asset registration changed. Also confirm behavior under both file and redis cache stores, and under statamic.stache.watcher configurations.

Sequencing.

1. Resolve provenance: confirm the vendor/repo relationship and the Packagist record.
2. Check whether the built-in CP cache utility already satisfies the requirement; if yes, stop here.
3. Install in a disposable local environment and enumerate exactly which caches are affected, with timing measured against a production-sized content set.
4. Test on staging with a production-like cache driver and, if applicable, a multi-node topology.
5. Gate to super users only; enable in production behind that gate.
6. Add to the dependency-review list with a pinned version and a named owner.

Operational Impact

Maintenance. Code maintenance is near-zero; dependency maintenance is the actual cost. A single-release, zero-dependent package with an ambiguous publisher will not track Statamic majors on any schedule we can rely on. Pin the exact version, vendor it into the repository if policy allows (Composer path/vcs or a fork), and assign an owner who reviews it at each Statamic upgrade. Budget the fork as the expected end state, not the contingency.

Support. There is no vendor. Support is GitHub issues on a repository with no visible community, which in practice means self-support. Internal documentation should record which commands the widget runs so that an operator can reproduce the action manually during an incident.

Scaling. This is the weakest dimension. Statamic's Stache is file-based and node-local by default; a widget-triggered clear affects only the node that served the CP request. On a load-balanced deployment, operators will believe caches are cleared when they are not — a silent correctness problem that surfaces as stale content on a subset of requests. Either standardize on a shared cache store and a shared Stache strategy before enabling this, or restrict it to single-node environments. Separately, the clear itself is a load event: on a large site, a Stache rebuild triggered during peak traffic is a self-inflicted latency spike, so the widget's availability should be treated as a change-window tool rather than an everyday button.

Failure modes.

• Timeout / partial completion — Stache rebuild exceeds the request timeout; CP shows an error while state is indeterminate, prompting an operator to retry and compound the load.
• Cache stampede — full application-cache flush with a warm Redis under sustained traffic drives a thundering herd to the origin.
• Cross-node divergence — as above; stale reads persist on non-targeted nodes.
• Authorization gap — a non-privileged editor clears caches mid-session, invalidating config/route caches while queue workers hold references to the previous bootstrap.
• Worker desynchronization — clearing config cache while long-running queue workers are active leaves workers on stale configuration until restarted.
• Widget render failure — an unhandled exception in the widget class takes out the dashboard panel for all users, not just the operator.

Ramp-up. Effectively zero for the operator — a button on a dashboard. That simplicity is the risk: the action is irreversible, the feedback is coarse, and the user is not required to understand what a Stache rebuild costs. Mitigations are cheap and should be mandatory: restrict to super users, add a confirmation step, return per-cache results rather than a single success toast, and document the multi-node caveat.

Recommendation. Do not adopt as a standing dependency at this time. The capability is worth having; this implementation is not well-evidenced. Confirm first whether Statamic's built-in Utilities → Cache already covers the need — if it does, the correct action is to close the request. If it does not, build the widget in-house (~1 day) against the same artisan commands, behind an explicit permission gate, and avoid taking on an unattributed, unadopted, single-release package for a privileged operation.