- How do I install alfrasc/laravel-matomo-tracker in a Laravel application?
- Run composer require alfrasc/laravel-matomo-tracker, then publish the config file with php artisan vendor:publish and set MATOMO_URL and MATOMO_SITE_ID in your .env file. The service provider registers a container-bound singleton and a facade, so you can inject the tracker or use the facade alias in controllers, jobs, and console commands. On Laravel 10 or 11 with PHP 8.2+ you will likely need a fork or --ignore-platform-reqs because the published constraints are older.
- Which Laravel and PHP versions does laravel-matomo-tracker support?
- The package was last released in November 2021, so its Composer constraints target roughly Laravel 8 and 9 on PHP 7.4 through 8.1. It predates Laravel 10 and 11 and PHP 8.2 and 8.3, and there is no CI matrix in the repository showing broader coverage. On newer stacks, plan to fork it with updated illuminate/support constraints or vendor the small wrapper into your own codebase.
- How do I track a page view or custom event server-side with Matomo in Laravel?
- Resolve the tracker from the container or via the facade and use the fluent methods exposed by the underlying Matomo PHP tracker, such as doTrackPageView, doTrackEvent, doTrackGoal, and the e-commerce helpers. This lets you record signups, payments, provisioning steps, and webhook-driven state changes that never involve a browser page view. Wrap those calls in a narrow internal analytics contract so the package API does not leak across your application.
- What configuration values does the package need to reach my Matomo instance?
- You configure the Matomo base URL and the target site ID, and optionally an auth token for the Matomo API, typically through MATOMO_URL, MATOMO_SITE_ID, and a token variable in your .env file. The publishable config file maps those values onto the underlying piwik-php-tracker instance. If you run multi-tenant or modular applications, check that the publish step does not overwrite an existing config/matomo-tracker.php or collide with a facade alias.
- Is alfrasc/laravel-matomo-tracker still maintained and safe to depend on?
- The repository has a single maintainer, around 20 stars, and no release since November 2021, so treat it as unmaintained. The wrapper itself is only a few hundred lines, which makes forking or reimplementing it inexpensive compared with the risk of an abandoned dependency. If you adopt it, pin the exact version, constrain the transitive matomo/piwik-php-tracker version, and assign an owner for the fork.
- What license is laravel-matomo-tracker released under, and can I use it commercially?
- The repository reports NOASSERTION, meaning no recognized SPDX license was detected, so there is no clear grant of rights. Legal teams typically cannot approve that for a commercial codebase without written clarification from the author. Given the package's small size, a clean-room reimplementation or a direct dependency on matomo/piwik-php-tracker is often cheaper than the license review.
- Will server-side Matomo tracking slow down my Laravel requests?
- By default the underlying tracker makes a synchronous HTTP call to your Matomo instance, so tracking inside a controller couples request latency and availability to your analytics backend. Dispatch tracking from queued jobs or after the response is sent, and set explicit connect and read timeouts on the tracker. For high event volume, batch or throttle hits so your Matomo instance can absorb peak traffic.
- How do I test Matomo tracking in Laravel without hitting a real Matomo server?
- Because the package binds a singleton in the container, you can swap it for a fake or mock implementation in your test suite and assert on recorded events instead of making network calls. The cleanest approach is to depend on your own AnalyticsTracker interface and bind a spy implementation during tests. That also removes any need for a live Matomo instance or token in CI.
- What are the alternatives to laravel-matomo-tracker for server-side Matomo tracking?
- You can use matomo/piwik-php-tracker directly, which is the maintained library this package wraps, or send raw requests to Matomo's HTTP Tracking API. Both avoid the abandoned wrapper and the license ambiguity while still supporting page views, events, goals, and e-commerce. Whichever you choose, keep it behind an internal interface so you can switch implementations without refactoring call sites.
- How do I handle GDPR consent, IP anonymization, and data minimization with server-side Matomo tracking?
- The package has no first-class consent, queue, or batching semantics, so those concerns have to be built around it. Decide whether your events are product analytics that tolerate loss or business metrics that need durability, and apply consent checks before dispatching any tracking job. IP anonymization and data minimization are configured on the Matomo side, but you should also avoid sending personal data in event labels, URLs, or custom dimensions.