Statamic Widget Cache Controller Laravel Package

Getting Started

Install the addon and let Statamic's addon discovery pick it up:

composer require webographen/statamic-widget-cache-controller

Statamic auto-registers addon service providers, so there is usually no manual provider entry. If the package ships publishable config or views, check what is available before assuming defaults:

php artisan vendor:publish --provider="Webographen\...\ServiceProvider"

The exact provider namespace is in the package's composer.json under extra.laravel.providers; verify it there rather than guessing.

Next, register the widget on the control panel dashboard in config/statamic/cp.php:

'widgets' => [
    [
        'type' => 'cache_controller', // confirm handle in the addon's widget class / README
        'width' => 50,
    ],
],

Then clear config caches and log into /cp:

php artisan config:clear

Where to look first

1. vendor/webographen/statamic-widget-cache-controller/src/ — identify the ServiceProvider, the widget class (extends Statamic\Widgets\Widget), and any controller/route registration.
2. routes/ or src/Http/Controllers/ — confirm what the buttons actually call and which middleware protects the endpoint.
3. The widget's Blade view — confirm which cache operations are exposed and what labels editors will see.

First use case

Give content editors a dashboard button to clear Statamic's static cache after publishing, instead of asking a developer to SSH in and run php please static:clear. Treat that as the primary value: a safe, permissioned shortcut for non-technical users. Developers should still keep CLI/deploy-based cache clearing as the source of truth.

Implementation Patterns

Dashboard shortcut for editors, CLI for deploys

Use the widget for ad-hoc, human-initiated clearing (publish corrections, emergency content updates). Keep deterministic cache clearing in your deployment pipeline:

php please stache:clear
php please static:clear
php please glide:clear
php artisan cache:clear

The widget should complement those commands, not replace them. If editors frequently need it, that usually signals your publish-time invalidation is incomplete.

Pair with static caching

If you use Statamic's static caching, the widget is most useful as a "clear static cache" button. Configure static caching normally and use the widget for the cases where a content change does not trigger a full invalidation (imports, external data, template-only changes). Verify whether the widget clears static cache, Stache, Laravel cache, Glide, or all of them — do not assume "clear cache" means everything.

Gate by role or permission

The dashboard config is global, so every CP user who can see the dashboard may see the widget. If the addon's controller does not enforce a permission, wrap or extend the widget's html() method:

public function html()
{
    $user = Statamic::user();

    if (! $user || ! $user->can('clear cache')) {
        return '';
    }

    return parent::html();
}

Alternatively, register the widget conditionally in a custom dashboard configuration or replace it with a small custom widget. Confirm the route itself has web, auth, and Statamic CP middleware — hiding the UI is not authorization.

Custom, scoped actions

If the package exposes only broad "clear everything" buttons, extend the widget or add your own route that calls the specific command you need:

use Illuminate\Support\Facades\Artisan;

Route::post('/cp/cache/static', function () {
    Artisan::call('static:clear');

    return back();
})->middleware(['web', 'statamic.cp']);

Prefer this over clearing Stache unnecessarily; Stache clears trigger rebuilds and slow the next requests.

Multi-site awareness

Determine whether the action clears all sites or only the current one. On multi-site installs, clearing all static caches can be expensive; if the package does not support per-site clearing, add a custom action or document that the button is global.

Local development workflow

Use the widget as a convenience while developing templates and content, especially when you cannot easily run CLI commands (containers, remote environments). After installing or upgrading the addon, clear config and Statamic's caches so discovery and widget registration refresh.

Gotchas and Tips

Audit before relying on it. Zero stars, zero dependents, and a very low opportunity score mean little community validation. Read the service provider, widget, controller, and routes before installing in production. Pin the version in composer.json and check compatibility with your Statamic major.

Authorization is the main risk. A cache-clearing endpoint is a denial-of-service vector if exposed to any authenticated CP user or, worse, unauthenticated requests. Confirm middleware and add permission checks if absent.

Require POST and CSRF. If the widget triggers cache clearing via GET links, browser prefetching or crawlers can clear caches unexpectedly. If the package uses GET, fork the view or wrap the action in a POST form with @csrf.

Understand the scope. "Clear cache" is ambiguous in Statamic: Stache, static HTML, Laravel application cache, Glide images, response cache, and CDN/edge cache are different layers. The widget will not purge Cloudflare, Fastly, or your reverse proxy. Document exactly what each button does for editors.

Cache clearing is not free. Stache clears force a rebuild on the next request; static clears can be slow on large sites; Glide clears can remove generated images that must be regenerated. Do not wire the widget into entry.saved listeners or other high-frequency events.

Laravel cache clear does not fix everything. Clearing the application cache does not restart queue workers, reset Octane workers, or clear OPcache. For deployment, still run php artisan queue:restart and reload PHP-FPM/Octane as appropriate.

Config and discovery caching. After install or upgrade, run php artisan config:clear and, if needed, php please stache:clear. Statamic caches addon manifests; a missing widget is often a cached manifest rather than a broken package.

Extension points to check. Look for publishable views (vendor:publish), a config file controlling which cache types appear, and whether the widget class is easy to extend. If the view is publishable, you can relabel buttons ("Clear static cache" vs "Clear application cache") without forking the package.

Have an exit plan. Given the low adoption, the pragmatic fallback is a ~50-line custom widget that renders POST forms to a small controller calling Artisan::call('static:clear') and Artisan::call('stache:clear'). That gives you the same day-to-day editor experience with full control over authorization, scope, and maintenance. Use this package only if its code is simple enough that you would be comfortable owning it.