- What is konnco/filament-safely-delete and what does it do?
- It is a Filament panel plugin that adds safe-delete friction to destructive admin actions, typically by swapping or augmenting Filament's default DeleteAction with a guarded variant. It is presentation-layer tooling meant to reduce accidental deletions by prompting or requiring confirmation before the action runs. It does not change Eloquent models, migrations, or authorization policies, and it is not a recoverability or audit control.
- How do I install konnco/filament-safely-delete in a Laravel Filament app?
- Install it with composer require konnco/filament-safely-delete, register the plugin in the relevant Filament PanelProvider, and replace the stock delete action on the resources that need protection. The integration is small enough that a Filament-fluent engineer can complete a proof of concept in under a day. The real feasibility check is version alignment with your Filament major, not installation effort.
- Does konnco/filament-safely-delete support Filament 3?
- Assume it does not support Filament 3 until you prove otherwise. The package was last tagged on 2023-02-24, which predates Filament 3's general availability, and Filament's action API changed materially between v2 and v3. On a Filament 3 codebase, expect a port, fork, or reimplementation rather than drop-in adoption.
- Which Laravel and PHP versions are compatible with konnco/filament-safely-delete?
- The best-fit stack described is Laravel 9 or 10, Filament 2.x, and PHP 8.1 or newer. You should still inspect the package's composer.json constraints against your target application before adopting it. If your panel is on Filament 3.x, treat compatibility as unresolved and plan for a port if you want the same behavior.
- How do I configure the safe delete action in a Filament resource?
- Configuration is intentionally minimal: register the plugin and substitute the guarded delete action on the Filament resources where you want confirmation friction. The package is presentation-only, so there are no schema changes or domain-service changes to wire up. Check the README and source for the exact action class or configuration keys before rolling it across many resources.
- Does it protect bulk delete actions and relation manager deletes?
- This must be verified against the actual package behavior before you rely on it. The TPM assessment flags coverage of bulk delete, relation-manager deletes, and global or table actions as an open question, with the likely baseline being row-level delete protection. If those surfaces matter, test them explicitly or add equivalent guards in your own action definitions.
- Is konnco/filament-safely-delete a replacement for soft deletes and audit logging?
- No. It provides accidental-deletion friction in the admin UI, not recoverability, immutable deletion trails, or policy enforcement. Pair it with soft deletes, audit logging, and authorization policies for any deletion operation that matters. Do not present it to auditors or leadership as a data-retention or compliance control.
- Is konnco/filament-safely-delete maintained and safe for production?
- Treat it as unmaintained: the last release was 2023-02-24, it has roughly 34 stars and zero dependents, and there is no visible downstream validation. That does not make it dangerous, because the code surface is small and reversible, but it does mean you own the risk. A time-boxed trial or an internal fork is safer than assuming upstream support.
- Can I fork or reimplement konnco/filament-safely-delete if it is abandoned?
- Yes. The package is MIT-licensed and small enough that forking the source into an internal namespace is cheap, and removal is equally cheap because adoption is just a plugin registration plus per-resource action substitution. The reimplementation alternative is a custom DeleteAction with confirmation behavior plus any server-side authorization or halt logic you require. Prefer the fork or custom action over waiting on upstream if you need Filament 3 support.
- Does the safe delete confirmation run server-side or is it only a UI countdown?
- You need to confirm this in the source before treating it as a real control. If the guard is a Livewire or JavaScript countdown, it prevents misclicks but not automation or intent; it is cosmetic friction rather than enforcement. For a stronger control, combine the UI confirmation with server-side authorization or action halt logic in your Filament resource.