• v1.5.6 f58585be0d

    v1.5.6
    CI / Coding Standards (push) Successful in 18s
    CI / No Debug Code (push) Successful in 6s
    CI / Tests (PHP 8.5) (push) Successful in 33s
    CI / Static Analysis (push) Successful in 37s
    CI / Tests (PHP 8.1) (push) Successful in 37s
    CI / Tests (PHP 8.3) (push) Successful in 37s
    CI / Tests (PHP 8.2) (push) Successful in 39s
    CI / Build Plugin Zip (push) Successful in 12s
    Release / Build and Publish Release (push) Successful in 25s
    Release / Open next-version bump PR (push) Successful in 4s
    Stable

    thatguygriff released this 2026-09-05 15:03:35 +00:00 | 23 commits to main since this release

    Security

    • 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 https on git.unsupervised.ca exactly; 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