- What does the filament-expiration-notice package do?
- It replaces Livewire's default 'Page expired' 419 dialog with a Filament-styled modal so session-timeout recovery matches the rest of your admin panel. It is a presentation-layer override only and does not touch models, migrations, routes, or persistence. It is intended for Laravel applications that already use Livewire and Filament.
- How do I install filament-expiration-notice in a Laravel Filament app?
- Install it with composer require marcelweidum/filament-expiration-notice, then register it as a Filament plugin on the panel provider where you want the styled modal, or rely on Laravel package auto-discovery if you want a global effect. There are no migrations or data backfills, and publishing views or config is only needed when you want to override defaults. Verify the exact registration snippet against the package README for your Filament major version.
- Which Filament and Livewire versions are supported?
- The provided materials do not specify a definitive supported version matrix, so check the package composer.json and tagged releases before adopting it. Filament plugin contracts and Livewire's page-expired hook have changed across Filament v2, v3, and v4, so version compatibility is the main integration gate. Pin the package version against your exact Filament and Livewire versions and record that triplet in your dependency log.
- Is it a Filament panel plugin or a global service provider?
- The expected integration is either registering it as a Filament plugin on specific panels or relying on Laravel auto-discovery for a global effect. The evaluation flags this as something to confirm in the README rather than assume. Per-panel registration is preferable when you only want the notice on selected admin panels.
- Does it support Filament multi-panel installs and SPA mode?
- Per-panel opt-in should be possible if the package is registered as a Filament plugin, but the provided evaluation lists multi-panel and SPA-mode support as open questions. Confirm both against the package documentation before rolling it out across several panels. Test the expiration flow under Filament SPA navigation if you use that mode.
- Can I customize the modal's recovery action, such as reloading or redirecting to login?
- The available materials do not confirm configurable recovery actions like full reload, login redirect, or preserved form state. Treat those behaviors as items to verify in the package config and README before relying on them. If the defaults do not fit, publishing and overriding the package view is the likely customization path.
- Does it handle only 419 page-expired errors, or also 401 and Livewire offline states?
- The package is scoped to Livewire's 'Page expired' 419 session-timeout dialog, not general authentication expiry or Livewire's offline state. Do not assume it covers 401 responses, token revocation, or network-loss UI unless the documentation explicitly says so. Keep separate handling for those cases.
- Is replacing Livewire's page-expired view safe in production?
- Risk is low because the package is a narrow view override, but it depends on an internal Livewire behavior that is not a formal public API, so a Livewire minor release could change the mount point. Add the expiration flow to your Filament and Livewire upgrade smoke tests. Also verify what happens if the Blade view fails to resolve, since a graceful fallback is not confirmed.
- How do I test the expiration modal without waiting for a real session timeout?
- Set a deliberately short SESSION_LIFETIME in a staging environment and trigger a 419 by submitting a Livewire request after the session lapses. Confirm the Filament-styled modal appears and that the recovery action works as expected. Rollback is simple: remove the plugin registration or the Composer dependency.
- Is filament-expiration-notice actively maintained, and should I worry about frequent expiration notices?
- Maintenance posture is unclear from the provided materials; check the actual tag list, release cadence, and open-issue response because a listed last-release date should be verified. Separately, frequent expiration modals usually signal session misconfiguration such as file sessions behind a load balancer, a short SESSION_LIFETIME, or aggressive CSRF token rotation. Fix the root cause rather than relying on the styled modal to make it tolerable.