Drafts and preview

What this covers

Two related workflows you use together when a page is not ready for visitors:

  • Drafts: a page exists in the editor but visitors get 404. Driven by the Published checkbox on the page form.
  • Preview: render the in-progress markdown in an overlay so you can check formatting without saving.

The two are independent: a draft does not have to be previewed, a preview does not have to be of a draft. They show up together because the same workflow uses both.

Walkthrough

Scenario 1: a page you have been writing for a while

You started a new page yesterday, you are not done, and you do not want visitors to land on a half-finished page in the meantime.

  1. Open the page in the Pages module.
  2. Untick Published at the bottom of the form.
  3. Click Save.

The page is now a draft. Visitors get 404; the editor still shows the row in the tree. Edit it as much as you like, save as often as you like. When you are done:

  1. Tick Published.
  2. Click Save.

The page is live. The URL has not changed; anyone with a link that used to 404 now sees the page.

Scenario 2: a quick formatting check while editing

You are writing markdown and want to see how a heading or a list will render before you commit.

  1. Click Preview on the page form.
  2. The overlay opens with your in-progress markdown rendered to HTML.
  3. Close the overlay (× or Escape) and keep editing.

The preview does not save the page. Closing the overlay discards the rendered HTML, not your edits. The preview applies the same markdown rules the frontend uses (Parsedown safe-mode) so what you see in the overlay is what a visitor would see in the page body.

What the preview does not show: the surrounding theme. The overlay is the body HTML on its own; if your theme adds a sidebar, header, footer, or styles the body in a particular way, none of that appears. For a full theme-rendered look, see the next scenario.

Scenario 3: a full theme-rendered preview of an unpublished page

The Preview overlay shows the body only. To see the page through your active theme (header, sidebar, footer, CSS, the lot), visit the page URL in a separate browser tab while you are logged into the editor.

A wrinkle: visitors see 404 for an unpublished page, but you might too if your editor session is in a different browser than the one you are previewing in. Two options:

  1. Preview from the same browser session. Open a new tab in the same browser, paste the page URL. Scriptor does not reveal unpublished pages to logged-in editors by default; you will see the same 404 a visitor would. The full theme-rendered preview only works after you publish.
  2. Publish, preview, unpublish. When you genuinely need the full theme-rendered look before going live, tick Published, reload the public tab, look, then untick Published and save again. The window during which visitors could see the page is whatever it takes you to refresh and look (seconds). Not ideal for high-traffic sites; fine for most.

A future Scriptor release may add a logged-in-editor bypass for unpublished pages. Until then, this is the workflow.

What to check after

  • For a draft: the public URL returns 404 in an anonymous browser session (incognito tab is the easiest way to confirm).
  • For a publish: the public URL returns 200 and the page renders the content you saved.
  • The Preview overlay shows the markdown rendered with paragraph breaks, headings, lists, and code blocks where you put them; no theme chrome.

Troubleshooting

I unticked Published and saved, but the page still shows in the public site

Browser cache. Reload the public tab with Ctrl-Shift-R / Cmd- Shift-R (hard reload). If a CDN or reverse proxy sits in front of your site, it may also have cached the previous response; flush the cache for that URL.

I ticked Published and saved, but visitors still get 404

Two checks:

  1. Is the parent page published? A draft parent hides its children even if they are individually published. Publish the parent (or move the child to a published parent) and reload.
  2. Did the slug actually save? Look at the Slug field in the page form. If it is empty for a non-home page, the page has no URL. Set a slug and save again.

The Preview overlay shows raw markdown instead of rendered HTML

The Remarkable library that drives the in-browser preview did not load. Check the browser's developer console for a script error. The most common cause is a CSP that blocks editor-assets/scripts/remarkable/; the site's Content Security Policy needs to allow script-src 'self' for the editor's assets.

The Preview shows different formatting than the live page

The browser-side Remarkable preview and the server-side Parsedown render are intentionally aligned (raw HTML disabled on both, the same language prefix for fenced code), but the two libraries are not byte-identical. For edge cases (deeply nested lists, raw HTML attempts) the server side wins. When the preview disagrees with what you see after publishing, the publish is correct.

See also