11 Commits

Include renames

Author	SHA1	Message	Date
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
thatguygriffandClaude Opus 5	9344ab7193	Show price cadence and require a pay agreement at booking ... Every price a student meets on the front end now carries the cadence it is billed on — at booking, up front, weekly, monthly — so a bare amount can no longer read as a one-off when it is a recurring charge. Both registration forms then restate the price and require a second, separate tick agreeing to pay it, distinct from the policy acceptances above it. The agreed figure includes the studio HST so it matches Payment::total(), the amount actually billed; the rate reaches the browser as a new localized `taxRate`. A weekly reservation is charged per lesson for every week it claims, and a week another student takes first is simply not claimed, so its total is quoted as a ceiling ("up to 12 lessons") rather than a promise. Free offerings have nothing to agree to and show no price block at all. The formatting and the agreement live in one shared helper (`window.usPricing`, registered as `us-scheduler-pricing`) so a price reads the same in the booking form, the class catalogue and the editor preview. Closes #124 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 14:43:38 -03:00
thatguygriffandClaude Opus 5	264d9cba01	Add per-embed lesson-type and section options to the booking block ... Three sidebar options on the Lesson Booking block, all mirrored as shortcode attributes and carried to the front end as data attributes on #us-booking-app (or as omitted containers): - Lesson type (lessonTypeId / lesson_type) pins the calendar to a single private-lesson type: only the times bookable as it are listed, and it is the only type bookable there, auto-selected on the registration form. A pinned type that is no longer offered says so instead of showing an empty calendar. - Show the lesson-type filter (showTypeFilter / show_filter) drops the "Show Only" control for studios that do not want it. - Sections (displayMode / show) embeds one half of the page — the booking calendar or the student's upcoming lessons — so the two can live on different pages. The script skips the work belonging to a missing half: no availability or catalog request for an upcoming-only embed, no bookings request for a booking-only one. An unrecognised value renders the whole page. The editor preview follows the same setting. Also fixes the expanded filter's first lesson type sharing a line with the "Lesson type" heading — the choices now sit in their own row beneath it. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 13:16:18 -03:00
thatguygriffandClaude Opus 5	9d11cc3b01	Collapse the lesson-type filter behind a Show Only button ... The filter took a row of the booking calendar before a student had asked for it. The view toggle and a new "Show Only" button now share one control row, and the lesson-type list is revealed between that row and the calendar. The list stays open across re-renders once revealed, and collapsing it leaves the filter applied — the button keeps its active styling and carries the number of ticked types, so a collapsed filter is never invisible. Closes #119 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 12:47:24 -03:00
thatguygriffandClaude Opus 5	edcacae816	Filter booking calendar slots by available lesson type ... Not every open time can be booked as every private-lesson type: a slot tied to an offering takes that offering only, and a generic slot only takes types whose length fits. Students had no way to see that before clicking a time. The booking calendar now carries a lesson-type filter — a checkbox per active private-lesson type, fetched once from GET /offerings?kind=private_lesson. Ticking types narrows the calendar to the times bookable as one of them and re-anchors the week view on the earliest match. The registration form's Lesson type picker is narrowed the same way, and a lone remaining type is pre-selected with its intake questions loaded. Bookability is decided by offeringFitsSlot(), the client-side mirror of the rule POST /bookings enforces; the filter is a browsing aid and the server still validates every booking. No ticks means no filter, and the whole control is hidden when the studio offers fewer than two private-lesson types. Closes #117 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 12:27:37 -03:00
thatguygriffandClaude Opus 4.8	32619a1b75	Show booked lesson info on upcoming lists and add admin booking detail ... Front end: the student "upcoming lessons" panel now shows each booked offering's name and length next to the time, and renders only the soonest five lessons with a "Show all" reveal. GET /bookings returns offering_title and duration_minutes so the list needs no extra request. Admin: the Scheduler and My Lessons week/list views now show the booked offering, and each lesson links to a detail view showing 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. composer test / composer lint / composer cs all pass. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-24 11:07:06 -03:00
thatguygriffandClaude Fable 5	ab90dae638	Let students cancel their own lessons from the booking page ... Adds POST /bookings/{id}/cancel (owner-only, idempotent): marks the lesson cancelled, releases the availability slot for rebooking, and voids a still-pending payment so it leaves the admin confirmation queue. Paid payments are untouched — refunds stay a manual admin decision. The instructor PATCH /bookings/{id}/status path now does the same slot release and payment voiding on cancellation (previously cancelled lessons left their slot permanently booked), and reinstating a cancelled lesson re-claims the slot, rejecting with 409 if the freed time was rebooked. The "Your upcoming lessons" panel gets a Cancel button with a confirm prompt; on success both the lesson list and the slot calendar refresh. Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 17:17:30 -03:00
thatguygriffandClaude Fable 5	5888032ed7	Skip payment step for unpriced bookings, confirm them immediately, show students their lessons ... Booking a slot with no priced offering created the lesson but no payment, yet the front end still called POST /payments/intent, which 400ed with "Could not start payment for this registration" — the student saw an error while the backend held a claimed slot and a lesson stuck at pending. - POST /bookings and POST /enrollments now return a `payment` summary ({id, method, status}) or null when nothing is owed; the JS only runs the payment step when a payment exists. - Bookings with nothing owed are confirmed at creation — there is no payment step that would ever confirm them later. - The booking page now shows the student's upcoming lessons (GET /bookings, now scoped to upcoming non-cancelled lessons with slot start/end times) with a pending-payment/confirmed status badge. Fixes #53 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 17:02:38 -03:00
thatguygriffandClaude Fable 5	b7d5e3039e	Split availability windows into bookable lesson-length slots with weekly calendar views ... Availability windows were stored and served as a single bookable row, so a 9:00 AM-4:00 PM window showed to students as one giant slot and booking it consumed the whole day; past and multi-day windows also leaked into the booking page as nonsense entries. - Split windows into consecutive lesson-length slots on save (REST and admin form); each chunk is independently bookable and weekly recurrence creates a series per chunk so "reserve this time weekly" holds the same hour each week - Reject windows spanning multiple days or shorter than the lesson length (400 invalid_window) - Never return slots whose start has passed from GET /availability - Migrate pre-split rows: Plugin::boot re-runs the Installer on version change and AvailabilityRepository::splitOversizedWindows() rewrites unbooked same-day oversized windows in place - Display all times in 12-hour AM/PM form (booking page, wp-admin lists, editor previews) - Add a List | Week view toggle to the student booking page and the instructor availability page, with previous/next-week navigation honouring the site's start_of_week option (new WeekCalendar helper) Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 16:00:47 -03:00
thatguygriffandClaude Fable 5	fc70cde9d5	Add Gutenberg dynamic-block wrappers for the front-end shortcodes ... Wrap the four shortcodes (us_booking, us_student_login, us_student_register, us_group_classes) in dynamic blocks so pages can be previewed and styled in the block editor. Front-end rendering delegates to the same page objects the shortcodes use; in the editor's block-renderer REST preview a static, script-free BlockPreview is rendered instead (no live REST calls, redirects, or Stripe.js). The editor script (vanilla JS, no build step) registers each block with wp.serverSideRender previews and shortcode transforms; frontend.css is attached as the block style so previews pick up theme styling. Resolves #44 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-06-12 12:03:27 -03:00
thatguygriffandClaude Sonnet 4.6	0fbafc9d18	Initial plugin scaffold: lesson scheduling WordPress plugin ... - Custom DB tables for availability slots and lesson bookings - Instructor (wp-admin) and student (front-end) roles with custom capabilities - REST API under us-scheduler/v1 for availability CRUD and booking - [us_booking] and [us_student_login] shortcodes for student front end - PHPUnit + Brain\Monkey unit test suite (29 tests) - Gitea Actions CI: lint, PHPStan, tests on PHP 8.1/8.2/8.3, no-debug check - Feature docs under docs/features/ Co-Authored-By: Claude Sonnet 4.6 <[email protected]>	2026-03-30 12:44:46 -03:00