Weave Code
Laravel Status Laravel Package
exolnet/laravel-status
Exolnet Laravel Status adds flexible, database-backed status management to Laravel Eloquent models. Define available statuses, assign them to records, and track changes through a simple trait, making it easy to model workflows and record state across your application.
The eXolnet Laravel Status package extends the base features available in Laravel.
Frequently asked questions about Laravel Status
- What does exolnet/laravel-status do?
- It adds database-backed status management to Laravel Eloquent models. You define the statuses a model can have, assign a status to each record, and track changes through a trait. That makes it useful for modelling simple workflows, approval states, and record lifecycle across your application.
- How do I install exolnet/laravel-status in a Laravel application?
- Install it with Composer using composer require exolnet/laravel-status. The package supports Laravel package auto-discovery, so the service provider is registered automatically. Publish any provided config or migration files, run your migrations, then add the supplied trait to the models that need status handling.
- Which Laravel versions does exolnet/laravel-status support?
- Version 2.14.0 dropped support for Laravel 11 and targets Laravel 12. Services still on Laravel 11 must stay pinned to the 2.13.x line. Check the package composer.json for the exact PHP minimum and transitive constraints before approving the upgrade, since the release notes do not spell them out.
- How do I define the available statuses for a model?
- Add the package trait to your Eloquent model and declare the statuses that model is allowed to use, following the configuration approach documented in the package README. The status value itself is persisted on the model record, so you can query and filter by it like any other column. Keep the status list explicit rather than free-form strings so invalid states cannot be written.
- How do I upgrade exolnet/laravel-status from 2.13.0 to 2.14.0?
- Treat it primarily as a Composer constraint change: 2.14.0 drops Laravel 11 and bumps dependencies. No application code changes are expected, but diff the published config and the composer.json between the two tags and review the lockfile diff in the pull request. Only move to 2.14.0 after the service itself is on Laravel 12.
- Can I use exolnet/laravel-status on a Laravel 11 service?
- Not version 2.14.0, which explicitly drops Laravel 11 support. Pin those services to ^2.13 deliberately and record it as accepted technical debt with a target upgrade date. Avoid a single fleet-wide constraint that would drag Laravel 11 services onto 2.14.0, and assume the 2.13.x line is effectively frozen.
- Is exolnet/laravel-status a health check or uptime monitoring package?
- No. Despite the name, it manages domain statuses on Eloquent records rather than exposing an application health endpoint. For infrastructure probes use Laravel's built-in /up route or a dedicated monitoring tool. Keeping those concerns separate avoids adding a third-party dependency where the framework already covers you.
- How do I test models that use the status trait?
- Use an in-memory or test database with RefreshDatabase and model factories, then assert the status column after assignment and after any transitions your workflow allows. Because statuses are stored in your own database, no external services need to be mocked. Add a test that rejects an undefined status so the allowed list stays enforced.
- What are the maintenance and production risks of this package?
- It comes from a small maintainer organisation with a low release cadence and no visible support policy, so bus factor is a real consideration. A framework major was dropped inside a minor release, which means consumers on older Laravel versions are stranded on a frozen branch. Acceptable for a small, well-isolated feature, but not something to build core business logic on without a fallback plan.
- What are alternatives to exolnet/laravel-status?
- For simple cases a native enum cast plus a status column on the model covers most needs with zero dependencies. If you need full audit history, dedicated activity log packages record changes with more detail. Compare against those before adopting, and confirm the package adds enough value to justify another dependency in your stack.
Weaver
How can I help you explore Laravel packages today?