Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Activity Log Bundle Laravel Package

madmis/activity-log-bundle

A Symfony bundle for tracking user activity and entity changes. It provides configurable activity logging, Doctrine event integration, and a simple API to record, retrieve, and display activity history in your application.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Audit-trail / activity-feed feature scoping. The core need this package gestures at — "who changed what, when, and from what value to what value" — is a recurring, high-value product capability. It underpins admin audit screens, customer-facing activity timelines, support forensics ("why did this record change?"), and enterprise compliance asks. Evaluating this package forces the team to decide whether that capability is a v1 requirement or a fast-follow.
  • Build vs. buy, resolved toward "build thin." The existence of a package here is a useful signal that the problem is generic and well-understood; the state of this package (11 stars, 0 dependents, archived, last release 2017-08-07) is the signal that the off-the-shelf option is not viable. Net recommendation: a single append-only activity_log table with a polymorphic subject, actor, event, and JSON diff payload is roughly a one-to-two-sprint build and removes an unmaintained dependency from the critical path.
  • Roadmap input for compliance and enterprise tiers. Field-level change history is a prerequisite for SOC 2 change-management evidence, GDPR/CCPA data-subject requests ("show me every change to this user's record"), and any HIPAA-adjacent audit control. If an enterprise/regulated tier is on the roadmap, this is a gating capability, not a nice-to-have — and it should be scheduled deliberately rather than inherited from a stale bundle.
  • Data-model decision: entity diffs vs. domain events. This package (an extension of Gedmo's Doctrine Loggable) commits to entity-level field diffs — it hooks the ORM and records column changes. That is a different product artifact from domain event logging (business-meaningful events like invoice.refunded). Deciding which one you actually need changes the schema, the query patterns, and the UI. Diffs alone rarely satisfy product-facing activity feeds; you usually need both, and conflating them is a common and expensive mistake.
  • Retention and privacy scoping. Any audit log stores historical PII by definition. Choosing an approach surfaces the policy questions early: retention window, redaction of sensitive columns, whether the log is exposed to end users, and how erasure requests reconcile with immutable history.
  • Stack-fit gate. Critically, this is a Symfony bundle built on Doctrine ORM and Gedmo DoctrineExtensions — not a Laravel package. For a Laravel codebase it supplies no usable code, only a design reference. The correct Laravel-side comparison is spatie/laravel-activitylog (actively maintained, first-party Laravel integration). Use this package's existence to justify the feature; use Spatie or an in-house table to implement it.

When to Consider This Package

Consider it only under a narrow, largely historical set of conditions:

  • You maintain a legacy Symfony 2.x/3.x application already running Doctrine ORM and Gedmo DoctrineExtensions, on PHP 5.6–7.x, where the upgrade path is frozen and the codebase will not see PHP 8.
  • You need field-level change capture fast and have essentially no budget to build it, and the log is internal-only (admin/debug), not customer-facing or compliance-bearing.
  • You accept that you are vendoring an archived artifact: no security patches, no compatibility fixes, no upstream responsiveness. You should fork it, pin it, and treat it as owned code.

Look elsewhere — decisively — if any of the following is true:

  • Your stack is Laravel. This bundle is not applicable. Evaluate spatie/laravel-activitylog or build a thin table.
  • You are on PHP 8.x or plan to be. An eight-year-dormant Doctrine extension is a near-certain incompatibility, and 0 dependents means nobody has published the workaround you'll need.
  • The log carries compliance weight (SOC 2, GDPR, HIPAA, financial audit). Archived dependencies with no CVE response process are an automatic finding in vendor review.
  • You need user-facing activity feeds, notifications, or event semantics. Entity diffs are the wrong primitive; you want explicit domain events.
  • Volume matters. ORM-hooked diffing writes on every flush and is a common source of write amplification and unexpected latency in high-throughput systems.
  • You need retention policies, redaction, or search. This package provides none of that; you're building it either way, at which point the package is not saving you anything.

How to Pitch It (Stakeholders)

To executives: We evaluated this package and recommend against adopting it — but the evaluation was still worth the time, because it clarified a capability we do need. Audit history ("who changed this record, when, and what changed") is a recurring ask from enterprise buyers and a prerequisite for SOC 2 and GDPR obligations. The specific open-source option we looked at is not a viable foundation: it was last released in 2017, has no downstream users, and is formally archived, meaning no security patches. Adopting it would import unmaintained code into a compliance-sensitive path — the opposite of what an auditor wants to see. The recommended path is a small in-house audit-log table (roughly one to two sprints) or a maintained alternative if we're on Laravel. The decision to make is not "which package," it's "which release does this land in," because it gates the enterprise tier.

To engineering: Do not integrate madmis/activity-log-bundle. It is a Symfony/Doctrine bundle, not Laravel — there is no integration surface for our stack, and the repository is archived with its last tagged release in August 2017 and zero dependents, so we would be the only party maintaining it. Its model is entity-level ORM field diffing via Gedmo Loggable, which also happens to be the wrong primitive for our product-facing activity feed. Proposal: an append-only activity_log table (actor, subject type/id, event name, JSON before/after diff, timestamp, request context) written from a small service layer rather than ORM hooks, so we control write volume and can redact sensitive fields. If we want field-level diffs specifically, we build them on model observers/events, not on a third-party ORM extension. Estimate: one to two sprints including a back-office viewer and retention job. If someone prefers buying over building, the maintained comparison is spatie/laravel-activitylog, which we should evaluate on its own merits — not this bundle's.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elmogy/larafast
xeviant/laravel-paystack
gorilladash/laravel-website-sdk
martialbe/flysystem-oss
chondal/3312client
jeroen-g/flickr
opscale-co/nova-genbi
itsjustvita/laravel-retention
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log
gregsphotography/site-builder-components
io-digital/clickatell
snowsoft/laravel-admin
oxygen/auth
relicsoftware/barakah-payment-gateway
tobya/work-with-composer
equipc/laravel-email-validator
equipc/laravel-email-database-log
adedsec/nova-translated-labels