Skip to main content

Your Astro Website Deserves a Better CMS: Meet isHistory

How I built isHistory CMS — an Obsidian plugin that turns your notes into a full content management system for Astro-powered websites with live validation, pre-flight deployment, and mobile support.

I
Ishaan
| | 9 min read | 1,651 words (Updated: )

Your Astro Website Deserves a Better CMS

How I Built isHistory CMS — an Obsidian plugin that turns your notes into a full content management system for Astro-powered websites

If you’ve ever built a content-heavy site with Astro, you know the framework is fast, the builds are snappy, and the content collections system is genuinely elegant. But day-to-day content management? That’s another story.

Open VS Code. Navigate through folders. Manually edit YAML frontmatter. Hope you didn’t miss a required field. It works — but it’s not a workflow. It’s a chore.

I built isHistory CMS to solve this problem. It’s now an official Obsidian Community Plugin that turns Obsidian into a full CMS for Astro websites. Think of it as a spell‑checker for your blog posts — but instead of checking spelling, it checks that every post has all the information your Astro site needs to display it properly.

TL;DR – isHistory CMS gives you a visual dashboard, live frontmatter validation, one‑click pre‑flight marking, and a mobile‑friendly editorial interface — all inside Obsidian. No external servers, no API keys, your data stays in your vault.


The Problem: Managing History Content in a Static World

Building an AI history publication in Astro is fast, elegant, and delightfully developer-friendly — until you have to manage it day to day. Each post in my publication has:

  • A track (Articles, Profiles, or Events)
  • A series order code
  • Validation rules for frontmatter fields
  • A publishing status

That’s a lot of metadata to juggle across dozens of Markdown files. A single typo in a frontmatter field can silently break your entire build.

The default workflow — manually editing YAML in VS Code — works, but for a content-heavy site like mine, it becomes an active burden. I built isHistory CMS to turn Obsidian into a writing-first environment where content management feels like writing, not programming.

What isHistory CMS Does

isHistory CMS is designed for the isHistory Astro project (a deep‑dive into the history of AI) but works with any Astro site that uses Content Collections.

A Visual Dashboard for Your Content

The plugin opens a full dashboard view inside Obsidian that displays every post in your content collections as interactive cards. Each card shows:

  • Post title
  • Track badge
  • Validation status (ready / errors)
  • Description
  • Tags
  • Draft status

Color‑coded left borders instantly tell you whether a post is ready for publication, has errors, or is still a work in progress.

The dashboard also includes:

  • A stats bar (archive posts, vault notes, track counts, drafts, errors, ready posts)
  • Full‑text search
  • Filter buttons for tracks, drafts, recent edits, errors
  • Sort options (series order, newest first, oldest first, title, errors first, drafts first)

Live Frontmatter Validation

Missing a required field like title, description, or track can cause your Astro build to fail silently. isHistory CMS validates every post against your content schema in real time, directly inside Obsidian.

The validation engine checks for:

  • Missing required fields
  • Badly formatted dates
  • Tags that aren’t YAML lists
  • Series fields with missing partners
  • Track mismatches
  • Draft/published conflicts

Errors and warnings appear on dashboard cards and in the sidebar validator as you type. What used to be a build‑time surprise becomes an in‑your‑face fix‑it‑now prompt while you’re still editing.

Pre‑flight: Mark Posts Ready for Deployment

The Pre‑flight button is the heart of the publishing workflow. When you click Pre‑flight on a post, the plugin:

  • Sets draft: false in frontmatter
  • Adds a published timestamp (and today’s date if none is set)

This signals your Astro site that the post is ready to go live on the next build. You can also Pre‑flight multiple posts at once through the bulk operation modal.

Important: Pre‑flight marks the post as ready, but it does not deploy it. Deployment requires a separate Git sync step (see Getting Started).

Mobile‑First Design

isHistory CMS is built with mobile support from the ground up. The manifest declares isDesktopOnly: false, and every UI component is tested on the Obsidian mobile app. The dashboard grid adapts to smaller screens, the sidebar view works in the mobile drawer, and the new post creation flow is fully touch‑friendly.


The Technical Journey: From Idea to Official Plugin

Getting a plugin into the Obsidian Community Plugin directory is a rigorous process. Here are the key lessons from my review journey.

Eliminating XSS Vectors

The review team flagged three instances of innerHTML in my initial code. I replaced every one with Obsidian’s native createEl API, which constructs DOM elements programmatically and automatically escapes dangerous content.

Taming Asynchronous Chaos

Obsidian plugins interact with the vault file system through event listeners. My solution was a centralized debouncing framework that queues file paths and processes them on a schedule, eliminating race conditions and UI freezes.

Honest UX: Pre‑flight, Not Publish

I originally called the button “Publish.” But the plugin only modifies local frontmatter — actual deployment requires Git. Renaming it to Pre‑flight sets accurate expectations: the plane is ready for takeoff, but the pilot (you) still needs to push the throttles (Git sync).

The CSS Specificity Lesson

The review’s CSS lint caught five uses of !important. I replaced them with higher‑specificity selectors (e.g., .cms-card.cms-card-track-A instead of .cms-card-track-A with !important).

Artifact Attestations and Build Verification

I set up a GitHub Actions workflow that runs on every tag push, executes a build verification script, generates attestations for main.js and styles.css, and creates the release automatically. The build script checks for forbidden patterns like innerHTML and console.log, and verifies no !important remains in the CSS.


The Broader Ecosystem

The idea of using Obsidian as a CMS for Astro isn’t new. Several tools have explored this space:

ToolFocus
Vault CMSOpen‑source headless CMS with auto‑detection of routes and preconfigured workspace
Astro ComposerAutomates post creation, slug generation, and link conversion
Bases CMSCard‑based views and bulk operations for Obsidian’s core Bases plugin

Where does isHistory CMS fit? While Vault CMS emphasises automation and a complete publishing platform, isHistory CMS is built for writers who need rigorous frontmatter validation, track‑based organisation, and a clean editorial interface inside Obsidian. It’s designed for the isHistory AI history project but works with any Astro site that uses Content Collections.

Current stats: 25 downloads, four releases, recent v1.6.0 update. The plugin has not yet been manually reviewed by Obsidian staff, but it’s available in the community directory.


Getting Started with isHistory CMS

Installation

  1. Open Obsidian -> Settings -> Community Plugins -> Browse
  2. Search for isHistory CMS
  3. Install and enable the plugin
  4. A new ribbon icon will appear — click it to open the dashboard

Configuration

The plugin looks for content inside src/content/blog (archive path) and src/content/vault by default. If your Astro project is structured differently, change these paths in Settings -> isHistory CMS.

No external server, no API keys, no cloud dependency. Your data stays in your vault, on your machine, under your control.

Deployment Pipeline

Pre‑flighting a post marks it as ready, but it doesn’t push it live. To deploy:

  1. Install Obsidian Git
  2. Configure it to auto‑commit and push on an interval (e.g., every 5 minutes)
  3. Your Astro site’s CI/CD (Vercel, Netlify, Cloudflare Pages, etc.) detects the push and rebuilds automatically

Full pipeline: Write -> Pre‑flight -> Git sync -> Auto‑deploy

If you click Pre‑flight and your site doesn’t update, the first place to check is your Git sync — the plugin’s FAQ covers this exact scenario.


Why I Built This and What Comes Next

I built isHistory CMS because Obsidian is where I think and write. It should also be where I manage my content. Now it finally is.

The Obsidian plugin review process pushed the code toward a higher standard of security, usability, and maintainability. The result is a plugin I use every day to run my own site — and one that has already been downloaded 25 times since its recent release.

Roadmap

  • Git integration – embed Git operations directly so Pre‑flight can optionally commit and push without a separate plugin
  • Schema auto‑detection – read Astro content config files to eliminate manual path configuration
  • Media management view – bring image and asset management into the same dashboard

Try isHistory CMS

If you’re running an Astro site — especially a content‑heavy one with complex frontmatter validation needs — give isHistory CMS a try.

Install isHistory CMS from Obsidian Community Plugins

  • Free and open source (MIT licensed)
  • Available now in the Obsidian Community Plugin directory

Write in Obsidian. Validate in real time. Pre‑flight with confidence. Deploy with Git. Your notes deserve a better CMS, and now they have one.


FAQ

Q: Does isHistory CMS work with any Astro site? A: Yes — it works with any Astro project that uses Content Collections. The default paths are src/content/blog and src/content/vault, but you can configure them in settings.

Q: Does the plugin deploy my site? A: No. Pre‑flight only modifies local frontmatter (sets draft: false and adds timestamps). Deployment requires a Git sync (e.g., Obsidian Git) and your hosting platform’s auto‑deploy.

Q: Is my data sent to any server? A: No. Everything stays in your local Obsidian vault. No external APIs, no telemetry, no cloud dependencies.

Q: Is it really mobile‑friendly? A: Yes. The plugin is tested on the Obsidian mobile app and adapts to smaller screens.

Q: How is this different from Vault CMS? A: Vault CMS focuses on automation and a complete publishing platform. isHistory CMS focuses on rigorous validation, track‑based organisation, and a clean editorial interface — ideal for writers managing complex frontmatter.


Linked References

Share this article X Reddit LinkedIn