Weave Code
Historytracker Laravel Package
laravel-enso/historytracker
HistoryTracker for Laravel Enso automatically records model changes, storing a versioned audit trail of created, updated, and deleted records with the user and timestamp behind each change, so you can review and roll back history from the Enso UI.
Laravel Model history tracking made easy
Frequently asked questions about Historytracker
- What does laravel-enso/historytracker do?
- It is an Eloquent-level audit package from the Laravel Enso admin-suite ecosystem that records model create, update, and delete events into a polymorphic history table. Each row captures attribution such as the user and timestamp behind the change, so you can review a record's timeline and roll it back from the Enso UI. It is designed to run inside an Enso application rather than standalone.
- How do I install HistoryTracker in a Laravel Enso app?
- In an existing Enso application the integration is trivial: composer require the package, publish and run its migrations, add the tracking trait to the models you want to audit, and toggle the tracked events in the package config. Expect hours rather than days of work. Confirm the exact dependency graph from composer.json, since it pulls in Enso core and helper packages and relies on Enso's user and people conventions for attribution columns.
- Can I use laravel-enso/historytracker without the Enso admin suite?
- It is possible but feasibility drops sharply outside Enso. The package's migrations and created_by and updated_by attribution columns assume Enso's user model and table naming, so retrofitting means editing migrations and overriding config, which is effectively maintaining a fork. The MIT license makes forking legally clean, but the decoupling cost usually exceeds adopting a maintained alternative such as spatie/laravel-activitylog or owen-it/laravel-auditing.
- Which Laravel and PHP versions does HistoryTracker support?
- The repository is archived, so the supported Laravel and PHP range is frozen at the pinned release. Check the declared constraints in composer.json and verify the package installs cleanly on your target runtime before committing. Modern Laravel 10, 11, or 12 on PHP 8.2+ will likely require constraint relaxation and a review of typed properties, facades, and event signatures.
- Is laravel-enso/historytracker still maintained?
- No. The repository is archived, with a single-maintainer lineage and roughly 51 stars, and its aggregate assessment score is around 0.33. Archival means no upstream bug fixes, no Laravel or PHP version bumps, and no security response, so anything beyond the pinned version matrix becomes internal maintenance. Treat it as viable code in an unmaintained project and budget accordingly.
- Does HistoryTracker track mass updates, inserts, or raw SQL changes?
- No. Tracking is driven by model events for create, update, and delete, so it silently misses Model::query()->update(), insert(), raw SQL, and queue or console contexts where auth attribution is absent. If you need audit or compliance coverage, validate these gaps explicitly or pair it with database-level auditing. Do not assume every mutation produces a history row.
- Is the history table a tamper-evident audit log?
- No. The record shape is snapshot-plus-attribution, with one history row per model mutation keyed to historable_type and historable_id, which is convenient for a show-me-this-record timeline UI. It is not an append-only, tamper-evident audit ledger. Check whether the schema stores full snapshots, dirty-attribute diffs, or both, and whether the history table is writable or editable through any UI.
- What are the delete semantics, and does history survive deletes?
- The package records deleted events, but you need to validate the exact behavior for soft deletes, hard deletes, and cascading deletes in your schema. Confirm whether history rows survive the source record's removal and whether cascading deletes can take history with them. This matters if you rely on the timeline for rollback or audit reconstruction.
- Are there retention and privacy concerns with the history table?
- Yes. History rows duplicate data from your source models, including PII, so retention, right-to-erasure, and access control on the history table become your responsibility. The package does not ship retention or pruning tooling, so growth is unbounded by design unless you add your own. Plan for data governance before enabling it on sensitive tables.
- What are the best alternatives to laravel-enso/historytracker?
- Outside an Enso application, spatie/laravel-activitylog and owen-it/laravel-auditing are the usual choices, with broader Laravel version support and active maintenance. Inside Enso, HistoryTracker remains the native audit mechanism, and adopting anything else means fighting Enso's UI conventions for history panels. If you stay on the archived package, plan to fork and maintain it internally.
Weaver
How can I help you explore Laravel packages today?