Weave Code
Laravel Manageable Laravel Package
signifly/laravel-manageable
Laravel Manageable lets you make any Eloquent model manageable with a single trait, adding admin-friendly CRUD, publish states, and sorting. It keeps management logic reusable and controllers lean, so building back-office screens takes minutes instead of hours.
Track users who manages models in your Laravel app
Frequently asked questions about Laravel Manageable
- What does signifly/laravel-manageable actually do?
- Laravel Manageable lets you make any Eloquent model manageable with a single trait, recording which user created, updated or deleted a record and exposing that attribution back through a polymorphic relationship. The tracking data lives in a side table, so your domain schema stays free of created_by and updated_by columns. It is a narrow cross-cutting audit-attribution concern rather than a full back-office framework.
- How do I install and set up laravel-manageable?
- Installation is mechanically trivial: composer require signifly/laravel-manageable, publish the package migration with php artisan vendor:publish, run php artisan migrate, then add the trait to each model you want tracked. Expect a few hours for a spike rather than days of integration work. Enable it on one low-risk model first as a canary before rolling it out.
- Does laravel-manageable support Laravel 11 and Laravel 12?
- The last release was 2023-11-21 and the package was tested against Laravel 8-10 on PHP 8.0-8.2. There is no guarantee of Laravel 11 or 12 support, and no stated support for PHP 8.3 or 8.4. Check the version constraint in composer.json and run the test suite against your target Laravel and PHP pair before assuming compatibility.
- Is signifly/laravel-manageable still maintained?
- No. The repository is archived, the last release was November 2023, and there is no issue triage or security response path. With roughly 40 stars, real-world validation is thin, so you will be reading the source rather than relying on documentation. Treat it as unmaintained source you own, not as a live dependency.
- How is laravel-manageable different from spatie/laravel-activitylog or owen-it/laravel-auditing?
- Its only real differentiator is keeping attribution in a separate table so domain schemas stay clean, which is a modest ergonomic gain. spatie/laravel-activitylog covers the same ground with richer configuration, active maintenance and a much wider support corpus, while owen-it/laravel-auditing is stronger if you need old and new value diffs. Laravel's native model events plus created_by and updated_by columns remain the zero-dependency option.
- What happens if the tracking insert fails during a model save?
- Attribution is written from model event listeners, so it runs synchronously inside the same request and likely the same transaction as the domain write. A tracking-table failure can therefore surface as a failed save, or the domain write can drag the tracking row down with it. Read the listeners and confirm the failure semantics before enabling this on critical write paths.
- Does it track attribution in queue jobs, console commands and unauthenticated requests?
- This is an open question the review flags for a source-code spike: the behaviour may be null attribution, a skipped write, or an exception. Queue workers and artisan commands typically run without an authenticated user, so expect null or missing attribution unless you explicitly set the actor. Verify each context before relying on the data being complete.
- Does it capture soft deletes, force deletes and bulk updates?
- Soft deletes and force deletes need to be verified against the event listeners, since the review lists both as open questions. Bulk operations such as query()->update(), Model::where(...)->delete() and DB::table() writes bypass model events entirely and are generally not captured. If bulk changes matter, you need a separate audit strategy.
- Is laravel-manageable safe for production and high-write tables?
- Every managed write adds one row to a tracking table with no documented pruning, so high-write tables grow unbounded unless you add an index strategy and a retention job first. Persisting an indefinite user-to-record attribution index is personal data under GDPR, which attaches erasure and retention obligations. Also confirm exactly what is stored: actor and action alone is not compliance-grade audit if you need old and new values, IP or user agent.
- Should I fork laravel-manageable into my app or replace it with another package?
- Replacing it with an actively maintained equivalent such as spatie/laravel-activitylog is the preferred route, at the cost of a small adapter if your code references the Manageable API. Forking it in-tree, lifting the trait and migration into app/Support/ at roughly 150 lines, preserves existing call sites and the existing table without a data migration. Pinning the archived package as-is is not recommended, because the upgrade debt surfaces silently at the next Laravel major.
Weaver
How can I help you explore Laravel packages today?