Weave Code
Laravel Model Auditlog Laravel Package
orisintel/laravel-model-auditlog
Laravel Model AuditLog automatically tracks model create, update, and delete events, recording who made each change and the before/after values. Simple to install and configure, it gives you a clear, queryable audit trail for Eloquent models.
Tracks changes made to models and logs their column values to individual tables
Frequently asked questions about Laravel Model Auditlog
- How do I install orisintel/laravel-model-auditlog in a Laravel app?
- Require the package with Composer and let Laravel's package auto-discovery register its service provider. Publish the package config if you need to change the defaults, then enable auditing on the Eloquent models you want tracked. Run the package migrations before you start logging so the audit tables exist.
- Does Laravel Model AuditLog support PHP 8 and Laravel 10 or 11?
- Version 4.1.0 added PHP 8 support, and PHP 8.0+ is a hard prerequisite for Laravel 9, 10, and 11, so the package can follow a modern upgrade path. The exact illuminate/support constraint lives in the composer.json published on Packagist, so check it against the Laravel version you run. If you are still on PHP 7.4 and Laravel 8, pin the last 7.x-compatible release until your runtime is upgraded.
- Does it store logs in separate tables per model?
- Yes. The package logs column values to individual tables rather than one shared activity table, which keeps each audited model's history isolated and straightforward to query. The trade-off is schema growth: every audited model gets its own log table, so high-write models produce proportionally more rows. Plan retention or archival for those tables early.
- How do I configure which events and columns are audited?
- Auditing covers the create, update, and delete events, and each entry records who made the change along with the before and after column values. Configuration lives in the package config file that you publish into your application. Review that file for the options that control which events and columns are captured per model.
- Does it log deletes and who deleted the record?
- Yes, delete events are tracked alongside creates and updates. The entry records who performed the delete and the column values as they stood at the time. Because the values are copied into the audit table, the history survives after the original row is gone.
- How do I query the audit trail for a model?
- Since each model's history sits in its own table, you can read it with the query builder or an Eloquent model like any other data. Filter by the audited record's identifier to rebuild that record's timeline, or by the user column to see everything one person changed. Order by the log timestamp to replay the changes in sequence.
- How does it compare to spatie/laravel-activitylog?
- spatie/laravel-activitylog writes everything into a single activity table with a JSON property diff, which is more compact when you need to search across all models at once. This package deliberately writes to per-model tables, which suits per-model reporting and retention but spreads data across the schema. Choose based on whether you want one unified log or per-model isolation.
- What is the performance impact in production?
- Every audited write becomes an additional insert, so high-throughput tables will see extra write load and faster database growth. Keep the audited column set tight and put a retention or archival policy on the log tables. Also confirm your CI matrix covers the PHP minor you actually deploy, since v4.1.0 was a PHP 8 compatibility release.
- How do I test that model audit logging works?
- In a feature test, perform the model action and then assert the expected row exists in that model's audit table. Use RefreshDatabase or transactions so log rows do not leak between tests. Assert the recorded user and the before/after values too, since those are the parts most likely to regress.
- Is upgrading to 4.1.0 safe, or is it a breaking change?
- 4.1.0 is a minor bump whose stated change is PHP 8 support, which by convention implies an additive, non-breaking release. The real risk is the php constraint: if the floor moved from ^7.4|^8.0 to ^8.0, consumers on PHP 7.4 are effectively broken on a minor version. Diff composer.json between 4.0.x and 4.1.0 and run composer update --dry-run in a scratch branch before committing.
Weaver
How can I help you explore Laravel packages today?