Weave Code
Device Detector Laravel Package
piwik/device-detector
Device Detector is a universal library that parses User Agents and Browser Client Hints to detect devices, browsers, operating systems, brands, and models. It identifies desktop, tablet, mobile, TV, car, and console devices plus clients like feed readers and media players.
The Universal Device Detection library will parse any User Agent and detect the browser, operating system, device used (desktop, tablet, mobile, tv, cars, console, etc.), brand and model.
Frequently asked questions about Device Detector
- How do I install Device Detector in a Laravel app?
- Install it with composer require matomo/device-detector. The package was renamed from piwik/device-detector, so use the matomo vendor name in new projects and expect Composer to flag the old name. It is a plain library with PSR-4 autoloading, so there is nothing to publish or configure in Laravel.
- Is there a Laravel service provider or facade for matomo/device-detector?
- No, matomo/device-detector is a framework-agnostic library, not a Laravel package, so it ships no service provider, config file, or facade. The only Laravel-native piece is the DeviceDetector\Cache\LaravelCache bridge. You will need to write a small service provider, config, middleware, and DTO or hydration layer yourself, which is typically about half a day to a day of glue work.
- Which PHP and Laravel versions does device-detector support?
- Device Detector is framework-agnostic, so it does not pin a Laravel version; your Laravel constraint comes from your application, and the package only declares its PHP requirement in composer.json. Check that file for the current PHP minimum rather than trusting directory summaries, and run it on your PHP and Laravel test matrix. Because there is no Laravel integration code, Laravel upgrades generally do not break the library itself.
- How do I cache User Agent parsing in Laravel to avoid repeated regex work?
- Wrap Laravel's cache repository with DeviceDetector\Cache\LaravelCache and pass it to setCache(), using a shared store such as Redis or APCu rather than the default in-process array cache. Key entries on the User-Agent string plus any Client Hints you send, because detection output depends on both. Set a reasonable TTL and consider versioning the cache key by detector version so rule updates invalidate stale classifications. In PHP-FPM the array cache is per-request and gives you almost no reuse.
- Do I need Browser Client Hints for accurate detection in Laravel?
- Increasingly yes: Device Detector accepts Client Hints as the second constructor argument, and detection quality for modern browsers depends on them. You must send the appropriate Accept-CH and Permissions-Policy headers and capture the resulting headers on subsequent requests. If you ship User-Agent parsing first and add Client Hints later, you bake in a known accuracy ceiling and will need a second migration.
- How can I detect and block bots in Laravel using Device Detector?
- Call isBot() after parse() and use the result as one signal rather than an automatic hard block. skipBotDetection and discardBotInformation let you tune whether bot parsing runs and whether details are retained. Bot regexes can misfire on privacy browsers, headless-but-human traffic, link previewers, and monitoring agents, so combine the result with rate limiting and other signals and log decisions before blocking. The business impact of false positives is usually more visible than the CPU cost.
- Is Device Detector fast enough to run on every Laravel request?
- An uncached full parse walks a large regex corpus, so it is measurable at p95 in hot paths such as every request or every log line. Use a shared cache keyed on User-Agent and Client Hints, and cap attacker-controlled User-Agent length before parsing to limit regex input surface. Run parsing in middleware only on routes that need it, or move bulk log backfill into queued jobs. With caching and scoping it is usually fine; without them, treat it as a cost to budget.
- Is LGPL-3.0 licensing a problem for a commercial Laravel application?
- Using the unmodified library as a Composer dependency through dynamic autoloading is the standard, low-risk LGPL-3.0 pattern and does not require you to open-source your Laravel application. If you fork and ship modified library source, the source-availability obligations apply to the library itself. Have legal sign off once on that policy so the decision is not relitigated for every project.
- How current are detection rules, and what happens when they update?
- Detection accuracy is a function of how current the bundled rule files are, so new browser versions, bot families, and device models degrade silently between releases. Adopt releases on a defined cadence and decide in advance how rule changes affect analytics history, because re-parsing old traffic with new rules creates retroactive inconsistency. Store the raw User-Agent, Client Hints, and detector version alongside parsed output so you can explain and reproduce classifications later. A recent last-release date is a good signal but does not replace an update policy.
- Is matomo/device-detector actively maintained, and what are the alternatives for Laravel?
- Yes, it is backed by Matomo, has a long public history, and runs PHPStan, PHPUnit, PHPCS, and regex validation in CI. For Laravel alternatives, jenssegers/agent is a lightweight wrapper, whichbrowser/php and browscap offer different rule sets, and mobile-detect is simpler but narrower. Device Detector is usually chosen for breadth, including TV, console, car, wearable, and bot families, at the cost of heavier parsing and rule-maintenance dependency.
Weaver
How can I help you explore Laravel packages today?