Weave Code
Laravel Model Auditlog Laravel Package
always-open/laravel-model-auditlog
Laravel Model AuditLog automatically tracks changes to your Eloquent models, recording creates, updates, and deletes with the data needed for a clear audit trail. Add lightweight, configurable history to models without cluttering your app logic.
Tracks changes made to models and logs their column values to individual tables
Frequently asked questions about Laravel Model Auditlog
- How do I install always-open/laravel-model-auditlog in a Laravel app?
- Install it with Composer using composer require always-open/laravel-model-auditlog, then publish the package config and migration files and run php artisan migrate. After that, apply the provided trait or observer to the models you want tracked. Confirm the exact publish tags and service provider registration in the repository README, since those details can change between major versions.
- Does laravel-model-auditlog support Laravel 13, and what about Laravel 10, 11, or 12?
- Version 10.0.0 states support for Laravel 13, and that release note lists the framework support as the change. Applications on Laravel 12 or earlier should pin to v9.5.0 rather than assume v10 works on their stack. Always check the composer.json constraints and the changelog to confirm the full Laravel and PHP version matrix before upgrading.
- How do I enable audit logging on a specific Eloquent model?
- Coverage is opt-in: you add the package's audit trait or register its observer on the Eloquent models you want tracked. Once enabled, creates, updates, and deletes are written to the model's audit table with the column values needed for a usable trail. Start with a proof of concept on one or two representative models and confirm the payload shape before rolling out broadly.
- Does it log deletes, soft deletes, and force deletes?
- The package records creates, updates, and deletes, so destructive operations are captured in the audit trail. Soft delete handling depends on how Eloquent fires the underlying events and how the package is configured, so test your soft delete and force delete paths explicitly. If compliance requires force deletes to be logged with their final column values, verify that behavior in staging before relying on it.
- Are audit writes synchronous, and can they be queued?
- Audit writes add work to your request path, and synchronous inserts can increase latency or couple a business transaction to an audit failure. Check the published config for whether audit writes can be routed to a queue or a separate connection. If you queue audits, monitor failed jobs closely, because silently dropped audit records undermine the entire trail.
- Which databases are supported and how do I stop the audit tables from growing forever?
- The package stores history in relational tables, and the expected stack is MySQL or PostgreSQL with Laravel's standard queue drivers. Audit logging increases write volume and table growth, so high-write models can noticeably amplify database load. Plan indexing, partitioning or archival, and a retention policy, and benchmark under production-like write volume before broad adoption.
- How do I redact PII or exclude sensitive columns from the audit log?
- Redaction matters because audit tables can quietly become a second copy of your sensitive data. Review the published config file and README for options to ignore or mask columns, and treat PII handling as an open question until you have confirmed it. If the built-in options are not enough, avoid tracking sensitive attributes or transform the payload before it reaches the audit table, and also verify how records are scoped in multi-tenant applications.
- What changed in version 10, and is there an upgrade guide from v9?
- The v10.0.0 release note says only that it supports Laravel 13, which makes it hard to tell a routine compatibility bump from a behavior-changing upgrade. Review the full diff, composer constraints, migration files, and any upgrade guide before running migrations. Pay particular attention to schema changes, config keys, event names, trait contracts, and audit payload shape, since dashboards, exports, and retention jobs may depend on them.
- How do I test that audit records are written for creates, updates, and deletes?
- Write feature tests that create, update, and delete a tracked model, then assert the expected rows and column values exist in the audit table. Cover the easy-to-miss paths too: soft deletes, force deletes, multi-tenant scoping, and any queued write mode. When you upgrade the package, rerun the same tests against the new schema so migration drift surfaces early.
- How does this compare to spatie/laravel-activitylog for model audit trails?
- Spatie's activity log stores changes in a single shared activity table with a subject and causer, while laravel-model-auditlog writes column values to individual per-model audit tables. Per-model tables can make forensic queries and reporting simpler, but they also mean more tables to migrate, index, and archive. Evaluate both against your retention, multi-tenancy, and export requirements rather than picking purely on install convenience.
Weaver
How can I help you explore Laravel packages today?