• v1.5.0 1e4e21e8d3

    v1.5.0
    CI / Tests (PHP 8.2) (push) Successful in 44s
    CI / Tests (PHP 8.1) (push) Successful in 54s
    CI / No Debug Code (push) Successful in 1s
    CI / PHPStan (push) Successful in 2m54s
    CI / Coding Standards (push) Successful in 2m58s
    CI / Tests (PHP 8.3) (push) Successful in 2m43s
    Release / Build and Publish Release (push) Successful in 2m58s
    Release / Open next-version bump PR (push) Successful in 4s
    CI / Build Plugin Zip (push) Successful in 2m46s
    Stable

    thatguygriff released this 2026-07-30 19:42:54 +00:00 | 2 commits to main since this release

    Added

    • 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 5d98aedfa5

    v1.4.1
    CI / PHPStan (push) Successful in 2m53s
    CI / Coding Standards (push) Successful in 3m2s
    Release / Build and Publish Release (push) Successful in 2m59s
    Release / Open next-version bump PR (push) Successful in 4s
    CI / Tests (PHP 8.3) (push) Successful in 2m42s
    CI / Build Plugin Zip (push) Successful in 2m46s
    CI / Tests (PHP 8.1) (push) Successful in 44s
    CI / Tests (PHP 8.2) (push) Successful in 51s
    CI / No Debug Code (push) Successful in 2s
    Stable

    thatguygriff released this 2026-07-30 15:30:56 +00:00 | 10 commits to main since this release

    Added

    • 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 969d864106

    v1.4.0
    CI / Tests (PHP 8.2) (push) Successful in 45s
    CI / No Debug Code (push) Successful in 2s
    CI / Coding Standards (push) Successful in 2m54s
    CI / PHPStan (push) Successful in 2m55s
    CI / Tests (PHP 8.3) (push) Successful in 2m44s
    CI / Tests (PHP 8.1) (push) Successful in 53s
    Release / Build and Publish Release (push) Successful in 3m1s
    Release / Open next-version bump PR (push) Successful in 4s
    CI / Build Plugin Zip (push) Successful in 2m53s
    Stable

    thatguygriff released this 2026-07-30 02:26:51 +00:00 | 17 commits to main since this release

    Added

    • 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_birth user 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, the us_family shortcode and the us-scheduler/family block — 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
  • v1.3.0 3c41d1119d

    v1.3.0
    CI / No Debug Code (push) Successful in 2s
    CI / PHPStan (push) Successful in 2m56s
    CI / Tests (PHP 8.3) (push) Successful in 2m45s
    CI / Tests (PHP 8.2) (push) Successful in 43s
    CI / Tests (PHP 8.1) (push) Successful in 54s
    CI / Coding Standards (push) Successful in 3m1s
    Release / Build and Publish Release (push) Successful in 3m1s
    Release / Open next-version bump PR (push) Successful in 3s
    CI / Build Plugin Zip (push) Successful in 2m49s
    Stable

    thatguygriff released this 2026-07-29 19:19:23 +00:00 | 41 commits to main since this release

    Added

    • Parent and guardian accounts. A parent registers once and manages lessons for one or more children, who need no login of their own. The signup form gains an "I'm registering as a parent or guardian" tick that reveals a block per child — name, date of birth, and the studio's account-signup questions asked per child, since those describe the student rather than the account holder. Signup policies are recorded once per child with the guardian named as the person who agreed, which is the record that actually means something: "this guardian accepted version N on behalf of this child, at this time, from this address." A guardian can also be a student themselves and book their own lessons from the same account.
    • A "Who is this for?" picker on the booking and group-class forms, listing children first and the account holder last — so the default selection is never the parent, and a lesson meant for a child is not quietly booked and billed in the parent's name. An account with only itself on the list sees no picker and behaves exactly as before. A guardian's upcoming-lessons panel covers the whole household, each row naming whose lesson it is, and they can cancel or withdraw for any of their children.
    • A Family page for guardians ([us_family], or the Family block) to add, edit and remove children after signup. Removing a child is refused once they have lessons or enrolments on record — that history belongs to them, and the studio unpicks it by hand rather than the page orphaning it.
    • One family, one bill. Payments record the child the lesson was for and the guardian who owes it, so per-child reporting is unchanged while notices, receipts and the payment step all go to the parent. Account credit is held by the payer, so a credit from one child's cancelled lesson can settle a sibling's next charge, and the billing-method override (comp / card / e-transfer) is one setting on the guardian rather than one per child. The daily billing scan sends a guardian one notice covering every child, with each line naming whose lesson it is.
    • Students in wp-admin gains a Family column linking a child to their guardian and a guardian to their children, and the student screen gains a Family panel. A child's row shows the guardian's email — a child's own address is a placeholder that can never receive mail — and their credit balance is labelled with whose account actually holds it.

    Changed

    • Child accounts cannot be signed in to. They hold the student role so every existing lookup keeps working, but authentication is refused outright and the booking capability is withheld, so the only route to a lesson in a child's name is their guardian's authorised booking.
    Downloads
  • v1.2.4 bbc85d88f1

    v1.2.4
    CI / Build Plugin Zip (push) Successful in 2m50s
    CI / Tests (PHP 8.2) (push) Successful in 52s
    CI / No Debug Code (push) Successful in 2s
    CI / PHPStan (push) Successful in 2m50s
    CI / Coding Standards (push) Successful in 2m53s
    Release / Open next-version bump PR (push) Successful in 3s
    CI / Tests (PHP 8.1) (push) Successful in 48s
    CI / Tests (PHP 8.3) (push) Successful in 2m42s
    Release / Build and Publish Release (push) Successful in 2m55s
    Stable

    thatguygriff released this 2026-07-29 02:26:40 +00:00 | 46 commits to main since this release

    Fixed

    • Adding availability no longer fails in silence. Entering a window shorter than the chosen lesson length — 5:30–6:00 PM with the lesson length left on its default of 60 minutes, say — saved nothing and said nothing: the page just reloaded, whether the window was one-off or set to repeat for 41 weeks. The Lesson length menu now offers only the lengths that actually fit the window you have entered, and the form refuses to submit when none of them do. Every other way the form could quietly do nothing now explains itself too — an unreadable date, an end time before the start, a window running past midnight into the next day — and a successful save says how many bookable slots it created. Deleting says whether the slot went, and tells you when one is refused because it is already booked. Availability added through the API is checked against exactly the same rules, which it previously enforced slightly differently.
    • A student's upcoming lessons no longer pile on top of each other. On the booking page, the lesson name, its date and time, the status badge and the Cancel button could render over one another instead of sitting in a tidy row — worst with a long lesson-type name, and on narrow screens, where the row had no phone layout at all. The panel now keeps its shape whatever the theme around it does, long names wrap instead of shoving the Cancel button out of the row, and on a phone the lesson details stack above the buttons.
    • The registration page no longer dead-ends a visitor who is already signed in. It used to greet them with "You already have an account and are logged in." and nothing else, leaving them to find their own way to the studio. They now get a link onward to the page chosen under the block's After registration panel, and the link names it — "Continue to Book a Lesson" rather than the vaguer wording an invited student used to see. With no page chosen, the message appears on its own as before, because sending someone who is already signed in to the sign-in screen helps nobody.
    Downloads
  • v1.2.3 fabbd35fa7

    v1.2.3
    CI / Tests (PHP 8.2) (push) Successful in 46s
    CI / Tests (PHP 8.1) (push) Successful in 57s
    CI / No Debug Code (push) Successful in 2s
    CI / PHPStan (push) Successful in 2m55s
    CI / Coding Standards (push) Successful in 2m58s
    CI / Tests (PHP 8.3) (push) Successful in 2m42s
    CI / Build Plugin Zip (push) Successful in 2m49s
    Release / Build and Publish Release (push) Successful in 2m50s
    Release / Open next-version bump PR (push) Successful in 4s
    Stable

    thatguygriff released this 2026-07-28 20:23:22 +00:00 | 58 commits to main since this release

    Changed

    • A monthly group class is now billed its price once per month, however many times the class meets in that month. Previously the monthly charge multiplied the price by the number of sessions in the month — a class priced at 40.00 CAD meeting weekly was billed 160.00 CAD on the 1st — which no studio could quote honestly on a class card. A monthly private lesson is unchanged: its price is a per-lesson fee and the month is still billed one fee per lesson, which is why it is quoted per lesson. Studios running a monthly group class should check the class price now reads as the monthly fee they intend to charge.

    Added

    • Every price a student sees now says when it is due. Lesson types in the booking form read 50.00 CAD at booking, and group-class cards read 120.00 CAD up front, 40.00 CAD weekly or 40.00 CAD monthly — the offering's billing mode, in the student's words. A monthly private lesson is quoted per lesson (50.00 CAD per lesson monthly), since its monthly charge covers every lesson booked that month; a monthly group class is quoted as the monthly figure it is. A free offering still just reads Free.
    • The Policies admin page can now show you what is actually in a version. Every row in the versions table has a View button that opens that version's text below the table, rendered exactly as students see it at booking and signup, whether the version is the published one, an old archived one, or a draft nobody has seen yet. The text is editable straight from the viewer, and what happens when you save depends on the version: a draft is simply updated in place, while editing a published or archived version saves your text as a new draft version and leaves the original exactly as students accepted it. The new draft then opens in the viewer ready to publish. Nothing a student has agreed to is ever rewritten.
    • Booking a lesson and enrolling in a class now take a second confirmation that the student agrees to pay. Above the Confirm button the form restates the price with its cadence, spells out how it is collected ("Charged on the 1st of each month, for that month's lessons"), adds the studio's HST so the figure matches the total actually billed, and requires a tick on "I agree to pay 56.50 CAD at booking." before it will submit — separate from, and in addition to, the studio policies the student accepts above it. Reserving a time weekly quotes the per-lesson fee and the most it can add up to ("up to 12 lessons, 678.00 CAD in total"), since a week another student takes first is simply not booked. Free offerings have nothing to agree to and show no price block.

    Fixed

    • Policies are readable where students have to accept them. A policy typed as plain paragraphs — the normal way to write one, with no HTML — was being dropped into the booking, enrolment, and signup forms unformatted, collapsing the whole document into a single squashed line with a horizontal scrollbar and words piling on top of each other. Policy text is now formatted the same way WordPress formats post content, so blank lines become real paragraphs, and the acceptance box is styled as a proper bounded reading panel: long policies scroll vertically instead of running off the side of the page, long pasted links wrap rather than forcing the page sideways, and the "I have read and agree" tick stays in view. Policies written with HTML are unaffected. The studio registration page was also missing the plugin's stylesheet entirely, which is why the problem was at its worst there.
    Downloads
  • v1.2.2 3a25c397c5

    v1.2.2
    CI / No Debug Code (push) Successful in 2s
    CI / Tests (PHP 8.2) (push) Successful in 46s
    CI / Tests (PHP 8.1) (push) Successful in 53s
    CI / PHPStan (push) Successful in 2m56s
    CI / Coding Standards (push) Successful in 2m58s
    CI / Tests (PHP 8.3) (push) Successful in 2m42s
    CI / Build Plugin Zip (push) Successful in 2m48s
    Release / Build and Publish Release (push) Successful in 2m49s
    Release / Open next-version bump PR (push) Successful in 4s
    Stable

    thatguygriff released this 2026-07-28 16:33:51 +00:00 | 66 commits to main since this release

    Added

    • The Lesson Booking block gained three embedding options in its sidebar. Lesson type pins the block to a single private-lesson type — only the times bookable as that type are listed and it is the only thing bookable there, auto-selected on the registration form — so a page about one lesson type can carry its own calendar. Show the lesson-type filter turns the Show Only control on or off. Sections embeds just one half of the page: booking calendar only, or the student's upcoming lessons only, so the two can live on different pages. All three are available to the shortcode as [us_booking lesson_type="…" show_filter="no" show="booking|upcoming"], and the block's editor preview follows the chosen sections.
    • The booking calendar now has a Show Only button beside the List/Week toggle that opens a lesson-type filter, so a student browsing open times can narrow them to the types they actually want. Because not every open time can be booked as every private-lesson type — some times are tied to a specific type, others only take types of a matching length — the filter shows just the times bookable as the ticked types, and re-anchors the week view on the earliest one so it never opens on an empty week. Picking one of those times narrows the Lesson type picker on the registration form to the same list, and when only one type is left it is chosen automatically with its questions loaded. The type list starts collapsed and can be tucked away again without losing the filter; the button shows how many types are ticked. Tick nothing (or use Show all types) to see every open time as before. The filter is hidden when the studio only offers one private-lesson type.
    • The Group Classes block can now be pinned to a single class, under Classes shown → Class in the block sidebar (shortcode: [us_group_classes offering="…"]). Pick a class and the block shows only that one, so it can be embedded on a page that describes the class. In this mode the class's own description is left out to avoid repeating the page copy — the card shows the schedule, instructor, price, enrolment deadline and the enrol/withdraw controls. Leaving it on All classes keeps the full browsable catalog with descriptions.
    • The Student Registration block can now send students onward to a page of your choosing once they finish registering. Its After email confirmation panel is now After registration: the page you pick there is where the link shown to a newly registered student points — the "Sign in to your account" link after they confirm their email, and a "Continue to your account" link for an invited student, who is signed in immediately. A new Redirect automatically option takes them straight there instead of showing the link. Registration errors are never skipped — a failed sign-up and an expired confirmation link still show their message on the page, as does the "check your email to confirm your address" step. The redirect needs a page to be chosen; with none set, students see the link (or, for invited students, just the confirmation) as before.
    Downloads
  • v1.2.1 c611268bdb

    v1.2.1
    CI / Tests (PHP 8.1) (push) Successful in 39s
    CI / Tests (PHP 8.2) (push) Successful in 1m2s
    CI / No Debug Code (push) Successful in 3s
    CI / PHPStan (push) Successful in 2m54s
    CI / Coding Standards (push) Successful in 2m58s
    CI / Tests (PHP 8.3) (push) Successful in 2m42s
    Release / Build and Publish Release (push) Successful in 2m59s
    Release / Open next-version bump PR (push) Successful in 5s
    CI / Build Plugin Zip (push) Successful in 2m50s
    Stable

    thatguygriff released this 2026-07-24 23:28:28 +00:00 | 79 commits to main since this release

    Fixed

    • Registration questions, offering titles/notes, and policy names longer than their storage limit are no longer silently discarded. Previously typing a fixed-size field past its maximum length reported success but saved nothing — the database quietly rejected the over-long value. These fields now cap the input in the form, and the API rejects an over-long value with a clear error.
    • Students can no longer reach the WordPress dashboard. A student who navigates to wp-admin is redirected to the site front end and the admin toolbar is hidden for them, so they only ever see the studio's booking pages. Anyone who runs the studio — administrators, studio admins, and instructors — keeps full wp-admin access.
    • The instructor picker on the Add/Edit Offering form no longer comes up empty for a solo studio owner. When the person running the studio teaches from a WordPress administrator account (the default single-account setup), they now appear in the instructor dropdown and can be assigned to a class.
    Downloads
  • v1.2.0 771942be8b

    v1.2.0
    CI / Tests (PHP 8.1) (push) Successful in 40s
    CI / Tests (PHP 8.2) (push) Successful in 1m5s
    CI / No Debug Code (push) Successful in 3s
    CI / Coding Standards (push) Successful in 2m53s
    CI / PHPStan (push) Successful in 2m52s
    CI / Tests (PHP 8.3) (push) Successful in 2m36s
    Release / Build and Publish Release (push) Successful in 3m1s
    Release / Open next-version bump PR (push) Successful in 4s
    CI / Build Plugin Zip (push) Successful in 2m47s
    Stable

    thatguygriff released this 2026-07-24 19:30:27 +00:00 | 83 commits to main since this release

    Added

    • Offerings can now bill on a schedule: weekly (a pending payment 24 hours before each lesson) or monthly (one payment on the 1st for that month's lessons), alongside the existing one-time and full-term modes. Applies to both private lessons and group classes. A daily job generates due payments, and each student receives one consolidated itemised email per scan; batched payments share a reference so the admin Payments queue groups them with a lump-sum total for e-transfer reconciliation. Cancelling a lesson never voids a scheduled payment.
    • Cancelling a lesson that was already paid for now credits the student that money instead of leaving it as a manual refund. The credit is one lesson's share of what they paid — the whole amount for a single lesson, or a per-lesson slice of a monthly charge or a full-term series. The daily billing scan automatically applies any available credit against a student's upcoming weekly/monthly charges before emailing their notice, which shows the credit applied and the reduced total due; a charge fully covered by credit is settled and leaves the admin Payments queue. A student's outstanding credit balance is shown on their student detail page in the studio admin. Still-pending (unpaid) payments continue to be voided on cancellation as before.
    • Group classes now carry an enrolment deadline the instructor sets on the offering. It defaults to the first day of the class, and once it passes students can no longer enrol — the enrolment page shows the class as closed and the API rejects late enrolments. While enrolment is open, each class card shows an "Enrol by" date.
    • Group classes now also carry a withdrawal deadline the instructor sets per class. Up to that day a student can withdraw themselves from the class (the group-class page shows a Withdraw button) — this frees their seat and voids any pending payment but does not credit their account. After the deadline self-withdrawal closes and the student must ask the studio, who can still withdraw them by hand from the student detail page. Leaving the deadline blank keeps self-withdrawal open indefinitely.
    • The Add/Edit Offering form now shows only the fields relevant to the selected kind: the group-class settings (capacity, dates, times, enrolment/withdrawal deadlines, sessions, schedule note, invite-only) appear only for a group class, and the weekly-reservation option only for a private lesson.
    • Instructors can add students to any group class by hand from its details page (Add students directly), which now appears for public classes too, not just invite-only ones. This bypasses the enrolment deadline and capacity, so a student can be enrolled as a late enrolment after the class has closed to self-enrolment.
    • Studio admins and instructors can open a lesson detail view from the Scheduler and My Lessons lists, showing the offering booked, the policy versions the student accepted (with acceptance time and IP), and their intake answers. On My Lessons an instructor may only open their own lessons; the studio Scheduler may open any.
    • The Student Registration block's "registration is by invitation only" message is now customisable, under a new Invitation-only notice panel (shortcode: invite_only_message). Leaving it blank keeps the default wording.

    Changed

    • The student upcoming lessons panel now shows each booked offering's name and length beside the time, and lists only the soonest five lessons with a "Show all" reveal. The Scheduler and My Lessons week/list views likewise show the booked offering.

    Fixed

    • Accepting an invitation now keeps the student signed in. Previously the registration form processed the submission after the page had started rendering, so the sign-in cookie was never sent and the new student was bounced back to the (logged-out) registration page; it is now handled before any output, and the student lands logged in.
    • Account-registration questions now save. On sites first installed before account-scope questions existed, the us_questions.offering_id column was left NOT NULL (the schema migration relied on dbDelta, which does not reliably relax a column to allow NULL), so saving an account question failed with "Column 'offering_id' cannot be null". A one-time, self-healing migration relaxes the column on the next load.
    Downloads
  • v1.1.1 1fe28d5575

    v1.1.1
    CI / Coding Standards (push) Successful in 2m52s
    CI / No Debug Code (push) Successful in 2s
    CI / Tests (PHP 8.2) (push) Successful in 40s
    CI / Tests (PHP 8.1) (push) Successful in 54s
    CI / PHPStan (push) Successful in 2m49s
    CI / Tests (PHP 8.3) (push) Successful in 2m40s
    Release / Build and Publish Release (push) Successful in 3m1s
    Release / Open next-version bump PR (push) Successful in 5s
    CI / Build Plugin Zip (push) Successful in 2m47s
    Stable

    thatguygriff released this 2026-07-24 11:48:22 +00:00 | 100 commits to main since this release

    Fixed

    • The Enable auto-updates toggle now appears for the plugin on the Plugins screen. The self-updater now reports the plugin to WordPress even when it is already current, so core marks it update-supported and shows the toggle; previously the toggle was hidden between releases.
    Downloads