Browse docs
Template overrides
Reskin any front-end template from your theme, WooCommerce-style, at {theme}/dsb/{path}.
Every front-end template Tempo renders can be overridden from the active theme, exactly like WooCommerce's template system: copy the file from the plugin's templates/ directory into your theme under dsb/, mirroring the path, and your copy wins.
plugin: templates/booking/screens/discover.php
theme: {your-theme}/dsb/booking/screens/discover.phpWhat's overridable
Everything under the plugin's templates/ directory. The main areas:
| Area | Plugin path | Covers |
|---|---|---|
| Booking flow | templates/booking/screens/ + partials/ | The four member booking steps |
| Checkout | templates/checkout/ | The booking panel (panel.php), sticky pay bar, confirmed panel |
| My Account | templates/account/ | Bookings, credit and students tabs, teacher PIN, photo permission, child switcher, pager |
| Register | templates/register/ | app.php, day/register/profile screens, roster and profile partials |
| First-login wizard | templates/wizard/ | The standalone wizard document, screens and partials |
| Emails | templates/emails/ | The HTML partials inside the locked transactional blocks |
| Shared | templates/partials/ | For example class-mark.php, the class thumbnail-and-dot used by every surface that names a class |
The rules of engagement
- Override as a last resort. The templates are built to look right on any theme, they read the
--dsb-*design tokens (which already carry the club's brand colours), and most visual goals are met with CSS or the branding settings instead. The matching theme ships an intentionally emptydsb/directory as a statement of intent. - Never restyle
.dsb-*internals from theme CSS. Class names inside the plugin's components are internals, not API; target your own wrappers, or override the template properly. - Keep overridden files current. An override freezes that template at the version you copied. After plugin updates, diff your overrides against the shipped versions, the same discipline WooCommerce shops know.
- Behaviour stays in the plugin. Templates receive prepared data and render it; the safety machinery (capacity, holds, permissions) runs before your template is ever loaded, and an override can't weaken it. One instructive example: the protected-profile card template receives unreadable-value cards with the warning text already in place of the value, so even an outdated override can't accidentally render a phone link for a value that failed to decrypt.
Two adjacent switches worth knowing
Not template overrides, but they live in the same conversation:
- A theme that wants to host the first-login wizard inside its own layout (rather than the default full-window takeover) can opt out with the
dsb_wizard_takes_over_pagefilter. - A theme that handles the booking-page-as-front-page case itself can opt out of Tempo's front-page handling with
dsb_bypass_front_page_template. Both are covered with their context in Hooks and integration.
Thanks. That helps us improve these guides.
Thanks for letting us know. Ask us on the Support page and we'll help directly.