Filament Page Cache Laravel Package

Product Decisions This Supports

• Admin UX consistency in multi-panel Filament apps. The new navigationGroup() option lets the Page cache screen live under your panel's own navigation group instead of the package's translated "Settings" default. If your admin IA is organized around domains (e.g. "Content", "Operations", "Platform"), you can now keep cache management where operators expect it rather than creating a one-off group or accepting the vendor default.
• Localization and multi-locale back offices. Accepting a closure (fn (): string => __('admin.navigation.settings')) means the group label resolves at render time through your translation files. For products shipping in more than one admin language, this removes the need to fork the package view or patch a vendor string — a small but real reduction in maintenance surface.
• Build vs. buy for cache tooling. This is a narrow, well-scoped capability (a Filament page wrapping an existing page-cache implementation plus a configurable nav entry). If your roadmap already includes an operational admin surface, adopting this avoids writing and maintaining a bespoke cache-management screen; if you need cache warming strategies, per-URL invalidation policies, or CDN purge orchestration, this package is unlikely to be the whole answer.
• Roadmap signal, not a roadmap item. A release this small is primarily evidence of maintenance health: the maintainers respond to admin-ergonomics and i18n requests. That is worth weighting when deciding whether to depend on it for a long-lived product versus a throwaway internal tool.

When to Consider This Package

Consider it when:

• You run Filament as your admin layer and already use (or plan to use) a Laravel page-cache package — this plugin is the admin surface, not the caching engine.
• Your panel has a defined navigation taxonomy and you do not want vendor-owned groups leaking into your IA. The navigationGroup() option is the deciding feature for teams that treat the admin nav as a product surface.
• You ship a localized admin. The closure form is the correct pattern; if the package had only accepted a string, translated group names would have required workarounds.
• You want low-ceremony operational visibility — a cache page your support or ops staff can open without SSH access.

Look elsewhere when:

• You need programmatic cache control in application code; use the underlying cache package directly and skip the admin page.
• You need cache invalidation tied to content events, tag-based purging across drivers, or multi-server coordination — verify driver support explicitly before assuming.
• You are not on Filament, or you are on a Filament major version the plugin has not declared support for. This release does not signal anything about version compatibility, so confirm constraints rather than assuming.
• Your admin nav is generated entirely from config and you would rather not grant a vendor package a slot in it — though navigationGroup() substantially weakens that objection.

How to Pitch It (Stakeholders)

To executives: A small, low-risk upgrade to a package we use for page-cache administration. The change lets us place the cache screen in our own admin menu section and translate its label like the rest of the back office, instead of accepting a hard-coded vendor group name. No breaking changes, no migration work, no new dependencies — an upgrade-and-configure task, not a project.

To engineering: PageCachePlugin::make()->navigationGroup(fn (): string => __('admin.navigation.settings')) — accepts a string or a closure, closure is evaluated for translation, falls back to the existing translated "Settings" group when unset. Purely additive and backward compatible. Recommend adopting the closure form for any panel that already routes nav labels through translation files, and standardizing on our own navigation group constant rather than a literal. The main diligence item is unchanged: confirm the plugin's Filament version constraint still matches ours before bumping.