Publishing

What the button does

“Publish to live” is one button, and it runs a sequence. Understanding the sequence is understanding the safety model of the whole system.

One — the status changes. The article, book or deck is marked published in its own file. Nothing is live yet; a file changed on disk.

Two — the site is built. The front end is compiled with the new content in it. A build failure stops everything here, on my machine, with a real error message.

Three — the guards run. A set of checks that can each fail the release. They are the subject of the next section.

Four — it deploys. The built bundle goes to the hosting platform and the CDN starts serving it.

Five — it is verified from outside. Each draft is fetched from the live site and must return “not found”. This is the check that matters most, because it is the only one performed against reality rather than against intent.

The guards

Four checks stand between a build and a deploy. Each one exists because of a specific way a publication can embarrass itself.

No drafts may reach the public site. This is the big one, and it checks three things rather than one: that no page bypasses the single content gate, that each gate still filters drafts, and that no draft slug or title appears anywhere in the built output. Structure, source and output.

That guard has an instructive history. It originally scanned only the built output for draft slugs. When the site moved to rendering pages at request time, the build stopped emitting page HTML — and the scan quietly had almost nothing left to look at. It could no longer fail. A guard that cannot fail is worse than no guard, because it reports success. It was rebuilt to check the structure and the source as well, so it fails for the right reasons even when there is nothing in the output to scan.

No control characters in content. Invisible characters find their way in from copied text and produce rendering bugs that are almost impossible to diagnose by looking.

No mathematical notation left unrendered. Half-converted notation renders as literal backslashes in the middle of a sentence.

Every published book and deck carries a valid social card. Checked against the same rules the editor applies on upload, so a card cannot silently degrade between being uploaded and being published.

The draft rule, restated

It appears in enough places to be worth collecting:

• New content is created as a draft, always, with no way to skip it.
• Anything not exactly “published” is a draft, so typos fail closed.
• Content is read through one gate per collection, which applies the rule.
• A guard verifies the gates still exist and still filter.
• A guard scans the built output for anything draft-shaped.
• After every deploy, each draft is fetched from the live site and must 404.

That is six layers for one rule, which sounds excessive until you consider what the failure looks like: unfinished writing, published under my name, discovered by a reader.

Building without deploying

The Build button does steps two and three and then stops.

I use it constantly. It is the difference between finding out that an image reference is broken while I am working, and finding out from a deploy log after the site is already live with it.