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.Reported in #3.
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).lang/en/messages.php and lang/de/messages.php, and wired RegistrationSettings (nav label/group, page title, form labels/helpers, actions, notifications), the settings Blade view, CaptchaField, and Register page validation messages through __('filament-registration::messages.…'). Driven by the host app's APP_LOCALE; ships with English and German out of the box.illuminate/support to ^11.0|^12.0|^13.0. This was the last dependency blocking the standalone TallCMS skeleton from running on Laravel 13 (the core tallcms/cms package is already Laravel 13–ready). Dev dependencies bumped accordingly: orchestra/testbench ^11.0 and spatie/laravel-permission ^7.0 (Laravel 13 requires PHP 8.3+).composer test and composer pint to match the documented release workflow.php artisan config:cache on production deploys. The service provider was calling env() directly in register(), which silently returns null once Laravel's config cache is active (Laravel intentionally skips .env loading on cached deploys for performance). Symptom: dev (config:clear) worked perfectly, but production with cached config saw FILAMENT_REGISTRATION_CAPTCHA_* env vars resolve to empty/null at runtime — captcha falling back to NullCaptchaProvider regardless of what was in .env. Moved env() calls into an internal package config file (config/filament-registration.php) and load 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.If you're on a deploy that runs php artisan config:cache, after pulling v1.1.3 you must re-run the cache step so the new config-file values get baked in:
composer install
php artisan config:cache # or `php artisan optimize`
sudo systemctl restart php8.4-fpm
mergeDbSettingsIntoConfig() was overriding runtime config for any key present in tallcms_registration_settings, even when the stored value was an empty string. This silently broke env-driven setups where the user pressed Save in the admin form before filling all fields — a blank site_key in the DB would clobber a valid FILAMENT_REGISTRATION_CAPTCHA_SITE_KEY env var and the captcha manager would fall back to NullCaptchaProvider. The merge now skips empty-string and null values, so env wins when the DB row is unfilled. Booleans (including false), numbers (including 0), and non-empty strings all still override env as before.spatie/laravel-permission is now an optional dependency (moved from require to suggest). The Register page checks class_exists(Spatie\Permission\Models\Role::class) before attempting role assignment, so hosts that don't use Spatie roles get a no-op instead of a fatal class-not-found error. Spatie users continue to work without changes.HasPageShield trait 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 the page and either add HasPageShield (Shield users), override canAccess() (any custom check), or rely on panel authMiddleware.If you installed v1.0.0 and ran shield:generate --page=RegistrationSettings, the resulting 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, then point the panel at your subclass (the plugin's settings page registration accepts a config override; see README).
settingsPage() setter on the plugin for host-defined Shield gating of the captcha admin page.\Filament\Auth\Pages\Register. Implements customisations entirely via documented Filament hooks (form(), mutateFormDataBeforeRegister(), handleRegistration()) — no register() reimplementation.CaptchaProvider contract; new providers can be added without changing the page.FilamentRegistrationPlugin with chainable defaultRole(string|null) config. Logs a warning and skips role assignment if the configured role doesn't exist (so a misconfig doesn't block signups).RegistrationSettings Filament admin page for captcha configuration, gated through Filament Shield's HasPageShield trait (permission View:RegistrationSettings). Encrypts secret keys at rest.Illuminate\Auth\Events\Registered is dispatched alongside Filament's Filament\Auth\Events\Registered, so existing Laravel-event listeners keep firing.RegistrationResponse (Filament's contract) so hosts can swap the post-register redirect — useful for onboarding flows.tallcms_registration_settings (guarded with Schema::hasTable); fresh installs create it, existing tables are left untouched.tallcms/tallcms-user-registration-plugin v1.x/registered and /awaiting-verification flow; now defers entirely to Filament's ->emailVerification() panel method.How can I help you explore Laravel packages today?