Filament Notification Center Laravel Package

Getting Started

Verify your runtime first — this is the whole story of v1.1.0. The package now declares "php": "^8.3" in composer.json, correcting a v1.0.x constraint that was never actually satisfiable. The chain is: Filament v5 → livewire ^4.1 → the only Pest tooling supporting Livewire v4 requires PHP ^8.3. So on PHP 8.2 you don't get a runtime error, you get a Composer resolution failure — pest-plugin-livewire resolves down to v3 (capped at livewire ^3.5.6), which conflicts with Filament, and composer require dies before anything installs. Check php -v and any Docker/CI images before you start; if you were previously stuck on 8.2, this release is the one that unblocks you, but only by raising the floor.

1. composer require prodstarter/filament-notification-center on PHP 8.3+ with a Filament v5 panel already in place.
2. Publish and run migrations — the package ships a notifications table (or extends Laravel's). Use php artisan vendor:publish and pick the package's migration/config tags; the exact tag names are in the README under the package vendor namespace.
3. Register the plugin on your panel in app/Providers/Filament/*PanelProvider.php via the ->plugin(...) chain. The plugin FQCN lives at the root of the package's src/ — confirm it from the README rather than guessing, since the class name isn't referenced in these release notes.
4. php artisan migrate, then load the panel.

First use case: drop a bell/inbox into the topbar so authenticated users see unread notifications and can mark them read, without you building a Livewire component. That's the day-one win — everything else is configuration.

Implementation Patterns

Per-panel registration, not global. Filament plugins attach to a Panel, so in a multi-panel app (e.g. AdminPanelProvider + AppPanelProvider) you register it on each panel that needs an inbox. If only admins should see notifications, register it only there — this is the cheapest access control you get and it's easy to forget when you copy a provider.

Drive it with Laravel's native notification system. The idiomatic pattern is standard Notifiable + database channel: define an app/Notifications/* class, implement toDatabase(), and $user->notify(new ...). The center is a renderer over that data, so you keep all the existing Laravel affordances — queued notifications, via() routing, on-demand notifications — and don't learn a second API. Reach for the package's own send helper only if you need center-specific metadata (icon, colour, action URL) that a plain database notification can't carry.

Read state is the thing to design around. Decide early whether "read" is per-notification or a global "mark all as read", and whether the badge count polls or refreshes on navigation. Polling intervals are the usual config knob; a short interval on a busy panel will quietly add load, so set it deliberately rather than accepting the default.

Testing with Pest + Livewire v4. Use pest-plugin-livewire v4 (the reason your PHP floor is 8.3) and test the component directly: Livewire::test(...) for render/badge/mark-as-read, plus assertDatabaseHas on the notifications table after firing a notification. Set Notification::fake() for the sending side and test the center separately from the sender — mixing both in one test is where these suites get brittle.

Mirror the package's own CI lesson in your app's pipeline. The v1.1.0 fix is directly transferable: if your phpunit.xml has a <coverage> block and CI installs PHP without xdebug/PCOV, PHPUnit 12 emits a bootstrap warning — and if failOnWarning="true", the entire suite aborts with exit code 1 and zero tests executed. Symptom looks like "all tests failing"; reality is "no tests ran".

Gotchas and Tips

• PHP 8.3 is a hard floor, not a suggestion. This is a breaking change on paper even though the release notes call it a correction — if any environment in your matrix is 8.2, that environment now fails at install time. Update your CI matrix and composer.json platform config in the same commit as the bump.
• Livewire 4.1 is a major-version dependency. Audit your other Filament plugins before upgrading. One plugin still pinning Livewire 3 makes the whole panel unresolvable, and the error surfaces as a generic Composer conflict rather than naming the culprit — composer why-not livewire/livewire 4.1 is the fast diagnostic.
• v1.1.0 is behavior-free. No migrations, no config keys, no API changes — a safe composer update from v1.0.1. Don't schedule a regression pass for this alone; fold it into your next deploy.
• Broken README badges were a real signal, not cosmetics. The shields pointed at run-tests.yml / fix-php-code-style-issues.yml, neither of which exists (the actual files are tests.yml / fix-code-style.yml). If you forked this package, your fork is still showing "repo or workflow not found" — fix the badge URLs or you'll keep assuming CI is green when it isn't.
• Don't trust a green badge as proof of a passing suite for v1.0.x history. Tests genuinely failed on every run for the life of that release, so "it passed CI upstream" was never evidence for anything in 1.0.x. Test your integration yourself.
• Extension points to look for before forking: publishable views (swap the dropdown markup for a full page), publishable config (polling interval, per-panel toggles), and a bindable notification model. Confirm each from the README's publish tags — the release notes don't enumerate them, and guessing tags wastes a debugging cycle.

Debugging checklist when notifications don't appear: (1) plugin registered on this panel, (2) migrations actually ran in this database, (3) the notification used the database channel and via() returned it, (4) Notification::fake() left in a test but not in your local bootstrap, (5) queue worker running if the notification is queued.