Filament Profile Laravel Package

Getting Started

1. Install the package

   composer require ryangjchandler/filament-profile
   

   Check the composer.json constraint before installing — this package predates some Filament v3 APIs, so confirm it supports the Filament version in your app (v2 vs v3 plugin registration differs).

2. Register it on the panel that should expose profiles. In your PanelProvider:

   use RyanChandler\FilamentProfile\FilamentProfilePlugin; // verify exact FQCN in README
   
   public function panel(Panel $panel): Panel
   {
       return $panel
           ->plugin(FilamentProfilePlugin::make());
   }
   

   If the package ships as a page rather than a plugin, add it to ->pages([...]) instead. The README is the source of truth here; the surface area is small, so read it end-to-end before writing code.

3. Publish config/views if offered (tag names vary):

   php artisan vendor:publish --tag=filament-profile-config
   php artisan vendor:publish --tag=filament-profile-views
   

4. First use case: log in as a normal user, open the user menu in the top-right, click Profile, and edit name/email/password. That round-trip tells you whether the page is registered, whether the form hydrates with the authenticated user, and whether saving persists correctly — the three things this package exists to do.

Where to look first: the registered page class (usually RyanChandler\FilamentProfile\Pages\Profile), its form()/getFormSchema() method, and the User model it assumes. If your auth model differs (custom table, UUIDs, extra required fields), start there.

Implementation Patterns

Scope it to the right panel. Register the plugin only on the panel where end users authenticate. In a multi-panel app (e.g. Admin + App), adding it to both is usually wrong — admins editing their own profile from the admin panel is rarely desired.

Treat the package as a baseline, not a fixed form. The common pattern is to subclass the page and override the schema:

class Profile extends \RyanChandler\FilamentProfile\Pages\Profile
{
    protected function getFormSchema(): array
    {
        return [
            TextInput::make('name')->required()->maxLength(255),
            TextInput::make('email')->email()->required()
                ->unique(ignoreRecord: true),
            FileUpload::make('avatar')->image()->directory('avatars'),
            // wrap password fields in a section so they can be left blank
        ];
    }
}

Then register your subclass instead of the vendor page. This keeps upgrade diffs small and avoids editing vendor code.

Password handling is the one thing to get right. Two viable patterns:

• Let the package hash it (check the source first — do not assume).
• Override the save behaviour and hash explicitly:

  ->dehydrateStateUsing(fn ($state) => filled($state) ? Hash::make($state) : null)
  ->dehydrated(fn ($state) => filled($state))
  

  The dehydrated guard is essential — without it you will null out the user's password every time they edit their name.

Add a "current password" gate for credential changes. A profile page that lets an authenticated session change email/password without re-confirmation is a security smell. Either prompt for the current password or route sensitive changes through a separate, re-authenticated flow.

Notify after save. Filament's Notification::make()->success()->send() in a save hook is the idiomatic touch and confirms the write actually happened (useful when password hashing silently fails).

Integrate with the rest of the panel via the user menu. Filament exposes menu registration hooks; if the package's menu item doesn't fit your layout (e.g. you want it inside a dropdown with "Log out"), move it there rather than bolting on a second link.

Gotchas and Tips

• Filament version compatibility is the biggest risk. Plugin registration, getFormSchema() visibility, and page base classes changed between v2 and v3. Pin the package version and run the panel test suite before upgrading Filament. If the package is unmaintained for your Filament version, fork the single page class — it is small and cheaper than fighting the constraints.

• Email uniqueness must ignore the current user. ->unique(ignoreRecord: true) on a page that is not a resource edit form can behave unexpectedly because there is no bound record. Use ->unique(table: 'users', column: 'email', ignorable: auth()->user()) explicitly.

• Password fields need dehydrated() guards. As above — the most common production bug with profile pages is a blank password overwriting the hash. Test by editing only the name and asserting the password still authenticates.

• Restrict page access. The page is exposed to every authenticated user by default. Override canAccess() / shouldRegisterNavigation() if profiles should be limited (e.g. only verified users, or disabled entirely for impersonated sessions).

• Tenancy. If you use Filament's tenancy, the profile page does not automatically know about the current tenant. Decide whether profile data is global (typical for users) or tenant-scoped; the latter needs custom queries in the page.

• Route/cache debugging.

  php artisan route:list | grep -i profile
  php artisan filament:cache-components   # after changing pages/plugins
  php artisan optimize:clear
  

  A missing menu item is almost always a cached component registry or the plugin registered on a different panel.

• Extension points to prefer: subclass the page, publish and override the Blade view, and publish the config. Avoid vendor/ edits — the package is small enough that a fork is viable, but a subclass keeps you on the upstream track.

• Test the round-trip, not the happy path. Verify: (a) form hydrates existing values, (b) name-only edit preserves email and password, (c) email collision shows a validation error, (d) password change actually re-hashes and the old password stops working. Those four assertions catch nearly every real bug in this class of plugin.