Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Matomo Laravel Package

jeffersongoncalves/filament-matomo

filament-matomo by jeffersongoncalves brings Matomo analytics into Filament. Add dashboard widgets and reports to view visits, page views, referrers, and traffic insights directly in your admin panel, keeping key metrics accessible without switching apps.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Panel UX and information architecture: Plugin::make()->navigationGroup(string|Closure) lets a product team place the settings/analytics page inside an existing panel navigation group instead of the package's default translated group. This is a small but user-visible customization that supports decisions about where analytics configuration lives in the admin experience (e.g., "Settings" vs. "Insights" vs. a bespoke operations group).
  • Multi-panel and white-label rollouts: Because the group accepts a Closure, the destination can be resolved dynamically per panel, tenant, or user role. That makes the package more viable for products that ship several Filament panels (customer-facing admin, internal ops, tenant dashboards) without forking views or writing custom navigation.
  • Build vs. buy: The change reduces the marginal cost of adopting the package over hand-rolling a settings page — customization no longer requires overriding navigation registration. It strengthens the "buy/adopt" case for teams already standardized on Filament.
  • Roadmap signal: A navigation affordance is typically requested by teams in production, not evaluation. Treat this as a maturity indicator: the maintainers are responding to real deployment friction rather than adding surface area, which is a positive signal for continued investment.
  • Use cases unlocked: consolidated admin menus, role-conditional placement of analytics settings (e.g., only surfaced to admins), and localizing/renaming the group without touching translations.
  • Not a differentiator: This does not change the package's core capabilities. It should not, on its own, move a roadmap decision — it's a polish item that removes a customization workaround.

When to Consider This Package

Adopt when:

  • The product is built on Filament and needs a settings/analytics surface inside the admin panel rather than a separate app.
  • You run multiple panels or multi-tenant deployments and need navigation placement to vary by context — the Closure form of navigationGroup covers this without custom code.
  • You have opinionated navigation (branded group names, consolidated "Settings" sections) and previously would have had to fork the plugin to reposition its page.
  • You are already on filament-analytics-core 3.1+; the feature is gated on that version, so confirm the dependency before committing.

Look elsewhere or defer when:

  • You are on an older filament-analytics-core and cannot upgrade — the default translated group is retained, so the new capability is unavailable and the customization value doesn't apply.
  • Your admin surface is not Filament-based; the plugin's value is tightly coupled to the Filament panel model.
  • You need analytics reporting/visualization rather than a settings/configuration entry point — evaluate whether this package's scope actually matches the requirement.
  • Navigation placement is the primary reason you're evaluating it. This is a convenience, not a reason to adopt; the decision should rest on the core feature set.

Also verify upgrade risk: the change is additive and defaults to existing behavior ("without it the translated group is kept"), so it should be non-breaking — but confirm the filament-analytics-core version constraint in your lockfile before scheduling the bump.

How to Pitch It (Stakeholders)

To executives: This release is a low-risk, additive customization that lets our Filament admin panel present the analytics settings page wherever it best fits our navigation — including per-panel and per-role. There are no breaking changes, and default behavior is unchanged if we do nothing. It modestly lowers the cost of keeping this package versus maintaining our own settings page, and it signals the maintainers are shipping based on real customer feedback. No budget or timeline impact; treat it as routine maintenance.

To engineering: Plugin::make()->navigationGroup(string|Closure) overrides the default translated navigation group for the settings page, with closure support for dynamic resolution per panel/tenant/role. Requires filament-analytics-core >= 3.1. The change is additive and backwards compatible — omitting the call preserves current behavior, so the upgrade is a safe patch-level bump. Recommend including it in the next dependency refresh, and using the closure form where we already branch navigation by tenant or role rather than maintaining a local plugin fork. Worth a quick check that our panel navigation tests assert group membership, since that's the only behavior surface that moves.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle