Activity Log Laravel Package

Getting Started

Install the package via Composer:

composer require dcode-group/laravel-activity-log

Publish the configuration and migrations:

php artisan vendor:publish --provider="DCODE\ActivityLog\ActivityLogServiceProvider"

Run migrations to create the activity_log table:

php artisan migrate

The quickest first use case is automatic model event logging. Add the LogsActivity trait to any Eloquent model you want to track:

use DCODE\ActivityLog\Traits\LogsActivity;

class Post extends Model
{
    use LogsActivity;
}

By default, this logs created, updated, and deleted events. You can immediately inspect entries via the Activity model:

use DCODE\ActivityLog\Models\Activity;

$activities = Activity::latest()->take(10)->get();

If you need manual logging, use the provided helper or facade:

activity()->log('User viewed the dashboard');

Look first at the package’s config/activitylog.php (or similarly named config) for defaults such as the log name, enabled state, and database connection.

Implementation Patterns

Automatic model logging
Apply the LogsActivity trait to models. Customize which events are logged and which attributes are recorded by overriding properties or methods:

protected static $logEvents = ['created', 'updated', 'deleted'];
protected static $logAttributes = ['title', 'status'];
protected static $logOnlyDirty = true;

Manual logging with context
Log arbitrary actions while associating a causer (usually the authenticated user) and a subject model:

activity()
    ->causedBy(auth()->user())
    ->performedOn($post)
    ->withProperties(['ip' => request()->ip()])
    ->log('post.published');

Retrieving and filtering logs
Use the query builder methods on the Activity model:

Activity::forSubject($post)->get();
Activity::causedBy($user)->latest()->paginate(20);
Activity::inLog('default')->where('description', 'post.published')->get();

Integration in controllers and services
Treat logging as a cross‑cutting concern. Prefer automatic trait logging for CRUD, and use manual logging for domain events (e.g., payment processed, export generated). You can wrap logging in a dedicated service or use Laravel events to decouple it.

Custom activity model
If you need extra columns or behaviour, extend the package’s Activity model and update the config to point to your custom class. This is a common extension point for adding tenant IDs or custom casts.

Gotchas and Tips

• Run migrations before logging – without the activity_log table, any logging attempt will throw a database exception.
• Dirty attribute logging – by default the package may log all attributes on update. Set $logOnlyDirty = true on your model to avoid noisy entries.
• Performance and pruning – activity logs grow quickly. Schedule regular pruning (e.g., delete records older than 90 days) or use a separate database connection. The package may ship a activitylog:clean command; check the console kernel.
• Trait event conflicts – if your model already uses another trait that hooks into the same Eloquent events (e.g., soft deletes, UUIDs), test that both traits fire correctly.
• Config caching – after changing the package config, run php artisan config:clear in development. In production, remember to re-cache.
• Debugging missing logs – verify the trait is applied, the model event actually fires (e.g., save() vs update()), and the log is not disabled via config. Check the activity_log table directly.
• Extension points – you can swap the Activity model, add custom log names, or implement a custom ActivityLogger if the default behaviour is insufficient. The 4.0.6 release adds a feature (see PR #99) but introduces no breaking changes; review the PR if you rely on the affected area.
• Queue support – for high‑volume logging, consider queuing log writes. The package may not do this by default; wrap manual logging in a job if needed.