Basker Docs

Customising Basker

How custom themes shape your site — what they control, what site editors configure, and where the boundary sits

A custom theme is what makes a Basker site visually and behaviourally yours. Where Basker provides the content model and the platform underneath, the theme decides how that content becomes a live site — the layout, look, navigation, and rendering of every block on every page.

This page explains the boundary between what a theme controls and what site editors configure, and what to expect when working with a theme developer.

What a custom theme controls

A theme controls four things:

  • Templates — the structural arrangement of each kind of page. Different templates can render the same content very differently.
  • Blocks — the building units editors use to compose page content. Different themes ship with different blocks, and the same content can look quite different depending on which blocks are used.
  • Layouts — the outer shells (header, footer, navigation, global elements) that wrap pages.
  • Theme settings — the global controls editors configure. The theme decides which settings exist and what they affect.

Themes can also expose per-page settings that override global theme settings on a single page, and they can integrate with installed apps to render booking buttons, account flows, and other widgets.

For more on each, see Themes.

What site editors configure

Site editors don't write theme code, but they configure plenty:

  • The values of theme settings (the brand colours, the chosen fonts, the menu structure).
  • The template each page uses, where the theme exposes a choice.
  • The blocks on each page, drawn from the theme's block palette.
  • Per-page overrides of theme settings.

The boundary is roughly: the theme defines what's possible; editors decide what to do within that. If you need something a theme doesn't expose, that's a theme-level change rather than something the editor can do.

Working with a theme developer

Most Basker organisations have a theme developer — sometimes in-house, more often a partner agency. The developer:

  • Builds the theme and ships its initial version.
  • Adds new blocks, templates, and settings as the site evolves.
  • Maintains the theme as Basker releases new platform features.

When you need a change that the existing theme doesn't support — a new block, a different layout, a new theme setting, a new per-page override — speak to your theme developer. They make the change in the theme code; once they push the update, you'll see a new theme deployment and the new capability appears in the editor.

When something looks wrong on the live site

If the live site doesn't look the way you expect, the issue is most likely in one of three places:

  1. Theme settings — a global setting that's now conflicting with content. Check Theme settings.
  2. Per-page overrides — a page has overridden a setting and is now out of step with the rest of the site. Check the page's per-page theme settings.
  3. The theme itself — a deployment changed how something renders. Check Theme logs and Theme deployments. If the theme is the cause, share the relevant log entries with your theme developer.

Beyond what site editors do

For developer-level information about building or extending a theme — block authoring, template structure, theme APIs, layout composition — see basker.dev.

Where to go next

On this page