tallcms/filament-registration
RouteNotFoundException: Route [verification.verify] not defined when ->emailVerification() is required. Register::handleRegistration() fires Laravel's Illuminate\Auth\Events\Registered event so non-Filament listeners (e.g. multisite site-plan assignment) keep working, but that also triggers Laravel's own auto-registered SendEmailVerificationNotification listener. Its default MustVerifyEmail::sendEmailVerificationNotification() builds Illuminate\Auth\Notifications\VerifyEmail, which resolves its link via route('verification.verify') — a route Filament-only apps never register, since they use panel-scoped verification routes instead. FilamentRegistrationServiceProvider now registers VerifyEmail::createUrlUsing() (guarded so it won't clobber a host's own callback) pointing at Filament::getVerifyEmailUrl(), so that listener's notification resolves a working link instead of crashing.sendEmailVerificationNotification() (called from register()) would each send a verification email. Register now detects when the Laravel listener already handled it (Event::getRawListeners()) and defers to it, falling back to Filament's native send only if that listener isn't registered — so exactly one email goes out.No breaking changes. No host User model changes required — both fixes are entirely package-side.
Fixes #3.
Full Changelog: https://github.com/tallcms/filament-registration/compare/v1.4.1...v1.4.2
RegistrationSettings can once again override the nav label and page title. v1.4.0's getNavigationLabel() / getTitle() returned the translated string unconditionally, ignoring static::$navigationLabel / static::$title. Both getters now check the static property first and fall back to the translation, restoring the documented subclass-and-override pattern (e.g. for settingsPage() Shield gating).No breaking changes. No migration steps required. Recommended upgrade for anyone on v1.4.0 who subclasses RegistrationSettings to customize its nav label or title.
lang/en/messages.php and lang/de/messages.php, and wired the RegistrationSettings admin page (nav label/group, page title, form labels/helpers, actions, notifications), the settings Blade view, CaptchaField, and the Register page's validation messages through __('filament-registration::messages.…'). Driven by the host app's APP_LOCALE; ships with English and German out of the box.No breaking changes. No migration steps required.
RegistrationSettings::getNavigationLabel() / getTitle() now return the translated string directly instead of checking static::$navigationLabel / static::$title first, so subclasses that override those properties to customize the nav label/title (e.g. for settingsPage() Shield gating) will find them silently ignored. A fix is planned for a follow-up patch release.
Adds Laravel 13 support. This was the last dependency blocking the standalone TallCMS skeleton from running on Laravel 13 — the core tallcms/cms package is already L13-ready.
illuminate/support widened to ^11.0 | ^12.0 | ^13.0orchestra/testbench ^11.0, spatie/laravel-permission ^7.0composer test / composer pint scripts added to match RELEASING.mdplugin.json version and backfilled the 1.2.0 CHANGELOG entryspatie/laravel-permission v6 or v7 (for role assignment)No breaking changes — existing Laravel 11/12 installs are unaffected. After updating, composer update on a TallCMS skeleton can move to Laravel 13.
Closes #1.
The service provider's `register()` method was calling `env()` directly to read `FILAMENT_REGISTRATION_CAPTCHA_*` defaults. This works fine in development (where `.env` is loaded on every request), but silently breaks on production deploys that run `php artisan config:cache` — Laravel intentionally skips `.env` loading once config is cached, so all `env()` calls outside of config files return `null`.
Symptom: env vars present on the server, plugin installed correctly, version reads as v1.1.x — but the captcha admin badge shows ✗ Not set, the captcha widget never renders, and registration silently falls back to `NullCaptchaProvider`.
v1.1.3 moves the env() calls into an internal package config file (`config/filament-registration.php`) loaded via `mergeConfigFrom()`. The values are now baked into `bootstrap/cache/config.php` at cache-time and read from there at runtime — the standard Laravel package pattern.
`composer install` alone is not enough — you also need to re-run the cache so the new config file's env() values get resolved:
```bash
composer install
php artisan config:cache # or php artisan optimize
sudo systemctl restart php8.4-fpm # or your PHP-FPM service
```
Verify with: ```bash php artisan tinker --execute="echo strlen((string) config('filament-registration.captcha.site_key', '')) . PHP_EOL;" ```
Should print a non-zero number (your site_key length).
If you don't run `config:cache` on deploy, just `composer update` is enough — both the v1.1.2 path (direct env() in register()) and v1.1.3 path (config file via mergeConfigFrom) work identically without caching.
`mergeDbSettingsIntoConfig()` was overriding runtime config for any key present in `tallcms_registration_settings` — even when the stored value was an empty string. The most common way to hit this:
The captcha widget silently disappears with no error in the logs. Hard to diagnose because env DOES work end-to-end if the DB row doesn't exist; it's specifically the DB-merge step that breaks the chain.
v1.1.2 skips null and empty-string DB values in the merge so env wins for genuinely-unfilled keys. Booleans (including `false` for an intentional disable), numbers (including `0`), and non-empty strings all still override env as before.
`composer update tallcms/filament-registration` is enough — no DB migration, no config changes needed.
Without an explicit label, Filament humanises the underlying token field name (`cf-turnstile-response` or `g-recaptcha-response`) and renders "Cf turnstile response" / "G recaptcha response" as a label heading above the captcha widget — confusing for end users since the widget itself is self-explanatory.
v1.1.1 sets an accessible "Verification" label and hides it visually with `hiddenLabel()`. Screen readers and validation messages still get a sensible identity.
No code or config changes needed for upgraders. `composer update tallcms/filament-registration` is enough.
v1.0.0 over-coupled the plugin to TallCMS conventions. v1.1.0 unwinds two of those:
spatie/laravel-permission is now optional (moved from require to suggest). The Register page guards role assignment with class_exists(Spatie\\Permission\\Models\\Role::class), so hosts that don't use Spatie roles get a no-op instead of a fatal class-not-found. Hosts that do use Spatie continue to work unchanged.HasPageShield removed from the default RegistrationSettings page. Filament Shield is no longer a required dependency. By default the settings page is accessible to any user who can reach the panel; hosts wanting stricter gating subclass and pick their own approach (Shield, plain canAccess(), or panel middleware). README has copy-paste examples for each.If you installed v1.0.0 and ran shield:generate --page=RegistrationSettings, the View:RegistrationSettings permission row is now orphan but harmless — the page no longer reads it. To restore Shield-based gating in v1.1.0, subclass the page in your app and add the HasPageShield trait (full snippet in the README).
A composer update tallcms/filament-registration is enough. If you previously relied on Shield gating on the settings page, follow the migration note above.
A Filament v5 plugin that provides a customised Register page with pluggable captcha (Cloudflare Turnstile, Google reCAPTCHA v3) and configurable default-role assignment. All customisations flow through documented Filament hooks (form(), mutateFormDataBeforeRegister(), handleRegistration()) — no register() reimplementation, no internal copy-paste.
\Filament\Auth\Pages\Register. Login ↔ register cross-linking works for free.Illuminate\Auth\Events\Registered is fired alongside Filament's own Filament\Auth\Events\Registered event, so listeners written for the Laravel event keep working unchanged.Filament\Auth\Http\Responses\Contracts\RegistrationResponse) — hosts can swap the post-registration redirect for an onboarding flow without subclassing the page.->emailVerification() panel method.```bash composer require tallcms/filament-registration php artisan migrate ```
Wire up your panel:
```php use Tallcms\FilamentRegistration\Filament\FilamentRegistrationPlugin; use Tallcms\FilamentRegistration\Filament\Pages\Register;
public function panel(Panel $panel): Panel { return $panel ->id('admin') ->path('admin') ->login() ->registration(Register::class) ->plugin( FilamentRegistrationPlugin::make() ->defaultRole('member') ); } ```
Both `->registration(Register::class)` and `->plugin(FilamentRegistrationPlugin::make())` are required — the first tells Filament which page handles the route, the second registers the admin settings page and exposes the chainable config.
This plugin is the upstream extraction of the captcha pipeline + Filament-native register page. If you were using `tallcms/tallcms-user-registration-plugin` v1.x, see that plugin's v2.0.0 release for the migration runbook — it now depends on this package and adds TallCMS-specific glue (onboarding redirect, default site-plan assignment) on top.
How can I help you explore Laravel packages today?