Filament Profile Laravel Package

Getting Started

This is the initial 1.0 release of iPatco/filament-profile, a Filament plugin that drops a Breeze-style profile page into a panel: profile form, active browser sessions, and an account widget, plus a configurable profile menu entry.

1. Install into an existing Filament panel:

   composer require ipatco/filament-profile
   

2. Register the plugin on the panel you want it in (app/Providers/Filament/AdminPanelProvider.php). Check the README for the exact FQCN — it follows the usual iPatco\FilamentProfile\...Plugin::make() convention:

   ->plugin(FilamentProfilePlugin::make())
   

3. Publish config and views so you can see what's configurable before you start overriding:

   php artisan vendor:publish --provider="iPatco\FilamentProfile\FilamentProfileServiceProvider"
   

4. Clear caches (php artisan optimize:clear, or at minimum route:clear / config:clear) and load the panel. A "Profile" item should appear in the user menu.

Where to look first: the published config file (menu registration flags, route/slug, middleware, form class), then the package's Pages/ directory to see the profile page class you'd extend. The profile page itself is the first real use case — log in as any user, hit the menu item, and confirm the form saves and the sessions list renders.

Implementation Patterns

Let the plugin own the menu item, or opt out. The headline feature in this release is configurable menu registration. For a single-panel app, leave it on and delete any hand-rolled ->userMenuItems([...]) profile link. For multi-panel apps or panels with a custom user menu, disable auto-registration and add the item yourself so you control ordering, icons, and visibility per guard.

Publish-then-extend, don't fork. The profile form is publishable. Publish the view/form class, then point the config at your own class rather than editing vendor files. This keeps you on the upgrade path for the page shell and sessions/account widget while letting you add fields (avatar, timezone, notification prefs) to the form.

Scope to the right guard. Register the plugin only on panels whose users you want to expose profile editing for. If you have separate admin and web guards with different user models, register per panel and verify the sessions/account widget resolve the correct Auth guard — the account widget in particular assumes a "current user" context and will misbehave if the panel guard doesn't match the page's expected guard.

Sessions block pairs with password confirmation. The "log out other browser sessions" action typically wants a password re-entry. If you gate the profile route behind password.confirm, test the flow end-to-end; if you don't, decide deliberately whether that's acceptable for your app and document it.

Treat it as a Breeze-parity surface, not a full auth module. This package gives you the profile page. Registration, password reset, and email verification still belong to Filament's auth features. Don't try to make this plugin replace them.

Testing. Feature-test the page with actingAs($user) and assert the form submits and the profile updates. For sessions assertions you'll need the database session driver in your test env — see gotchas.

Gotchas and Tips

• Session listing needs the database driver. If SESSION_DRIVER=file or cookie, the active-sessions section will be empty or absent. Switch to database (and run the sessions migration) if session management is the feature you actually want.
• Double menu entries. Enabling auto-registration and manually adding a profile userMenuItems entry is the most likely day-one mistake. Pick one.
• Fresh 1.0 = pin it. "ipatco/filament-profile": "^1.0" rather than dev-main, and check the composer constraints against your Filament major version before upgrading Filament. A brand-new plugin rarely has broad version ranges battle-tested yet.
• Route/config caching. New routes and menu registration won't appear until route:clear / config:clear; in deployed environments remember php artisan optimize after changing plugin config.
• Published views go stale. Once you publish and edit the profile view, upstream fixes to that view won't reach you. Diff published files against vendor on each upgrade, and keep overrides small.
• Extension points to prefer: config flags → plugin fluent methods → extending the page/form class → published view overrides (last resort). Staying left in that list keeps upgrades cheap.
• Debugging blank profile pages: check the panel's authGuard, the route middleware stack the plugin registers, and whether the user model implements the contracts Filament expects (FilamentUser, and whatever the account widget touches). Filament swallows a lot of this into a 403 rather than an exception.
• Account widget placement is a dashboard-widget concern; if it isn't showing, confirm the widget is registered on the panel's dashboard and that the user has permission to view the dashboard at all.