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 Omnisearch Laravel Package

ifsware/filament-omnisearch

Add a fast global omnisearch and command palette to Filament panels, letting users jump to resources, pages, and records from one search box. Lightweight, keyboard-friendly, and easy to install.

View on GitHub
Deep Wiki
Context7

Getting Started

ifsware/filament-omnisearch is a Filament panel plugin that adds a command-palette-style global search modal (think Cmd+K / Ctrl+K) so users can jump straight to records, resources, and pages without navigating menus. The v1.1.0 release is a small, non-breaking polish release: dashboard panel names are now genericized (relevant if you run multiple panels), and the footer brand text is configurable for white-labeling.

Minimum steps:

composer require ifsware/filament-omnisearch
php artisan vendor:publish --tag="filament-omnisearch-config"

Register the plugin on the panel(s) you want it enabled for, in your PanelProvider:

use Ifsware\FilamentOmnisearch\OmnisearchPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(OmnisearchPlugin::make());
}

Where to look first

  1. The publishable config file (config/filament-omnisearch.php) — this is where the new v1.1.0 footer/brand text key lives, plus any shortcut, debounce, and search-scope settings.
  2. The plugin class itself (OmnisearchPlugin) — check which fluent/static setters it exposes before reaching for config.
  3. The README, which typically documents the keyboard shortcut and any supported options.
  4. Your resources' global search methods (getGloballySearchableAttributes(), getGlobalSearchResultUrl(), getGlobalSearchResultDetails()) — Omnisearch can only search what your resources expose.

First use case: open any panel page, hit the shortcut, type a few characters of a record title, and confirm you can jump directly to the record's edit/view page. If results appear but links 404, the problem is almost always your resource's global search URL, not the plugin.

Implementation Patterns

Per-panel enablement. The plugin is registered on a specific panel, so you can ship the palette to admin panels while omitting it from lightweight customer-facing panels. This is exactly the scenario v1.1.0's "genericize panel names on dashboard" change improves — if you register the plugin across several panels, the dashboard no longer hardcodes a single panel name.

Lean on Filament's global search contract rather than the plugin. Day-to-day, the palette is a UI over Filament's existing global search. That means your work happens in resources:

protected static ?string $recordTitleAttribute = 'name';

public static function getGloballySearchableAttributes(): array
{
    return ['name', 'email', 'company.name'];
}

public static function getGlobalSearchResultDetails(Model $record): array
{
    return [
        'Company' => $record->company?->name,
        'Email'   => $record->email,
    ];
}

Everything you already know about limiting search results (getGlobalSearchResultUrl(), returning null from getGlobalSearchResultUrl() for sensitive models, canGloballySearch()) carries over unchanged.

White-labeling / branding. With v1.1.0, set the footer brand text in config (or via the plugin's setter, if exposed) instead of overriding published views. Prefer the config path — view overrides are the first thing to break on the next upgrade:

// config/filament-omnisearch.php
'brand' => [
    'footer' => config('app.name'),
],

If you ship a multi-tenant SaaS, drive this from a tenant setting rather than a static config value, and clear the config cache per deploy.

Authorization comes for free — verify it anyway. Results are filtered by Filament's global search, which respects model policies. Add an explicit test that a user without viewAny on a resource cannot surface that resource's records through the palette; this is the highest-value regression test you can write for the package.

Testing. The palette is a Livewire component under the hood. Test the user-facing contract: assert the shortcut markup renders on a panel page, and assert search results resolve to the correct URLs. Avoid snapshot-testing the modal DOM — it will churn between releases.

Multi-panel rollout order. Enable on one panel, confirm search scope and shortcut behaviour, then enable on the rest. The v1.1.0 dashboard change means panel labels now come from the panel itself, so verify each panel's ->brandName() / ->id() produces sensible dashboard output after upgrading.

Gotchas and Tips

  • Config publishing after upgrade. v1.1.0 adds a configurable footer brand text. If you published config in v1.0, you may not have the new key. Re-publish and diff, or add the key manually — php artisan vendor:publish --tag="filament-omnisearch-config" --force will overwrite your customizations, so back up first.
  • Config cache. Branding changes silently not applying is nearly always php artisan config:cache stale. Add a cache-clear to your deploy script.
  • Resources without getGlobalSearchResultUrl(). Records surface in the palette but aren't clickable, or throw. Always define a URL for anything globally searchable.
  • Missing policies leak results. Global search is authorization-aware only if your policies are complete. An absent view policy method is not the same as a denial in every Filament version — audit this before enabling on a public panel.
  • Shortcut collisions. Cmd+K / Ctrl+K is contested by browsers, IDE-style embedded browsers, and your own Alpine components. If you already bind that combo, remap it in config and update your in-app docs, since users will report it as "broken."
  • Search performance. getGloballySearchableAttributes() with LIKE %term% on unindexed columns across large tables is the usual performance cliff. Cap attributes, add indexes, and consider Filament's search result limits before rolling out to a 100k+ row resource.
  • Upgrade risk from v1.0 → v1.1.0 is low. Both changes are additive/backwards-compatible (genericized panel names, configurable footer text). No deprecations or breaking API changes are signalled in the release notes — but do a visual pass on multi-panel dashboards, since "genericize panel names" changes rendered output.
  • Extension point to prefer: the config file and plugin fluent API. Overriding the package's Blade views or the Livewire component class couples you to internals that this release just demonstrated are still moving (branding, panel naming).
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.
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core