- Does jhumanj/laravel-model-stats support Laravel 11 and Laravel 12?
- The last tagged release was August 2023, which targets the Laravel 9/10 era and PHP 8.1+, so Laravel 11 and 12 compatibility is not officially verified. Because the package is a thin service provider, a config file, routes, and stat closures, it often works after widening the illuminate/* constraint in a fork. Run composer why-not jhumanj/laravel-model-stats against your target framework to see how far behind it is. Budget a small fork with a CI job that runs your app's test suite on every Laravel upgrade.
- How do I install laravel-model-stats in a Laravel app?
- It is a Composer-only install: require jhumanj/laravel-model-stats, then publish the package config and any publishable dashboard assets with the vendor:publish command documented in the readme. No npm build of your own is normally required because the front-end assets ship pre-compiled. Pin the version in composer.json and install it behind a feature flag on a namespaced route prefix such as /admin/stats so you can pull it without touching application code.
- How do I define a statistic for an Eloquent model?
- Stats are written as closures or small classes that run an aggregate query against an Eloquent model and are registered in the package config. A typical definition returns a count, a sum, or a value grouped by day so the dashboard can render a number or a trend line. Keep each closure explicit about the time window and the columns it filters on, and prefer indexed timestamp columns over whereDate on large tables.
- Does laravel-model-stats publish migrations or write to my database?
- It is an additive, read-only presentation layer with no data store of its own, so it introduces no schema coupling and no dual-write problem. You should still confirm after installing whether any migrations are published, but expect none. Because nothing is persisted, removing the package is a composer remove plus deleting your stat definitions.
- Are the statistics computed on every request, and can I cache or queue them?
- Stats are aggregate queries executed when the dashboard is loaded, and there is no documented rollup or queue layer built into the package. On production-sized tables that means naive count and group-by-day queries can turn an admin page refresh into sequential scans. Mitigate with proper indexes, a short-lived cache in front of the closures, or scheduled jobs that write pre-aggregated values to a rollup table the stats then read. Treat your initial spike as a query-cost experiment rather than a UI experiment.
- How do I secure the model stats dashboard routes in production?
- Assume authorization is left to the integrator rather than enforced by the package, and gate the routes yourself. Put them behind your auth middleware plus an explicit gate or policy restricted to staff or operator roles, and use a namespaced prefix such as /admin/stats so they are easy to audit. In-app dashboards are a recurring source of accidental exposure, so verify with a non-admin account in staging before shipping.
- Does it respect Eloquent global scopes and multi-tenant scoping?
- Stat closures built on normal Eloquent query builders inherit global scopes, so tenant filters usually apply automatically. The risk is closures that drop to raw SQL, call withoutGlobalScopes, or query another connection, because those bypass scoping and become cross-tenant leak vectors. Review every stat definition before enabling it in a multi-tenant admin console, and test the dashboard while authenticated as two different tenants.
- Does laravel-model-stats need an npm build, and is it Octane-safe?
- It ships a Blade and Vue based dashboard, and installs typically require publishing the package's compiled assets, but you should not need to run your own npm build. Octane safety is not verified for the 2023 release, so check the service provider for static state or config reads that only happen at boot before running it under Laravel Octane. If you need certainty, test the dashboard under Octane on staging with config and route caching enabled.
- Should I use laravel-model-stats or a BI tool like Metabase or Redash?
- If your team already runs Metabase, Redash, or Looker, adding an in-app dashboard creates a fourth place operators look for numbers instead of the second. The package fits best when you want a lightweight analytics tab inside an existing Laravel admin console for a handful of agreed metrics. Use it alongside a BI tool only when the numbers must be visible to staff who will never get BI access.
- Is laravel-model-stats still maintained, and what is the upgrade risk?
- Last release was August 2023 with roughly 242 stars and effectively a single maintainer, so assume maintenance staleness and plan for the possibility that you become the maintainer. Compatibility with newer Laravel and PHP versions should be treated as requiring a fork or patch until proven otherwise. The upside is low lock-in: nothing is persisted, so you can delete the package and keep your favourite queries as scheduled jobs writing to a rollup table.