luketowers/wn-easyaudit-plugin
Winter CMS plugin that integrates EasyAudit to automatically record an audit trail of model changes, tracking who created, updated, or deleted records with detailed old and new value diffs for easy review.
Revision note — v4.3.1 is a patch, not a reassessment trigger. The new release contains a single fix (PR #8, authored by the maintainer): honour trackable overrides registered as dynamic properties. No breaking changes, no deprecations, no new features, no new dependencies, no license change, no change to the platform target. The conclusion of the prior assessment stands. Two things in this release do carry signal for a TPM, and are folded in below: it resolves the "is the maintainer responsive" question in the affirmative, and it reveals that the tracked-attribute configuration surface can silently under-capture.
Architecture fit — the framing is still wrong, and that still matters. luketowers/wn-easyaudit-plugin is a Winter CMS plugin (Composer type winter-plugin), not a Laravel library. It cannot be composer required into a Laravel application and used as a service provider. Winter CMS is a Laravel-derived fork of October CMS, so the package sits downstream of Laravel; it targets Winter's plugin registration, backend controllers, and model behaviors. If our target is a plain Laravel/Symfony app, the architecture fit is effectively zero and the evaluation should stop here. If our target is Winter CMS, fit is good: it is purpose-built for the backend UI patterns Winter developers already use.
Integration feasibility. In a Winter project the mechanics are simple — drop into plugins/luketowers/easyaudit, run migrations, attach the audit behavior to models, get a backend viewer. Low effort if auditing is already instrumented. The real cost is upstream of the plugin: retrofitting audit capture onto existing models means schema decisions, backfill strategy for historical state, and per-save write amplification. Those costs are ours regardless of which plugin we pick. v4.3.1 adds one wrinkle: if we configure tracked attributes dynamically (rather than as a static $trackable property), we are depending on code that shipped a fix for that path only days ago — treat dynamic configuration as a less-travelled path and verify it explicitly rather than assuming it behaves like the static case.
Technical risk.
NOASSERTION. Still a hard gate, not a yellow flag. Nothing in this release addresses it. We cannot ship it into a commercial or regulated product without written clarification from the maintainer or a fork with a clean provenance story.What v4.3.1 changes in the risk picture. The fix means that, prior to this release, a trackable override registered as a dynamic property was not honoured — the plugin would audit a different attribute set than the integrator declared, without erroring. That is precisely our ranked failure mode #1 (silent non-capture) occurring in the wild, in the configuration layer. It has been fixed, which is good, but it tells us the configuration contract is loose enough to fail quietly, and it tells us the plugin's own tests did not catch it. Any spike must therefore assert the captured attribute set against the declared set, not merely observe that rows appear.
Key questions to resolve before any commitment.
2026-09-06 last-release date was a metadata artifact, not reality.trackable attributes configured in our intended design — static property or dynamic? If dynamic, is there test coverage we can point to, and does the captured set match intent on every instrumented model?Stack fit. Only adopt if Winter CMS is the platform. If we are on plain Laravel, the correct decision is owen-it/laravel-auditing plus a viewer built in our admin stack (Filament/Nova) — we get the same capability with a maintained dependency and a license we can defend. This plugin's value in that scenario is as a design reference for the viewer UX, nothing more.
Migration path. Treat it as vendored project code, not a dependency: pin to a specific commit — now v4.3.1, since it fixes a silent-under-capture bug we would otherwise have to patch ourselves — mirror into our own org-controlled fork, and record the license clarification alongside it. Because audit tables are append-heavy and painful to reshape after the fact, decide the schema and partitioning approach before the first production write, not after.
Compatibility. Verify Winter major version, PHP version, and DB JSON column support before spiking. Check for conflicts with Winter's built-in revisionable behavior and any other auditable plugin — double-instrumentation means duplicate rows and doubled write cost. If we run October CMS rather than Winter, assume adaptation work; do not assume drop-in. Note that v4.3.1 is a behavioural change on the configuration path: if we had prototyped against v4.3.0, re-baseline the spike rather than assuming identical results.
Sequencing.
trackable configuration, and diff the captured attribute sets.Maintenance. With one maintainer, low activity, and zero dependents, we should plan on being the maintainer. v4.3.1 is evidence the upstream is alive — one fix, maintainer-authored — which is better than a frozen repo but does not change the fork-and-own posture. Budget for periodic upstream diff review, our own patch queue, and a named internal owner. The alternative — consuming upstream passively — is not viable for a component that produces audit evidence.
Support. No vendor support, community forum at best. Incident response for "audit log is wrong/missing/inaccessible" lands entirely on our team. Because audit logs are frequently the artifact you hand to an auditor or use in a security investigation, the support gap is disproportionate to the code's size. The class of bug fixed in v4.3.1 — a quietly wrong attribute set — is exactly the kind of issue that arrives as a support ticket months later, from an auditor rather than a user.
Scaling. Audit tables grow monotonically and roughly proportional to write volume on instrumented models — often the fastest-growing table in the database. Plan partitioning or archival and a deliberate index review up front; the viewer's list/filter queries will degrade first. Expect measurable per-save overhead on the write path for models with large attribute sets.
Failure modes, ranked by severity.
saveQuietly path, an unhonoured dynamic trackable override) and we keep believing we have coverage. This is the worst outcome — false compliance confidence. v4.3.1 is a live example of this class; assume others exist. Mitigate with a synthetic write canary, an alert on missing expected audit rows, and a test that asserts the captured attribute set equals the declared set.Ramp-up. Low for a Winter-fluent engineer (install in hours, instrument in days). High for anyone expecting Laravel idioms — the plugin's extension points are Winter backend patterns, not Laravel package conventions, and that mismatch will mislead estimates. The genuinely expensive ramp is auditing-domain design (what to capture, retention, who can see it), which the plugin does not solve.
Decision guidance. v4.3.1 does not move the score: still ~18.7/100, still a reference implementation rather than an adopted dependency. The license gate and the bus factor dominate, and neither changed. What changed is two facts worth carrying: the maintainer is responsive enough to ship fixes (one open question closed), and the configuration layer has demonstrated the ability to under-capture silently (one risk concretely evidenced). Recommend: pin any exploratory work to v4.3.1, read the source for viewer/UX patterns, then either fork with explicit license and ownership, or build the equivalent on owen-it/laravel-auditing inside our own Winter plugin. Do not take a production dependency on it as-is.
How can I help you explore Laravel packages today?