Filament Tawk To Laravel Package

Getting Started

composer require filament-analytics filament-analytics-core:^3.1
php artisan vendor:publish --tag="filament-analytics-config"
php artisan migrate

Register the plugin on the panel(s) you want the analytics settings page to appear in — usually app/Providers/Filament/AdminPanelProvider.php:

use FilamentAnalytics\Plugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugins([
            Plugin::make(),
        ]);
}

Where to look first:

1. config/filament-analytics.php — credentials, driver, caching, and whether the settings page is registered at all.
2. The plugin class itself (Plugin::make()) — every fluent setter on it maps to something the panel renders, so it is the fastest way to discover what is configurable without reading docs.
3. The generated settings page in the panel navigation — that page is the day-to-day surface for a non-technical stakeholder, and it's the thing this release changes.

First use case for 3.1.0: your panel already has semantic groups ("Reporting", "Configuration", "Integrations") and the settings page was dropping into a translated catch-all group. Now:

Plugin::make()
    ->navigationGroup('Configuration'),

Implementation Patterns

Keep plugin configuration in the panel provider, not in a service provider. Plugin::make() is a panel object; configuring it anywhere else means it won't be resolved per-panel, and multi-panel apps (Admin + Tenant) will fight over the same instance.

Group by intent, not by package. The value of navigationGroup() is that the analytics settings page stops looking like a vendor bolt-on:

Plugin::make()
    ->navigationGroup('Integrations'),

Use the Closure form for anything environment- or tenant-dependent. A closure is evaluated at render time, which is what you want when the group name comes from a translation file, a DB-backed setting, or the current tenant:

Plugin::make()
    ->navigationGroup(fn () => __('navigation.groups.reporting')),

Pair it with navigationSort() so the page lands predictably inside the group rather than wherever the vendor default puts it.

Mirror your panel's existing grouping strategy. If the rest of your panel uses enum-backed groups (Filament's NavigationGroup objects), don't assume they'll pass straight through — the signature is string|Closure. Wrap the label:

Plugin::make()
    ->navigationGroup(fn () => NavigationGroup::Reporting->getLabel()),

Multi-panel setups. Register the plugin separately in each panel and give each its own group — a "Settings" group makes sense in the admin panel, but in a tenant panel you probably want it under "Analytics" or hidden from navigation entirely. Duplicating a small Plugin::make()->navigationGroup(...) call per provider is clearer than a shared factory.

Gate visibility in the same place. Navigation grouping and authorization should be configured together so reviewers can see both in one diff:

Plugin::make()
    ->navigationGroup('Configuration')
    ->navigationSort(99)

…and then control access with a policy / canAccess() on the resulting page rather than trying to hide it via the group name.

Gotchas and Tips

• Hard dependency on filament-analytics-core:^3.1. The navigationGroup() method lives in core 3.1. If your composer.lock still pins 3.0.x, the method either doesn't exist (BadMethodCallException at boot) or — worse on a stale opcache/compiled container — silently keeps the translated default group. Run composer update filament-analytics-core and commit the lock file with the plugin bump.
• No navigationGroup() call = no change. The translated group is retained as the fallback, so a minor upgrade is safe, but you get zero benefit until you opt in. Don't expect the upgrade alone to tidy your sidebar.
• string|Closure only. Passing a Filament NavigationGroup enum/object won't type-check the way you expect from other panel APIs. If you standardise on enums elsewhere, convert to a string at the call site.
• Closures run on every navigation render. Keep them cheap — no N+1 queries or remote calls inside navigationGroup(), or you'll pay for it on every authenticated page load. Cache the underlying lookup if it's DB-backed.
• Clear caches after changing panel config. php artisan filament:optimize-clear (and config:clear) — panel providers and plugin registrations are cached by component/cache commands, and a changed nav group that "doesn't apply" is almost always stale cache.
• navigationSort is scoped to the group, not the whole sidebar. Moving the page into a new group changes what it's sorted against, so revisit any sort value you'd previously tuned.
• Extension point to watch: the plugin's fluent setters are the supported surface; avoid reaching into the settings page class directly to alter navigation, as that's the part most likely to move between minors. If you need behaviour the plugin doesn't expose, open an upstream issue rather than subclassing the page.
• Debugging tip: if the page vanishes from navigation after the change, it's usually navigationGroup(null)-adjacent behaviour or a group name that doesn't exist on that panel — Filament won't create the group for you, it just nests the item under that label.