- How do I install and configure goldnead/statamic-activity?
- Install it with Composer using composer require goldnead/statamic-activity, then publish the package config with the vendor:publish command. Statamic addons are auto-discovered, so no manual service provider registration is normally needed. Check the package README for the exact publish tag and any post-install steps.
- Which Statamic and Laravel versions does this activity log support?
- It is a Statamic addon, so its compatibility follows the Statamic version and Laravel dependency supported by your host installation. Check the package composer.json for the pinned Statamic floor before upgrading. Version 1.5.0's settings nav tuple is consumed by statamic-brand-context 1.16 or later for nesting under Einstellungen or Addon-Suite.
- What events does Statamic Activity record?
- The package records create, update, publish, and delete events for content changes. The tracked events are configurable, and entries appear in a per-user activity timeline in the Control Panel. The log is filterable and searchable, so editors can audit changes without opening entry revisions.
- How long are activity logs kept in v1.6.0?
- In v1.6.0, retention is a single installation-wide retention.days config value, overridable with ACTIVITY_RETENTION_DAYS. If ACTIVITY_RETENTION_DAYS is unset, the default is 365 days, so the next activity:prune run deletes entries older than a year. Before v1.6.0 an unset value did not prune by age, so treat this as a destructive default and set an explicit value.
- Why does my published config/activity.php still keep activity forever?
- An older published config/activity.php may still read env('ACTIVITY_RETENTION_DAYS') with no default, which keeps everything instead of applying the 365-day default. That means two installs on the same package version can behave differently based on whether the config file was published years ago. Audit config/activity.php in every environment before relying on prune behavior.
- How do I safely run activity:prune in production?
- Run activity:prune with --dry-run first and compare the candidate deletions against your retention policy. Confirm the scheduled cadence and next run time, and pause the schedule during rollout if needed. v1.6.0 fails closed on non-positive or non-numeric windows, but actual deletion is irreversible and guardrails are procedural.
- What changed with per-brand retention settings in v1.6.0?
- v1.6.0 removes the per-brand retention Settings field because it wrote a value nothing read while the prune command deleted across all brands using one number. Retention is now installation-wide and stored in config. Orphaned brand_settings rows for retention.days are dead data and can be manually removed; if a policy promised per-brand retention, treat that as a disclosure issue.
- Is activity:anonymize per-brand or store-wide?
- activity:anonymize operates store-wide, but retention.anonymize_after_days is still stored per brand. That is the same class of bug v1.6.0 fixed for prune, left in place for anonymize. Audit any per-brand anonymize values and assumptions, and expect this to be addressed in a future breaking release.
- How do I test that activity logging works?
- Test by exercising a create, update, publish, and delete on a staging entry and confirming the events appear in the Control Panel timeline. Also verify filtering and search, and run activity:prune --dry-run with a short retention window to check which entries are candidates. If you schedule prune, test the scheduled command path as well as manual invocation.
- How do I upgrade from v1.5.0 to v1.6.0 safely?
- Treat the upgrade as composer update plus a config audit, not just a version bump. Check whether config/activity.php exists in each environment, whether its days key has a default, and what the scheduled activity:prune cadence is relative to deploy. Also review whether 365 days is defensible for your audit data or whether you need an explicit different value.