- How do I install filament-autosave in a Laravel Filament app?
- Install it with composer require yousefaman/filament-autosave, then register AutosavePlugin::make() in your panel provider. Optionally publish the config, translations, and indicator view. If you copy Filament assets into public for production, re-run php artisan filament:assets so the autosave indicator assets are included.
- Does filament-autosave support Laravel 11?
- The package itself does not constrain Laravel; Filament accepts Laravel 11.28+, 12, and 13. However, CI only covers Laravel 12 and 13, and Composer 2.9+ refuses Laravel 11 installs because the 11.x line is past security support. Verify your Laravel version before treating the package as installable.
- What is the difference between Edit page autosave and Create page drafts?
- On Edit pages, changes are written directly to the database after a debounce. On Create and custom pages, unsubmitted work is stored as a draft in Laravel Cache and users can Restore or Discard it when they return. These are different persistence semantics with different risk profiles.
- Does autosave validate the form before writing to the database?
- The README and provided context do not document whether Edit-page autosaves are gated on full form validation, field-level validation, or per-write policy checks. That is flagged as an open technical question. Do not assume invalid or partial state is blocked until you verify it in your application.
- How does filament-autosave handle two users editing the same record?
- The README does not describe conflict handling for concurrent editors. The technical assessment flags lost updates as a high data-integrity risk unless versioning or locking is implemented. Treat the default behavior as potentially last-write-wins and test concurrent edits before production use.
- Where are drafts stored, and can I use a dedicated cache store?
- Create and custom page drafts are stored in Laravel Cache. The assessment recommends explicitly mitigating cache risk with a dedicated cache store, a TTL policy, and key namespacing per tenant or user, but the README excerpt does not specify these details. Cache eviction, deploy-time cache clears, or memory pressure can silently destroy unsubmitted user work.
- Is autosave global once the plugin is registered, or can I enable it per resource?
- The documented setup registers the plugin on the panel, while the assessment mentions applying a trait to specific pages as an integration option. The README excerpt does not fully document whether autosave is opt-in per resource, per form, or per field. Review the config and trait usage to confirm granular control before rolling it out broadly.
- What does one-step Undo actually revert, and does it survive a page reload?
- Undo is described at the form level for Edit pages, but its exact scope is unspecified: it may revert a single field or an entire record snapshot. The context also questions whether Undo is held in browser memory or reconstructed server-side and whether it survives reloads. Test these behaviors directly before relying on Undo for recovery.
- Will autosave trigger model observers, events, notifications, or webhooks on every debounce?
- If Edit-page autosave writes model updates, it may fire the same observers, events, notifications, webhooks, and search indexing as a normal save on each debounce tick. The README does not document an event-suppression path. Audit your model side effects and add suppression where needed before enabling autosave on sensitive resources.
- Is filament-autosave production-ready, and what are the maintenance risks?
- The package currently has 3 stars, 0 dependents, and a single maintainer, with no downstream evidence of production use cited. The assessment rates maturity risk as high and also flags data integrity, Undo semantics, cache durability, and Filament/Livewire upgrade coupling risks. Pilot it on a limited resource, pin versions, and test the debounce, draft, and undo paths before wider adoption.