Visithor Bundle Laravel Package

Getting Started

First, calibrate expectations: this is a Symfony bundle, not a Laravel package. There is a framework mismatch baked into the question. If you are on Laravel, composer require visithor/visithor-bundle will not give you a service provider, facades, or config publishing — you will get a bundle class and Symfony DI wiring that Laravel never boots. The practical move is to evaluate the underlying visithor/visithor library and wire it into a Laravel service provider, or only adopt the bundle if you are actually running Symfony 2.8/3.x.

If you are on Symfony:

1. composer require visithor/visithor-bundle
2. Register the bundle in AppKernel::registerBundles() (Symfony 2/3 style — there is no Flex recipe for a 2016 package).
3. Add a visithor: block in config.yml. Do not guess keys — read DependencyInjection/Configuration.php in the bundle to see every option and its defaults.
4. Inspect Resources/config/ — this is where the service IDs, the storage service, and any Doctrine mappings live. That directory is your source of truth for what you can inject.

Your first use case should be the smallest possible: inject the tracker service, record one visit, and confirm it persists to whatever storage the bundle configures (Doctrine by default, most likely). Get that round-trip working before adding request listeners.

Where to look first, in order: Configuration.php (options) → Resources/config/*.yml (service graph) → the core visithor library's main service (actual tracking logic) → the Doctrine entity/mapping if you plan to query visits.

Implementation Patterns

Request-level auto-tracking (Symfony). The idiomatic pattern is a kernel event listener rather than calling the tracker from every controller. Track on kernel.request to capture intent, but persist on kernel.terminate so the visitor never waits on a write. Register the listener in the bundle config or your own services.yml and inject the tracker.

Manual tracking. For finer control, inject the tracker service directly into a controller/service and call it where a "visit" is meaningful (e.g., a specific resource view rather than every asset request). This is the pattern that survives a framework migration best.

Storage decoupling. Watch the dependency boundary. The bundle almost certainly binds to Doctrine ORM. If you are on Laravel/Eloquent, do not fight the bundle — use the core library's storage interface (if present) and implement an Eloquent-backed adapter. Treat the storage layer as the extension point you are most likely to replace.

Querying and aggregation. Once visits are persisted, expose read-side queries (counts per resource, per day, per visitor) through a repository or a thin query service. Keep these out of the tracking path so writes stay cheap.

Laravel bridge pattern. If you commit to the core library on Laravel: a ServiceProvider binding the tracker as a singleton, a global or route middleware that records on response, a queued job for the write, and a migration for the visits table. This is roughly the workload you should budget for — the Symfony bundle does none of this for you in a Laravel app.

Middleware ordering. If you do auto-track, ensure ordering relative to auth/session middleware so you can attribute visits to a user when one exists, but still record anonymous visits.

Gotchas and Tips

• The package is effectively abandoned. Last release 2016-06-01, 16 stars, zero dependents. Assume PHP 5.x/7.0-era constraints and Symfony 2/3 requirements. Modern Symfony (5/6/7) and PHP 8 will almost certainly trip Composer's platform checks; expect to fork, or install with --ignore-platform-reqs and patch as you go.
• No Laravel integration exists. Do not expect a ServiceProvider, config publishing, or facades. Any Laravel usage is net-new glue code you write and own.
• Doctrine coupling. The bundle's config and mappings assume Doctrine. Swapping to Eloquent means replacing the storage service, not just a config value. Verify whether the core library exposes a storage interface before assuming this is feasible.
• Configuration caching quirks. Symfony bundle config of this vintage can misbehave under cache:clear/config caching if options are defined loosely. After changing visithor: keys, clear the cache and re-inspect the compiled container (debug:container).
• Performance traps. Never flush synchronously inside the request path. Persist on kernel.terminate or via a queue; batch where possible. Naive per-request flushes will dominate your response time under load.
• Debugging approach. Because docs are thin and the package is stale, debug through the container (debug:container visithor) and the actual service definitions in Resources/config/. Trust the code over any README.
• Extension points to prefer. The storage adapter and the tracking listener are the two seams to own. Keep your application code calling an interface, not a concrete bundle service, so the inevitable replacement/fork is a one-file change.
• Verdict for day-to-day use. Low opportunity, high maintenance. The realistic outcome is: use the core library's concepts, write your own thin integration (provider/middleware/storage), and treat this bundle as a reference implementation rather than a dependency. The 5.57 opportunity score reflects a genuine gap — a maintained, framework-agnostic visitor-tracking package — not a reason to adopt a decade-old Symfony wrapper.