Vom Obsidian-Notiz zum WordPress-Blogpost
Ein Script, ein Terminal-Befehl – aus einer Markdown-Notiz in Obsidian wird ein fertiger WordPress-Blogpost mit Teaser, Lesezeit, Kategorie und Tags. Kein Login, kein Copy-Paste zwischen Editor und Browser.
Warum ein Blog direkt aus Obsidian
Meine Notizen entstehen sowieso in Obsidian – Ideen, Entwürfe, halbfertige Gedanken. Für einen Blog wollte ich keinen zusätzlichen Schritt "erst in WordPress umziehen", sondern direkt aus einer fertigen Notiz einen Beitrag machen können, ohne mich einzuloggen und ohne Copy-Paste zwischen Editor und Browser.
Die Anforderung war überschaubar: Titel, Teaser, Tags und Kategorie im Frontmatter der Notiz, ein Terminal-Befehl, fertig ist ein WordPress-Entwurf zur Kontrolle. Die Umsetzung war es weniger.
Wie der Sync funktioniert
Der Blog läuft über WordPress' eingebaute Beiträge – keine Sonderkonstruktion, sondern ganz normale Beiträge mit ganz normalen Kategorien und Tags. Ein Python-Script übernimmt die eigentliche Arbeit: Notiz einlesen, Markdown zu HTML wandeln, Kategorie/Tags anlegen oder wiederfinden, alles per REST API an WordPress übergeben.
Eine ACF-Feldgruppe ergänzt zwei zusätzliche Felder pro Beitrag – Teaser und Lesezeit –, die im Divi-Theme-Builder-Template für die Blog-Übersicht und die Einzelansicht verwendet werden. Gerendert wird über ein einziges Theme-Builder-Template statt einer eigenen Code-Modul-Datei pro Post – das ist der eigentliche Automatisierungs-Gewinn gegenüber meinem sonstigen Seiten-Workflow.
- Native WordPress-Beiträge, -Kategorien und -Tags
- ACF-Feldgruppe "Blog Meta" für Teaser und Lesezeit
- Ein Divi-Theme-Builder-Template für alle Blogposts
- SEO-Titel/-Description automatisch über Rank Math gesetzt
Der Workflow
Der eigentliche Ablauf ist seit der Umstellung angenehm kurz:
python3 scripts/obsidian_blog_sync.py notiz.md – Markdown wird zu HTML, Lesezeit aus der Wortzahl berechnet, Kategorie/Tags per REST angelegt oder wiedergefunden.Die Frontmatter-Konvention
Bewusst ein festes, einfaches Schema statt vollem YAML – slug ist dabei der Schlüssel: läuft das Script erneut über dieselbe Notiz, wird der bestehende Post aktualisiert statt dupliziert.
---
title: "Titel des Posts"
slug: mein-post-slug
teaser: "Kurzer Teaser-Text für die Blog-Übersicht."
tags: [n8n, automatisierung]
category: "Automatisierung"
cover: "./assets/cover.jpg"
seo_title: "..." # optional, sonst Fallback auf title
seo_description: "..." # optional, sonst Fallback auf teaser
---
Markdown-Body hier ...Kein Autopilot: Kontrolle vor Veröffentlichung
Jeder Sync setzt den Post-Status konsequent auf "Entwurf" zurück – auch wenn der Beitrag vorher schon live war. Wird eine Notiz nach der Veröffentlichung nochmal korrigiert und erneut gesynct, geht der Post automatisch wieder offline, bis ich ihn manuell erneut freischalte.
Das kostet einen zusätzlichen Klick bei jeder Korrektur – aber es verhindert zuverlässig, dass ein automatisierter Lauf unbeabsichtigt live geht. Automatisierung soll Arbeit abnehmen, nicht die letzte Kontrolle.
Eingesetzte Technologien
Fazit
Der Blog-Sync nimmt mir genau den Schritt ab, der sonst am meisten Reibung erzeugt hätte: den Wechsel vom Schreib-Tool ins CMS. Die Notiz bleibt in Obsidian, wo ohnehin alle meine Gedanken entstehen – ein Terminal-Befehl reicht, um daraus einen kontrollierbaren WordPress-Entwurf zu machen.
Auch dieser Artikel ist klassisch als Divi Code-Modul entstanden, nicht über den hier beschriebenen Blog-Workflow – der ist bewusst nur für den neuen Blog-Bereich unter /blog/ gedacht, nicht für Themen-Artikel wie diesen.