Weave Code
Laravel Model Expires Laravel Package
maize-tech/laravel-model-expires
A Laravel package that gives Eloquent models expiration dates. Add the trait, set an expiry, and use scopes to query active or expired records. Includes commands to prune expired models automatically, keeping your database clean and your data fresh.
Laravel Model Expires
Frequently asked questions about Laravel Model Expires
- How do I install laravel-model-expires in a Laravel application?
- Install it with composer require maize-tech/laravel-model-expires. Then publish or write a migration that adds a nullable expires_at timestamp column to the tables you want to expire, and apply the package trait to the corresponding Eloquent models. There are no external services, credentials, or infrastructure prerequisites, so the install itself is low friction. The real work is deciding which models should expire and what expiry should mean for your domain.
- How do I make an Eloquent model expire with this package?
- Add the package trait to the model and give its table a nullable expires_at column. From then on you set the expiry by assigning a date to that attribute and saving the model, and the package uses it to decide whether the record is active or expired. Apply it to one low-risk model first, such as invitations, trial records, OTP tokens, or draft listings, before rolling it out more widely.
- How do I query only active records, or only expired ones?
- The package provides query scopes for selecting active and expired records, so you can ask for exactly the set you need instead of filtering manually. Because the default read path is also scoped, most of your normal queries return active records automatically. Use the expired scope explicitly for reporting, cleanup jobs, or admin screens that need to see what has lapsed.
- Does laravel-model-expires apply a global scope that hides expired models?
- Yes. Expiry is implemented with a globally applied scope, a pattern conceptually similar to soft deletes but based on time rather than a deleted_at flag. That means expired records silently drop out of ordinary Eloquent queries, which is convenient but can surprise reporting queries, admin panels, and exports. Audit your read paths before enabling it broadly, and remember that raw queries and the DB facade bypass the scope entirely.
- How do I include expired records in a query when I need them?
- Use the package's own scope for expired records, or Laravel's standard withoutGlobalScope escape hatch to bypass the global constraint on a specific query. This is the key thing to document for your team, because any developer who does not know the scope exists will be confused by missing rows. Keep the escape hatch usage visible and intentional rather than scattering it through the codebase.
- How do I automatically delete expired models and keep the database clean?
- The package ships an Artisan command intended for purging expired records, which you register in the Laravel scheduler to run on whatever cadence suits your data. Introduce it only after the read path has been validated with the global scope active, since the purge is irreversible in most configurations. Before relying on it in production, confirm in the source whether the command deletes in chunks, whether it fires model events, and whether it hard deletes or respects soft deletes.
- Is a NULL expires_at treated as never expiring, and should the column be indexed?
- Treating NULL as never expiring is the safe rollout default, because it makes adding the trait a no-op until you actually populate dates. Add the nullable expires_at column with an index, since both the global scope and the purge command filter on it and will scan the table otherwise. Backfill deliberately: decide per table whether legacy rows should stay NULL or receive a computed date.
- Which Laravel and PHP versions does laravel-model-expires support?
- Release 1.2.0 added Laravel 12 and 13 support via a community pull request, and the package follows the conventional Laravel package structure with a trait and an Artisan command. The release notes do not state the supported PHP range, so check composer.json for the exact laravel/framework and php constraints before upgrading. If you are targeting Laravel 13, also confirm whether that constraint points at a stable major or a pre-release branch.
- Can I use laravel-model-expires alongside Laravel's SoftDeletes?
- They are independent mechanisms: SoftDeletes uses deleted_at, while this package adds a global scope driven by expires_at, so combining them means two overlapping global scopes on the same model. The interaction between the two, plus model observers and queued jobs that serialise models, is not verified for this package. If you need both, test the query behaviour and the purge command's delete semantics carefully in a staging environment first.
- How should I handle timezones for the expiry column, and is the package abandoned-risk safe?
- Store expiry values in UTC and normalise at the application boundary, since the package does not document whether comparisons are UTC-normalised or depend on the app timezone, so verify that before relying on precise cutoffs. On maintenance: change velocity is low, the 1.2.0 release was mostly CI dependency bumps plus one first-time contributor's framework support PR, and there is no stated support SLA. The mitigation is cheap, because the core behaviour is small enough to fork or reimplement internally in about a day if the package is ever abandoned.
Weaver
How can I help you explore Laravel packages today?