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 normal page stays frozen-live at its last-published version.
• A held post/news article is removed from the live snapshot entirely — this is how "unpublish an article" works, and it takes effect immediately, so confirm intent before doing it.

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.