Feature spotlight / opinion piece

Draft & Publish: How Localess Protects Content Teams from Accidental Publishes

Understand the two-state Draft/Publish model in Localess — what saving means, what publishing means, and why nothing goes live until you promote it deliberately.

Understand the two-state Draft/Publish model in Localess — what saving means, what publishing means, and why nothing goes live until you promote it deliberately.

You have done it. Or someone on your team has. You hit the wrong button, something went live, and the next few minutes were a scramble to undo what was now in production.

The accidental publish is a specific kind of dread — the one where editing feels risky and saving feels dangerous. When every save could mean public exposure, editors slow down, double-check everything, and start treating their own CMS like it might bite them.

Localess is built on a different assumption: saving should always be safe. Publishing should always be deliberate.


The Two-State Model

Every piece of content in Localess exists in one of two states: Draft or Published. These are not tags or labels — they are enforced at the API level.

When an editor saves their work, the content moves to Draft. It is stored, versioned, and safe. But it is invisible to the API unless a client explicitly requests draft content. The production API — the one your live site calls — only sees Published content by default.

When an editor is ready and clicks Publish, the content is promoted to the Published state and becomes visible in production responses.

Nothing goes live by accident. The two states are a hard separation, not a soft convention.


What Save and Publish Actually Do

This distinction matters because it changes how editors think about their work.

Save writes the current state of the content to Draft. You can save ten times, edit back and forth, add a placeholder, and save again. None of it touches what is live. The document accumulates revisions and the last saved state is available for preview — but production sees nothing.

Publish explicitly promotes the current Draft to Published. It is the moment of intent. You are not just storing content — you are saying "this is ready for the world."

This separation lets editors treat saving as a notebook rather than a broadcast. Work-in-progress belongs in Draft. Finished work gets published.


Previewing Draft Content

Saving without publishing only works if editors can see what they are building. Localess supports draft preview in two ways.

Via the API: Any Localess client can request draft content by passing a version parameter:

const content = await client.getContentBySlug("blog/my-post", {
  version: "draft",
});

Without the parameter, only Published content is returned. This means your preview routes can call the API with version: "draft" while your production routes call without it — the same API, two audiences.

Via the Visual Editor: The Visual Editor in the Localess admin panel renders a live iframe of your connected frontend. As you type in the editor, changes reflect instantly in the preview — no save required. This gives editors a real-time view of how their content looks in the actual production layout, before a single word goes live.

Both paths mean editors are never flying blind. They can see exactly what will publish before they publish it.


"Promote" Is the Right Mental Model

The word "publish" implies something irreversible — a newspaper being printed. In Localess, it is better to think of publishing as a promotion: moving content from one state to another.

And promotion is reversible. If you publish something and need to pull it back, you can update it — the new save goes to Draft, and a subsequent Publish replaces what was live. You are always in control of what the production API returns.

The underlying principle: Draft is the workspace. Published is the storefront. You decide when to open the door.


The Confidence Effect

This two-state model has a practical consequence for content teams: it removes the hesitation around saving.

When editors know that saving is safe — that no autosave or keyboard shortcut can accidentally surface unfinished work — they write more freely. They save early and often. They keep multiple drafts in progress. They do not need to maintain a separate "safe" copy outside the CMS.

The result is less cognitive overhead and faster content cycles. The editorial workflow becomes: write → preview → publish, with a clear gate between preview and live. No accidental publishes, no recovery sprints, no dread.


Where to Go Next

If you are setting up Localess for your team, the content model documentation covers how Draft and Published states interact with the API in detail:

The two-state model is one of the foundations of how Localess handles content. Once you have it working, the rest of the editorial workflow follows naturally.