After a self-signup student clicks their confirmation email link, the registration page showed the "email confirmed, awaiting approval" message with the full registration form still rendered underneath — useless at that point (re-submitting would fail with "an account already exists") and confusing about what to do next. The page now shows only the confirmation message plus a "Sign in to your account" link. A confirmed-but-unapproved student can already log in — the pending gate only withholds booking — so signing in is the natural next step; they'll see the "awaiting approval" screen on the booking page until approved.
How it works
templates/frontend/register-page.php — the us_confirmed=1 case moves up to the top-level branch chain, so it renders the message + sign-in link and never falls through to the form. The expired notice keeps the form as before (that visitor may be following a stale link or need to contact the studio).
Auth\RegistrationPage computes the link target. There is no stored login-page setting, so this follows Booking\BookingPage's existing pattern: a loginPageId block attribute / login_page_id shortcode attribute ([us_student_register login_page_id="…"]), falling back to wp_login_url() — the same fallback the approval email uses.
The Student Registration block gains an "After email confirmation" inspector panel with the same page picker the booking block uses (assets/js/blocks.js), and the attribute is declared server-side in BlockRegistrar so the editor preview accepts it.
Tests
Four new render-level tests in RegistrationPageTest (confirmed → link shown and no form; configured sign-in page used; normal render still shows the form; expired still shows the form), plus the updated attribute-schema assertion in BlockRegistrarTest.
Closes #67
## What & why
After a self-signup student clicks their confirmation email link, the registration page showed the "email confirmed, awaiting approval" message with the full registration form still rendered underneath — useless at that point (re-submitting would fail with "an account already exists") and confusing about what to do next. The page now shows only the confirmation message plus a **"Sign in to your account"** link. A confirmed-but-unapproved student can already log in — the pending gate only withholds booking — so signing in is the natural next step; they'll see the "awaiting approval" screen on the booking page until approved.
## How it works
- `templates/frontend/register-page.php` — the `us_confirmed=1` case moves up to the top-level branch chain, so it renders the message + sign-in link and never falls through to the form. The `expired` notice keeps the form as before (that visitor may be following a stale link or need to contact the studio).
- `Auth\RegistrationPage` computes the link target. There is no stored login-page setting, so this follows `Booking\BookingPage`'s existing pattern: a `loginPageId` block attribute / `login_page_id` shortcode attribute (`[us_student_register login_page_id="…"]`), falling back to `wp_login_url()` — the same fallback the approval email uses.
- The Student Registration block gains an "After email confirmation" inspector panel with the same page picker the booking block uses (`assets/js/blocks.js`), and the attribute is declared server-side in `BlockRegistrar` so the editor preview accepts it.
## Tests
Four new render-level tests in `RegistrationPageTest` (confirmed → link shown and no form; configured sign-in page used; normal render still shows the form; expired still shows the form), plus the updated attribute-schema assertion in `BlockRegistrarTest`.
- `composer test` — 365 tests pass
- `composer lint` — PHPStan level 10 clean
- `composer cs` — PHPCS clean
Docs updated: `docs/features/account-registration.md`, `docs/features/editor-blocks.md`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Closes#67
When a student lands on the registration page from the confirmation
email (?us_confirmed=1), replace the registration form with the
confirmation message and a "Sign in to your account" link — the form
is useless at that point and re-submitting would only produce an
"account already exists" error. A confirmed-but-unapproved student can
already log in (the pending gate only withholds booking), so signing in
is the natural next step.
The link target follows the booking block's pattern: a loginPageId
block attribute (page picker in the editor sidebar) or login_page_id
shortcode attribute, falling back to wp_login_url(). The expired-link
notice keeps the form as before.
Co-Authored-By: Claude Fable 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #67
What & why
After a self-signup student clicks their confirmation email link, the registration page showed the "email confirmed, awaiting approval" message with the full registration form still rendered underneath — useless at that point (re-submitting would fail with "an account already exists") and confusing about what to do next. The page now shows only the confirmation message plus a "Sign in to your account" link. A confirmed-but-unapproved student can already log in — the pending gate only withholds booking — so signing in is the natural next step; they'll see the "awaiting approval" screen on the booking page until approved.
How it works
templates/frontend/register-page.php— theus_confirmed=1case moves up to the top-level branch chain, so it renders the message + sign-in link and never falls through to the form. Theexpirednotice keeps the form as before (that visitor may be following a stale link or need to contact the studio).Auth\RegistrationPagecomputes the link target. There is no stored login-page setting, so this followsBooking\BookingPage's existing pattern: aloginPageIdblock attribute /login_page_idshortcode attribute ([us_student_register login_page_id="…"]), falling back towp_login_url()— the same fallback the approval email uses.assets/js/blocks.js), and the attribute is declared server-side inBlockRegistrarso the editor preview accepts it.Tests
Four new render-level tests in
RegistrationPageTest(confirmed → link shown and no form; configured sign-in page used; normal render still shows the form; expired still shows the form), plus the updated attribute-schema assertion inBlockRegistrarTest.composer test— 365 tests passcomposer lint— PHPStan level 10 cleancomposer cs— PHPCS cleanDocs updated:
docs/features/account-registration.md,docs/features/editor-blocks.md.🤖 Generated with Claude Code