Filament Page Cache Laravel Package

Getting Started

PageCachePlugin is a Filament panel plugin that exposes a "Page cache" admin page (list cached URLs, clear individual entries or the whole cache) inside your panel. Start here:

1. Install and register the plugin in the panel provider that should own the cache UI — usually your admin panel, not a public-facing one:

   public function panel(Panel $panel): Panel
   {
       return $panel
           ->id('admin')
           // ...
           ->plugin(PageCachePlugin::make());
   }
   

2. Look first at the plugin class and the Page class, not the package README. PageCachePlugin is where panel-facing configuration lives (including the new navigationGroup()), and the Page class is a normal Filament Page — it is the thing you extend when you need different behaviour. The plugin registers the page, so most "how do I change X" questions resolve to either a plugin setter or a subclassed page.

3. Check the config file and cache driver early. The page is only a UI over Laravel's cache/response-cache layer; confirm which store is in use per environment before you start clicking buttons, because cache:clear in local will not tell you anything about production behaviour.

4. First use case: open the panel, find the "Page cache" entry, load a public page in another tab, and confirm it appears/clears from that screen. That two-minute loop validates the whole chain (route middleware, cache store, panel authorization) before you wire anything into deploys.

As of 3.1.0 the entry no longer has to live in the package's translated "Settings" group — you can place it in one of your own groups with navigationGroup(), which is the first thing most teams will want to change on a fresh install.

Implementation Patterns

Place the page in an existing navigation group. This is the headline of 3.1.0 and matches how most panels are already organised:

PageCachePlugin::make()
    ->navigationGroup('Operations');

Pass a closure when the label is translated, so the translation is resolved at render time rather than at panel boot:

PageCachePlugin::make()
    ->navigationGroup(fn (): string => __('admin.navigation.settings'));

Reuse your app's existing translation keys. If your resources already use __('admin.navigation.settings'), use the same key here rather than a new one — Filament groups navigation by the resolved label string, so reusing the key is what actually merges the page into that group instead of creating a near-duplicate group beside it.

Multi-panel setups. Register the plugin only in panels where the cache UI belongs. If you have a admin and a ops panel that share navigation structure, either register it in both (accepting two entry points) or register once and gate access with canAccess()/policy rather than duplicating the page.

Feature-flag by environment or role. Wrapping registration keeps the page out of local/staging where it invites accidental cache clears:

->plugin(
    PageCachePlugin::make()
        ->navigationGroup(fn (): string => __('admin.navigation.settings'))
)

…combined with the panel's ->when() or a config flag, and a policy on the page so only trusted roles can hit the clear-all action.

Prefer the UI for one-off invalidation, automate the routine case. Day-to-day, developers use the page to clear a single stale URL after a content fix; deployments and content publishes should clear programmatically (observer/saved hook, or a deploy step). Don't make "someone opens the admin and clicks clear" part of a release process.

Treat the page as a starting point, not a fixture. When you need extra columns, filters, or an audit trail of who cleared what, subclass the package Page and register your subclass — that is the intended extension path and survives minor upgrades better than patching the vendor view.

Gotchas and Tips

• String vs closure is not cosmetic. A plain string is resolved when the panel boots; a closure is resolved when navigation is rendered. If you support per-user locales, a locale switcher, or setLocale() in middleware, use the closure. A string will freeze the label in whatever locale was active during boot and can silently split your navigation group in two.
• The group label must match exactly. Filament matches groups by the resolved string. __('admin.navigation.settings') in one place and 'Settings' in another produces two groups that look identical in English but diverge in other locales. Grep your resources for the key you intend to use before picking one.
• The default changed scope, not default behaviour. If you don't call navigationGroup(), the page still lands in the package's translated Settings group — existing installs see no difference after upgrading to 3.1.0. This release is additive; no migration or config publish is required.
• Verify sorting and icons alongside the group. Moving the page into your own group often exposes ordering issues (navigationSort, navigationLabel, icon collisions) that weren't visible in the package's isolated group. Check the sidebar in a non-English locale too.
• Cache scope surprises are the real debugging cost. Pages cached while unauthenticated can be served to logged-in users if your response-cache keys don't vary correctly; conversely, per-user caching bloats the store. When something "randomly" shows old content, check the cache key/vary rules before blaming the plugin.
• Clearing the wrong thing. The page's clear-all is a cache clear for the configured store — confirm the store is scoped (separate Redis DB/prefix, dedicated file path) so a clear doesn't take out sessions or queues sharing the same backend.
• Deploy checklist item. After a release that changes views or translations, clear the response cache as part of the deploy; otherwise the first thing users see is the previous layout. Note this in the deploy script rather than relying on the admin page.
• Upgrade hygiene for a plugin this small. Pin the version, read each changelog (3.1.0 is a one-method addition), and keep customisations in a subclass or your own panel provider — that keeps minor bumps to a composer update with no code archaeology.