Loading

The Visual Page Builder

The visual page builder produces nested flex and grid documents that render as web pages — and, from the same tree, theme parts such as headers and footers, popups, and e-mail templates.

Where to find it

Architect Panel → Layout & Pages:

  • Page Builder — the builder itself
  • Pages — the pages in your site
  • E-mail Templates — templates the builder can produce
  • Header — the site header as a theme part

One tree, four outputs

The same document structure renders to several targets. A web page and an e-mail need very different HTML — e-mail requires tables and inline CSS to survive older clients — but you build once and the renderer handles the difference.

That matters practically: your brand, spacing and colours are defined in one place rather than diverging between the website and the emails it sends.

Documents, revisions and publishing

A page is a document with revisions. You can work on a draft without affecting what visitors see, and publish when it is ready. Because revisions are kept, reverting is possible — which makes editing a live page far less nerve-racking.

Access control

Pages carry access control, so a page can be public, restricted to signed-in users, or limited to particular groups. That is enforced when the page is served rather than by hiding a link.

It coexists with the legacy pages

The older page system still dispatches, so existing pages carry on working. You do not have to migrate anything to start using the visual builder for new pages — and the friendly URL behaviour documented for the legacy system still applies.

When to use which

  • The visual builder — anything with layout: landing pages, portal home pages, styled emails, popups.
  • The legacy pages — existing pages that work, and anything already built.

Worked example

A council builds a self-service portal home page in the visual builder: a header theme part shared with every page, a grid of service tiles, and a popup for service announcements. The same header is used by the confirmation emails, so a rebrand later is one change rather than a hunt through templates.

Recommendations

  • Build the theme parts first. Header and footer shared across pages save the most work later.
  • Preview the e-mail target specifically — it is the one most likely to surprise you.
  • Publish deliberately and keep drafts for anything substantial.
  • Set access control when you create the page, not after somebody finds it.