Add an account block showing who is signed in #156

Merged
thatguygriff merged 2 commits from feature/142-account-block into main 2026-07-30 01:53:31 +00:00
Owner

Closes #142.

[us_account], or the Account block: the name and email of whoever is signed in, and a Sign out link. Nothing else.

Two decisions worth your eye

Signed out with no login page chosen, the block renders nothing. Its whole subject is the person signed in, which a stranger is not, and a bare "you are not signed in" in a site header is noise with no way to act on it. With a login page chosen it offers a Sign in link instead. The editor preview stays populated regardless, so the block is never an invisible box to whoever is placing it.

Signing out returns to the chosen login page, or the current page when there is none. A block meant for a header shouldn't also navigate someone somewhere when they use it. The login page wins when configured, since the page they were on may well be members-only.

The name comes from Auth\UserName::format(), so the block never exposes a username the way display_name can.

Also included

docs/features/editor-blocks.md was stale: it described "the plugin's four front-end shortcodes" and had never listed the family block. Both fixed while adding the account rows.

Verification

composer test (789, up from 782), composer lint, composer cs all pass. AccountPageTest covers each visitor state, both sign-out redirect targets, the shortcode attribute spelling, and a login page that has since been deleted (get_permalink() returning false). The two registrar tests that assert the full block and shortcode lists were updated.

Rendered both signed-in and signed-out states in a browser against the real stylesheet to check it sits sensibly at sidebar width.

Closes #142. `[us_account]`, or the **Account** block: the name and email of whoever is signed in, and a **Sign out** link. Nothing else. ## Two decisions worth your eye **Signed out with no login page chosen, the block renders nothing.** Its whole subject is the person signed in, which a stranger is not, and a bare "you are not signed in" in a site header is noise with no way to act on it. With a login page chosen it offers a **Sign in** link instead. The editor preview stays populated regardless, so the block is never an invisible box to whoever is placing it. **Signing out returns to the chosen login page, or the current page when there is none.** A block meant for a header shouldn't also navigate someone somewhere when they use it. The login page wins when configured, since the page they were on may well be members-only. The name comes from `Auth\UserName::format()`, so the block never exposes a username the way `display_name` can. ## Also included `docs/features/editor-blocks.md` was stale: it described "the plugin's four front-end shortcodes" and had never listed the family block. Both fixed while adding the account rows. ## Verification `composer test` (789, up from 782), `composer lint`, `composer cs` all pass. `AccountPageTest` covers each visitor state, both sign-out redirect targets, the shortcode attribute spelling, and a login page that has since been deleted (`get_permalink()` returning false). The two registrar tests that assert the full block and shortcode lists were updated. Rendered both signed-in and signed-out states in a browser against the real stylesheet to check it sits sensibly at sidebar width.
thatguygriff force-pushed feature/142-account-block from 4c92d19d2e to ca5fac5c06 2026-07-30 01:41:38 +00:00 Compare
thatguygriff added 2 commits 2026-07-30 01:42:49 +00:00
[us_account], or the Account block: the signed-in visitor's name, their
email, a Sign out link, and — only when the account books for someone
besides itself — the students it books for. A parent's first question on
seeing "signed in as Grace" is whether this is the account their children's
lessons are on.

Two decisions worth naming.

Signed out with no login page chosen, the block renders nothing. Its whole
subject is the person signed in, which a stranger is not, and a bare "you
are not signed in" in a site header is noise with no way to act on it. With
a login page chosen it offers a Sign in link instead. The editor preview is
populated regardless, so the block is never an invisible box to the person
placing it.

Signing out returns to the chosen login page, or to the current page when
there is none. A block meant for a header should not also navigate someone
somewhere when they use it; the login page wins when configured, because the
page they were on may well be members-only.

The name comes from UserName::format(), so the block never exposes a
username the way display_name can.

Also brings docs/features/editor-blocks.md back in step: it still described
"four shortcodes" and had never listed the family block.

Closes #142

Co-Authored-By: Claude Opus 5 <[email protected]>
Show only the name and email, not who the account books for
CI / Tests (PHP 8.2) (pull_request) Successful in 41s
CI / Tests (PHP 8.1) (pull_request) Successful in 42s
CI / No Debug Code (pull_request) Successful in 2s
CI / PHPStan (pull_request) Successful in 2m48s
CI / Coding Standards (pull_request) Successful in 3m1s
CI / Tests (PHP 8.3) (pull_request) Successful in 2m44s
CI / Build Plugin Zip (pull_request) Skipped
ab5212282d
The block reports who is signed in and nothing more. Dropping the "Booking
for …" line takes GuardianService with it — it was the only reason the page
had a dependency at all, so AccountPage now constructs with no arguments.

Co-Authored-By: Claude Opus 5 <[email protected]>
thatguygriff force-pushed feature/142-account-block from ca5fac5c06 to ab5212282d 2026-07-30 01:42:50 +00:00 Compare
thatguygriff merged commit 1b42d20541 into main 2026-07-30 01:53:31 +00:00
thatguygriff deleted branch feature/142-account-block 2026-07-30 01:53:31 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#156