-
v1.4.0
StableCI / Tests (PHP 8.2) (push) Successful in 45sCI / No Debug Code (push) Successful in 2sCI / Coding Standards (push) Successful in 2m54sCI / PHPStan (push) Successful in 2m55sCI / Tests (PHP 8.3) (push) Successful in 2m44sCI / Tests (PHP 8.1) (push) Successful in 53sRelease / Build and Publish Release (push) Successful in 3m1sRelease / Open next-version bump PR (push) Successful in 4sCI / Build Plugin Zip (push) Successful in 2m53sreleased this
2026-07-30 02:26:51 +00:00 | 17 commits to main since this releaseAdded
- An Account block (
[us_account]) showing who is signed in — their name and their email — and a Sign out link. Signing out returns to the login page chosen in the block, or to the page the visitor was already on when none is set, so putting it in a site header does not also move people somewhere. To a signed-out visitor it shows a Sign in link when a login page is chosen, and nothing at all when one is not: a panel about who is signed in has nothing to tell a stranger, and a notice they cannot act on is just clutter in a header.
Security
- Signup now checks the password properly. The form scores it as you type with the same zxcvbn meter wp-admin uses and will not submit a weak one, and the server refuses — regardless of what the browser allowed — anything shorter than 8 characters, one of the well-known leaked passwords, one built from barely any distinct characters, or one containing your own name or email address. Composition rules ("must contain a symbol") are deliberately not imposed: they mostly produce predictable substitutions. Email addresses are validated on the server on every signup path, with a clear message when one is already registered.
Changed
- Signup now asks "Who are you registering?" as a three-way choice — just myself, on behalf of one or more students, or both — in place of the single parent/guardian tick. The tick could only ever say "I have children to add"; it could not say whether the account holder was a student themselves, so every account was offered its own name in the Who is this for? picker whether or not anyone meant to book them a lesson. Choosing on behalf of now leaves the account holder out of that picker. Existing accounts are unaffected and stay bookable, since the flag records only the new "not a student" case.
- The studio's account-signup questions are now asked of anyone registering as a student, including someone registering themselves alongside their children. Choosing both previously collected the questions per child only, so the account holder's own instrument, level and the rest were never asked for or stored, even though they could book lessons. Their answers are recorded against their own account, and a blank required answer now names them rather than blaming "each student".
- A student's name and birth year are now required, marked in the form the same way a required registration question is and enforced on the server whichever way they were submitted. On signup the requirement applies only once the parent/guardian box is ticked, so registering for yourself is unaffected. A student block you have started filling in is now reported back to you rather than silently dropped when the name is missing — only a completely untouched spare block is still ignored.
- Signup and the profile page now ask for a birth year rather than a full date of birth — a four-digit year between 1900 and the current year, with anything else discarded rather than stored. Students added before this change keep showing a birth year, derived from the date already on file; that old full date is then dropped the first time the record is saved, so the studio ends up holding only what it now asks for. No bulk purge runs, so a site wanting the remaining old dates gone should clear the
us_date_of_birthuser meta directly. - The interface now says student where it said "child" and profile where it said "family". The
[us_family]page is headed Your profile, its form is Add a student, signup asks for a Student's name, and the wp-admin students list and student screen both label the relationship Profile. Two strings were reworded rather than swapped: the students list reads Managed by name (a bare "Student of name" would read as a teacher's pupil), and a managed account is described as a managed student account so it is not confused with the account holder. Internal names — database columns, request parameters, form field names, theus_familyshortcode and theus-scheduler/familyblock — are unchanged, since they are contracts with existing installs and saved post content.
Fixed
- Booking a lesson no longer dead-ends on the confirmation. The confirmation used to replace the calendar entirely, leaving a student who wanted a second lesson with nothing to click and no way back short of reloading the page. It is now a dismissible notice sitting above a freshly loaded calendar — the slot just taken already gone from it, the upcoming-lessons panel already updated — so "it worked" and "book another" are the same screen. Enrolling in a group class did the same thing and is fixed the same way.
- Upcoming lesson rows no longer render on top of each other. The row's text sits in inline elements that a theme can pull out of normal flow, which dropped the date and time onto the lesson title and the status pill onto the Cancel button; those elements are now pinned into flow alongside the rest of the panel's theme-proofing. The rows held behind Show all also stayed visible under the
div { display: block }reset that many themes still carry, since[hidden]is only a browser default — they are now hidden for real.
Downloads
- An Account block (