-
v1.6.0
StableCI / Coding Standards (push) Successful in 15sCI / No Debug Code (push) Successful in 4sCI / Tests (PHP 8.5) (push) Successful in 23sCI / Tests (PHP 8.2) (push) Successful in 29sCI / Tests (PHP 8.1) (push) Successful in 52sCI / Tests (PHP 8.3) (push) Successful in 52sCI / Static Analysis (push) Successful in 1m2sCI / Build Plugin Zip (push) Successful in 12sRelease / Build and Publish Release (push) Successful in 22sRelease / Open next-version bump PR (push) Successful in 4sreleased this
2026-09-18 13:01:22 +00:00 | 4 commits to main since this releaseAdded
- You can now read, rewrite and preview the "Payment due" email, on Studio Settings → Payment Due Email. The notice a family gets when the daily scan finds lessons to pay for was fixed wording baked into the plugin; now its subject and body sit in an editor you can change to match how your studio talks to its students. Drop in
{student_name},{items},{total_due}and the rest wherever you want them, and a preview below fills those tokens with sample values and updates as you type, so you see the actual email a scan would send before you save. Leave a field blank to fall back to the built-in wording, or use the reset button to restore all of it at once. Nothing about how or when the email is sent changes — only what it says — and until you touch it, students receive exactly the notice they always did.
Downloads
- You can now read, rewrite and preview the "Payment due" email, on Studio Settings → Payment Due Email. The notice a family gets when the daily scan finds lessons to pay for was fixed wording baked into the plugin; now its subject and body sit in an editor you can change to match how your studio talks to its students. Drop in
-
v1.5.6
StableCI / Coding Standards (push) Successful in 18sCI / No Debug Code (push) Successful in 6sCI / Tests (PHP 8.5) (push) Successful in 33sCI / Static Analysis (push) Successful in 37sCI / Tests (PHP 8.1) (push) Successful in 37sCI / Tests (PHP 8.3) (push) Successful in 37sCI / Tests (PHP 8.2) (push) Successful in 39sCI / Build Plugin Zip (push) Successful in 12sRelease / Build and Publish Release (push) Successful in 25sRelease / Open next-version bump PR (push) Successful in 4sreleased this
2026-09-05 15:03:35 +00:00 | 23 commits to main since this releaseSecurity
- Signing in on the front end no longer hands out a session cookie that can travel over plain HTTP. The studio's own login form told WordPress not to work out for itself whether the site was secure, and WordPress took that as "it is not" — so on an HTTPS site every student's session cookie was issued without the flag that keeps a browser from ever sending it unencrypted. Anyone able to watch the network and provoke a single
http://request to the site could have lifted a signed-in session with it. The form now leaves that judgement to WordPress, which is what the standard login screen has always done. Nothing changes for you; existing sessions are unaffected. - Plugin updates are now only accepted from the release server itself. The update check asks the repository where to download the new version and used to take whatever answer came back. An answer that was not really the release server's — a hijacked hostname, a tampered response — could have pointed the site at any file on the internet, which WordPress would then have unpacked over the plugin. The download address must now be
httpsongit.unsupervised.caexactly; a lookalike, a subdomain, or an unencrypted address is refused and no update is offered. Ordinary updates are unaffected. - A student can no longer tell a booking that is not theirs from one that does not exist. Cancelling someone else's lesson was already refused, but the refusal was worded differently from "no such booking" — enough for a signed-in student to work through the numbers and learn how many lessons the studio holds. Both now answer identically. Withdrawing from a group class was the same and has had the same treatment.
- Students created by anything other than the studio's own signup form now wait for approval. Turning on open registration switches on WordPress's site-wide "anyone can register" setting and makes Student the default role for new accounts — which is what the studio's registration page needs, but it also arms any other signup form the site happens to have. An account created that way arrived able to book and be billed immediately, with no email confirmed, no approval and no policies agreed to. Any student account that appears without going through the studio's own form is now held and listed under Students → Pending Students, exactly like a self-signup; it can sign in, but cannot book until you approve it. Students you add yourself from wp-admin, invited students, and the children a parent adds are all unaffected.
Added
- You can now decide what deleting the plugin takes with it, on Access → Plugin removal. WordPress gives an uninstall nothing to ask you with, so the answer is given ahead of time. By default your records stay: delete the plugin and your lessons, enrolments, payments, credits, intake answers, policy agreements, invites and family links are still there when you reinstall, so a delete during a migration or a bit of troubleshooting costs you nothing. Ticking Erase everything when the plugin is deleted — which also asks you to type DELETE, because there is no undo — drops every table, setting and role the plugin made. Either way your Stripe secret key and webhook signing secret are now forgotten on deletion, where before they stayed in the database indefinitely: they take a minute to paste back in, and live keys on a site that no longer has the code to use them are worth nothing but risk. The two WordPress settings open registration borrows are put back as they were, too, so deleting the plugin can never leave the site quietly accepting signups into a role that no longer exists.
Downloads
- Signing in on the front end no longer hands out a session cookie that can travel over plain HTTP. The studio's own login form told WordPress not to work out for itself whether the site was secure, and WordPress took that as "it is not" — so on an HTTPS site every student's session cookie was issued without the flag that keeps a browser from ever sending it unencrypted. Anyone able to watch the network and provoke a single
-
v1.5.5
StableCI / Coding Standards (push) Successful in 17sCI / No Debug Code (push) Successful in 1sCI / Tests (PHP 8.1) (push) Successful in 32sCI / Tests (PHP 8.5) (push) Successful in 29sCI / Tests (PHP 8.3) (push) Successful in 42sCI / Static Analysis (push) Successful in 52sCI / Tests (PHP 8.2) (push) Successful in 52sCI / Build Plugin Zip (push) Successful in 23sRelease / Build and Publish Release (push) Successful in 20sRelease / Open next-version bump PR (push) Successful in 4sreleased this
2026-08-25 02:20:29 +00:00 | 28 commits to main since this releaseChanged
- Payments moved up to version 21 of Stripe's PHP library, from version 17. Being four major versions behind also meant asking Stripe to behave like an older version of its API; the plugin now uses API version
2026-07-29.dahlia. Taking a card payment and handling a webhook are unchanged — the same charge is raised, the same events are honoured, and a forged webhook is still rejected. Nothing to do on your side.
Downloads
- Payments moved up to version 21 of Stripe's PHP library, from version 17. Being four major versions behind also meant asking Stripe to behave like an older version of its API; the plugin now uses API version
-
v1.5.4
StableCI / Coding Standards & Static Analysis (push) Successful in 13m23sCI / Tests (PHP 8.1) (push) Successful in 55sCI / Tests (PHP 8.2) (push) Successful in 1m7sCI / Tests (PHP 8.3) (push) Successful in 6m59sCI / Tests (PHP 8.5) (push) Successful in 12m55sCI / No Debug Code (push) Successful in 3sCI / Build Plugin Zip (push) Successful in 5m53sRelease / Build and Publish Release (push) Successful in 8m5sRelease / Open next-version bump PR (push) Successful in 5sreleased this
2026-08-24 23:41:46 +00:00 | 47 commits to main since this releaseFixed
- Adding students to a group class now checks that each one is actually a student. Add students directly and Make available acted on whatever ids the form posted without confirming they named students at all, so a stale page — or a tampered submission — could put an instructor, an administrator, or an account that had since been deleted onto a class roster, raising a real payment against them. Both controls now skip anything that is not a student, and the "%d student(s) added" count tells you how many actually went through. Children and students awaiting approval are unaffected: they are students, and adding them is what these controls are for.
- A refused booking no longer empties the Book a lesson for a student form. Whatever the reason it came back — the time taken while you were typing, a weekly reservation asked for on a time that does not repeat — the panel reopens with the student, time, lesson type, both ticks and your note exactly as you left them, so a correction is one field, not five. A booking that goes through still leaves an empty form behind for the next one.
- Booking a lesson for a child, or for a student you have not approved yet, no longer fails with "Choose a student to book for." The Book a lesson for a student panel offered every student it could see, but then refused a good half of them: a parent's child and a self-signup still awaiting approval both appeared in the list, and both were rejected on submit — with an error that read as though no student had been chosen, and which cleared the form. Neither of those accounts is allowed to book in their own name (a child's is never signed in to at all, and an unapproved signup waits for you), and the panel was mistakenly applying that same restriction to the studio booking on their behalf, which is precisely the case it was built for. Anyone the panel offers can now be booked for.
Downloads
-
v1.5.3
StableRelease / Build and Publish Release (push) Successful in 4m43sRelease / Open next-version bump PR (push) Successful in 3sCI / Tests (PHP 8.1) (push) Successful in 51sCI / Tests (PHP 8.2) (push) Successful in 56sCI / Tests (PHP 8.3) (push) Successful in 4m41sCI / Tests (PHP 8.5) (push) Successful in 3m6sCI / No Debug Code (push) Successful in 4sCI / Coding Standards & Static Analysis (push) Successful in 8m23sCI / Build Plugin Zip (push) Successful in 2m39sreleased this
2026-08-24 17:51:49 +00:00 | 51 commits to main since this releaseAdded
- Intake answers and policy agreements can now be recorded after the fact for a lesson the studio booked, or a student it added straight into a group class. A lesson booked from wp-admin has no answers and no signed policies — nobody was at a keyboard to give them — and until now there was nowhere to put them once the studio did collect them at the first lesson or over the phone. The lesson's detail page now carries Record intake collected elsewhere, offering whatever is still outstanding: the unanswered questions and the policy versions with no acceptance on file. Fill in what you have, leave the rest, come back later — nothing already recorded can be overwritten, and a form posted twice cannot duplicate anything. Every recording must say how it was collected — a signed paper form, in person, over the phone, by email, or some other way you describe — and that answer is stamped on each entry along with your name. Both audit tables gained a How it was given column, so a policy accepted online and one transcribed from paper can never again look like the same thing. Only registrations the studio made have the panel: one a student made already holds their own answers, and those stay theirs alone. Group classes work the same way, reached from the new Intake → View link on each roster row of a class's detail page — a student added with Add students directly was never shown the enrolment form, and this is where what you collect instead now goes.
- You can now book a lesson for a student yourself, from Scheduler or My Lessons. Group classes have always had Add students directly, but a private lesson could only be booked by the student — or by their parent, for a child — so a booking taken over the phone, or a make-up lesson an instructor wanted to slot in, had no way in short of asking the family to go and do it themselves. Book a lesson for a student, a panel at the top of both lesson pages, takes the student, an open time and the lesson type and books it there and then. Tick Reserve this time weekly to hold the same time for the rest of the term, or No charge for a make-up or goodwill lesson — that one skips payment entirely and confirms the lesson immediately, where an ordinary booking raises a pending payment at the lesson type's price and confirms when it settles, exactly as a student's own booking does. The Scheduler reaches every instructor's open times; My Lessons shows an instructor only their own. Booking this way does not ask the intake questions or record the policy agreements the student would give themselves — those stay theirs to answer, so a lesson booked for someone simply shows none on its detail page.
Downloads
-
v1.5.2
StableCI / PHPStan (push) Successful in 8m6sCI / Tests (PHP 8.1) (push) Successful in 1m6sCI / Tests (PHP 8.2) (push) Successful in 54sCI / Tests (PHP 8.3) (push) Successful in 6m48sCI / No Debug Code (push) Successful in 2sCI / Coding Standards (push) Successful in 5m55sCI / Build Plugin Zip (push) Successful in 2m51sRelease / Build and Publish Release (push) Successful in 16m35sRelease / Open next-version bump PR (push) Successful in 4sreleased this
2026-08-20 15:54:00 +00:00 | 71 commits to main since this releaseAdded
- You can now choose which payment method the studio bills by, instead of it following your Stripe keys. Saving Stripe keys used to move every student onto credit-card billing the moment they were entered — there was no way to have Stripe live and still bill by e-transfer while you satisfied yourself that card payments worked. Studio Settings → Billing → Default payment method now makes that an explicit choice between Credit card and E-transfer. Leaving it on E-transfer with Stripe configured lets you switch one student at a time to Credit card on their student detail page and watch their bookings charge for real; when you are satisfied, changing this one setting moves everyone over. Credit card remains the default, so a studio that adds keys and changes nothing else behaves exactly as before, and it still falls back to e-transfer until keys are saved — a card cannot be charged without them.
- Stripe can now be disconnected from Studio Settings. Keys could be replaced but never removed, so a studio that set Stripe up to try it had no way back to e-transfer short of editing the database. Clear Stripe configuration, at the foot of the settings page whenever any Stripe value is stored, forgets the publishable key, the secret key and the webhook signing secret, and returns the mode to Test — billing falls back to e-transfer until keys are entered again. Payments already recorded are untouched, as are your currency, HST, e-transfer and registration settings. If you are disconnecting for good, delete the webhook endpoint in the Stripe Dashboard too, or it will keep sending events this site can no longer verify.
Downloads
-
v1.5.1
StableCI / No Debug Code (push) Successful in 4sCI / Tests (PHP 8.1) (push) Successful in 1m4sCI / Tests (PHP 8.2) (push) Successful in 1m10sCI / Coding Standards (push) Successful in 3m35sCI / PHPStan (push) Successful in 3m52sCI / Tests (PHP 8.3) (push) Successful in 21m42sCI / Build Plugin Zip (push) Successful in 14m57sRelease / Build and Publish Release (push) Successful in 3m11sRelease / Open next-version bump PR (push) Successful in 5sreleased this
2026-08-11 22:02:59 +00:00 | 75 commits to main since this releaseFixed
- A parent can now enrol more than one child in the same group class. Enrolling the first student worked, and then the class card switched to "You are enrolled in this class." with a Withdraw button — for the whole account. There was no way to sign up a second child short of withdrawing the first, even though nothing was ever actually full or forbidden: the class page was matching enrolments to the account rather than to the student, so one child's seat spoke for everybody. Each enrolled student now gets their own line on the card, named — "Ada is enrolled in this class." — with their own Withdraw button, and the Enrol button stays put, reading Enrol another student, until everyone on the account is in. The form's "Who is this for?" list offers only the students not yet enrolled, so the class cannot be double-booked for the same child by accident. Enrolments already recorded are unaffected; the seats were always separate on the studio's side, and this is the page catching up with that.
Downloads
-
v1.5.0
StableCI / Tests (PHP 8.2) (push) Successful in 44sCI / Tests (PHP 8.1) (push) Successful in 54sCI / No Debug Code (push) Successful in 1sCI / PHPStan (push) Successful in 2m54sCI / Coding Standards (push) Successful in 2m58sCI / Tests (PHP 8.3) (push) Successful in 2m43sRelease / Build and Publish Release (push) Successful in 2m58sRelease / Open next-version bump PR (push) Successful in 4sCI / Build Plugin Zip (push) Successful in 2m46sreleased this
2026-07-30 19:42:54 +00:00 | 79 commits to main since this releaseAdded
- A registration question can now be asked of students only, and can be required of a student without being required of the account holder. Every account-signup question was asked of everybody who registered, on the same terms — so "School and grade" had to be put to the adult signing themselves up, and a question a studio needed answered for a child could only be made required by demanding it of everyone. Each question now says who it is asked of — everyone, or only the students you register on behalf of — and carries its own Required setting for each: optional for you, required for every student you enrol, is now a thing a studio can ask for. Existing questions are untouched: they stay asked of everyone, and one that was required stays required of everyone.
- You can now edit your own details on the profile page, not just your students'. The page is called Your profile, and until now the one person on it you could not change was yourself: a mistyped name at signup, or a name that had since changed, meant asking the studio to fix it. Your details now sits at the top of the page with your name, your birth year, and whether you take lessons yourself. Your email address is shown but not editable — it is also how you sign in, so changing it stays a studio-side job.
- "I take lessons myself" can be corrected after signup. Signup asks whether you are registering just yourself, only on behalf of students, or both, and the answer decides whether you are offered as a student when booking. Choosing wrongly — or taking up lessons later alongside the children you book for — used to leave you asking the studio to change it. Ticking the box makes you bookable again and asks for your birth year like any other student; unticking it takes you back off the list without discarding the birth year you already gave, so ticking it back on costs you nothing.
Fixed
- A recurring lesson now shows the policies the student accepted on every week of it, not just the first. Booking a weekly lesson reserves a series of them, and the student answers the intake questions and agrees to the studio's policies once, for the whole reservation. Opening any week after the first showed no answers and no policies accepted — as though nothing had been agreed to. Nothing was ever missing: the agreement was recorded against the first lesson of the series and every other week was looking for one of its own. Each week of a series now shows the intake answers and the full acceptance record — policy, version, when it was accepted, and from where — captured when the reservation was booked. Existing bookings read correctly straight away; there is nothing to re-collect from anyone.
Downloads
-
v1.4.1
StableCI / PHPStan (push) Successful in 2m53sCI / Coding Standards (push) Successful in 3m2sRelease / Build and Publish Release (push) Successful in 2m59sRelease / Open next-version bump PR (push) Successful in 4sCI / Tests (PHP 8.3) (push) Successful in 2m42sCI / Build Plugin Zip (push) Successful in 2m46sCI / Tests (PHP 8.1) (push) Successful in 44sCI / Tests (PHP 8.2) (push) Successful in 51sCI / No Debug Code (push) Successful in 2sreleased this
2026-07-30 15:30:56 +00:00 | 87 commits to main since this releaseAdded
- Group classes now appear in "Your upcoming lessons". A class is stored as a term rather than as bookable slots, so nothing that listed lessons could ever show one — a student whose whole term was a group class saw an empty schedule, and an instructor teaching one saw nothing on their My Lessons page. Each remaining session of a class you are enrolled in now sorts in among your lessons by date, labelled group class; instructors see every session of the classes they teach, one row per session however many students are in it. A session has no Cancel button, because there is no such thing as cancelling one date of a term — withdrawing from the class is still done from the class page.
- A class you are enrolled in shows up whether or not its schedule is pinned to a clock. Class time and duration are both optional on the offering form, and the schedule note is there so a studio can simply write "Tuesdays 4:00pm" — so a class with a time but no duration lists its dates and says when each session starts rather than guessing when it ends, and a class with no time at all gets a single row carrying its schedule note (or its term dates) where the time would go. Only a class whose last day has passed drops off the list.
- A student's admin detail page now shows Booked by in the Account section — the name of the parent or guardian who books and pays for them, linked to their own page. It was only stated further down under Profile, and only when there was one; the row is now always there, saying in words when a student books for themselves.
- The same group-class sessions now appear in Upcoming lessons on a student's admin detail page, so one table answers "what are they booked into next week?". Only upcoming ones — the Group-class enrolments table below already holds the history.
- A policy can be renamed. The title was fixed at creation, so a typo or a change of wording meant creating a second policy and re-collecting everyone's acceptance. Renaming changes only what students read above the policy text: the slug stays put, so every version already accepted stays attached.
Fixed
- People are named by their name again, not their email address. Anywhere the plugin named a person it could show their email instead — "Managed by [email protected]" in the students table, the same under Booked by, and instructor names on the class pages. WordPress starts a new account's nickname off as its username, and signup uses the email address as the username, so the address became the nickname of every self-registered account; the name they had typed was sitting in the account's display name the whole time. Names are now read from there when the nickname turns out to be an address, so existing accounts read correctly with nothing to fix by hand, and new signups store the name properly in the first place. Students added by a parent were never affected.
- Deleting a parent now removes the students they booked for. A managed student account has no login of its own and exists only so its parent has somebody to book for — with the parent gone nobody can reach it, book for it, or be billed for it, so it was left stranded on the roster still holding lesson times. Deleting a parent now releases each of their students' upcoming lessons and enrolments on the same terms as their own, and deletes the accounts. Removing a student from the family screen is unchanged and still refuses one with lessons on record.
- The upcoming-lessons panel no longer collapses onto itself in some themes. Rows could render on top of one another and the status badge's colour could stop short of the text inside it. Both came from the same thing: the panel never stated its own line spacing, so a theme setting a line height of zero anywhere above it — a common icon-font reset — was inherited straight through, leaving each line of text taller than the space allotted to it. The panel now sets its own.
- Deleting a student now gives back what they had booked. WordPress deletes a user without knowing anything about lessons, so their bookings were left behind: the times stayed marked as booked and nobody else could take them, the lessons stayed on the instructor's schedule under a name that no longer resolved, and a group class kept a seat filled by nobody. Deleting an account now cancels each of its upcoming lessons, frees the time for rebooking, cancels its active class enrolments, and voids any payment still pending on them. Past lessons are left exactly as they are — they happened, and the payment report has to keep adding up. A paid lesson is not credited back: a credit could only be spent on the account being deleted, so a refund owed to someone who has left stays the studio's decision to make.
- A weak password is now caught before the form is submitted, not after. The strength meter scores the password as you type, but zxcvbn's dictionary arrives a moment after the page loads — so a password typed straight away was never scored at all, and the first you heard of it was the server rejecting the whole form. The password is now re-scored on submit, so the verdict is always the one your password actually earns.
Changed
- Signup is one page again. The studio's registration questions used to be a second step behind a Next button; they are now asked on the main form, in an About you panel above the students you are adding. What the studio needs to know about you is part of registering, not a sequel to it — and there is now one submit rather than three.
- Signup asks an adult student for their birth year, the same four-digit year already asked of every student being registered on someone else's behalf. It is asked only when you are a student yourself — choosing on behalf of one or more students leaves the whole About you panel out, since those questions describe a student and in that case you are not one.
Downloads
-
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 | 94 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 (