3 Commits

Include renames

Author	SHA1	Message	Date
KydoimosandClaude Opus 5	1847159e31	Fix five findings from a security assessment of the plugin ... The assessment looked for three things: whether students can reach each other's bookings, whether payment settings can be dodged, and whether the plugin opens a way into the rest of the install. The student-isolation and payment paths held up. These are what did not. - The front-end login form told WordPress not to work out whether the site was secure, so on HTTPS every student's session cookie was issued without the Secure flag. wp_signon() only derives it from is_ssl() when the second argument is left at its default; an explicit false reads like "no preference" and is not. - The update check took whatever download URL the release API returned and handed it to core, which unpacks it over the installed plugin. The package must now be https on git.unsupervised.ca exactly, compared on the parsed host so a lookalike name cannot pass. - Uninstalling dropped 2 of 14 tables and left the Stripe secret and webhook signing key in wp_options. Removal is now a choice made in advance on Access -> Plugin removal: records are kept unless the owner opts in (with a typed confirmation), while credentials and the borrowed core registration settings go every time. - Open registration switches on the site-wide users_can_register and makes Student the default role, arming any other signup form on the site to mint students who could book and be billed immediately. The pending state is now decided once, on user_register, rather than by whichever form created the account. - Cancel and withdraw answered "not yours" differently from "does not exist", which let a signed-in student enumerate the studio's bookings. Both now give the same 404. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-05 11:55:53 -03:00
thatguygriffandClaude Opus 4.8	51dd032668	Show the Enable auto-updates toggle for the self-updater ... WordPress only renders the "Enable auto-updates" toggle for a plugin that appears in the update_plugins transient's response or no_update list, which is what sets core's update-supported flag. UpdateChecker only populated the response side (when a newer release existed), so between releases the plugin was absent from the transient and the toggle never showed. provideUpdate() now returns a no_update payload (installed version, empty package) whenever no newer release is offered — including when the release lookup fails — so the plugin stays in the transient and the toggle appears. The response path (one-click and unattended updates) is unchanged. Bumps to 1.1.1 so the fix ships to installed sites via the self-updater. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-24 08:46:31 -03:00
thatguygriffandClaude Fable 5	ab055c7a0c	Serve plugin updates from tagged Gitea releases ... Closes #65 Declare an Update URI header and answer core's update_plugins_{hostname} filter from a new Update\UpdateChecker that offers the latest published Gitea release's zip asset when it is newer than the installed version, with transient caching and silent degradation on API failures. Add a release workflow that fires on v* tag pushes: verifies the tag matches the plugin Version header, runs the tests, builds the plugin zip, and attaches it to the release (reusing a UI-created release, flagging hyphenated versions as pre-release so /releases/latest skips them). Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-18 11:09:50 -03:00