Rust works by default#

fn main() {
    let traveler = "Mira";
    println!("Welcome to the lantern gate, {traveler}!");
}

Web lessons stay local#

Web lessons stay in a dependency-free, opaque-origin preview:

<button id="gate">Reveal the gate</button>

button { padding: 0.75rem 1rem; color: rebeccapurple; }

document.querySelector("#gate").onclick = (event) => { event.currentTarget.textContent = "The gate opens"; };

Configured languages fail closed#

The repository example intentionally does not configure an external runner. This Python fence therefore stays static even though it opts into runnable; a site owner must explicitly allow Python and deploy an isolated gateway first.

name = input().strip() or "traveler"
print(f"Welcome, {name}!")

That fail-closed behavior lets an author keep portable lesson source without silently turning the blog or Admin server into a code-execution service.

Join the discussion on the original article.

Production notes

Production

Season 1, episode 1

Status

editing

Credits

Story and direction by the Lantern Gate team; animation and edit by the episode crew

Zhalendor — The Gate of Embers on YouTube

Seven travelers arrive at a sealed mountain gate as an old ward begins to fail. This companion page keeps the episode, production context, and accessible transcript in creator-owned Markdown.

Chapters#

1. 00:00 The road beneath the mountain
2. 00:42 A warning in the ash
3. 01:36 The gate answers
4. 02:28 Beyond the threshold

Production log#

• Story beat and continuity review
• Shot list and animatic
• Voice and sound pass
• Final color and accessibility review
• Release copy and scheduled publication

Shot notes#

The opening uses a wide silhouette before moving to individual reaction shots. The gate remains the visual anchor, while ember light distinguishes forbidden magic from ordinary torchlight.

Transcript#

Narrator: The mountain had no door on any map, but every road bent toward it.

Mara: Nobody touches the seal until we know who lit those runes.

Narrator: From the other side came a sound like a great chain falling through the dark.

Comments are closed. Read the discussion on the original article.

Contributions

• Example AuthorAuthor, Conceptualization, Writing – original draft
• Example EditorEditor, Writing – review & editing

Abstract#

This working example shows how a portable Markdown article can publish research-oriented metadata and credit more than one person without putting identity data in front matter. The post selects the research profile, while an adjacent JSON sidecar supplies ordered authorship and controlled contributor roles.

Follow the source files#

Three files make the demonstration work:

1. openblog.json registers the reusable example-author and example-editor identities.
2. This Markdown file contains the article, license, Abstract, and References sections.
3. 2026-02-16-research-and-contributor-credits.credits.json connects those identities to this work with Crossref and CRediT roles.

The identities are deliberately synthetic and their ORCID fields are empty. Replace them with real people and add only identifiers those people actually control. Manually entered ORCID iDs remain visibly labeled as unauthenticated.

What to inspect#

Open this post in Admin Studio to see the same data from an author's point of view:

• Settings → Credit contributors and roles preserves credit order and exposes controlled roles.
• Evidence reports the research structure and bounded reference links below.
• Site preview renders the production byline, work details, and Contributions panel.
• Social uses the same publishing-engine metadata as the generated page.

After openblog build, inspect this page, rss.xml, feed.json, and the page's JSON-LD. Only the Crossref author appears in author-only metadata; both people and all their roles remain visible in the Contributions panel.

References#

1. CRediT role taxonomy
2. Crossref contributor guidance

Join the discussion on the original article.

1. publish the article on your open.blog site;
2. make sure its final URL is live;
3. create drafts on the other platforms;
4. set each copy's canonical URL back to the open.blog article;
5. review the formatting, then publish the copies.

The canonical URL tells search engines which copy is the original. Deploying that URL first also prevents every destination from pointing at a page that does not exist yet.

Start with the feeds#

Every open.blog site can expose full-content RSS at /rss.xml and JSON Feed at /feed.json. Enable feeds.rss, feeds.json, and feeds.fullContent in openblog.json. A feed automation service can then watch either URL and create a draft when a new post appears.

Before connecting one, confirm that its destination action can:

• create a draft instead of publishing immediately;
• set the original article URL as canonical;
• update the same remote article rather than create a duplicate.

If it cannot do those things, use the destination's API or import flow instead.

Pick the right setup for each platform#

• Hashnode: its official GitHub Action can publish repository Markdown and supports drafts, dry runs, and canonical URLs. API publishing now requires a Hashnode Pro publication.
• DEV Community: its API accepts Markdown, supports drafts, and has a canonical_url field. Save the returned article ID so future runs update the same post.
• Medium: use Import a story after the original is live. Medium does not accept new API integrations; its importer adds the original URL as canonical automatically.
• Ghost: its Admin API supports drafts and custom canonical URLs. Keep the Admin API key on a trusted server or in CI, never in browser JavaScript.
• WordPress: its REST API supports drafts, but core WordPress has no portable field for an external canonical. Only syndicate automatically if your particular SEO plugin or site configuration exposes and verifies one.

The repository's complete cross-posting guide walks through credentials, API requests, CI safety, updating instead of duplicating, and the official documentation for each platform. It also includes a complete GitHub Actions template that waits for deployment, verifies the canonical URL, and creates or updates a DEV draft from the deployed JSON Feed.

Keep publishing credentials private#

Store tokens as encrypted CI secrets. Never put one in Markdown front matter, the generated site, or code that runs in a reader's browser. Start every integration in draft mode and test it with one disposable article.

Once that works, automation can handle the repetitive copying while you keep the final review. Your Markdown stays authoritative, every public copy points home, and a failure on one community does not prevent the original article from reaching your readers.

Join the discussion on the original article.

Prep

10 min

Cook

15 min

Total

25 min

Serves

4

Cuisine

Italian

Course

Dinner

open.blog is not only for code. Add profile: recipe to a post's front matter, put the ingredients in a list under an ## Ingredients heading and the steps in a list under a ## Steps heading, and the post becomes a recipe:

• A summary card with the times and servings, and a "Jump to recipe" link.
• Buttons that scale the amount at the start of each ingredient to more or fewer servings.
• Checkboxes to tick off ingredients and steps (remembered on the reader's device).
• Timers: any time in a step, like "10 minutes", starts a countdown when tapped.
• Cook mode keeps the screen awake, and "Print recipe" prints just the recipe.
• Search engines get schema.org recipe data; with a photo, the post can appear as a recipe result.

Start a new one with openblog new "Lemon garlic pasta" --recipe. This post is a working example; try the buttons above.

Notes#

The front matter for this post:

profile: recipe
servings: 4
prep: 10 min
cook: 15 min
cuisine: Italian
course: Dinner

Times can be written as 15 min, 1 hr 30 min, or 1:30; something like overnight is shown as written. Use makes: 12 cookies to say what a recipe makes, alongside servings if readers should be able to scale it.

Join the discussion on the original article.

openblog build

writes a complete static site to dist/: pages, RSS and JSON feeds, a sitemap, a search index, and the assets. Upload that folder to any static host, or run openblog serve to host it yourself.

Drafts#

draft: true keeps a post out of every build and feed. openblog serve --drafts previews drafts locally. The admin editor shows drafts with their own badge.

Scheduling#

Give a post a date in the future and it is scheduled:

date: 2026-12-25T09:00:00Z

Scheduled posts stay out of the pages, feeds, sitemap, and search index. When the time comes, openblog serve rebuilds by itself. On a static host, any openblog build after that time publishes it, so a daily build (a cron job or a scheduled workflow) is enough.

The admin editor#

For editing from a browser, including on the server that hosts the blog:

openblog user add you
openblog serve --admin

Then open /admin. It writes the same Markdown files, so you can mix both ways of working. docs/admin.md covers running it safely on the public internet.

Feeds and cross-posting#

/rss.xml carries the full post HTML and /feed.json is JSON Feed 1.1. Most newsletter and cross-posting tools accept either. If you republish a post elsewhere, set the copy's canonical URL to its address here; for a post that was first published elsewhere, set canonical: in its front matter.

Continue with Safely cross-posting your blog for a review-first workflow covering Hashnode, DEV, Medium, Ghost, and WordPress.

That is the whole workflow. Delete this series when your own posts arrive, or keep it as a reference.

Join the discussion on the original article.

List them in the front matter. Each tag gets a page at /tags/<slug>/, and /tags/ lists them all with counts. Tags are matched case-insensitively, so Rust and rust are one tag.

tags:
  - guide
  - rust

Series#

A series is a file in content/series/. This one is content/series/getting-started.md:

---
name: Getting started
description: Three short parts ...
theme: demo        # every post in the series renders with this theme
order: 1           # position on the /series/ page
---
Optional Markdown shown at the top of the series page.

A post joins a series with series: getting-started. Parts are ordered by seriesOrder, or by date when it is missing. The post page then shows "Part 2 of 3", previous and next links, and a list of all parts. If you reference a series that has no file, open.blog creates it from the slug and warns you.

Themes per series#

Set theme: on a series and all of its posts switch theme, including this one. A single post can override with theme: of its own. The themes available are the folders under themes/; run openblog themes to list them. See docs/themes.md for how a theme is built from design tokens, and docs/theme-components.md for the heading effect this series is using.

Next: Publishing and scheduling.

Join the discussion on the original article.

Front matter#

---
title: Writing a post
subtitle: Optional. A one-line subheading shown under the title.
date: 2026-01-12           # or a full time: 2026-01-12T09:30:00Z
tags: [guide, markdown]    # inline lists work too
description: Optional. Used in feeds and search results.
cover: /images/cover.png   # optional; the first image in the body is the fallback
draft: false
---

Dates without a time are midnight UTC. A post dated in the future is scheduled and stays hidden until that moment (part three has the details).

Markdown that works#

CommonMark plus the GitHub extensions: tables, task lists, footnotes, and strikethrough. Headings get ids and anchor links, so #markdown-that-works links here.

• Write the post
• Publish it

Callouts draw attention to a note, a tip, or a warning:

Regular code blocks are read-only: they keep the original syntax colouring, line numbers, highlighted lines, and copy button. This one demonstrates that decorative presentation:

pub fn greeting(name: &str) -> String {
    format!("Hello, {name}!")
}

Add runnable only when readers should be able to edit and execute a self-contained Rust example. A runnable block deliberately becomes an editor with controls and inline output:

fn main() {
    let name = "reader";
    println!("Hello, {name}!");
}

The two fences begin with ```rust title="..." and ```rust runnable playgroundLink=false title="..." respectively. Leave out playgroundLink=false when you want the external Playground fallback. Add showLineNumbers=10 to a read-only block to count from 10, or showLineNumbers=false to drop the numbers. Running the live example sends its edited source to the official Rust Playground. To change highlighting and numbering for the whole blog, see code in openblog.json.

Check your understanding#

Images#

Put files in static/; they are copied to the site root. static/images/photo.png is /images/photo.png:

![A short description](/images/photo.png)

The admin editor uploads and inserts images for you, including by drag and drop or paste.

Next: Tags and series.

Join the discussion on the original article.

Three ways to write#

1. A text editor. Open the file, change it, save. openblog serve rebuilds the site while it runs.
2. The admin editor. Run openblog user add you, then openblog serve --admin and open /admin. It edits these same files, with a live preview.
3. The command line. openblog new "A post title" creates a file with today's date.

What a post needs#

The block between the --- lines at the top is the front matter. Only date is required, plus a title unless the body starts with a # heading. tags, description, series, cover, draft, and theme are optional; the Getting started series walks through them.

Make it yours#

• Set the title, description, author, and address in openblog.json.
• Replace this post, or keep it as a reminder of how the pieces fit.
• Pick a theme in openblog.json, or write one in themes/.

Join the discussion on the original article.