100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
thatguygriff	2781243742	Merge pull request 'Bump version to 1.5.6' (#196) from release/bump-1.5.6 into main ... Reviewed-on: #196	2026-08-25 02:22:10 +00:00
thatguygriff	61a40f0e8d	Merge pull request 'Update stripe-php from 17.6.0 to 21.2.1' (#195) from feature/194-stripe-php-21 into main ... Reviewed-on: #195	2026-08-25 02:18:36 +00:00
thatguygriffandClaude Opus 5	88a8d0ae5c	Date the Stripe changelog entry by version rather than by "current" ... "the current Stripe library" is only true until Stripe ships the next major. A changelog is read long after the release it describes, so name the versions — 17 to 21, API version 2026-07-29.dahlia — and let those date the entry. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 23:17:33 -03:00
thatguygriffandClaude Opus 5	e2da45a1b0	Update stripe-php from 17.6.0 to 21.2.1 ... Four majors behind on the plugin's only production dependency. No site is using Stripe yet and the integration has not been verified end to end, so the pinned API version can move now at close to zero cost — later it would mean coordinating with live payment traffic. The library surface this plugin uses is four symbols, all in StripeGateway: StripeClient, paymentIntents->create, Webhook::constructEvent and Event. Checked each against the installed v21 by reflection; all present with compatible signatures. Most of the breakage flagged across 18 to 21 is in the V2 Events API, which this does not use — webhooks go through the V1 Webhook::constructEvent path. The pinned Stripe API version moves to 2026-07-29.dahlia. Verified beyond the suite, which mocks the client: a real HMAC-signed payload round-trips through Webhook::constructEvent and returns a Stripe\Event with the expected type and data, and a forged signature still raises SignatureVerificationException. The 21.0.0 ErrorObject retyping to null|string produces no new PHPStan findings. Part of #194 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 23:15:01 -03:00
thatguygriff	dfa29745df	Merge pull request 'Update the dev dependencies' (#193) from chore/update-dev-dependencies into main ... Reviewed-on: #193	2026-08-25 02:10:14 +00:00
thatguygriffandClaude Opus 5	54a8b906f7	Update the dev dependencies ... Routine catch-up on the test and analysis tooling. Every package here is already allowed by the existing constraints, so composer.json does not move and no production dependency is touched. mockery/mockery 1.6.12 -> 1.6.15 phpstan/phpstan 2.2.2 -> 2.2.9 phpunit/phpunit 10.5.63 -> 10.5.64 hamcrest/hamcrest-php v2.1.1 -> v3.0.0 (transitive, via mockery) myclabs/deep-copy 1.13.4 -> 1.14.0 nikic/php-parser v5.7.0 -> v5.8.0 sebastian/recursion-context 5.0.1 -> 5.0.2 Seven patch releases of PHPStan is the one worth watching, since a static analyser routinely gains inferences between them. It reports no new errors here, and PHPCS and the suite are unchanged. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 23:08:54 -03:00
thatguygriff	b3ed3a67d5	Merge pull request 'Pin the Composer platform to PHP 8.1 and clear the PHPCS security advisories' (#192) from fix/187-composer-platform-pin into main ... Reviewed-on: #192	2026-08-25 02:08:07 +00:00
thatguygriffandClaude Opus 5	908b7fcd1f	Update the coding-standards tooling off three security advisories ... composer audit reported three advisories against the PHPCS stack, two rated high: squizlabs/php_codesniffer 3.13.5 -> 3.13.6 CVE-2026-67434, OS command injection wp-coding-standards/wpcs 3.3.0 -> 3.4.1 CVE-2026-45293, arbitrary code execution phpcsstandards/phpcsutils 1.2.2 -> 1.2.3 CVE-2026-65954, arbitrary code execution All three are dev-only and none ship in the plugin — bin/build-zip.sh installs --no-dev — but they execute against repository content on every CI run. The existing ^3.7 and ^3.0 constraints already allowed the fixed releases, so composer.json is unchanged. phpcsextra and the codesniffer installer come along as transitive dependencies. Five packages move, none are added or removed, and the updated standards report no new violations. composer audit is now clean. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:50:34 -03:00
thatguygriffandClaude Opus 5	b17adf02ff	Pin the Composer platform to PHP 8.1 ... composer.json declares "php": ">=8.1", but resolution ran against whatever PHP the machine doing the update happened to have. Running composer update on 8.5 could therefore produce a lock containing a package that requires 8.2 or newer, which installs fine locally and fails on the 8.1 leg of the test matrix — a lock that is only discovered to be wrong in CI. config.platform.php makes resolution always target the declared minimum, so a lock that resolves at all is a lock that installs everywhere the plugin claims to run. No package versions change: nothing currently locked requires a PHP newer than 8.1, so this only records platform-overrides and the new content hash. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:46:11 -03:00
thatguygriff	a23490ec80	Merge pull request 'CI: run jobs in shared ci-php images, commit composer.lock' (#191) from feature/187-run-jobs-in-ci-images into main ... Reviewed-on: #191	2026-08-25 01:41:19 +00:00
thatguygriffandClaude Opus 5	1552bf4b5f	Move the CI image definitions to the shared ci-php repository ... The image definition and its publishing workflow were only here because this was the first project to need them. They are project-agnostic, so they now live in Unsupervised/ci-php and any PHP project can consume the same tags. The registry path is unchanged — Gitea container images are named owner/image, not after the repository that pushes them — so nothing here needs repointing. Split the combined quality job into separate phpcs and phpstan jobs. They were folded together to halve the number of toolchain installs per run; with the toolchain in the image that saves nothing, and separating them means a coding-standards failure no longer hides the static analysis result. Rewrite the workflow comments to describe what the jobs do rather than the setup step they replaced, and cut docs/ci.md down to what is specific to this project — the image contents and publishing are documented in ci-php. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:39:08 -03:00
thatguygriffandClaude Opus 5	f8762e1095	Correct the registry auth docs: the Actions token does not work ... docs/ci.md and the workflow comment both described secrets.GITHUB_TOKEN as the working credential with REGISTRY_TOKEN as a fallback. That is backwards: the task token is rejected by Gitea's container registry (go-gitea/gitea#23642) and the first publish attempt failed on exactly that. REGISTRY_TOKEN is required. Part of #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:35:10 -03:00
thatguygriffandClaude Opus 5	c9d18fec74	Commit composer.lock so CI and releases install a fixed dependency set ... composer.lock was gitignored, so `composer install` resolved the graph afresh on every job. CI could quietly start testing different dependency versions than it did the day before, and two builds of the same tag could ship different vendor trees — the run that produces the zip is the same run that picks the versions. Track the lock, and make the two places that consume it use it: - the Composer cache keys hash composer.lock rather than composer.json, since the lock is now what actually fingerprints the dependency set; - bin/build-zip.sh stages the lock alongside composer.json, so the --no-dev production install resolves to the locked versions. It already deleted both from the staging directory before zipping, so the shipped plugin is unchanged. The current lock installs cleanly on 8.1: nothing in it requires a PHP newer than the >=8.1 composer.json declares. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:33:04 -03:00
thatguygriffandClaude Opus 5	ab609898d6	Run CI and release jobs inside the prebuilt CI images ... Replaces setup-php with `container:` in every job that needs PHP. The images published by ci-images.yml already carry PHP, Composer, the intl and zip extensions and the CLI tools the workflow scripts shell out to, so nothing installs PHP at job time any more. That removes the apt path #178 was about: a ~145s floor on 8.3 against ~35s on 8.1/8.2, with a tail that twice ran past the step timeout and failed the run. All three copies of the `Keep downloaded .debs` / `Cache apt packages` workaround go with it. no-debug and bump-version stay on the runner image — neither needs PHP, and no-debug wants the runner's GNU `grep --include`. The Composer cache moves to /composer/cache, which is COMPOSER_HOME in the image, and release.yml gains the cache step it never had. Also corrects the image size in docs/ci.md to the 67MB measured from the published manifest; the ~120MB in the original was an estimate. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:25:02 -03:00
thatguygriff	4bc8e80837	Merge pull request 'CI: install GNU tar in the CI image so actions/cache works' (#190) from fix/187-ci-image-gnu-tar into main ... Reviewed-on: #190	2026-08-25 01:23:12 +00:00
thatguygriffandClaude Opus 5	28f586d207	Install GNU tar in the CI image so actions/cache works ... actions/cache shells out to `tar --posix -P`. Alpine's busybox tar rejects both flags, so the cache step would fail in every job that runs inside these images — which is all of them once ci.yml switches over. coreutils does not cover this: tar is its own Alpine package. Add it, add zstd (which actions/cache prefers over gzip when present), and assert GNU tar in the image's smoke test so a future base-image change cannot quietly drop it again. Part of #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:15:40 -03:00
thatguygriff	e097b7a0bf	Merge pull request 'CI: publish prebuilt CI images to the Gitea container registry' (#188) from feature/187-ci-container-images into main ... Reviewed-on: #188	2026-08-25 01:05:33 +00:00
thatguygriffandClaude Opus 5	572aaf5b49	Publish prebuilt CI images to the Gitea container registry ... setup-php installs PHP 8.3+ from apt on these arm64 runners: a ~145s floor against ~35s for 8.1/8.2, with a tail that twice ran past the step timeout and failed the run (#178). Caching the .debs softened it without removing the apt step, and 8.5 has the same problem. Add a per-version CI image built on php:<version>-cli-alpine and a workflow that publishes it to git.unsupervised.ca/unsupervised/ci-php:<version>. The org is public, so the packages pull anonymously. The image carries bash and nodejs because act_runner runs JavaScript actions inside the job container, GNU coreutils/grep/sed because the workflow scripts use `tac` and `grep --include`, and curl/jq/git/zip for release.yml and bin/build-zip.sh. Composer 2 and the intl and zip extensions round it out. Nothing consumes the images yet — ci.yml and release.yml switch over in a follow-up, because a job cannot run in an image that has not been published. Part of #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 21:55:28 -03:00
thatguygriff	116394f2ff	Merge pull request 'Bump version to 1.5.5' (#189) from release/bump-1.5.5 into main ... Reviewed-on: #189	2026-08-25 00:50:11 +00:00
thatguygriff	7278309bf5	Merge pull request 'Let the studio register the students who cannot register themselves' (#186) from fix/185-book-for-child-and-vet-group-enrolment into main ... Reviewed-on: #186	2026-08-24 22:03:11 +00:00
thatguygriffandClaude Opus 5	5ce42f0003	Let the studio register the students who cannot register themselves ... The Book a lesson for a student panel built its picker from the us_student role but vetted the submission with the book_lesson capability. ChildLoginGate and RegistrationLoginGate withhold that capability from accounts that keep the role, so the panel offered every guardian-managed child and every unapproved signup and then refused them — with a message claiming no student had been chosen, and a form cleared of all five fields. Withholding book_lesson stops those accounts registering in their own name. It was never meant to stop the studio acting for them, which is what the panel is for, and for a child is the only route to a lesson besides their guardian. Guard the student role instead, via a new RoleManager::isStudent() shared with every picker and guard on the staff side so the two cannot drift apart again. Group enrolment gets the same predicate: addDirect() and grantAccess() vetted their posted ids not at all, and would enrol an instructor, an administrator, or an account deleted since the page was drawn — raising a real payment against them for a priced class. Keep a refused booking's fields as submitted, reading the form through one LessonController::submittedBooking() so what gets booked and what is shown again cannot disagree about a field name. A booking that succeeds still leaves an empty form, so the next one does not inherit it. Closes #185 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01XunBYk2sFEc1oL14sUiuBU	2026-08-24 18:42:59 -03:00
thatguygriff	76530878b5	Merge pull request 'Bump version to 1.5.4' (#184) from release/bump-1.5.4 into main ... Reviewed-on: #184	2026-08-24 17:59:40 +00:00
thatguygriff	41843e5253	Merge pull request 'Let the studio book lessons and record intake collected elsewhere' (#183) from feature/182-admin-booking-and-intake-recording into main ... Reviewed-on: #183	2026-08-24 17:50:46 +00:00
thatguygriffandClaude Opus 5	8c21a3fa9d	Let the studio book lessons and record intake collected elsewhere ... Two related gaps, closed together because the second is created by the first. A private lesson could only be booked by the student or their guardian, so a booking taken over the phone had no way in — where group classes have had "Add students directly" all along. "Book a lesson for a student" is now a panel on Scheduler and My Lessons: student, open time, lesson type, with weekly term reservations and a no-charge option for make-up lessons. The booking core is extracted to Booking\LessonBooker and shared with POST /bookings, so the two paths cannot drift on offering rules, slot claiming, or billing. That leaves a registration with no intake answers and no policy acceptances, because nobody was at a keyboard to give them — already true of every directly added group-class student. Ticking the boxes on a student's behalf would be an audit trail that says something untrue, so instead the answers are collected another way and recorded afterwards, from a lesson's or an enrolment's detail page. Every recording must say how it was collected, which is stamped on each row along with who typed it and shown in a new "How it was given" column: a policy ticked online and one transcribed from paper must never look alike. Only staff-made registrations qualify (us_lessons.booked_by, us_group_enrollments.enrolled_by) — one the student made already holds their own answers. Only what is still missing can be recorded, re-checked at write time, so a stale or double-posted form cannot duplicate or overwrite. No IP is stored for a transcription, and accepted_by stays the student while recorded_by names the staff member. Intake is now generic over Registration\IntakeSubject, which Lesson and Enrollment both implement; LessonDetail became Registration\IntakeAudit and is shared by both detail views rather than duplicated. Closes #182 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QfHt6CyJHz6KkA4RuaS7WK	2026-08-24 14:06:16 -03:00
thatguygriff	8a34ec41e9	Merge pull request 'Cache the packages php-builder installs, and restore PHP 8.5' (#181) from ci/cache-php-builder-deps into main ... Reviewed-on: #181	2026-08-20 19:18:46 +00:00
thatguygriffandClaude Opus 5	37c8d2b39e	Put PHP 8.5 back in the matrix ... I misread the instruction to hold 8.5 as "take it out until the cache lands" and removed it in f6481d4, so #179 merged without it. It was meant to stay where it was. Restoring it. 8.5 takes the same php-builder path as 8.3, so the apt cache in this branch is exactly what it needs, and the per-version key means it caches its own ~70 -dev packages rather than sharing with the ondrej-path jobs. composer test passes on 8.5.9 locally: 915 tests, 2592 assertions. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 16:04:52 -03:00
thatguygriffandClaude Opus 5	a90e06ae70	Key the apt cache per PHP version and drop the instrumentation ... Run 536 proved the cache works -- ACTIONS_CACHE_URL is now populated, no GHES warning, "Cache saved with key: apt-php-builder-deps-ARM64-v1" -- and in doing so showed the key was wrong. The jobs that saved it were 8.1 and 8.2. They take the ondrej PPA path, a handful of runtime packages, while 8.3 takes php-builder and its ~70 -dev packages. One shared key therefore lets whichever job finishes first decide what every other job restores, and 8.1 is always first, at ~30s against 8.3's several minutes. 8.3 would have restored a few runtime .debs it has no use for and then downloaded all 70 anyway. My "the dep list is the same for every PHP version" comment was true only among the builder versions. Keyed per version now, so each path caches what it actually installs. That also picks up a small win on 8.1 and 8.2 rather than only avoiding harm. Both temporary steps are gone. Report restored .debs was there to show the cache URL arriving and the restore landing; both are established, so it goes. Keep downloaded .debs stays -- it is not instrumentation, it disables Ubuntu's docker-clean, without which there are no .debs left to cache. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:57:27 -03:00
thatguygriffandClaude Opus 5	d5f6ebf0b5	Move actions/cache to v4 and probe the cache URL ... thatguygriff/infra#1 turned the runner cache server on, so actions/cache has an endpoint for the first time. v4 rather than v3 because v4.2+ can speak the cache service v2 API, which is what the runner serves. The instrumentation step now also prints ACTIONS_CACHE_URL, so a single run shows the endpoint arriving and the cache being read in one log rather than needing a separate probe. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:56:37 -03:00
thatguygriffandClaude Opus 5	4b4b2453ae	Cache the .debs php-builder installs, to measure whether it helps ... Experiment for #178. On self-hosted runners setup-php installs PHP 8.3+ through php-builder, whose install.sh apt-installs ~70 -dev packages before unpacking the build. The build tarball itself is only 19MB, so that apt work is the whole cost, not the download. Ubuntu's image drops the .debs after install, so every job fetches them from the archive again. This keeps them and restores them through the cache server, which lives in the cluster, so a WAN download becomes a local one. The dependency list does not vary by PHP version, so a single key serves 8.3 and 8.5 and the quality and build jobs alike. Only the .debs are cached. /var/lib/apt/lists is deliberately left alone, since a stale index is how apt starts 404ing mid-install, and reducing flakiness is the entire point. The Report restored .debs step is temporary instrumentation to show whether the cache is actually being read. Baseline to beat, from run 526: 8.1 30s, 8.2 53s, 8.3 454s, quality 151s, 8.5 733s and a hard failure. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:56:37 -03:00
thatguygriff	7f10769330	Merge pull request 'Fold PHPCS and PHPStan into one job' (#179) from ci/consolidate-quality-job-and-php-85 into main ... Reviewed-on: #179	2026-08-20 18:55:16 +00:00
thatguygriffandClaude Opus 5	f6481d4a3f	Hold PHP 8.5 until the runner serves a cache ... 8.5 lands on setup-php's php-builder path, same as 8.3, so it pays for ~70 apt -dev packages on every run. It timed out in run 526 and passed in 527 on identical code, which is a coin toss, and merging it would mean intermittent red for a version nothing ships on yet. The code is fine on 8.5 — verified locally on 8.5.9: 915 tests, PHPStan and PHPCS clean, check-platform-reqs satisfied. This is purely about the runners, so 8.5 comes back once #178 is fixed and the matrix is cheap again. This PR is now just the PHPCS/PHPStan consolidation. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:33:03 -03:00
thatguygriffandClaude Opus 5	43b903c1c8	Revert the v4 cache retry: the gate stays shut, so it is the runner ... Tested and the hypothesis is dead. actions/cache@v4 resolved properly (SHA 0057852) and printed the same GHES warning as v3, so the action version was not what was closing the gate. That points at the runner rather than the action. Gitea's docs say the runner patches the GHES check out of the action's bundle only when it recognises it, and that a bundle it does not recognise "is left alone". No patching for either v3 or v4, and no ACTIONS_CACHE_URL to patch it towards, is what you get when cache is simply off in the runner config. So the fix is cache.enabled in act_runner's config.yaml, with host set to an address job containers can reach. Nothing in this repository unblocks it, and inert steps are what let the Composer cache rot unnoticed, so the experiment comes out again. Both halves — the apt cache and the move to v4 — should land together once the runner serves a cache. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:07:18 -03:00
thatguygriffandClaude Opus 5	d5eb2764a3	Retry the apt cache on actions/cache@v4 ... My last conclusion was wrong. The GHES warning is not evidence that the runner has no cache server; it is actions/cache v3 disabling itself. v3's isGhes() reads GITHUB_SERVER_URL, and anything that is not github.com reads as GitHub Enterprise, so on Gitea it always trips and the action returns before touching the cache. That explains the 0.2s save perfectly well without any runner setting being off. Gitea's runner 3.0.0 release notes say every runner starts its own cache server and that the runner "patches action bundles at load time to open the GHES gate and read the cache endpoint from ACTIONS_CACHE_URL", with actions/cache supported unforked. Our runners report v3.0.0, so the server should be there and the gate should be open — but the patching evidently does not reach a v3 bundle. So this reapplies the apt cache and moves every actions/cache to v4. If the hypothesis holds the GHES warning disappears, the save step actually takes time, and a second run restores the .debs. The Composer cache gets the bump too, since it has been silently doing nothing for the same reason. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:04:33 -03:00
thatguygriffandClaude Opus 5	dd31afcd06	Revert the apt cache experiment: the cache service is switched off ... Measured on run 527 and it cannot work. Every actions/cache step on these runners prints Cache action is only supported on GHES version >= 3.5 ... check with GHES admin if Actions cache service is enabled or not and then no-ops. The save step finishes in 0.19-0.31s, which is not a few hundred megabytes of .debs going anywhere. setup-php timings were unchanged against the run 526 baseline, within the usual variance: 8.3 454s then 148s, 8.5 733s then 446s, both noise rather than signal. The same warning appears on the Composer cache this workflow has carried all along, including run 523 and earlier, so that step has never cached anything either. Worth fixing, but in the runner config rather than here. Leaving dead steps in the workflow is how the Composer cache went years without anyone noticing it did nothing, so the experiment comes out until act_runner has its cache service enabled. It is in the history when that happens. Detail in #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 14:59:39 -03:00
thatguygriffandClaude Opus 5	85c7a01939	Cache the .debs php-builder installs, to measure whether it helps ... Experiment for #178. On self-hosted runners setup-php installs PHP 8.3+ through php-builder, whose install.sh apt-installs ~70 -dev packages before unpacking the build. The build tarball itself is only 19MB, so that apt work is the whole cost, not the download. Ubuntu's image drops the .debs after install, so every job fetches them from the archive again. This keeps them and restores them through the cache server, which lives in the cluster, so a WAN download becomes a local one. The dependency list does not vary by PHP version, so a single key serves 8.3 and 8.5 and the quality and build jobs alike. Only the .debs are cached. /var/lib/apt/lists is deliberately left alone, since a stale index is how apt starts 404ing mid-install, and reducing flakiness is the entire point. The Report restored .debs step is temporary instrumentation to show whether the cache is actually being read. Baseline to beat, from run 526: 8.1 30s, 8.2 53s, 8.3 454s, quality 151s, 8.5 733s and a hard failure. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 14:44:54 -03:00
thatguygriffandClaude Opus 5	bc046ec2a1	Fold PHPCS and PHPStan into one job and test PHP 8.5 ... The two jobs were identical up to their final step, each paying for its own Setup PHP. That step is the flaky one (#178), so running it twice to reach two short commands was two chances for a run to fall over instead of one. They are now steps in a single Coding Standards & Static Analysis job. The one thing given up is that PHPCS failing now stops the job before PHPStan reports, where before the two ran in parallel and both spoke. That seemed a fair trade for halving the exposure, and the fix for a PHPCS failure rarely depends on knowing PHPStan's verdict at the same time. PHP 8.5 joins the test matrix. composer.json already allows it at >=8.1 and the suite passes on 8.5.9 locally: 915 tests, PHPStan and PHPCS clean, check-platform-reqs satisfied. 8.4 is deliberately not added, only 8.5. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 14:29:30 -03:00
thatguygriff	b814ae34b4	Merge pull request 'Stop authenticating setup-php against the GitHub API' (#177) from ci/drop-github-token-from-setup-php into main ... Reviewed-on: #177	2026-08-20 17:25:22 +00:00
thatguygriffandClaude Opus 5	9071a3f70f	Stop authenticating setup-php against the GitHub API ... The GitHub API rate limit was the wrong diagnosis, so this reverts the 1Password-backed token added in #175 along with the mirrored composite action, leaving the workflows as they were. Timing every Setup PHP step across runs 454-523 rules the rate limit out. PHP 8.1 and 8.2 install in 26-41 seconds, 12 for 12, never once failing. PHP 8.3 has never finished in under 143 seconds and ranges up to 1273, with two outright failures. Those jobs share a fan-out, and so an egress address and a rate limit bucket, with the 8.1 and 8.2 jobs that are never touched. A throttle could not sort itself by PHP version that way. Run 523, the first to carry the token, is the direct refutation: the token resolved and verified, and Setup PHP still took 749 seconds on kallone and 408 on eris. The 8.3 penalty also predates the whole story, sitting at ~145 seconds back on 30 July. What is left is a slow path specific to 8.3 on these arm64 runners, whose long tail sometimes crosses the step timeout and reports the unhelpful "Could not setup PHP 8.3". That is worth fixing on its own terms rather than behind a token that was never in the path. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 14:22:52 -03:00
thatguygriff	170d7e6c21	Merge pull request 'Authenticate setup-php against the GitHub API' (#175) from ci/github-token-for-setup-php into main ... Reviewed-on: #175	2026-08-20 16:56:38 +00:00
thatguygriff	aa3dd13775	Merge pull request 'Bump version to 1.5.3' (#176) from release/bump-1.5.3 into main ... Reviewed-on: #176	2026-08-20 16:37:58 +00:00
thatguygriffandClaude Opus 5	1291af0b72	Authenticate setup-php against the GitHub API ... setup-php resolves its tools through the GitHub API, unauthenticated at 60 requests an hour per source address. A CI fan-out across the fleet exhausts that bucket, and the step then retries for several minutes before reporting only "Could not setup PHP 8.3". It reads as a hang rather than a throttle, and it took out both a main CI run and a release build. Each cluster has its own egress address and so its own bucket, which is why the same job passed on one runner and failed on another in the same minute. The token comes from 1Password through the Connect instance in whichever cluster picked up the job, matching the pattern in thatguygriff/infra. That repository's composite action is not reachable from here, so it is mirrored locally. It stays a step output rather than being exported to the job environment, to keep it away from the package scripts composer install runs. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_0133tYSQoZhoKebKZV8o2GPs	2026-08-20 13:27:22 -03:00
thatguygriff	78083fc96c	Merge pull request 'Let a studio choose its default payment method, and disconnect Stripe again' (#174) from feature/173-default-payment-method into main ... Reviewed-on: #174	2026-08-20 15:53:02 +00:00
thatguygriffandClaude Opus 5	c077a653fb	Let a studio pick its default payment method and disconnect Stripe ... Stripe configuration was a one-way door. Keys could be entered but never removed, and entering them moved every student onto card billing at once, so there was no way to have Stripe live and satisfy yourself that card payments worked before committing the studio to them. Two settings-page changes open both directions: Default payment method (`us_default_payment_method`) is now an explicit choice between card and e-transfer for students with no per-student override, rather than something inferred from whether keys exist. Card remains the default, so a site that adds keys and changes nothing else behaves as before. BillingMethodResolver still degrades a card default to e-transfer while Stripe is unconfigured — there is nothing to charge a card with — and `comp` is deliberately not offerable studio-wide, since it would silently stop billing everybody; an unrecognised stored value reads back as card. Holding the default on e-transfer with Stripe live is the staged-rollout path: move individual students to card on their detail page, watch real charges land, then flip the studio over. Clear Stripe configuration deletes the publishable key, secret key and webhook signing secret and returns the mode to test, so a re-configuration later cannot inherit live. Currency, HST, e-transfer and registration settings are untouched, as are recorded payments. The button only appears when some Stripe value is stored, and reuses the page's existing nonce and `manage_billing` check. `composer test` (915), `composer lint` and `composer cs` all pass. Options only — no schema change, so no version bump. Closes #173 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01WyktWmwNRgMYuwe5eBuPZm	2026-08-20 12:43:29 -03:00
thatguygriff	f9e222be29	Merge pull request 'Bump version to 1.5.2' (#172) from release/bump-1.5.2 into main ... Reviewed-on: #172	2026-08-11 22:06:41 +00:00
thatguygriff	b220de48c5	Merge pull request 'Let a guardian enrol every child in the same group class' (#171) from fix/group-multi-student-enrolment into main ... Reviewed-on: #171	2026-08-11 20:44:29 +00:00
thatguygriffandClaude Opus 5	8017dbb9ff	Let a guardian enrol every child in the same group class ... The group-class page matched enrolments to the account instead of to the student: the lookup it built from GET /enrollments was keyed by offering id alone, so the first household enrolment marked the class as "yours" and took the Enrol button away from everyone else on the account. A parent could enrol one child and was then offered nothing but Withdraw. The server was never the constraint — hasActiveEnrollment() checks the (offering, student) pair and GET /enrollments deliberately returns the whole household — so the fix is to stop discarding student_id on the way in. Active enrolments are now grouped per class as a list, each student gets their own "… is enrolled in this class." line and their own named Withdraw button, and the Enrol button stays (as "Enrol another student") while anyone the account may enrol is still out. The enrolment form offers only the students not yet enrolled. When exactly one of them is left the picker collapses, and that case needed care: an omitted student_id reads as "enrol the account holder" server-side, so a hidden field carries the id rather than posting nothing and signing up the parent instead of the last child. Closes #170 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Jy9UPhmpLUAfimsyecHN2Z	2026-08-11 17:36:01 -03:00
thatguygriff	c73b10d779	Merge pull request 'Bump version to 1.5.1' (#169) from release/bump-1.5.1 into main ... Reviewed-on: #169	2026-07-30 19:48:12 +00:00
thatguygriff	1e4e21e8d3	Merge pull request 'Show a recurring lesson's policy acceptances and intake answers on every week of it' (#168) from fix/167-series-policy-acceptances into main ... Reviewed-on: #168	2026-07-30 19:41:03 +00:00
thatguygriffandClaude Opus 5	df3462a8b3	Show a series' policy acceptances on every occurrence ... A weekly booking reserves a series of lessons, but the student answers the intake and ticks the policy boxes once — so BookingEndpoint records both against the anchor lesson alone. The admin detail view looked them up by whichever lesson id was being viewed, so every occurrence after the first showed no answers and no acceptances at all. LessonDetail now takes the Lesson rather than a bare id and resolves the registration to `series_id ?? id`, so each occurrence reads the anchor's records. This is the same seam PaymentService already uses to find a series lesson's payment on the anchor. Nothing was ever missing from the database, so existing bookings read correctly with no migration and no schema change. Closes #167 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 16:35:26 -03:00
thatguygriff	748478f2f1	Merge pull request 'Let the account holder edit their own details on the profile page' (#166) from feature/165-editable-own-profile into main ... Reviewed-on: #166	2026-07-30 19:29:21 +00:00
thatguygriffandClaude Opus 5	f97b8a4576	Let the account holder edit their own profile details ... The Profile block is headed "Your profile", but the one person on it you could not change was yourself: your name, your birth year, and whether you take lessons yourself were fixed at whatever signup recorded, and correcting any of them meant asking a studio admin. A "Your details" section now opens the page, saved through the same nonce-checked template_redirect post/redirect/get path the child rows use: - Your name, written to display_name and nickname together, for the reason updateChild() does — UserName reads the nickname first, and leaving it behind would put the account's email address back on every screen that names a person. - "I take lessons myself", the positive of us_guardian_only. This makes good on the claim already in bookableStudents() and the feature doc that a guardian-only account can put itself right from the profile page. - Your birth year, held to the same normaliseBirthYear() rule as every other student. The email is shown but not editable: it is the account's user_login as well as its address, so changing it stays a studio-side job. The birth-year field deliberately carries no `required` attribute. It is asked of a student only, and this page loads no JavaScript, so a browser-enforced `required` would leave a guardian who books solely for other people unable to submit the form at all; handleSelf() enforces it against the checkbox instead. Unticking the box does not clear a stored birth year — it says who books, not "forget what is on file". Closes #165 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 15:08:05 -03:00
thatguygriff	325a86f247	Merge pull request 'Ask some registration questions of students only, and require them of students without requiring them of the account holder' (#164) from feature/student-scoped-registration-questions into main ... Reviewed-on: #164	2026-07-30 16:56:33 +00:00
thatguygriffandClaude Opus 5	434fe801ba	Ask some registration questions of students only ... Every account-signup question was asked of everybody who registered, on the same terms: "school and grade" had to be put to an adult signing themselves up, and a question a studio needed answered for each student could only be made required by demanding it of everyone. A question now carries an audience — everyone, or only the students someone registers on behalf of — and its own required flag for each side, so optional for you and required for every student you enrol is expressible. Both settings are account-scope only: an offering asks its questions once, about the student being booked, so there is no second audience to differ from, and an offering question mirrors its single "required" into both columns. Every caller reads askedOfSelf()/isRequiredForSelf()/isRequiredForChild() rather than the raw flags, so a students-only question can neither block the account holder nor have an answer filed against them by a crafted post. The family screen, which only ever adds a student, is held to the students' rule. is_required_child arrives from dbDelta defaulting to 0, which would quietly stop every existing required question being required of the students a guardian registers — the case it most likely existed for. A one-time backfill copies is_required across, guarded by its own option so a question later made optional for students stays that way. Closes #163 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 13:51:52 -03:00
thatguygriff	84378e856b	Merge pull request 'Bump version to 1.4.2' (#162) from release/bump-1.4.2 into main ... Reviewed-on: #162	2026-07-30 15:55:06 +00:00
thatguygriff	5d98aedfa5	Merge pull request 'Editable policy name, one-page signup with adult birth year, group classes in upcoming lessons, and booking cleanup on user delete' (#161) from feature/demo-followups-2026-07-30 into main ... Reviewed-on: #161	2026-07-30 15:28:12 +00:00
thatguygriffandClaude Opus 5	8fd7bf983d	Name people by their name, 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, instructor names on the class pages. WordPress defaults a new account's `nickname` to its `user_login`, and signup uses the email address as the login. So every self-registered account carried its own address as its nickname, and UserName::format() fell straight through to it. The name they typed was in `display_name` all along. Accounts created by a guardian were never affected — GuardianService::createChild() sets `nickname` outright, which is exactly why children read correctly and their parents did not. UserName::format() now walks nickname then display name, skipping either when it is really the login or the email, so existing accounts read correctly with nothing to migrate. An identifier still never reaches the screen: an account with nothing but its address on file falls back to the id, as before. Signup also sets `nickname` at insert, so new accounts are right at the source rather than relying on the fallback. Tests: composer test (866), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 12:24:04 -03:00
thatguygriffandClaude Opus 5	122f7a0f53	Show "Booked by" in the Account section of a student's detail page ... The parent/guardian was only named further down under Profile, where it reads as background rather than as an account fact, and only when there was one — so a page with no such line was ambiguous between "books for themselves" and "the lookup found nothing". It now sits in the Account table beside display name and email, as the guardian's name linked to their own detail page, and always renders: a student who books for themselves says so outright. No email address — theirs is one click away on their own page, and repeating it here only makes the row harder to scan. The Profile section keeps only the note explaining the placeholder email, which is a different point. Tests: composer test (863), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 12:18:42 -03:00
thatguygriffandClaude Opus 5	c9a1205fc0	Never drop an enrolled class from upcoming lessons; delete a guardian's children with them; pin the panel's line spacing ... Three fixes from testing the branch. A group class was only listed when its schedule resolved to exact datetimes, which needs a class time *and* a duration — both optional on the offering form, and the schedule note exists precisely so a studio can write "Tuesdays 4:00pm" instead. A class configured that way vanished from the list, which is the one thing this feature must never do. So Offering::sessionStarts() splits "when does it meet" from "how long does it run" (sessionWindows() is that plus the duration, unchanged), and SessionSchedule degrades instead of disappearing: dated rows with an open end when there is no duration, and a single row carrying Offering::scheduleLabel() when there is no time to derive dates from. Only a class whose last day has passed drops out. Deleting a guardian now deletes the children linked to them, releasing each one's lessons and enrolments first. A child account is login-less and exists only so the guardian has somebody to book for; without the guardian nobody can reach it, book for it, or be billed for it, so it was left stranded on the roster still holding slots. A `handled` set makes the re-entrant delete_user each child deletion fires a no-op, and stops a circular link recursing. The upcoming panel never stated its own line-height, so a theme setting line-height: 0 above it — the usual icon-font reset — was inherited straight through. Below 1 that produces both reported symptoms at once: stacked lines overlap, and the status pill's background is shorter than the text in it. Pinned at the same id-level specificity as the rest. Tests: composer test (863), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 12:10:43 -03:00
thatguygriffandClaude Opus 5	cb347ffca0	Demo follow-ups: editable policy name, one-page signup, group classes in upcoming lessons, deletion cleanup ... Five items from the latest demo pass: - A policy's title can be edited from the Policies screen. Only the title moves; the slug is what the gates resolve policies by, so a rename can never detach a policy from acceptances already recorded against it. - Signup is one page again. The studio's registration questions move from a second step behind "Next" onto the main form, in an "About you" panel above the students being added, and that panel also asks an adult student for their birth year (the same us_birth_year meta a child's uses). register.js disables and hides the whole panel for a pure guardian, since the questions describe a student. - The password is re-scored on submit, not only as it is typed. zxcvbn's dictionary arrives after page load, so a password typed straight away was never scored at all and the first the student heard of it was the server rejecting the whole form. - Group-class sessions appear alongside lessons wherever upcoming lessons are listed: the [us_scheduler] panel (students and instructors) and the admin student detail page. GroupClass\SessionSchedule derives them from Offering::sessionWindows(), the same derivation the billing scan uses. They carry kind = 'group_class' and no Cancel action - a session is one date in a term, not a booked slot. - Deleting a user releases what the account was holding: each upcoming lesson is cancelled, its slot freed for rebooking, its pending payment voided, and active class enrolments cancelled. Past lessons and paid history are left alone. Tests: composer test (851), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 11:45:04 -03:00
thatguygriff	258468093b	Merge pull request 'Bump version to 1.4.1' (#160) from release/bump-1.4.1 into main ... Reviewed-on: #160	2026-07-30 02:30:31 +00:00
thatguygriff	969d864106	Merge pull request 'Ask who the signup is for, and ask each student the studio's questions' (#159) from feature/145-registering-for-choice into main ... Reviewed-on: #159	2026-07-30 02:24:52 +00:00
thatguygriffandClaude Opus 5	69179b75c9	Ask the account holder the studio's questions when they are a student too ... Under "both" the questions were collected per student only, so someone registering themselves alongside their children was never asked their own instrument, level or anything else — despite being able to book lessons. The account-scope questions describe a student, and under "both" the account holder is one. Their answers are recorded against their own user id, not shared with a child's, and recorded after the children so a rollback that deletes the account cannot leave answers pointing at a user that no longer exists. A pure guardian is unchanged: they are not a student, so anything posted for them is still ignored. Validation became two passes rather than one so the message can say whose answers are missing — with one pass, "both" had to blame "each student" for the account holder's own blank field. In the form, the two questions turn out to be independent: whether student blocks are in play, and whether the account holder answers for themselves. "Both" is the case that needs its own answer to each, so sync() now tracks them separately, and step two comes back into play under "both". Verified in a headless browser: 21 checks across all three choices, now including that "both" enables the account holder's own question panel and offers Next rather than the early submit. Closes #146 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 23:15:47 -03:00
thatguygriffandClaude Opus 5	4e5382e259	Ask who the signup is for as a three-way choice ... Replaces the single "I'm registering as a parent or guardian" tick with "Just myself" / "On behalf of one or more students" / "Both". Radios, not checkboxes as the feedback put it: the three answers are mutually exclusive, and "both" only means anything as a third choice alongside the other two. The tick could only ever say whether there were children to add. It could not say whether the account holder was a student, so bookableStudents() always offered them their own name and any guardian could book themselves a lesson nobody meant to sell. "On behalf of" now records us_guardian_only and leaves them out of the picker. That flag is stored as the negative on purpose. Every account predating this choice is a bookable student, and absence has to keep meaning exactly that, or the picker would quietly stop offering people themselves on upgrade. setGuardianOnly() clears the key rather than writing 0, so "not set" stays the single spelling of "yes, a student". A guardian-only account with nobody linked to it is still offered itself — an empty picker is no way to book at all, and they can put the account right from the profile page. An unrecognised or absent value reads as "just myself": the choice that collects the least and grants the least. A missing radio must never be taken as "register these children". Bumps to 1.4.0. The account holder's own questions stay out of play whenever students are being added, "both" included — asking them there is #146. Verified the form in a headless browser across all three choices: which blocks show, which fields carry `required`, whether the account holder's question panel is disabled, which submit is offered, and that switching back to "just myself" leaves no hidden required field blocking submit. Closes #145 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 23:09:47 -03:00
thatguygriff	28046e0fd1	Merge pull request 'Return to a bookable calendar after a booking is confirmed' (#158) from fix/143-return-to-bookable into main ... Reviewed-on: #158	2026-07-30 02:02:51 +00:00
thatguygriffandClaude Opus 5	699e479805	Return to a bookable calendar after a booking is confirmed ... showConfirmation() hid the slot list and put the confirmation in its place, which is a dead end: a student wanting a second lesson had nothing to click and no way back short of reloading the page. Enrolling in a group class did the same thing. The confirmation is now a dismissible notice above the calendar. The calendar is reloaded first — so the slot just taken is already gone and the upcoming-lessons panel is current — and the notice is shown over it, which is why loadSlots() had to start returning its promise. "It worked" and "book another" are the same screen. The notice clears when dismissed, when another slot's form is opened, and on any reload of the calendar. group-classes.js gets the identical treatment. It is built from DOM nodes rather than innerHTML because the message can carry a studio's e-transfer address, and it is toggled with the `hidden` attribute rather than an inline display — an inline style would outrank the stylesheet's display:flex and stack the notice's parts. `hidden` needs the !important guard for the same reason the upcoming-lessons panel does: the div{display:block} theme reset outranks the UA sheet. The slotList/list `display = 'block'` lines went with it. Nothing hides those any more, so restoring them each load only implied otherwise. Verified in a headless browser against a stubbed REST API: booking twice in a row without a reload, the booked slot leaving the calendar, the upcoming panel updating, dismissal, the notice clearing when the next form opens, and the notice staying hidden under div{display:block}. Closes #143 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 22:57:16 -03:00
thatguygriff	1b42d20541	Merge pull request 'Add an account block showing who is signed in' (#156) from feature/142-account-block into main ... Reviewed-on: #156	2026-07-30 01:53:31 +00:00
thatguygriffandClaude Opus 5	ab5212282d	Show only the name and email, not who the account books for ... The block reports who is signed in and nothing more. Dropping the "Booking for …" line takes GuardianService with it — it was the only reason the page had a dependency at all, so AccountPage now constructs with no arguments. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 22:42:25 -03:00
thatguygriffandClaude Opus 5	6e3affb1cb	Add an account block showing who is signed in ... [us_account], or the Account block: the signed-in visitor's name, their email, a Sign out link, and — only when the account books for someone besides itself — the students it books for. A parent's first question on seeing "signed in as Grace" is whether this is the account their children's lessons are on. Two decisions worth naming. Signed out with no login page chosen, the block renders nothing. Its whole subject is the person signed in, which a stranger is not, and a bare "you are not signed in" in a site header is noise with no way to act on it. With a login page chosen it offers a Sign in link instead. The editor preview is populated regardless, so the block is never an invisible box to the person placing it. Signing out returns to the chosen login page, or to the current page when there is none. A block meant for a header should not also navigate someone somewhere when they use it; the login page wins when configured, because the page they were on may well be members-only. The name comes from UserName::format(), so the block never exposes a username the way display_name can. Also brings docs/features/editor-blocks.md back in step: it still described "four shortcodes" and had never listed the family block. Closes #142 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 22:42:25 -03:00
thatguygriff	7875cb1bf7	Merge pull request 'Fix main: two signup fixtures use a now-rejected password' (#157) from fix/green-main into main ... Reviewed-on: #157	2026-07-30 01:41:29 +00:00
thatguygriffandClaude Opus 5	04cba9702c	Fix main: two signup fixtures use a now-rejected password ... #154 and #155 each passed on their own branch and broke on landing together. #154 added two guardian-signup tests using 'password123' as their fixture; #155 then added PasswordPolicy, which rejects exactly that. Neither branch ever saw the other's change, because #155 was cut from main before #154 merged. Both tests now use the same policy-clearing fixture as the rest of the file. The deliberate 'password123' in the rejected-passwords provider stays — that one is the point. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 22:40:51 -03:00
thatguygriff	d554e35d80	Merge pull request 'Validate signup email and password strength' (#155) from feature/150-signup-credential-validation into main ... Reviewed-on: #155	2026-07-30 01:27:05 +00:00
thatguygriffandClaude Opus 5	b5b9a7ac54	Validate signup email and password strength ... The password was only ever checked for length. It is now checked on both sides, with each side doing the job it can actually do. The browser scores it with zxcvbn, through WordPress's own password-strength-meter script rather than a second opinion of our own, and refuses to submit below "medium". That is the nuanced test — it knows Tr0ub4dor&3 is weaker than it looks — but it is advice a client can decline to take. Auth\PasswordPolicy runs on the server and is the rule that holds. It does not try to reproduce a strength score in PHP; it rejects the categorically bad, which is what a server can check without shipping a dictionary: too short, a well-known leaked password, fewer than four distinct characters, or the user's own name or email inside it. No composition rules — NIST advises against them, and they mostly produce predictable substitutions. Both thresholds come from the same two constants, handed to JavaScript by wp_localize_script, so the sides cannot drift into disagreeing about what was accepted. The verdict is attached to the field with setCustomValidity() rather than by disabling a button. The form has up to three submits plus a "Next" that already gates on checkValidity(), and an invalid field stops all of them without any of them needing to know why. Email validation moved ahead of the password check, since the password is now checked against the email. A blank form therefore reports the email first, which also matches the order the fields appear in. Verified the browser half against a controllable scorer: each score band blocks or allows as intended, the identity list reaches the meter, and the gate stays open while zxcvbn's dictionary is still loading — the server covers that window. Closes #150 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 22:13:31 -03:00
thatguygriff	f0149042cc	Merge pull request 'Require a name and birth year for every student' (#154) from feature/148-required-name-and-birth-year into main ... Reviewed-on: #154	2026-07-30 00:04:51 +00:00
thatguygriffandClaude Opus 5	1d2f95d388	Require a name and birth year for every student ... Both fields are marked in their labels the same way a required registration question is, and enforced on the server whichever form they arrive from: GuardianService::createChild() and updateChild() now refuse a blank name or an unusable birth year, and the signup form checks the same rule up front, before it creates a single user, so a bad block never leaves a half-registered family behind. normaliseBirthYear() became public and static so both paths share one definition of what a usable year is. The signup form cannot lean on the browser here. Its child blocks are hidden until the parent/guardian box is ticked, and a `required` field inside a hidden container makes the whole form unsubmittable with no control the user can reach to fix — the same trap the guardian's own question panel already sidesteps by disabling rather than hiding. So register.js puts `required` on and takes it off along with the block itself, and the server is what makes the rule hold with JavaScript off. The profile screen has no such problem: its forms are always visible, so the attribute is static there. One behaviour change beyond the requirement: a child block with anything typed into it is now reported back instead of dropped. Previously any block without a name was silently discarded, which would now mean losing a birth year the guardian had filled in. A wholly untouched spare block — the one the form always renders for "add another" — is still ignored. Verified the required-toggling in a headless browser: unticked submits, ticked blocks an empty block, a cloned block inherits the requirement, and re-unticking leaves nothing behind to block a non-guardian signup. Closes #148 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 21:00:45 -03:00
thatguygriff	2878beb221	Merge pull request 'Collect a birth year instead of a full date of birth' (#153) from feature/147-birth-year into main ... Reviewed-on: #153	2026-07-29 23:53:37 +00:00
thatguygriffandClaude Opus 5	7e2bba79fe	Collect a birth year instead of a full date of birth ... Signup and the profile page now ask for a four-digit year between 1900 and the current year. Anything else — a short year, a full date, a year in the future — is discarded rather than stored, so a typo cannot leave a nonsense age on the record. The year lives in a new us_birth_year user meta rather than reusing us_date_of_birth, which would have left one key holding two formats. The old key is not migrated in bulk. Instead GuardianService handles it in two halves: birthYear() falls back to the year of the old date when the new key is absent, so a student added before this change still shows one, and setBirthYear() deletes the old date on every save. That deletion is what makes the fallback safe rather than merely tidy. Without it, clearing the birth year on a student who predates the change would leave the old date behind for the fallback to read straight back, and the year could never be cleared at all. Stored in user meta, so no Schema.php change and no USC_VERSION bump. Closes #147 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 20:47:56 -03:00
thatguygriff	3a83decc82	Merge pull request 'Say "student" and "profile" in the UI, not "child" and "family"' (#152) from refactor/144-student-profile-copy into main ... Reviewed-on: #152	2026-07-29 23:41:55 +00:00
thatguygriffandClaude Opus 5	76caf178f0	Say "student" and "profile" in the UI, not "child" and "family" ... Sweep the translatable strings across the frontend templates, the admin screens, the editor previews and the block inserter entry. Nothing else moves: the database columns, request parameters, form field names, CSS classes, the us_family shortcode and the us-scheduler/family block name are contracts with existing installs and with post content people have already saved, so renaming them would break sites for no user-visible gain. Two strings are reworded rather than swapped, because the direct substitution reads wrong: - The students list said "Child of Jane" and now says "Managed by Jane". "Student of Jane" would read as a teacher's pupil, which is exactly the wrong idea in a music studio. - A managed account is now "a managed student account" rather than "a student account", which would not distinguish it from the account holder. The guardian feature doc gains a short section on the split, so the next person to work on it does not read the mismatch as drift and "fix" it. Closes #144 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 20:34:55 -03:00
thatguygriff	8013d05d68	Merge pull request 'Stop upcoming lesson rows rendering on top of each other' (#151) from fix/149-upcoming-lesson-overlap into main ... Reviewed-on: #151	2026-07-29 23:29:18 +00:00
thatguygriffandClaude Opus 5	6b29c0e78e	Stop upcoming lesson rows rendering on top of each other ... The panel's row and its two columns are divs with explicit flex rules, but the text itself still sits in inline elements. A theme is free to take those out of normal flow, and when it does the date and time land on the lesson title and the status pill lands on the Cancel button. Pin position, float and margin on the leaf elements at the same id-level specificity the rest of the panel already uses, so a theme rule cannot lift them out of the column. The rows behind "Show all" had the same shape of problem from the other direction: `[hidden]` is only a UA-stylesheet rule, so the `div { display: block }` reset that many themes still ship outranks it and the collapsed rows render anyway. An author `!important` is the only way to win that particular cascade. Verified with a headless-browser harness rendering the exact markup booking.js emits against twelve theme CSS patterns at two widths: before, five patterns overlapped text or revealed the hidden rows; after, all pass. Closes #149 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 20:28:25 -03:00
thatguygriff	7ea6616ba0	Merge pull request 'Trim CLAUDE.md to what the codebase can't tell you' (#141) from docs/trim-claude-md into main ... Reviewed-on: #141	2026-07-29 19:41:35 +00:00
thatguygriffandClaude Opus 5	7fdf97b073	Trim CLAUDE.md to what the codebase can't tell you ... Most of this file described the repo as it was around v1.0: three domain packages, two database tables, twenty-one classes. There are now eleven packages, fifteen tables, and well over a hundred classes, so those sections were not just redundant with `ls` and Schema.php — they were teaching the wrong shape of the codebase. Same for the CI section, which had drifted past the build job. Cut the command list (composer.json has the scripts), the bootstrap description, the directory tree, the table list, the Key Classes table, and the CI job summary. Kept every rule the code can't explain on its own: package-by-domain, no $wpdb outside repositories, capability checks rather than role names, and the Schema.php version-bump gotcha. Moved the Brain\Monkey and Mockery gotchas to tests/CLAUDE.md, which loads only when working under tests/ instead of in every session. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 16:39:43 -03:00
thatguygriff	d3843186c0	Merge pull request 'Bump version to 1.3.1' (#140) from release/bump-1.3.1 into main ... Reviewed-on: #140	2026-07-29 19:28:42 +00:00
thatguygriff	3c41d1119d	Merge pull request 'Let parents register once and book for their children' (#139) from feature/parent-guardian-accounts into main ... Reviewed-on: #139	2026-07-29 19:17:05 +00:00
thatguygriffandClaude Opus 5	8122c158cf	Keep the guardian service within the PHP the plugin supports ... `true` as a return type is PHP 8.2, but the plugin advertises 8.1, so the family screen's two service calls fataled on the 8.1 test job while every other job passed. They now return `?\WP_Error` — null on success — which matches RegistrationGate::validate() and works on 8.1. PHPStan was analysing against whatever PHP happened to be running (8.3 in CI, newer locally), so `composer lint` was green on syntax the plugin promises not to use. It is now pinned to the supported 8.1-8.3 range, which reproduces this failure at lint time instead of three jobs later. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 16:07:52 -03:00
thatguygriffandClaude Opus 5	b772e1811e	Let parents register once and book for their children ... A parent registers once and manages lessons for one or more children, who need no login of their own. A child is a real wp_users row with the student role but no usable login — so student_id keeps meaning "a WordPress user" on every table, and booking, credits, policies and enrolments work unchanged. A us_guardians link table maps guardian to child. The signup form gains a parent/guardian tick that reveals a block per child, with the account-signup questions asked per child rather than per guardian — they describe the student, not the account holder. Signup policies are recorded once per child with the guardian as the acceptor, which is the record that actually means something. A family that half-creates is rolled back entirely rather than leaving a guardian who cannot re-register. The booking and enrolment forms gain a "Who is this for?" picker listing children first, so the default selection is never the parent — booking for the wrong child is correctable, quietly billing a parent for their kid's lesson is not. POST /bookings and POST /enrollments take an optional student_id honoured only for that child's guardian; anything else is a 403. That check is the authorisation boundary of the feature. Payments and credits gain a payer: the charge names the child it was for and the guardian who owes it, so per-child reporting is unchanged while notices, receipts and the payment step reach the parent. Credit is held by the payer, so one child's cancellation can settle a sibling's charge, and the daily billing scan sends a guardian one notice covering every child. Closes #132 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 16:07:52 -03:00
thatguygriff	c25260a367	Merge pull request 'Bump version to 1.2.5' (#138) from release/bump-1.2.5 into main ... Reviewed-on: #138	2026-07-29 02:29:57 +00:00
thatguygriff	bbc85d88f1	Merge pull request 'Stop the availability form failing in silence' (#137) from fix/availability-silent-failures into main ... Reviewed-on: #137	2026-07-29 02:25:36 +00:00
thatguygriff	171b655bb8	Stop the availability form failing in silence ... Adding availability for 5:30-6:00 PM with the lesson length left on its 60-minute default saved nothing and said nothing. A window is stored as consecutive lesson-length slots, so one that fits no lesson splits into none: splitByDuration() returned [], createFromWindow() inserted nothing, and addSlot() discarded the result and re-rendered the page unchanged. The REST endpoint already rejected that window with a 400. The admin form checked the same rules separately, and its copy was both laxer and mute — an unreadable date, an end before the start, and a two-day window were bare `return`s, and it never checked offering ownership at all, so a crafted POST could tie a slot to another instructor's offering and inherit their price and payment routing. Both callers now go through WindowValidator, which returns the window or a WP_Error explaining the refusal. The endpoint returns that error as is; the page renders its message as a notice. handleFormAction returns a [notice, error] pair so deletes report themselves too, and a successful add says how many slots it created. Two failures could also go unnoticed underneath: wpdb::insert's result was ignored, and insert_id still holds the previous statement's id after a failed write, so a failure looked like a success — and could become the recurrence group of a weekly series, orphaning every later occurrence. weeks was unbounded server-side despite the form's max=52. availability-admin.js narrows the lesson-length choices to those that fit the window and blocks submission when none do, which is what makes the original mistake hard to repeat. It is a convenience: the server validates regardless. Closes #130	2026-07-28 23:19:49 -03:00
thatguygriff	d9dd576630	Merge pull request 'Link a signed-in visitor to the configured continue page' (#134) from feature/registration-logged-in-continue-link into main ... Reviewed-on: #134	2026-07-29 02:18:21 +00:00
thatguygriff	61b00c2ed3	Add the changelog entry for the continue link	2026-07-28 23:07:11 -03:00
thatguygriff	7eb2afc6a3	Name the destination page in the continue link ... "Continue to your account" says nothing about where the link goes. Use the chosen page's own title instead — "Continue to Book a Lesson" — so the visitor knows before clicking. An untitled page keeps the generic wording rather than rendering "Continue to ".	2026-07-28 23:06:54 -03:00
thatguygriff	8a985f04d6	Link a signed-in visitor to the configured continue page ... The registration page's already-logged-in branch returned a bare sentence with nowhere to go, leaving the visitor to find their own way to their account. The invited-student branch a few lines above already built exactly the link that was missing. Extract that into continueLink() and use it for both logged-in outcomes. There is deliberately still no wp_login_url() fallback: sending someone already signed in to the login screen is the same dead end with extra steps, so with no page configured there is no link. Both messages now carry the us-register-form wrapper and enqueue the plugin stylesheet, which the invite branch emitted markup for but never loaded. Closes #131	2026-07-28 23:06:54 -03:00
thatguygriff	da985c7f71	Merge pull request 'Add the changelog entry missed by #135' (#136) from docs/changelog-upcoming-lessons-layout into main ... Reviewed-on: #136	2026-07-29 02:04:51 +00:00
thatguygriff	7c91e1eef7	Add the changelog entry missed by #135 ... The upcoming-lessons layout fix shipped without one.	2026-07-28 23:04:29 -03:00
thatguygriff	f3917d0784	Merge pull request 'Stop the upcoming-lessons row collapsing onto itself' (#135) from fix/upcoming-lessons-row-layout into main ... Reviewed-on: #135	2026-07-29 02:02:10 +00:00
thatguygriff	b508ab92f8	Stop the upcoming-lessons row collapsing onto itself ... The lesson details and the actions rendered on top of each other. Three things left the panel fragile, all fixed here. The rules were bare class selectors while the visually identical .us-slot row next to them was written as `#us-booking-app .us-slot`. That inconsistency looks accidental, and it means a theme rule on div/span/strong outranks the panel's layout and flattens it. Every booking-page rule is now scoped under #us-booking-app. The row's two columns were spans carrying display:flex, so the layout only held while that declaration won. They are divs now — the layout no longer depends on overriding the inline default. The row had no flex-wrap and its title column no min-width:0, so a long offering title could not shrink and shoved the status pill and Cancel button out of the row. The 640px media query covered only the week grid, leaving the busier lesson rows with no narrow-viewport handling at all; they now stack details above actions. BlockPreview mirrors the markup change so the editor preview matches. Closes #133	2026-07-28 22:55:11 -03:00
thatguygriff	2a661a10ff	Merge pull request 'Bump version to 1.2.4' (#129) from release/bump-1.2.4 into main ... Reviewed-on: #129	2026-07-28 20:29:23 +00:00
thatguygriff	fabbd35fa7	Merge pull request 'View a policy version's content, and make policy text readable' (#128) from feature/policy-version-viewer-and-readable-text into main ... Reviewed-on: #128	2026-07-28 20:11:06 +00:00
thatguygriffandClaude Opus 5	3a954bac57	View a policy version's content, and make policy text readable ... The Policies admin page listed versions but never showed what any of them said, so revising a policy meant retyping it blind into an empty draft box. Each version row now has a View action that renders that version's text on the page, editable in place. A draft is saved back to itself; editing a published or archived version branches a new draft and leaves the original alone, because acceptances are recorded against policy_version_id and text a student agreed to must stay exactly as they saw it. That viewer also exposed why a studio reported the acceptance box as unreadable — one squashed line, overlapping words, a horizontal scrollbar. Bodies are typed into a bare textarea, so most carry no markup, and the raw text was emitted with its blank lines intact but nothing to turn them into paragraphs. PolicyVersion::bodyHtml() now renders every body the way WordPress renders post content (kses, then wpautop) and feeds all three consumers: the booking/enrolment JSON, the signup form, and the new viewer. Bodies written with markup are unaffected. The other half was that .us-policy-body had no CSS whatsoever and inherited whatever the theme did with an unstyled block in a form. It is now a bounded reading box that scrolls vertically and breaks long tokens, so a pasted URL cannot force the page sideways and a long policy cannot push the accept checkbox out of view. RegistrationPage was also never enqueueing the plugin stylesheet, which is why the signup gate looked worst of all. Closes #126 Closes #127 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 17:05:00 -03:00