thatguygriffandClaude Opus 5
699e479805
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]>
Unsupervised Scheduler
A WordPress plugin for instructor/student lesson scheduling — private lessons and group classes — with offerings, intake questions, versioned policies, account registration, and online payments.
Version: 1.0.0 · Requires: WordPress 6.0+, PHP 8.1+ · License: GPL-2.0-or-later
Pre-release. The booking platform is being built feature-by-feature; see Implementation status below.
Overview
The plugin is organised package-by-domain under src/ (PSR-4
Unsupervised\Schedular\). Each domain owns its value objects, repositories,
REST endpoints, and admin/front-end controllers. All data access goes through
repository classes against custom {prefix}us_* tables; permissions are enforced
with WordPress capabilities, never role-name checks. There is no front-end
build step (vanilla JS/CSS in assets/).
Every feature has a spec in docs/features/ describing its data
model, REST API, classes, and tests. For contributor/architecture guidance see
CLAUDE.md.
Implementation status
| Feature | Spec | Status |
|---|---|---|
| User roles & capabilities (studio admin / instructor / student) | user-roles.md | ✅ Implemented |
| Offerings (private-lesson types & group classes) | offerings.md | ✅ Implemented |
| Availability (durations, weekly recurrence, calendar) | availability-management.md | ✅ Implemented |
| Registration questions (per-offering intake) | registration-questions.md | ✅ Implemented |
| Policies (drafting, versioning, tracked acceptance) | policies.md | ✅ Implemented |
| Account registration (invite or open self-approval, email confirmation, signup policy acceptance) | account-registration.md | ✅ Implemented |
| Lesson booking (offering → questions → policies) | lesson-booking.md | ✅ Implemented |
| Group classes (capacity-enforced enrolment) | group-classes.md | ✅ Implemented |
| Student administration (studio-admin view) | student-administration.md | ✅ Implemented |
| Payments (Stripe card charge + e-transfer/comp + receipts + HST) | payments.md | ✅ Implemented |
| Payment reporting (monthly per-instructor + HST + CSV) | payment-reporting.md | ✅ Implemented |
Shortcodes
| Shortcode | Purpose |
|---|---|
[us_booking] |
Student calendar + private-lesson registration flow |
[us_group_classes] |
Browse and enrol in group classes |
[us_student_login] |
Front-end student login |
[us_student_register] |
Account registration — invite-based, or open self-signup with email confirmation + admin approval (accepts signup policies) |
REST API
All endpoints live under /wp-json/us-scheduler/v1/ (e.g. /offerings,
/availability, /bookings, /enrollments, /policies, /questions).
Permissions are enforced via permission_callback capability checks. See each
feature doc for the routes and required capabilities.
Roles & capabilities
Three custom roles — Studio Admin (us_studio_admin), Instructor
(us_instructor), and Student (us_student) — plus a user_has_cap filter
that grants every studio-admin capability to WordPress administrators, so the site
owner runs the studio without a separate role. Full capability matrix in
user-roles.md.
Installation
- Build a distributable zip (see Development):
composer build # -> dist/unsupervised-schedular-<version>.zip - In wp-admin: Plugins → Add New → Upload Plugin, choose the zip, install, and activate.
Activation creates the us_* database tables and registers the roles. CI also
publishes an installable zip artifact on every merge to main.
Development
composer install # install dependencies
composer test # PHPUnit (run after every change)
composer lint # PHPStan (level 6)
composer cs # PHPCS (WordPress coding standards)
composer cs:fix # auto-fix coding standards
composer build # build the plugin zip into dist/
# a single test file / single test
./vendor/bin/phpunit tests/Unit/Offering/OfferingRepositoryTest.php
./vendor/bin/phpunit --filter testInsertReturnsId
Tests use Brain\Monkey and Mockery to
stub WordPress and $wpdb without a full WP install. To run the plugin in a real
WordPress without Docker, wp-now works well: npx @wp-now/cli@latest start.
CI
Gitea Actions (.gitea/workflows/ci.yml) runs on every push and pull request:
lint (PHPCS), static-analysis (PHPStan), test (PHPUnit on PHP
8.1/8.2/8.3), and no-debug (rejects debug statements in src/). On merge to
main a build job publishes the installable plugin zip as an artifact.
License
GPL-2.0-or-later.