Classes / setup

Try the whole flow.

1. Choose a sample class from any schedule view. The first calendar opens details in a native modal; the second uses direct booking links.
2. Enter a name and email. A place is held for 15 minutes while you continue.
3. Choose Create demo reservation. You receive a DEMO check-in token and a private booking link. No payment is taken.
4. Open the owner tools. On your computer’s local PHP preview, choose your password once, then see the roster and confirmation email preview.
5. Add or edit a class. All five schedules read the same file, so every view updates on the next request.

The text file is the schedule.

assets/data/classes.json contains dates, local times, class titles, descriptions, venue, price and capacity. It is ordinary formatted text. class_types supplies editable defaults for the owner form.

Each session has a permanent ID. Classes are sorted by date and start time, regardless of their order in the file. The timezone is America/Los_Angeles, so daylight-saving changes are handled by PHP.

The editor uses revision checks and saves the previous schedule in private history. Sessions are cancelled rather than deleted. Once reservations exist, date, price and venue changes are blocked to keep the booking consistent.

A booking, without an account.

The student’s private link opens their reservation. A separate shorter token is used for check-in. A name, email and one place are attached to one session; the private roster stays behind owner sign-in.

Confirmation, token and email queue are recorded together. Duplicate submits return the same reservation. Expired unpaid holds stop consuming places. An uncertain payment capture stays held for reconciliation instead of silently freeing a potentially paid seat.

The owner can inspect the roster, check people in, download CSV and queue a reminder. Messages remain in an outbox until an email transport is configured; the demo never sends them.

What I need from you.

1. Real classes: names, dates/times, duration, exact venues, arrival instructions, class descriptions, prices and capacity.
2. Your booking rules: booking cutoff, cancellations, refunds, no-shows, transfers, and whether you want waitlists or multi-class credits. This version reserves one place per booking.
3. PayPal: a sandbox app and test buyer, then the correct business account’s live app. Configure client ID, secret, merchant ID and webhook ID privately on the server. Do not put secrets in the public schedule or send them in a prompt.
4. Hosting: the final HTTPS URL, PHP with cURL/TLS, and a writable private directory outside the public web root. The local PHP installation currently needs cURL enabled before it can call PayPal.
5. Email: your sender address/domain and a delivery choice: hosting mail, SMTP or a transactional email service. The hosting-mail adapter and outbox exist; another provider can replace that small adapter. A real delivery test is still required.
6. Owner access: choose your private password. If text messages are wanted later, choose an SMS provider, sender and consent wording; no SMS integration is activated here.

Where PayPal connects.

The server creates an Orders v2 order for the class price, sends the buyer to PayPal, then captures and verifies payment. A verified completed capture must match the reservation, amount, currency and merchant before a token is issued.

The return page cannot mark a class paid. The signed-webhook endpoint provides recovery if the browser closes after capture. Payment-change events suspend automatic admission for owner review. Automated refunds and a full dispute workflow remain a later step.

Sandbox and live modes use separate stores. Live checkout also requires an explicit enable switch, a real schedule replacing the sample data, and a configured email sender. Connecting keys alone does not switch the demo live.

Email, Formspree and receipts.

The existing contact form stays as it is. Formspree supports confirmation-email workflows, but a form submission is not evidence of a paid reservation. Booking confirmations should originate from the verified reservation backend.

PayPal’s payment receipt and your class confirmation serve different purposes. The class message needs the date, venue and check-in token. This implementation queues that message reliably; sending and delivery are reported separately.

Flat files now. A database if needed.

This is a reasonable starting point for a small schedule on one PHP server with local disk. The critical reservation update uses one lock and one atomic file replacement. No MySQL service is required.

SQLite would be the first database upgrade I would consider: still one file, but transactions and indexes make larger rosters and reporting simpler. MySQL becomes useful with multiple servers, larger traffic or hosting that requires it. Those changes can sit behind the existing storage functions without redesigning the pages.

Keep the two offerings clear.

Classes can mean the dated in-person schedule. Online training can become the separate self-paced curriculum. If you later offer live video classes, they can join the dated schedule with a delivery label and private joining instructions.

Detailed file map, configuration names, integration references, limitations and activation checklist are in the document.