Backend Tools Activity Log Bundle Laravel Package

Getting Started

• Do not composer require this into a Laravel app. Despite being on Packagist, this is a Symfony bundle from 2016 (PHP 5.x/early 7.x, Symfony 2.x/3.x era). There is no service provider, no publishable config/*.php, no Blade views, no Artisan commands. Installing it pulls a Symfony bundle chain (ModeraActivityLoggerBundle → Modera backend/foundation bundles) that will fight your Laravel dependency constraints before you write a line of code.
• Leverage it as a reference implementation, not a dependency. Your day-to-day use is reading the repo to derive a feature checklist and a schema for a Laravel-native activity log viewer.
• Where to look first:
  1. The activity entity / Doctrine mapping — use it to sanity-check the fields your activities table needs (actor, action, subject type, subject id, payload, occurred_at).
  2. The controller + routing definitions — the browse/filter/detail routes tell you the minimal URL surface.
  3. The Twig templates — they define the listing, filter bar, and detail view your Blade views should mirror.
• First use case: an admin-only "Activity Log" screen listing recent events with filters by actor, action, subject, and date range, plus a drill-in detail page. That's the whole product this bundle delivers.

Implementation Patterns

• Schema first. Recreate the data model in a migration: id, actor_id (FK users), action (string, e.g. created|updated|deleted), subject_type (string/class), subject_id, payload (json, old→new values), ip, user_agent, occurred_at. Copy the fields from the bundle; ignore the Doctrine mapping details.
• Emit events from model observers, not the bundle's handlers:

  // App\Observers\AuditableObserver
  public function updated(Model $model) {
      Activity::create([
          'actor_id' => auth()->id(),
          'action' => 'updated',
          'subject_type' => get_class($model),
          'subject_id' => $model->getKey(),
          'payload' => ['changes' => $model->getChanges()],
      ]);
  }
  

• Read-side controller mirroring the bundle's browse/detail split:

  Route::middleware(['web','auth','can:view-activity-log'])
       ->prefix('admin/activity-log')
       ->group(function () {
           Route::get('/', [ActivityLogController::class,'index'])->name('activity.index');
           Route::get('/{activity}', [ActivityLogController::class,'show'])->name('activity.show');
       });
  

• Query scopes for filters — replicate the bundle's filter bar as composable scopes: scopeForActor, scopeForAction, scopeBetween, scopeForSubject.
• Authorization via a Policy/Gate, not the Symfony voter model. Add a dedicated view-activity-log gate; the bundle's admin-only assumption maps trivially onto a Laravel ability check.
• Pagination: cursor, not offset. The 2016 UI almost certainly assumed offset pagination; for a monotonically growing table, use cursorPaginate() and index (actor_id, occurred_at), (subject_type, subject_id, occurred_at), and (action, occurred_at).
• If you want a maintained library instead of hand-rolling, spatie/laravel-activitylog + a small custom admin panel is the modern Laravel equivalent — it covers the same logging surface this bundle did.

Gotchas and Tips

• The Symfony→Laravel bridge is a non-starter. Bundle classes, DI extensions, container compiler passes, Doctrine repositories, and Twig templates have no mapping to a Laravel service provider, Eloquent, or Blade. Don't spend a sprint on it — a clean-room build is faster.
• This package is a thin UI shell. It does nothing without ModeraActivityLoggerBundle underneath, and that bundle carries its own Symfony/Doctrine assumptions. Reading it in isolation gives you requirements, not a working system.
• Treat the schema as inspiration, not gospel. The bundle's model predates JSON columns, retention policies, and partitioning. Add payload indexing, tenant scoping, soft retention, and immutability decisions consciously — changing an audit schema after millions of rows is painful.
• Abandonment risk is critical. Last release June 2016, [READ-ONLY] mirror, 0 stars, 0 dependents. No security patches, no upstream. Never adopt this in the critical path.
• Security surface. An activity log is a privileged admin screen showing who did what — often including IPs and payload deltas that can leak cross-tenant or sensitive data. Gate it explicitly and audit who views the audit log, especially if you handle PII.
• Debugging reality. There is no maintained support channel, so any "why does it render X" investigation lands on you and only you. Use the repo as a spec during discovery, then close the tab.
• Extension points to steal wholesale: the actor/subject/action/timestamp/payload field set; the list + filter + detail page trio; the human-readable action rendering. Reimplement all three in Blade with a payload presenter.
• Watch query performance early. Activity tables are the classic workload that punishes naive implementations — arbitrary filter combinations over an append-only table. Add composite indexes and an archival/partition plan from day one, not after the first slow page in production.