Activity Log Bundle Laravel Package

Technical Evaluation

Architecture fit — effectively zero for a Laravel codebase. Despite being catalogued as a "Laravel/PHP package," madmis/activity-log-bundle is a Symfony bundle built on top of the Gedmo Doctrine Loggable extension. It works by registering a Doctrine event subscriber that hooks onFlush against an ORM EntityManager, diffing managed entities and persisting version rows. Laravel's default persistence layer is Eloquent/ActiveRecord; there is no supported path to install this into a Laravel app without pulling in Symfony bundles, Doctrine ORM, and the Gedmo extension set. The realistic value to a Laravel TPM is conceptual, not code-level: it is a reference implementation of field-level audit diffing (object class + object id + version + serialized field delta).

Integration feasibility. Three options, all unattractive:

Technical risk — high, dominated by abandonment. Last release 2017-08-07, 11 stars, 0 dependents, repository archived. The code predates PHP 7.2-era typing cleanup and targets Symfony 2.x/3.x and Doctrine ORM 2.x; running it on PHP 8.2+/Symfony 6/7 is likely to produce deprecations and fatals. An archived repo means no security advisory stream, no CVE response, and no upgrade path — in an audit-trail subsystem, which is precisely the component regulators and security reviewers scrutinise. It also transitively depends on gedmo/doctrine-extensions, whose listener APIs have themselves changed substantially.

Key questions to resolve before any spend:

• Is the requirement field-level diffing for compliance/forensics, or user-facing activity feed? These have different retention, immutability, and query needs.
• Do we already run any Symfony/Doctrine services, or is the estate pure Laravel?
• Is tamper-evidence (append-only, hash-chained) required, or is soft-deletable CRUD logging sufficient?
• What is the write volume on the audited aggregates, and can logging be asynchronous?
• What are the PII/GDPR retention and erasure obligations for logged field values?
• Who would own a fork, and for how many years?

Integration Approach

Stack fit. 0/5 for a Laravel-only estate. If a legacy Symfony 2/3 + Doctrine monolith is in scope, the bundle is plausible as a short-term stopgap — but only there, and only with a documented exit plan.

Migration path. Do not port the bundle; port the model. The useful artefact is its schema shape: an audit table keyed on (object_class, object_id, version) with an action enum, actor, timestamp, and a serialized data delta. That translates cleanly to:

• An audit_logs table with auditable_type, auditable_id, event, old_values/new_values (JSON), actor_id, actor_type, created_at, plus a covering index on (auditable_type, auditable_id, created_at).
• Capture via Eloquent model events / observers, using getOriginal() vs getChanges() for the delta, or via a LogsActivity trait.

Compatibility. Before any prototype: audit the target runtime (PHP version, Laravel version) against the bundle's composer.json constraints. Expect hard conflicts on PHP and on symfony/*/doctrine/* packages. Treat any "just install it" estimate as invalid until a composer require dry run is done.

Sequencing.

1. Confirm audit requirements, retention window, and whether immutability is in scope (1 week, PM + security).
2. Evaluate maintained Laravel-native alternatives first — spatie/laravel-activitylog or owen-it/laravel-auditing will cover 80–90% of the requirement with active maintenance.
3. If a gap remains, run a 2–3 day spike on the Eloquent observer approach for one or two high-value aggregates only; do not attempt blanket coverage.
4. Put writes behind a queued job or transactional outbox so audit persistence cannot fail the domain transaction.
5. Add schema-evolution guardrails (a test asserting every audited model declares its loggable fields) and archival/partitioning jobs before volume ramps.

Operational Impact

Maintenance. Treat as vendored dead code. Budget explicit internal ownership if adopted: fork, pin, and accept that no upstream fixes arrive. Software-composition scanning will flag it as unmaintained, which is a recurring conversation with security review.

Support. None. No issue triage, no maintainer responsiveness, ~no user base means no Stack Overflow or blog coverage. Documentation is thin and assumes Doctrine fluency. Every question becomes an internal investigation.

Scaling. Audit tables grow monotonically with write volume — typically the fastest-growing table in the schema. Listener-based diffing adds per-write overhead (entity hydration, reflection over mapped fields, extra INSERT), and if the log write shares the domain transaction it introduces lock contention and longer transaction windows. Plan for: batched/queued writes, monthly partitioning or archival, and a retention job. Admin/reporting queries against a bloated audit table will need dedicated read paths.

Failure modes.

• Log listener throws → the business transaction rolls back. Audit logging should never be on the critical path of a checkout or signup.
• Lazy-loaded relation serialization → N+1 queries or circular-reference blowups in the stored payload.
• Unbounded table growth → slow admin UI, storage cost surprises, backup window creep.
• Schema drift → new columns silently unaudited because the loggable field list wasn't updated.
• PII captured in old_values/new_values → GDPR erasure requests become unimplementable without rewriting history.

Ramp-up. For a Laravel team, the concepts are a day's work; the bundle is a multi-day dead end requiring Symfony/Doctrine familiarity that the team likely doesn't have and won't reuse. Realistic TPM recommendation: adopt a maintained Laravel-native audit package, cite this bundle only as a schema/design reference, and avoid taking a dependency on an archived, zero-dependent 2017 Symfony bundle in a compliance-sensitive path.