Widgets, Themes and Styling
A page is a tree of nodes, and what each node may contain is defined by a widget registry. Widgets are the building blocks — text, images, grids, buttons, data blocks and the rest.
Where to find it
Architect Panel → Layout & Pages:
- Page Builder — where widgets are placed and styled
- Header — the header theme part
- E-mail Designs — design assets used by templates
Architect Panel → Styling:
- Logo — the site-wide styling the builder inherits
The registry decides what fits where
Not every widget may sit inside every other. The registry validates the tree, so a layout that could not render is rejected as you build rather than producing something broken when published.
Theme parts
A header or footer built once and shared is a theme part. Change it and every page using it changes.
This is the single biggest time-saver in the builder, and the thing most worth setting up before you build many pages — retrofitting a shared header across twenty individually-built pages is a tedious afternoon.
Popups
Popups are documents like any other, so they use the same widgets and styling. Use them sparingly: a popup on every visit is the fastest way to train people to dismiss without reading.
Styling and the asset cache
Styles are compiled and cached as assets rather than being emitted inline on every request. That keeps pages fast, and it means a style change is picked up when the asset recompiles.
If a style change does not appear, that cache is the first thing to check — this is the commonest confusion when two people are editing.
The e-mail target is different
E-mail rendering produces table-based layout with inline CSS, because that is what mail clients reliably support. Flex and grid do not survive in many of them.
The builder handles the translation, but the result is not pixel-identical to the web version. Always preview the e-mail target, and send yourself a test to a real client before using it in anger.
Worked example
A service builds one header theme part with the logo and main navigation, and one footer with contact details and the accessibility statement. Eleven portal pages use both. When the accessibility statement is updated, one edit updates all eleven — and the confirmation emails, which use the same footer.
Recommendations
- Theme parts before pages.
- Test emails in a real client, not only in the preview.
- Keep the widget tree shallow. Deeply nested layouts are hard to edit and slow to render.
- Check the style cache when a change does not show.