Repository navigation
Support spatie/laravel-activitylog v5 (for javaabu/activitylog v2) #16
Description
From javaabu/activitylog v2 (n4ff4h/activitylog#15), which is built on spatie/laravel-activitylog v5 (its current major; PHP 8.4 / Laravel 12+, the same floor as next-gen).
Permissions' runtime logging already works with v5: LogUserRoleUpdate and LogRolePermissionsUpdate only use activity()->performedOn()->causedBy()->withProperties()->log(), and v5 keeps all of those. Three small things would keep the two packages working together cleanly:
- Constraint:
require-devandsuggestsayspatie/laravel-activitylog: ^4.10. Could they be^4.10 || ^5.0, with tests on v5? An app with javaabu/activitylog v2 will have v5 installed. - Where the changes go: in v5, model changes live in a separate
attribute_changescolumn (withChanges([...])), andpropertiesholds only custom data. The listeners writeattributes/oldintoproperties. activitylog v2 readsproperties.attributes/oldas a fallback, so nothing breaks. On v5 it would be cleaner to callwithChanges()when the method exists (method_exists($log, 'withChanges')) andwithProperties()otherwise. Diffs, descriptions and rollback then treat role changes like any model change. - Docs:
docs/advanced-usage/activity-log.mdimportsSpatie\Activitylog\LogOptionsandSpatie\Activitylog\Traits\LogsActivity, which are v4 namespaces. In v5 they'reSpatie\Activitylog\Support\LogOptionsandSpatie\Activitylog\Models\Concerns\LogsActivity. With javaabu/activitylog v2 installed, apps would useJavaabu\Activitylog\Concerns\LogsActivity, whose defaults already skip hidden attributes and timestamps.
activitylog v2 also gives role_updated and permissions_updated their own tags (colour, icon) and readable descriptions, based on the log description, because those logs have no event. If you ever set an event on them (->event('role_updated')), please keep the same names.
Not blocking: activitylog carries on with the fallback.
Activity
Support spatie/laravel-activitylog v5 alongside v4
n4ff4h commentedon Nov 5, 2026
Fixed in f3fd84f on
next-gen(PR #15). CI is green; the first run failed with "Could not authenticate against github.com" during the Composer install, and the reruns passed.require-devandsuggestare^4.10 || ^5.0. This works now because v2 requires javaabu/helpers, which pins javaabu/settings ^1.7 and activitylog 4 (conflicts with settings v2 and activitylog v2) forms#18 dropped javaabu/helpers, which was pinning activitylog 4 through javaabu/settings. CI runs v5.1.3 on the prefer-stable legs and v4.10.1 or v4.12.0 on the prefer-lowest legs. A separate "spatie/laravel-activitylog v4" job runs the latest v4.Listeners\Concerns\LogsChanges. It callswithChanges()when the logger has it (v5), soattribute_changesholdsattributes/oldandpropertiesstays empty. On v4 it falls back towithProperties(). The tests check v5'sattribute_changesand v4'schanges(), and on v5 they also check thatpropertieshas no changes. The logs still have noevent; if one is ever added, it will berole_updatedandpermissions_updated.docs/advanced-usage/activity-log.mduses the v5 imports (Spatie\Activitylog\Models\Concerns\LogsActivity,Spatie\Activitylog\Support\LogOptions), with a note giving the v4 ones. It also has a javaabu/activitylog v2 example usingJavaabu\Activitylog\Traits\LogsActivity, the namespace in activitylog's next-gen code, notConcernsas the issue said. Requirements, the upgrade guide,llms.txtand the changelog are updated, and the upgrade guide no longer says forms installs helpers.