Building and publishing pages

Build a page out of sections, lay it out per device, and get it live — including why publishing a page does not publish its nav.

Build a page from sections, check it at phone and tablet width, and publish it — without pushing a half-finished draft live, and knowing which pages are already public whether you have looked at them or not.

What a page is made of

A page is an ordered list of sections — horizontal bands: a hero, a features grid, a pricing table. Navigation is pinned to the top of every page and Footer to the bottom: you can switch them off, but not drag, reorder or delete them. Some pages pin a third, central section — About pins an About section; /products, /blog and /events each pin the collection they exist to show. Pinned cards show a lock instead of a drag handle and have no trash icon.

The "Add a section" menu lists 23 types plus a Guarantee band preset; the four pinned kinds — Navigation, Footer, Event booking, Product sales — are absent from it. About is the exception — in the menu and pinned on the About page, so that page can end up with a locked About section plus one you added by hand. The second one renders, but it gets no card in the Sections list — nothing to drag, hide or delete. Removing it means deleting the section from the page's stored config, which the builder gives you no way to do.

The one thing to understand first: draft and published

Every page stores two separate copies of its layout.

The draft is what you edit. It autosaves roughly six-tenths of a second after you stop typing or dragging. There is no Save button — a "Saving…" then "Saved" indicator in the preview toolbar, beside "Live preview" and "View page", is the confirmation.
The published snapshot is what visitors see. Nothing you do in the builder touches it.

Only Publish / Republish changes this page's live snapshot. Leave a page mid-rebuild for a week and the live site is unaffected; equally, work you like is not on your site until you press the button. Publishing saves the draft first, so a forgotten save cannot publish an empty page.

One edit inside the builder escapes this rule — editing the nav or footer bar inline, which saves and republishes the shared component immediately. See "The navigation and footer trap" below.

Getting around

/admin/page-builder drops you straight onto Home — there is no index screen. The page switcher in the header holds the rest: eleven structural pages, plus your event, product and custom pages.

The left pane has three tabs: Page Theme (this page's own width, spacing, fonts, corners, shadows, accent and background — anything unset inherits the site theme; colour mode and the palette stay site-wide), Sections, and Settings for the selected section.

On the right is the Live preview — your draft, rendered with live data: your real products, posts, events and reviews. View page opens the actual public page. Click anything in the preview to edit it: text selects that element and opens Settings, anywhere else in a band selects the section.

Undo and redo are ⌘Z / ⇧⌘Z (Ctrl+Z / Ctrl+Shift+Z on Windows and Linux) — except while your cursor is in a text field, where the browser's own text undo takes over.

Which pages are already live

Home, /products, /blog and /events are always live and cannot be taken off the site; unpublished, they serve their default scaffold. On a fresh install those three collection pages are already public before anyone has opened the builder — review them early rather than discovering them later.

The other seven — About, Privacy, Impressum, Terms, Pricing, Contact, Roadmap — return a 404 until the first publish, which is what makes the URL exist.

Roadmap needs two switches, not one. Publishing the page is only half: /roadmap also stays a 404 until the Public roadmap page switch is on in /admin/roadmap, and it is off on a fresh install. That page states which half is missing and carries a Publish page link straight into the builder. A third condition to know: with both on but no milestone marked public, the page serves but has nothing on it.

Home opens with a ten-section scaffold, and its logo strip arrives switched off, because there are no logos in it yet.

Making a page that is not on that list

In the page switcher, under Custom pages, pick New custom page…, give it a title, and choose whether it is served at /<slug> (public) or /myarea/<slug> (signed-in members). It opens in the same builder and stays a draft until published. Custom pages also get a sliders icon beside the page name — page settings, holding slug, placement, Unpublish and Delete page. Structural pages have none of those.

Working with sections

Add one from the dashed Add a section menu above the list. It lands at the end of the page content, just above the footer, and the builder jumps into its Settings; drag its card to move it. Each card has three controls: the sliders icon opens its settings, the switch shows or hides it (hidden sections keep a "Hidden" badge and stay in the list), and the trash icon removes it — absent on pinned cards.

Sections that hide themselves when empty

Five data-driven types can disappear on their own: events, blog, products, testimonials and roadmap. Each has a switch labelled "Hide when there are no upcoming events" (or "…no products", "…no reviews", "…no posts"; "Hide when empty" on roadmap). It is on by default.

When it fires the whole band goes — heading, padding and all. The builder preview still shows the empty section with a note that it will be hidden live; sections deliberately do not vanish under you mid-edit.

Nav and footer links to /blog, /products and /events are stripped when those collections are empty too — but that is decided only by the switch on the collection page's own section, never by the copy of the section on the page you are editing. Switching it off on a Home blog section keeps the band and does nothing to the menu; switching it off on /blog restores the link everywhere — but only once you publish /blog. The test reads that page's published sections, so flipping the switch in the draft changes nothing on the live site and it looks like the fix did not work. (Links to /roadmap are dropped on the same principle but a different test: the roadmap feature being off, or having no public milestone.)

Two more behaviours that look like bugs:

A collection page never hides its own centrepiece: /products with no products still renders the section and its empty note. There the switch does something else — it decides whether nav and footer links to that page disappear while the collection is empty.
Leaving the switch on stores nothing. Only an explicit "off" is saved; "on" is read as the current default each time the page renders. A page published long ago can start auto-hiding a band after a software update, with nobody having touched it. If a section must always show, switch it off explicitly — that choice is stored.

FAQ, pricing and team have no such option and will render their heading with nothing under it.

Gallery and agenda have no switch either, but they do not need one — both drop out on their own when they have no items, unconditionally. Gallery vanishes in the builder preview too (an image with no URL does not count); agenda vanishes on the live page but stays visible in the preview so you can still fill it.

Per-device layout

A section's Layout panel opens with a Desktop · Tablet · Mobile control wired to the preview: switch device in either place and both follow. The preview uses the device's native width — 768 px tablet, 390 px mobile — so real breakpoints apply. You are not stuck with those three: drag either edge of the frame, or click the width pill to type a width or pick a saved preset.

Tablet and Mobile can override:

Header alignment — Left or Centered. Often the one worth setting: a heading that reads well centred on a wide screen can wrap badly on a phone.
Inset card — whether the band sits in a card or runs full width.
Section height — a preset list, not a number: Auto · fits content / Half screen · 50dvh / Two-thirds · 66dvh / Three-quarters · 75dvh / Full screen · 100dvh.
Top and bottom padding, horizontal padding, and the margins above and below.

Anything unset follows Desktop. Content width and card width stay desktop-only — they are maximum-width caps, wider than any phone or tablet viewport, so an override would bind against nothing; horizontal padding is what fixes a cramped phone layout.

Card-based sections also carry Mobile layout and Desktop layout, outside the device tabs. The group is Card design on testimonials and Card gallery on products and pricing; the Gallery section has no such group. Mobile offers Stack (scroll) or Carousel (swipe) — no grid. Desktop offers Grid and Carousel (swipe), plus Masonry on testimonials and Split — billing panel beside the plans on pricing.

Publishing

The header shows where the page stands: Not live yet, an amber Unpublished changes chip, or Published.

The chip opens "Changes since last publish", one row per change, tagged added, removed, moved or edited. Theme and translation changes also read "edited" — only the dot colour separates them. Hovering a row reveals its Revert; the popover header has Reset all, which sets the draft back to the live page. Both are undoable while the builder stays open. "Only cosmetic differences detected" means the page counts as changed but nothing meaningful differs: publish or ignore, both are harmless.

Every publish is recorded in a revision history capped at 20 per page, but there is no restore button in the builder — do not treat it as a safety net you can reach for yourself.

There is no unpublish and no delete for the eleven structural pages (custom pages have both). Once /about is published it stays served; to make it effectively gone, switch its sections off and republish, leaving navigation plus footer.

This is where people lose an afternoon. A page's nav and footer sections are pointers; the bar itself is a shared component, and the two ways to edit it behave in opposite ways:

Inside the page builder, selecting the nav or footer section gives you an inline editor with an amber warning: "Live edit — changes this navigation bar on EVERY page that uses it, immediately." That is literal: those edits save and republish the shared component about seven-tenths of a second after you stop. There is no draft, and publishing or reverting the page will not undo them. The inline editor also loads the component's published version, so unpublished work waiting in its own builder gets overwritten.
In the component's own builder at /admin/site-components/<id> (the "Edit nav" / "Edit footer" button), you get the normal draft-and-publish model. Changes stay invisible until you publish there — republishing every page in your site will not help.

And if a page's Source is set to "A specific navigation bar…" (or "…footer…") pointing at a component that was never published, that page renders with no navigation bar or no footer at all. There is no fallback to the site default, and the picker lists unpublished components, marked "· draft". If a page suddenly loses its header, check this first.

Limits worth knowing before you design around them

Collection pages show at most 24 items. /blog has a pager; /products and /events do not, so a shop with more than 24 published products cannot show the rest there.
"Custom HTML" is not raw HTML. The server filters it on save: <script>, <style> and <iframe> go, inline style is not allowed, class is the only global attribute that survives. The symptom: a pasted third-party embed looks fine while you work and is gone next time you load the page.
Use the Embed section for pasted code. It runs in a sandboxed frame. A switch labelled "Allow same-origin access" is on by default so embeds needing cookies or storage work; turn it off for code you do not fully trust. Both fields cap at 50,000 characters.
The link picker only offers six pages. Beside a URL field, the Section button links to a section anchor — but it lists Home, About, Privacy, Impressum, Pricing and Contact only. Terms, Roadmap and the three collection pages never appear, with nothing on screen to explain why; type those by hand (/terms#your-section). Some types also show their internal name there, so you may see statsband where the builder says "Stats band".

Theme changes are drafts too

Applying a site theme template in the Theme Studio offers a ticked option, "Also clear page, section & nav/footer style overrides". It rewrites drafts only — the theme's own draft, the eleven structural pages' drafts, and the default nav and footer drafts.

So a restyle needs two publishes, and forgetting either leaves the public site unchanged:

Publish (or Republish) in the Theme Studio. The public site reads the theme's published copy, never the draft — this step is easy to miss, because the studio preview already shows the new look.
A Republish on each page whose overrides were cleared. There is no bulk republish, so you have a list of pages to work through one by one.

Custom, event and product pages are not included in the reset: their own style overrides survive it and will keep shadowing the new template until you clear them by hand.

Close any page-builder tab before running it — an open builder holding unsaved edits can autosave the old styling back over the reset.

Everything here requires an admin account, and there is no per-page permission — any admin can edit and publish any page.