- Is kronhyx/tracker-bundle a Laravel package or a Symfony bundle?
- The package description presents it as a Laravel/PHP tracking package, but a technical review of the repository identifies it as a Symfony bundle that relies on Symfony's kernel, DI container and event dispatcher. Those primitives do not map directly onto Laravel's service providers, container and Eloquent model events, so there is no drop-in path to a Laravel app. Read the composer.json requirements and the bundle class before you commit to it in a Laravel roadmap.
- How do I install kronhyx/tracker-bundle with Composer?
- Install it with composer require kronhyx/tracker-bundle from the kronhyx vendor namespace. Immediately after install, open the package's composer.json and check which framework and major versions it actually declares support for, since that constraint is the real gate on whether it will run in your project. Then register the package's service provider or bundle in your application bootstrap and publish any configuration it ships.
- How does the package capture visits and page views automatically?
- It hooks into the framework's request lifecycle through middleware, so each incoming request is inspected and recorded as a visit or page view. Captured data typically includes the requested URL and the visitor's user agent, written through the configured storage driver. Setup is intentionally minimal: register the middleware and tracking starts on the routes you attach it to.
- How do I configure the storage driver for tracked events?
- Storage is driver-based, so you publish the package configuration and choose the driver that matches your persistence layer. Confirm which drivers actually ship with the package before planning around one, because the documentation surface is thin and the storage backend is one of the undefined axes flagged in review. Point the driver at a dedicated table or store rather than mixing tracking rows into your core business tables.
- Which Laravel versions does kronhyx/tracker-bundle support?
- No published compatibility matrix exists, and the package appears to be a Symfony bundle rather than a Laravel package. The realistic assumption is that it has been exercised against exactly one local stack configuration, the author's. Treat Laravel support as unproven until you have run it yourself on your target version in a scratch project.
- Can I add custom tracking points beyond page views?
- Yes, the event model is described as extensible, so you can record your own tracking points alongside the automatic request capture. In practice you emit a trackable event from your own code and let the configured driver persist it. Check the source for the exact event contract before designing custom points around it, since the README does not document the API.
- How do I query tracked events for a dashboard or report?
- Tracked visits and events are stored in a structured, queryable form, which is the main advantage over dumping raw log lines. If you use a database driver, you query the tracking table or model directly and aggregate by route, date or user agent. There is no evidence of a dedicated read or reporting API, so expect to build the query layer yourself.
- Is kronhyx/tracker-bundle safe to use in production?
- Treat it with caution. It has no stars, no dependents and no third-party issue history, so nobody else's deployment can give you confidence, and it is maintained by a single author with no visible activity. Tracking code is also correctness-sensitive: a dropped or partial record is worse than no record because it creates false confidence during incident review. Budget for reading the source and writing your own tests before it touches production traffic.
- How do I test that tracking events are actually recorded?
- Write a feature test that hits a real route through the middleware and then asserts a matching row exists in your tracking store. Also assert the failure path, such as what happens when the storage driver throws, so you know whether a tracking failure can break the request. The package itself has no demonstrated test coverage or CI, so your own suite is the only safety net.
- What are the alternatives if kronhyx/tracker-bundle does not fit my Laravel app?
- For a Laravel target, spatie/laravel-activitylog is the conventional choice for activity and change history, and Laravel's own events and listeners cover simple request tracking without any dependency. If you need a small, fully controlled footprint, a short middleware that writes to your own table is often cheaper than adapting an unmaintained package. Reserve kronhyx/tracker-bundle for cases where you have reviewed the source and confirmed it runs on your Symfony and Doctrine versions.