- How do I install sbamtr/laravel-auto-hard-deleter?
- Install it with composer require sbamtr/laravel-auto-hard-deleter, add the package trait to any model that already uses SoftDeletes, and declare that model's retention window via the trait's property. Then register the package's console command in your scheduler so expired trashed rows get force deleted on a recurring basis. The integration itself is quick, but check the composer constraint first because the package has been archived since February 2022 and will likely conflict with modern illuminate/support versions.
- Which Laravel and PHP versions does this package support?
- The repository is archived and its last release was 2022-02-10, which predates Laravel 10, 11, and 12. Expect the composer.json constraint to cap out around Laravel 8, possibly 9. If a loose constraint lets it install on a newer framework, treat that as untested rather than supported, since Eloquent soft-delete internals have changed since then.
- How do I set the retention period for a model?
- Retention is declared per model through a property on the trait, so each soft-deletable model carries its own number of days to linger in the trash before being purged. That keeps the setting close to the model but also hard-codes a data-governance policy into a class, which is awkward for compliance review. There is no documented way to move the window into a config file or policy layer.
- Can I drive the retention window from config or environment variables?
- The package pattern is per-model configuration via the trait property, not an external config or env file. That means changing a retention period requires a code deploy rather than a config change or an environment variable flip. For teams where legal or compliance owns retention, this is a real limitation and a common reason to prefer a first-party solution.
- Does the purge command chunk expired records or load them all into memory?
- This is not documented in the README, so you must read the command source to confirm. If it loads the full expired result set at once, large trash tables will spike memory and may time out under the scheduler. Before trusting it in production, verify chunking behavior yourself or add an explicit index on deleted_at per table.
- Does it fire model events and observers when force deleting?
- It depends on whether the command calls forceDelete() on each model instance or issues a mass query delete. Per-instance forceDelete() fires model events and observers but costs N queries, while a mass delete is fast and silently bypasses observers, media cleanup, and downstream cascade logic. Confirm which approach the command uses before relying on observers for cleanup.
- Is there a dry-run or reporting mode to preview what will be purged?
- No dry-run, report-only, or logging mode is documented. That is a significant gap for a destructive operation, because you cannot preview which rows will be permanently removed before the scheduler runs. If you adopt the pattern rather than the package, add a --dry-run flag and structured logging to your own command.
- Is the package still maintained and safe for production use?
- No. The repository is archived and read-only with no security response path, and dependency scanners will flag it as abandoned in supply-chain review. It has zero dependents and 47 stars, so there is no ecosystem validation, no bug reports, and no evidence of production use at scale. Auto-purge is irreversible, so shipping it via an unmaintained dependency inverts the usual risk calculus.
- Does it handle custom deleted_at column names, global scopes, or multi-tenant setups?
- There is no documented support for non-standard deleted_at column names, global scopes, or multi-tenant scoping. Any of those could cause the purge to miss rows or, worse, delete rows outside the intended tenant. Test explicitly against your schema before enabling the scheduler entry, and prefer a solution you control if you rely on scopes.
- What is the best alternative if I need soft-delete auto-purge on Laravel 10, 11, or 12?
- Adopt the pattern instead of the package: a first-party artisan command taking --model, --days, --dry-run, --chunk, and --limit, plus a config/retention.php mapping each soft-deletable model to a window sourced from env. Schedule it with withoutOverlapping() and a bounded runtime, chunk the deletes, and add an index on deleted_at. That is roughly 100 to 150 lines of code, removes the supply-chain finding, and puts retention under configuration review where auditors expect it.