open.blog keeps authored source readable before it adds any execution. Try changing this greeting;\nwithout JavaScript, it is still an ordinary code block.
\nfn main() {\n let traveler = "Mira";\n println!("Welcome to the lantern gate, {traveler}!");\n}\nRun and edit this example on the original article.
Web lessons stay in a dependency-free, opaque-origin preview:
\nHTML
<button id="gate">Reveal the gate</button>\nCSS
button { padding: 0.75rem 1rem; color: rebeccapurple; }\nJavaScript
document.querySelector("#gate").onclick = (event) => { event.currentTarget.textContent = "The gate opens"; };\nOpen the live preview on the original article.
The repository example intentionally does not configure an external runner. This Python fence\ntherefore stays static even though it opts into runnable; a site owner must explicitly allow\nPython and deploy an isolated gateway first.
name = input().strip() or \"traveler\"\nprint(f\"Welcome, {name}!\")\nThat fail-closed behavior lets an author keep portable lesson source without silently turning the\nblog or Admin server into a code-execution service.
\nJoin the discussion on the original article.
\n", "content_text": "Executable code lessons, with a safe fallback\nCanonical: https://open-blog-jtc.netlify.app/posts/executable-code-lessons/\nopen.blog keeps authored source readable before it adds any execution. Try changing this greeting;\nwithout JavaScript, it is still an ordinary code block.\nRust works by default\nRust · edit and run\nfn main() {\nlet traveler = \"Mira\";\nprintln!(\"Welcome to the lantern gate, {traveler}!\");\n}\nOpen in Rust Playground (https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=fn+main%28%29+%7B%0A++++let+traveler+%3D+%22Mira%22%3B%0A++++println%21%28%22Welcome+to+the+lantern+gate%2C+%7Btraveler%7D%21%22%29%3B%0A%7D%0A).\nRun and edit this example on the canonical article (https://open-blog-jtc.netlify.app/posts/executable-code-lessons/).\nWeb lessons stay local\nWeb lessons stay in a dependency-free, opaque-origin preview:\nHTML\n\nCSS\nbutton { padding: 0.75rem 1rem; color: rebeccapurple; }\nJavaScript\ndocument.querySelector(\"#gate\").onclick = (event) => { event.currentTarget.textContent = \"The gate opens\"; };\nWeb · reveal the gate on the canonical article (https://open-blog-jtc.netlify.app/posts/executable-code-lessons/).\nConfigured languages fail closed\nThe repository example intentionally does not configure an external runner. This Python fence\ntherefore stays static even though it opts into runnable; a site owner must explicitly allow\nPython and deploy an isolated gateway first.\nPython · static until enabled\nname = input().strip() or \"traveler\"\nprint(f\"Welcome, {name}!\")\nRun and edit this example on the canonical article (https://open-blog-jtc.netlify.app/posts/executable-code-lessons/).\nThat fail-closed behavior lets an author keep portable lesson source without silently turning the\nblog or Admin server into a code-execution service.\nPortable fallback: The source code and canonical run/edit link are preserved; eligible Rust examples also link to the external Playground. Review: Review the preserved source and keep the canonical link for editing or execution.\nPortable fallback: The HTML, CSS, and JavaScript sources are preserved; the live preview remains on the canonical article. Review: Review the preserved source and keep the canonical link for editing or execution.\nPortable fallback: The source code and canonical run/edit link are preserved; eligible Rust examples also link to the external Playground. Review: Review the preserved source and keep the canonical link for editing or execution.\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/executable-code-lessons/#ob-discussion)", "date_published": "2026-10-24T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/executable-code-lessons/", "summary": "Rust and browser lessons work out of the box; configured languages fail closed until a separate runner is enabled.", "tags": [ "tutorial", "rust", "web" ], "title": "Executable code lessons, with a safe fallback", "url": "https://open-blog-jtc.netlify.app/posts/executable-code-lessons/" }, { "content_html": "\n\n\nSeven travelers arrive at a sealed mountain gate as an old ward begins to fail. This companion page\nkeeps the episode, production context, and accessible transcript in creator-owned Markdown.
\nThe opening uses a wide silhouette before moving to individual reaction shots. The gate remains the\nvisual anchor, while ember light distinguishes forbidden magic from ordinary torchlight.
\nNarrator: The mountain had no door on any map, but every road bent toward it.
\nMara: Nobody touches the seal until we know who lit those runes.
\nNarrator: From the other side came a sound like a great chain falling through the dark.
\nComments are closed. Read the discussion on the original article.
\n", "content_text": "Zhalendor — The Gate of Embers\nCanonical: https://open-blog-jtc.netlify.app/posts/zhalendor-gate-of-embers/\nNote:\nThis is a fictional product example, not an actual Lantern Gate Studios release or production\ncredit. It is intended to be replaced with the studio's real words and media.\nSeven travelers arrive at a sealed mountain gate as an old ward begins to fail. This companion page\nkeeps the episode, production context, and accessible transcript in creator-owned Markdown.\nChapters\n00:00 The road beneath the mountain\n00:42 A warning in the ash\n01:36 The gate answers\n02:28 Beyond the threshold\nProduction log\nStory beat and continuity review\nShot list and animatic\nVoice and sound pass\nFinal color and accessibility review\nRelease copy and scheduled publication\nShot notes\nThe opening uses a wide silhouette before moving to individual reaction shots. The gate remains the\nvisual anchor, while ember light distinguishes forbidden magic from ordinary torchlight.\nTranscript\nNarrator: The mountain had no door on any map, but every road bent toward it.\nMara: Nobody touches the seal until we know who lit those runes.\nNarrator: From the other side came a sound like a great chain falling through the dark.\nVideo details\nEpisode: Season 1, episode 1\nProduction status: editing\nProduction credits: Story and direction by the Lantern Gate team; animation and edit by the episode crew\nVideo: Zhalendor — The Gate of Embers (https://youtu.be/Zha1endor01)\nRead the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/zhalendor-gate-of-embers/#ob-discussion)", "date_published": "2026-10-24T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/zhalendor-gate-of-embers/", "summary": "A fictional Lantern Gate Studios episode page demonstrating production status, credits, chapters, a transcript, and AI-assistance disclosure.", "tags": [ "animation", "fantasy", "behind-the-scenes" ], "title": "Zhalendor — The Gate of Embers", "url": "https://open-blog-jtc.netlify.app/posts/zhalendor-gate-of-embers/" }, { "content_html": "The rain stopped shortly before sunrise, but the woods kept dripping for most of the\nmorning. Water moved through every shallow channel beside the trail, and the first rocky\nclimb was slick enough to slow the pace.
\n\nThe lower trail crossed mixed hardwood forest before turning uphill through hemlock and\nwhite pine. At roughly the halfway point, the path reached an exposed ledge where wind had\nalready dried the rock. Low cloud hid the farther hills, so I turned around at the next\njunction instead of completing the longer loop.
\nThe approximate route above is enough to show the shape and effort of the outing without\npublishing a trailhead, campsite, or observation coordinate. For a real post, import a GPX\nfile in Field Review and choose the privacy mode before saving.
\nThe first kilometer was broad and gently graded. Beyond the stream crossing, roots, wet\nslabs, and two short step-ups made the route unsuitable for wheels and potentially difficult\nfor hikers with limited balance. Cell service was intermittent below the ridge. There was\nno reliable water source after the crossing.
\nOne fist-sized branch had fallen across the drainage outlet near the lower switchback. I\nmoved only the loose branch, leaving embedded rocks and the channel itself untouched. The\nlarger muddy section would benefit from assessment by the trail steward rather than an\ninformal reroute.
\nField journals work best when they record what was actually observed, distinguish estimates\nfrom measurements, and reveal no more location detail than the story needs.
\nJoin the discussion on the original article.
\n", "content_text": "A wet morning on the ridge\nCanonical: https://open-blog-jtc.netlify.app/posts/a-wet-morning-on-the-ridge/\nThe rain stopped shortly before sunrise, but the woods kept dripping for most of the\nmorning. Water moved through every shallow channel beside the trail, and the first rocky\nclimb was slick enough to slow the pace.\nNote:\nThis is a fictional but realistic working example. Its location is deliberately\ngeneralized, and its route drawing contains normalized illustration points—not latitude\nand longitude.\nRoute notes\nThe lower trail crossed mixed hardwood forest before turning uphill through hemlock and\nwhite pine. At roughly the halfway point, the path reached an exposed ledge where wind had\nalready dried the rock. Low cloud hid the farther hills, so I turned around at the next\njunction instead of completing the longer loop.\nThe approximate route above is enough to show the shape and effort of the outing without\npublishing a trailhead, campsite, or observation coordinate. For a real post, import a GPX\nfile in Field Review and choose the privacy mode before saving.\nField observations\nSeveral red-backed salamanders were active beneath already-loose bark beside the path.\nI left the bark in place and did not record a precise location.\nClub moss was bright green across the shaded slope, while the exposed ridge vegetation\nwas already dormant.\nFresh boot widening was visible around two muddy sections. Staying in the center of the\ntread kept the disturbed area from spreading farther into the understory.\nA small drainage crossing was carrying clear water with no visible sediment plume.\nTrail and access conditions\nThe first kilometer was broad and gently graded. Beyond the stream crossing, roots, wet\nslabs, and two short step-ups made the route unsuitable for wheels and potentially difficult\nfor hikers with limited balance. Cell service was intermittent below the ridge. There was\nno reliable water source after the crossing.\nStewardship note\nOne fist-sized branch had fallen across the drainage outlet near the lower switchback. I\nmoved only the loose branch, leaving embedded rocks and the channel itself untouched. The\nlarger muddy section would benefit from assessment by the trail steward rather than an\ninformal reroute.\nWhat I would bring next time\nTrekking poles for the wet descent\nA small towel for camera gear\nOffline trail information downloaded before leaving\nA few extra minutes to document the widening tread for the local steward\nField journals work best when they record what was actually observed, distinguish estimates\nfrom measurements, and reveal no more location detail than the story needs.\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/a-wet-morning-on-the-ridge/#ob-discussion)", "date_published": "2026-10-23T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/a-wet-morning-on-the-ridge/", "image": "https://open-blog-jtc.netlify.app/images/misty-ridge-field-note.jpg", "summary": "A working field-journal example with trail conditions, observations, an approximate route, and practical stewardship notes.", "tags": [ "hiking", "field-notes", "stewardship" ], "title": "A wet morning on the ridge", "url": "https://open-blog-jtc.netlify.app/posts/a-wet-morning-on-the-ridge/" }, { "authors": [ { "name": "Example Author" } ], "content_html": "\n\nThis working example shows how a portable Markdown article can publish research-oriented\nmetadata and credit more than one person without putting identity data in front matter. The\npost selects the research profile, while an adjacent JSON sidecar supplies ordered authorship\nand controlled contributor roles.
Three files make the demonstration work:
\nopenblog.json registers the reusable example-author and example-editor identities.2026-02-16-research-and-contributor-credits.credits.json connects those identities to\nthis work with Crossref and CRediT roles.The identities are deliberately synthetic and their ORCID fields are empty. Replace them with\nreal people and add only identifiers those people actually control. Manually entered ORCID iDs\nremain visibly labeled as unauthenticated.
\nOpen this post in Admin Studio to see the same data from an author's point of view:
\nAfter openblog build, inspect this page, rss.xml, feed.json, and the page's JSON-LD.\nOnly the Crossref author appears in author-only metadata; both people and all their roles remain\nvisible in the Contributions panel.
Join the discussion on the original article.
\n", "content_text": "Research posts and contributor credits\nCanonical: https://open-blog-jtc.netlify.app/posts/research-and-contributor-credits/\nAbstract\nThis working example shows how a portable Markdown article can publish research-oriented\nmetadata and credit more than one person without putting identity data in front matter. The\npost selects the research profile, while an adjacent JSON sidecar supplies ordered authorship\nand controlled contributor roles.\nFollow the source files\nThree files make the demonstration work:\nopenblog.json registers the reusable example-author and example-editor identities.\nThis Markdown file contains the article, license, Abstract, and References sections.\n2026-02-16-research-and-contributor-credits.credits.json connects those identities to\nthis work with Crossref and CRediT roles.\nThe identities are deliberately synthetic and their ORCID fields are empty. Replace them with\nreal people and add only identifiers those people actually control. Manually entered ORCID iDs\nremain visibly labeled as unauthenticated.\nWhat to inspect\nOpen this post in Admin Studio to see the same data from an author's point of view:\nSettings → Credit contributors and roles preserves credit order and exposes controlled\nroles.\nEvidence reports the research structure and bounded reference links below.\nSite preview renders the production byline, work details, and Contributions panel.\nSocial uses the same publishing-engine metadata as the generated page.\nAfter openblog build, inspect this page, rss.xml, feed.json, and the page's JSON-LD.\nOnly the Crossref author appears in author-only metadata; both people and all their roles remain\nvisible in the Contributions panel.\nReferences\nCRediT role taxonomy (https://credit.niso.org/)\nCrossref contributor guidance (https://www.crossref.org/documentation/schema-library/markup-guide-metadata-segments/contributors/)\nContributions\nExample Author — Author, Conceptualization, Writing – original draft\nExample Editor — Editor, Writing – review & editing\nWork details\nLicense: https://creativecommons.org/licenses/by/4.0/\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/research-and-contributor-credits/#ob-discussion)", "date_published": "2026-02-16T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/research-and-contributor-credits/", "summary": "A working example of research metadata, ordered authorship, contributor roles, references, and the Admin Studio workflow.", "tags": [ "research", "guide", "collaboration" ], "title": "Research posts and contributor credits", "url": "https://open-blog-jtc.netlify.app/posts/research-and-contributor-credits/" }, { "content_html": "Publishing in more than one community can help readers find your work, but your blog\nshould remain the source of truth. The dependable sequence is:
\nThe canonical URL tells search engines which copy is the original. Deploying that URL\nfirst also prevents every destination from pointing at a page that does not exist yet.
\nEvery open.blog site can expose full-content RSS at /rss.xml and JSON Feed at\n/feed.json. Enable feeds.rss, feeds.json, and feeds.fullContent in\nopenblog.json. A feed automation service can then watch either URL and create a draft\nwhen a new post appears.
Before connecting one, confirm that its destination action can:
\nIf it cannot do those things, use the destination's API or import flow instead.
\ncanonical_url field. Save the returned article ID so future runs update the same\npost.The repository's\ncomplete cross-posting guide\nwalks through credentials, API requests, CI safety, updating instead of duplicating, and\nthe official documentation for each platform. It also includes a complete GitHub\nActions template that waits for deployment, verifies the canonical URL, and creates or\nupdates a DEV draft from the deployed JSON Feed.
\nStore tokens as encrypted CI secrets. Never put one in Markdown front matter, the\ngenerated site, or code that runs in a reader's browser. Start every integration in\ndraft mode and test it with one disposable article.
\nOnce that works, automation can handle the repetitive copying while you keep the final\nreview. Your Markdown stays authoritative, every public copy points home, and a failure\non one community does not prevent the original article from reaching your readers.
\nJoin the discussion on the original article.
\n", "content_text": "Safely cross-posting your blog\nCanonical: https://open-blog-jtc.netlify.app/posts/automated-cross-posting/\nPublishing in more than one community can help readers find your work, but your blog\nshould remain the source of truth. The dependable sequence is:\npublish the article on your open.blog site;\nmake sure its final URL is live;\ncreate drafts on the other platforms;\nset each copy's canonical URL back to the open.blog article;\nreview the formatting, then publish the copies.\nThe canonical URL tells search engines which copy is the original. Deploying that URL\nfirst also prevents every destination from pointing at a page that does not exist yet.\nStart with the feeds\nEvery open.blog site can expose full-content RSS at /rss.xml and JSON Feed at\n/feed.json. Enable feeds.rss, feeds.json, and feeds.fullContent in\nopenblog.json. A feed automation service can then watch either URL and create a draft\nwhen a new post appears.\nBefore connecting one, confirm that its destination action can:\ncreate a draft instead of publishing immediately;\nset the original article URL as canonical;\nupdate the same remote article rather than create a duplicate.\nIf it cannot do those things, use the destination's API or import flow instead.\nPick the right setup for each platform\nHashnode: its official GitHub Action can publish repository Markdown and supports\ndrafts, dry runs, and canonical URLs. API publishing now requires a Hashnode Pro\npublication.\nDEV Community: its API accepts Markdown, supports drafts, and has a\ncanonical_url field. Save the returned article ID so future runs update the same\npost.\nMedium: use Import a story after the original is live. Medium does not accept\nnew API integrations; its importer adds the original URL as canonical automatically.\nGhost: its Admin API supports drafts and custom canonical URLs. Keep the Admin API\nkey on a trusted server or in CI, never in browser JavaScript.\nWordPress: its REST API supports drafts, but core WordPress has no portable field\nfor an external canonical. Only syndicate automatically if your particular SEO plugin\nor site configuration exposes and verifies one.\nThe repository's\ncomplete cross-posting guide (https://github.com/journey-to-code-org/open.blog/blob/main/docs/cross-posting.md)\nwalks through credentials, API requests, CI safety, updating instead of duplicating, and\nthe official documentation for each platform. It also includes a complete GitHub\nActions template that waits for deployment, verifies the canonical URL, and creates or\nupdates a DEV draft from the deployed JSON Feed.\nKeep publishing credentials private\nStore tokens as encrypted CI secrets. Never put one in Markdown front matter, the\ngenerated site, or code that runs in a reader's browser. Start every integration in\ndraft mode and test it with one disposable article.\nOnce that works, automation can handle the repetitive copying while you keep the final\nreview. Your Markdown stays authoritative, every public copy points home, and a failure\non one community does not prevent the original article from reaching your readers.\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/automated-cross-posting/#ob-discussion)", "date_published": "2026-02-09T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/automated-cross-posting/", "summary": "Publish here first, then send reviewable, canonical copies to DEV, Hashnode, Medium, Ghost, or WordPress.", "tags": [ "guide" ], "title": "Safely cross-posting your blog", "url": "https://open-blog-jtc.netlify.app/posts/automated-cross-posting/" }, { "content_html": "open.blog is not only for code. Add profile: recipe to a post's front matter, put the\ningredients in a list under an ## Ingredients heading and the steps in a list under a\n## Steps heading, and the post becomes a recipe:
Start a new one with openblog new \"Lemon garlic pasta\" --recipe. This post is a working\nexample; try the buttons above.
The front matter for this post:
\nprofile: recipe\nservings: 4\nprep: 10 min\ncook: 15 min\ncuisine: Italian\ncourse: Dinner\nTimes can be written as 15 min, 1 hr 30 min, or 1:30; something like overnight\nis shown as written. Use makes: 12 cookies to say what a recipe makes, alongside\nservings if readers should be able to scale it.
Join the discussion on the original article.
\n", "content_text": "Recipes, too: lemon garlic pasta\nCanonical: https://open-blog-jtc.netlify.app/posts/recipes-for-cooks/\nopen.blog is not only for code. Add profile: recipe to a post's front matter, put the\ningredients in a list under an ## Ingredients heading and the steps in a list under a\n## Steps heading, and the post becomes a recipe:\nA summary card with the times and servings, and a \"Jump to recipe\" link.\nButtons that scale the amount at the start of each ingredient to more or fewer servings.\nCheckboxes to tick off ingredients and steps (remembered on the reader's device).\nTimers: any time in a step, like \"10 minutes\", starts a countdown when tapped.\nCook mode keeps the screen awake, and \"Print recipe\" prints just the recipe.\nSearch engines get schema.org recipe data; with a photo, the post can appear as a recipe result.\nStart a new one with openblog new \"Lemon garlic pasta\" --recipe. This post is a working\nexample; try the buttons above.\nTip:\nSave a cup of the pasta water before you drain it. Its starch makes the sauce glossy.\nIngredients\n400 g spaghetti\n3 tbsp olive oil\n4 cloves garlic, thinly sliced\n1 1/2 lemons, zested and juiced\n1/2 cup grated parmesan, plus more to serve\n1 handful parsley, chopped\nSalt and black pepper, to taste\nSteps\nBring a large pot of salted water to the boil and cook the spaghetti for 9 minutes.\nMeanwhile, warm the olive oil in a wide pan over low heat and cook the garlic for\n2-3 minutes, until soft but not brown.\nSave a cup of the pasta water, then drain the spaghetti and add it to the pan.\nAdd the lemon zest and juice, the parmesan, and a splash of pasta water. Toss for\n1 minute, until glossy, adding more water if it looks dry.\nSeason, scatter over the parsley, and serve with more parmesan.\nNotes\nThe front matter for this post:\nprofile: recipe\nservings: 4\nprep: 10 min\ncook: 15 min\ncuisine: Italian\ncourse: Dinner\nTimes can be written as 15 min, 1 hr 30 min, or 1:30; something like overnight\nis shown as written. Use makes: 12 cookies to say what a recipe makes, alongside\nservings if readers should be able to scale it.\nRecipe details\nPrep: 10 min\nCook: 15 min\nTotal: 25 min\nServes: 4\nCuisine: Italian\nCourse: Dinner\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/recipes-for-cooks/#ob-discussion)", "date_published": "2026-02-02T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/recipes-for-cooks/", "summary": "open.blog is not only for code. Mark a post as a recipe and readers get a recipe card, servings scaling, checklists, timers, cook mode, and a print view.", "tags": [ "recipe", "guide" ], "title": "Recipes, too: lemon garlic pasta", "url": "https://open-blog-jtc.netlify.app/posts/recipes-for-cooks/" }, { "content_html": "openblog build\nwrites a complete static site to dist/: pages, RSS and JSON feeds, a sitemap, a search\nindex, and the assets. Upload that folder to any static host, or run openblog serve to\nhost it yourself.
draft: true keeps a post out of every build and feed. openblog serve --drafts previews\ndrafts locally. The admin editor shows drafts with their own badge.
Give a post a date in the future and it is scheduled:
\ndate: 2026-12-25T09:00:00Z\nScheduled posts stay out of the pages, feeds, sitemap, and search index. When the time\ncomes, openblog serve rebuilds by itself. On a static host, any openblog build after\nthat time publishes it, so a daily build (a cron job or a scheduled workflow) is enough.
For editing from a browser, including on the server that hosts the blog:
\nopenblog user add you\nopenblog serve --admin\nThen open /admin. It writes the same Markdown files, so you can mix both ways of\nworking. docs/admin.md covers running it safely on the public internet.
/rss.xml carries the full post HTML and /feed.json is JSON Feed 1.1. Most newsletter\nand cross-posting tools accept either. If you republish a post elsewhere, set the copy's\ncanonical URL to its address here; for a post that was first published elsewhere, set\ncanonical: in its front matter.
Continue with Safely cross-posting your blog for a\nreview-first workflow covering Hashnode, DEV, Medium, Ghost, and WordPress.
\nThat is the whole workflow. Delete this series when your own posts arrive, or keep it as\na reference.
\nJoin the discussion on the original article.
\n", "content_text": "Publishing and scheduling\nCanonical: https://open-blog-jtc.netlify.app/posts/publishing-and-scheduling/\nBuild and host\nopenblog build\nwrites a complete static site to dist/: pages, RSS and JSON feeds, a sitemap, a search\nindex, and the assets. Upload that folder to any static host, or run openblog serve to\nhost it yourself.\nDrafts\ndraft: true keeps a post out of every build and feed. openblog serve --drafts previews\ndrafts locally. The admin editor shows drafts with their own badge.\nScheduling\nGive a post a date in the future and it is scheduled:\ndate: 2026-12-25T09:00:00Z\nScheduled posts stay out of the pages, feeds, sitemap, and search index. When the time\ncomes, openblog serve rebuilds by itself. On a static host, any openblog build after\nthat time publishes it, so a daily build (a cron job or a scheduled workflow) is enough.\nThe admin editor\nFor editing from a browser, including on the server that hosts the blog:\nopenblog user add you\nopenblog serve --admin\nThen open /admin. It writes the same Markdown files, so you can mix both ways of\nworking. docs/admin.md covers running it safely on the public internet.\nFeeds and cross-posting\n/rss.xml carries the full post HTML and /feed.json is JSON Feed 1.1. Most newsletter\nand cross-posting tools accept either. If you republish a post elsewhere, set the copy's\ncanonical URL to its address here; for a post that was first published elsewhere, set\ncanonical: in its front matter.\nContinue with Safely cross-posting your blog (https://open-blog-jtc.netlify.app/posts/automated-cross-posting/) for a\nreview-first workflow covering Hashnode, DEV, Medium, Ghost, and WordPress.\nThat is the whole workflow. Delete this series when your own posts arrive, or keep it as\na reference.\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/publishing-and-scheduling/#ob-discussion)", "date_published": "2026-01-26T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/publishing-and-scheduling/", "summary": "Build the site, host it anywhere, keep a draft private, and schedule a post for later.", "tags": [ "guide" ], "title": "Publishing and scheduling", "url": "https://open-blog-jtc.netlify.app/posts/publishing-and-scheduling/" }, { "content_html": "List them in the front matter. Each tag gets a page at /tags/<slug>/, and /tags/ lists\nthem all with counts. Tags are matched case-insensitively, so Rust and rust are one tag.
tags:\n - guide\n - rust\nA series is a file in content/series/. This one is content/series/getting-started.md:
---\nname: Getting started\ndescription: Three short parts ...\ntheme: demo # every post in the series renders with this theme\norder: 1 # position on the /series/ page\n---\nOptional Markdown shown at the top of the series page.\nA post joins a series with series: getting-started. Parts are ordered by seriesOrder,\nor by date when it is missing. The post page then shows \"Part 2 of 3\", previous and next\nlinks, and a list of all parts. If you reference a series that has no file, open.blog\ncreates it from the slug and warns you.
Set theme: on a series and all of its posts switch theme, including this one. A single\npost can override with theme: of its own. The themes available are the folders under\nthemes/; run openblog themes to list them. See docs/themes.md for how a theme is\nbuilt from design tokens, and docs/theme-components.md for the heading effect this\nseries is using.
Next: Publishing and scheduling.
\nJoin the discussion on the original article.
\n", "content_text": "Tags and series\nCanonical: https://open-blog-jtc.netlify.app/posts/tags-and-series/\nTags\nList them in the front matter. Each tag gets a page at /tags/A post is a Markdown file in content/posts/. The file name can start with a date\n(2026-01-12-writing-a-post.md); the rest becomes the slug, so this post lives at\n/posts/writing-a-post/. Add slug: to the front matter to choose a different one.
---\ntitle: Writing a post\nsubtitle: Optional. A one-line subheading shown under the title.\ndate: 2026-01-12 # or a full time: 2026-01-12T09:30:00Z\ntags: [guide, markdown] # inline lists work too\ndescription: Optional. Used in feeds and search results.\ncover: /images/cover.png # optional; the first image in the body is the fallback\ndraft: false\n---\nDates without a time are midnight UTC. A post dated in the future is scheduled and stays\nhidden until that moment (part three has the details).
\nCommonMark plus the GitHub extensions: tables, task lists, footnotes, and strikethrough.\nHeadings get ids and anchor links, so #markdown-that-works links here.
| Feature | Syntax |
|---|---|
| Task list | - [x] done |
| Footnote | text[^1] |
| Strikethrough | ~~old~~ |
Callouts draw attention to a note, a tip, or a warning:
\n\nRegular code blocks are read-only: they keep the original syntax colouring, line numbers,\nhighlighted lines, and copy button. This one demonstrates that decorative presentation:
\npub fn greeting(name: &str) -> String {\n format!(\"Hello, {name}!\")\n}\nAdd runnable only when readers should be able to edit and execute a self-contained Rust\nexample. A runnable block deliberately becomes an editor with controls and inline output:
fn main() {\n let name = "reader";\n println!("Hello, {name}!");\n}\nRun and edit this example on the original article.
The two fences begin with ```rust title=\"...\" and\n```rust runnable playgroundLink=false title=\"...\" respectively. Leave out\nplaygroundLink=false when you want the external Playground fallback. Add\nshowLineNumbers=10 to a read-only block to count from 10, or showLineNumbers=false to\ndrop the numbers. Running the live example sends its edited source to the official Rust\nPlayground. To change highlighting and numbering for the whole blog, see code in\nopenblog.json.
What happens when a post is dated in the future?
\nAnswer: B. It stays hidden until a build runs after the scheduled time
\nA future-dated post becomes public in the first build run after its scheduled time.
\nPut files in static/; they are copied to the site root. static/images/photo.png is\n/images/photo.png:
\nThe admin editor uploads and inserts images for you, including by drag and drop or paste.
\nNext: Tags and series.
\nFootnotes render at the end of the post.
\nJoin the discussion on the original article.
\n", "content_text": "Writing a post\nCanonical: https://open-blog-jtc.netlify.app/posts/writing-a-post/\nFront matter, Markdown, images, and code blocks in one file.\nA post is a Markdown file in content/posts/. The file name can start with a date\n(2026-01-12-writing-a-post.md); the rest becomes the slug, so this post lives at\n/posts/writing-a-post/. Add slug: to the front matter to choose a different one.\nFront matter\n---\ntitle: Writing a post\nsubtitle: Optional. A one-line subheading shown under the title.\ndate: 2026-01-12 # or a full time: 2026-01-12T09:30:00Z\ntags: [guide, markdown] # inline lists work too\ndescription: Optional. Used in feeds and search results.\ncover: /images/cover.png # optional; the first image in the body is the fallback\ndraft: false\n---\nDates without a time are midnight UTC. A post dated in the future is scheduled and stays\nhidden until that moment (part three has the details).\nMarkdown that works\nCommonMark plus the GitHub extensions: tables, task lists, footnotes, and strikethrough.\nHeadings get ids and anchor links, so #markdown-that-works links here.\nFeature\nSyntax\nTask list\n- [x] done\nFootnote\ntext[^1]\nStrikethrough\n~~old~~\nWrite the post\nPublish it\nCallouts draw attention to a note, a tip, or a warning:\nTip:\nWrite > [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], or > [!CAUTION]\non the first line of a quote.\nRegular code blocks are read-only: they keep the original syntax colouring, line numbers,\nhighlighted lines, and copy button. This one demonstrates that decorative presentation:\nRead-only example · src/lib.rs\npub fn greeting(name: &str) -> String {\nformat!(\"Hello, {name}!\")\n}\nAdd runnable only when readers should be able to edit and execute a self-contained Rust\nexample. A runnable block deliberately becomes an editor with controls and inline output:\nLive example · try changing the name\nfn main() {\nlet name = \"reader\";\nprintln!(\"Hello, {name}!\");\n}\nRun and edit this example on the canonical article (https://open-blog-jtc.netlify.app/posts/writing-a-post/).\nThe two fences begin with ```rust title=\"...\" and\n```rust runnable playgroundLink=false title=\"...\" respectively. Leave out\nplaygroundLink=false when you want the external Playground fallback. Add\nshowLineNumbers=10 to a read-only block to count from 10, or showLineNumbers=false to\ndrop the numbers. Running the live example sends its edited source to the official Rust\nPlayground. To change highlighting and numbering for the whole blog, see code in\nopenblog.json.\nCheck your understanding\nQuestion: What happens when a post is dated in the future?\nIt is published immediately with a future date\nIt stays hidden until a build runs after the scheduled time\nIt is automatically saved as a draft\nAnswer: 2. It stays hidden until a build runs after the scheduled time\nExplanation: A future-dated post becomes public in the first build run after its scheduled time.\nImages\nPut files in static/; they are copied to the site root. static/images/photo.png is\n/images/photo.png:\n\nThe admin editor uploads and inserts images for you, including by drag and drop or paste.\nNext: Tags and series (https://open-blog-jtc.netlify.app/posts/tags-and-series/).\n[1]: Footnotes render at the end of the post.\nPortable fallback: The source code and canonical run/edit link are preserved; eligible Rust examples also link to the external Playground. Review: Review the preserved source and keep the canonical link for editing or execution.\nPortable fallback: The question and answer are preserved; scoring, retry, and remembered attempts are unavailable. Review: Review the static question and answer; keep the canonical link when scoring or retries matter.\nJoin the discussion on the canonical article (https://open-blog-jtc.netlify.app/posts/writing-a-post/#ob-discussion)", "date_published": "2026-01-12T00:00:00Z", "id": "https://open-blog-jtc.netlify.app/posts/writing-a-post/", "summary": "What goes in a post file, which Markdown features work, and how images and code blocks are handled.", "tags": [ "guide", "markdown" ], "title": "Writing a post", "url": "https://open-blog-jtc.netlify.app/posts/writing-a-post/" }, { "content_html": "You are looking at content/posts/2026-01-05-welcome-to-your-blog.md. Everything on this\nsite comes from Markdown files like it. There is no database to set up and nothing to\nexport later: your posts are plain text in a folder you own.
openblog serve rebuilds the site\nwhile it runs.openblog user add you, then openblog serve --admin and\nopen /admin. It edits these same files, with a live preview.openblog new \"A post title\" creates a file with today's date.The block between the --- lines at the top is the front matter. Only date is required,\nplus a title unless the body starts with a # heading. tags, description, series, cover, draft, and theme are optional;\nthe Getting started series walks through them.
openblog.json.openblog.json, or write one in themes/.