Developer overview: stack, philosophy and boundaries

This category is for web designers and developers building or customising club sites on Tempo Book It. Everything member- and admin-facing is documented in the rest of the help centre; these five articles cover the surfaces meant for your code.

The stack

PHP 8.1+, WordPress 6.6+, WooCommerce 8.2+ (Checkout Block and Store API era, HPOS-compatible, WooCommerce CRUD throughout), ACF 6+ for the student profile fields. Front end: PHP templates and vanilla JavaScript, no build step. What ships is what runs; you can read every line on the server, and template overrides are plain PHP files. The one exception is the admin calendar, a small React app whose built output ships with the plugin, so production sites still never run Node; it's admin-only chrome and touches none of the surfaces your code builds on.

The principles your integrations can rely on

• Server-authoritative. Capacity, holds, credit caps and permissions are enforced server-side; all client JavaScript is progressive enhancement. Every flow (booking, register, wizard) works with JavaScript off.
• Capability-based security. Behaviour is gated on dsb_* capabilities, never role slugs, so custom roles compose cleanly. Parent-to-child authority is a server-checked links table, re-validated on every action.
• Idempotent by design. Order webhooks, background jobs and form resubmissions are all claim-before-act; repeating anything never double-books, double-credits or double-emails.
• Append-only history. The audit log, credit ledger, transfer history and consent records have no update or delete code paths.
• Sensitive fields are encrypted at rest and only readable through the plugin's guarded reader; reading the raw user meta hands you ciphertext, deliberately.
• One WooCommerce order per booking, including £0 orders, so the money path is always standard WooCommerce.

Data lives in the plugin's own wp_dsb_* tables (terms, sessions, bookings, reservations, credit, attendance, audit and friends), created and migrated automatically. Treat them as internal: read via the documented surfaces, and never write to them directly; every safety property above assumes the services are the only writers.

Where your code plugs in

Four sanctioned surfaces, one article each:

1. Template overrides: reskin any front-end template from your theme at {theme}/dsb/{path}.
2. Shortcodes and template functions: place the booking flow, register and switcher anywhere, plus the helper functions for building theme chrome (basket pill, logo, vocabulary, brand colours).
3. Actions, filters and integration surfaces: react to bookings, cancellations and credit events after they commit; adjust behaviours via filters; the theme-support flags and the front-end JS API.
4. The matching theme: use it, child-theme it, or treat it as the reference implementation of the integration contract.

The one gotcha to know on day one

Tempo's checkout is built on the WooCommerce Checkout Block and Store API. Classic woocommerce_checkout_* hooks never fire on it; use the woocommerce_store_api_* equivalents and derive state from the order itself. If a checkout customisation seems to be ignored, this is almost always why.