- How do I install dp-0/user-activity in a Laravel app?
- Install it with composer require dp-0/user-activity, then publish the package config and migrations and run php artisan migrate. Register the service provider if your Laravel version does not auto-discover it, and add the page-visit middleware to the routes or groups where you want activity captured. The integration is a conventional Laravel drop-in and should take under a day on a compatible Laravel 10.x codebase.
- Does dp-0/user-activity support Laravel 11 and Laravel 12?
- The last release was July 2023, which targets the Laravel 10 era, so Laravel 11 and Laravel 12 compatibility is unverified and should be assumed broken until you prove otherwise. Skeleton changes, service-provider behavior, casts, and PHP 8.2/8.3 requirements can all affect it. If you are pinned to Laravel 10.x with PHP 8.1/8.2, it may work, but you will own any upgrade work.
- Is dp-0/user-activity still maintained?
- No. The repository is archived, the last release was July 2023, and there is no active issue triage, security patching, or Laravel major-version compatibility work. That makes it a hard disqualifier as a production dependency for anything with compliance or uptime obligations. Treat it as a reference implementation at most.
- Does dp-0/user-activity hurt Laravel performance with page-visit logging?
- Page-visit logging on the request path is write amplification: unbatched, synchronous inserts per request will not scale under meaningful traffic. The package is not designed around batching or queueing. If you must use this pattern, push writes onto a queue and sample or aggregate page visits rather than recording every request.
- How do I log a custom event with dp-0/user-activity?
- The package provides a facade and service provider for recording activity, but because the repository is archived and the public README excerpt is incomplete, confirm the exact method signature in the source before relying on it. In practice you call the recorder from a controller, listener, or middleware and pass the event name, the subject, and any properties you want stored. If you need a stable API, wrap it behind your own ActivityRecorder contract.
- What are the best alternatives to dp-0/user-activity?
- spatie/laravel-activitylog is the de facto standard and is actively maintained, so it is the recommended replacement for most teams. If your requirements are narrow, a thin in-house recorder of roughly 200 lines is also viable and gives you full ownership. Both options avoid taking on an archived dependency.
- Does dp-0/user-activity support Sanctum, API tokens, or multiple guards?
- This class of package commonly assumes a single web guard and session authentication, so multi-guard, Sanctum/token, multi-tenant, and console or queue contexts where no user is authenticated are the classic failure points. The dp-0/user-activity documentation does not establish support for those cases. Test every authentication path you use before trusting it, and expect to patch user resolution yourself.
- Is dp-0/user-activity safe for production and GDPR compliance?
- Logging IP addresses and user agents is personal data under GDPR and CCPA, and a small archived package almost certainly lacks retention limits, subject-access and deletion handling, and anonymisation. It is also unmaintained, so there are no security patches. Do not adopt it for production without Legal and Privacy sign-off and a plan for data lifecycle management.
- How do I migrate away from dp-0/user-activity?
- Introduce an internal ActivityRecorder interface with a single record(event, subject, properties) method and route all call sites through it, so the package becomes an implementation detail. If the package is already in use, keep its table schema and event naming stable during the swap so historical rows remain queryable. Where old and new writers must coexist briefly, dual-write behind a feature flag rather than backfilling.
- Should I fork dp-0/user-activity or write my own activity recorder?
- Forking is acceptable only if the scope is genuinely small and you accept ongoing ownership, typically 3 to 5 engineering days plus maintenance, and you will still need to do Laravel 11 and later compatibility work. A thin in-house recorder is often the better choice when requirements are narrow. Adopting the original package as-is is rejected because it is archived and unpatchable.