Statamic Livewire Search Laravel Package

Getting Started

1. Install and check compatibility first. composer require jonassiewertsen/statamic-livewire-search, then immediately open its composer.json and confirm the Livewire constraint. Because the repo is archived, this is the single most important step — the package may target Livewire 2 or 3, and you need to know which before wiring anything up.
2. Publish what it ships. Run php artisan vendor:publish and look for a provider tag (usually statamic-livewire-search). This typically exposes the Blade view (and sometimes a config for result limits/index name) so you can edit markup instead of patching vendor files.
3. Read the two files that matter. Find the Livewire component class (usually src/Search.php or similar) and its view under resources/views. Between those two you can see the property name being searched, how results are fetched (almost certainly Statamic\Facades\Search::index(...)->search(...)), and what data the view receives.
4. Build the Statamic search index. This package is a thin UI over Statamic's built-in search. Confirm config/statamic/search.php has an index, then run php please search:update. Without this you get an empty result set and will waste an hour debugging the component.
5. Drop it into a layout. Add <livewire:search /> (or @livewire('search') on Livewire 2) to your header/nav partial. Confirm @livewireStyles and @livewireScripts are present in your layout — Livewire components silently do nothing without them.

First use case: a header search box on a content-heavy marketing site that returns entry titles and URLs as the user types, dropping into a results page or a dropdown. That is the package's entire sweet spot — don't expect faceting, typo tolerance, or relevance tuning out of the box.

Implementation Patterns

• Wrap, don't fork. Create App\Livewire\SiteSearch extends \Jonassiewertsen\...\Search and override render() or the query method. Render your component in the layout (<livewire:site-search />), leaving an upgrade path and a clean place to patch behavior if the vendor package ever breaks.
• Own the view. Publish and modify the Blade file rather than styling via the vendor path. Typical changes: result limit, aria-live region, wire:key per result, and truncating long excerpts.
• Debounce at the input. For Livewire 3, the view must use wire:model.live.debounce.300ms="search" — plain wire:model is deferred and will look broken. Keep the debounce in your published view so it survives component upgrades.
• Keep the index fresh. Register a listener on EntrySaved / EntryDeleted that calls the search index insert/update (or dispatch php please search:update from a queue job). This is the integration point most people forget; a stale index is indistinguishable from a broken component.
• Scope results by collection. If the site has a blog and docs section, either create two wrapper components passing a collection filter into the query, or expose a public $collection property and set it from the parent view (<livewire:site-search collection="blog" />).
• Progressive enhancement fallback. Pair the Livewire component with a plain GET /search form action so no-JS users (and crawlers) still get results. The live dropdown is an enhancement, not the feature.
• Test with Livewire's harness. Livewire::test(SiteSearch::class)->set('search', 'foo')->assertSee('Foo Result'). This catches the common breakage where the property name or query method changed.
• Keyboard navigation. Alpine handles arrow keys/escape on top of the Livewire-rendered list; keep the data in Livewire and the focus behavior in Alpine. Don't try to do focus management in PHP.

Gotchas and Tips

• Archived = your problem now. No security patches, no Livewire 4 compatibility, no PHP 8.4 fixes. Pin the exact version in composer.json, and budget for either a fork or a 40-line replacement component using Statamic's Search facade directly. Honestly, the facade version is not much more work and removes the dependency entirely.
• Livewire 2 → 3 property binding is the #1 breakage. If your app is on Livewire 3 and the package was written for 2, search-as-you-type silently stops working (no error, just no requests). Check the rendered input for wire:model vs wire:model.live before debugging anything else.
• Empty results usually mean an empty index, not a broken component. Run php please search:update and verify from php artisan tinker with Search::index('default')->search('term') before touching the view.
• Only indexed fields are searchable. Titles and content are indexed by default; custom fields (or data inside Bard/Replicator sets) often are not. Fix in config/statamic/search.php, not in the Livewire component.
• Two instances on one page clash. Give each a unique wire:key or the components will fight over state. Same for the input id attribute — duplicate IDs break label/aria-controls wiring.
• XSS on result output. If the published view uses {!! $result->title !!} to highlight matched terms, sanitize with e() or strip_tags() first. The package can't protect you here.
• No pagination out of the box. Set a hard result cap (5–10 for a dropdown, ~20 for a results page) — an unbounded live query against a large index is a cheap way to make a slow page.
• Config quirks live in Statamic, not the package. Driver (local vs. Algolia), index name, and searchable fields are all Statamic settings. When something behaves oddly, check config/statamic/search.php and any cached config (php artisan config:clear) before assuming the package is at fault.
• Extension points are just three: published views, the config/view namespace, and subclassing the component. There's no event system or driver abstraction to hook into. Plan accordingly.
• Accessibility pass required. Live regions (aria-live="polite"), role="listbox"/option for the dropdown, and Escape-to-close are almost never included. Budget a small sprint for it.