Filament Discord Logger Laravel Package

Getting Started

This release adds one small but useful API on the plugin object: Plugin::make()->navigationGroup(string|Closure). It controls which navigation group the package's settings page is rendered under in your Filament panel.

Minimal setup:

1. Ensure filament-analytics-core is at ^3.1 — the new method depends on it. Bumping the plugin without bumping core will leave you with a method that either doesn't exist or is ignored.
2. Register the plugin as usual in your panel provider, chaining the new call:

use Filament\Panel;
use Vendor\Analytics\Plugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(
            Plugin::make()
                ->navigationGroup('Insights'),
        );
}

3. First use case: you already have a curated nav (e.g. "Settings", "Reporting", "Insights") and the plugin's default, translated group label doesn't match your panel's vocabulary. One chained call puts it where you want it.

Where to look first: the plugin class itself (Plugin::make()) and its register()/boot() methods, plus the settings page class's getNavigationGroup(). The new setter almost certainly overrides what that page returns.

Implementation Patterns

Static group for a consistent panel. The common case — the settings page should sit alongside your other admin pages:

Plugin::make()->navigationGroup('Settings')

Match the exact string used by your other resources/pages. Filament groups by label string, so 'Settings' and 'settings' are two different groups.

Closure for contextual grouping. Pass a closure when the group depends on runtime state — the current panel, the authenticated user, or a feature flag:

Plugin::make()->navigationGroup(
    fn () => filament()->getCurrentPanel()->getId() === 'admin'
        ? 'Administration'
        : 'Reports'
)

Because it's a closure, it is evaluated at render time. Don't assume the same page renders under one group everywhere; if you rely on grouping for tests or assertions, resolve it the same way the page does.

Opting back into the default. Simply omit the call. The package keeps its translated group when navigationGroup() is never invoked — which is the right choice for multi-locale panels where the shipped translations are better than a hard-coded English string. If you've set it conditionally, guard the chain rather than passing null:

$plugin = Plugin::make();

if ($useCustomGrouping) {
    $plugin->navigationGroup('Insights');
}

Pairing with sort order. Grouping alone doesn't control position. Combine with the package's navigation sort (or your panel's ordering) so the page lands predictably inside the group it now belongs to.

Per-panel configuration. Register the plugin in each panel provider with different groups — this is the cleanest way to get "Settings" in the admin panel and "Reports" in a customer-facing panel without any conditional logic.

Gotchas and Tips

• Version alignment is the real risk here. The method silently does nothing if filament-analytics-core is below 3.1, or throws a BadMethodCallException if the plugin delegates to core and the core version is old. Pin filament-analytics-core: ^3.1 explicitly in composer.json rather than relying on the plugin's constraint being correct, and check composer show after upgrading.
• The string is not translated for you. The default group is translated by the package; a string you pass is used verbatim. Wrap it yourself: ->navigationGroup(__('nav.insights')). In a multi-locale panel, hard-coding English silently degrades UX for other locales.
• Group label must match existing labels exactly (including case and whitespace) or you get a new orphan group at the bottom of the sidebar. When in doubt, copy the label from the resource or page you want to sit next to.
• Closures and caching. If your closure reads config or the current panel, remember php artisan config:clear / optimize:clear when debugging stale results — Filament caches navigation in some setups, and a "my closure isn't running" report is usually a stale cache or a panel instance built before your change.
• Closure return type. Return a string. Returning null from a closure is not the documented way to fall back to the default translated group — skip the call instead, otherwise you may end up with a blank or null-labelled group depending on how the page resolves it.
• Test the navigation, not the setter. Assert on the rendered navigation / getNavigationGroup() output rather than on the plugin's internal property, so you catch a core version mismatch or a later refactor in the plugin.
• Extension points stay the same. navigationGroup() is a fluent setter — keep chaining other plugin configuration after it; there's no ordering requirement relative to other Plugin::make() calls in this release.
• No breaking changes. Existing panels that never call navigationGroup() behave identically to before; the translated default is preserved, so this is a safe minor upgrade once core is bumped.