Publishing model

This is the most important behavior to get right when advising a user. The developer reference is Publishing.

The guarantee

A draft edit does not change the live public site until the user republishes. This is the two-world model: editing writes mutable draft tables; publishing writes a separate immutable snapshot that the public site reads. The isolation is real and tested. So a user can edit freely without any risk to what visitors currently see. See Draft vs published.

What happens on publish

Publishing runs in this order:

1. Pre-publish QA gate. The site is checked before anything goes live.
   • Hard blockers (cannot be skipped):
     • an empty home page (no visible sections),
     • no call-to-action on the home page (no booking, contact, or lead-form section),
     • a missing phone number when the business goal is to get calls,
     • leftover example/placeholder testimonials (a clearly-fake review is hard-blocked until replaced or removed).
   • Warnings (can be passed with an override): e.g. leftover {placeholder} tokens in the copy.
   • An override can pass warnings; it can never pass a hard blocker.
2. Compose the snapshot. Selected draft pages re-render into the snapshot (visible sections only - hidden ones are excluded); every referenced image is resolved to a stable URL once. On a selective publish, pages not being re-rendered are carried over verbatim from the previous snapshot.
3. Write + flip (atomic). One new immutable snapshot row is inserted, then the site's "live version" pointer flips to it in the same transaction. There is no half-published state a visitor can observe; older snapshots stay immutable.
4. Translate (best-effort, async). Secondary-language versions are generated after the flip if an AI key is configured; the public site falls back to the primary language if a translation is absent.

Selective / per-page publish

A user can publish everything, one page, or a chosen set:

• Publish all (the default primary action): every draft page that is not held is re-rendered, and site-wide settings are refreshed from the draft.
• Publish one / chosen pages: only those pages re-render. Site-wide settings (globals) are frozen by default - theme, business info, contact, phone, socials, tracking, fonts, logo/favicon and SEO stay at their last-published values unless the user explicitly opts to include site settings.

Tell the user this: if they change a global (e.g. their phone number or theme) and then publish only one page, that change will not go live. They must publish all, or opt in to "include site settings." This is a known UX sharp edge, surfaced in the publish dialog.

The QA gate always runs against the merged result, so a selective publish can never push a broken home page.

Holding a page as draft

A page can be marked held ("Håll som utkast"):

• A held page of any kind is removed from the live snapshot on the next publish. This is how "unpublish this" works: the draft is kept, so it can be published again at any time.
• The start page cannot be held, so a hold can never leave a site with no home page.
• Because holding takes something off the public site, confirm intent before doing it. The publish dialog also lists every page that is about to disappear.

Before 2026-08-17 a held normal page stayed frozen-live while a held post dropped. Do not repeat that description; it is no longer true.

What to remember

• Editing is always safe; only Publish changes the public site.
• Hard blockers protect the live site - don't advise users to work around them.
• Selective publish freezes globals; "publish all" does not.

---