{"id":413,"date":"2026-10-03T17:10:40","date_gmt":"2026-10-03T17:10:40","guid":{"rendered":"https:\/\/www.fabricioruch.ch\/?p=413"},"modified":"2026-10-03T17:14:24","modified_gmt":"2026-10-03T17:14:24","slug":"markdown-entwuerfe-wordpress-ohne-block-editor","status":"publish","type":"post","link":"https:\/\/www.fabricioruch.ch\/?p=413","title":{"rendered":"Technische Artikel ohne Block-Editor: Markdown, Git und WordPress-Entw\u00fcrfe"},"content":{"rendered":"\n

Wenn du diesen Blog liest, siehst du am Ende nur eine normale WordPress-Seite<\/strong>: Titel, Kategorien, Leselayout, manchmal Code mit Syntax-Farben. Was du nicht<\/strong> siehst, ist wie<\/em> der Text entstanden. Für die meisten Beiträge gilt weiterhin: Autor öffnet WordPress im Browser, schreibt im Block-Editor<\/strong> (Gutenberg), setzt ein Titelbild, klickt auf Veröffentlichen.<\/p>\n\r\n\n

Für technische Field Notes<\/strong> und alles, was ich mit Git<\/strong>, Terminal<\/strong> oder KI-Assistenten<\/strong> vorbereite, nutze ich einen zweiten Weg: Der Artikel lebt zuerst als Textdatei<\/strong> auf meinem Rechner (Markdown), wird per Skript als Entwurf<\/strong> nach WordPress geschickt, und erst dort schaue ich noch einmal drüber und veröffentliche manuell. Dieser Beitrag erklärt diesen Weg von Grund auf<\/strong> \u2014 auch wenn du WordPress nur als Leser kennst oder noch nie von \u201eREST API\u201c oder \u201eFrontmatter\u201c gehört hast.<\/p>\n\r\n\n

Kurzfassung<\/h2>\n\r\n\n
    \r\n\n
  1. Schreiben<\/strong> passiert in einer Datei (.md<\/code>), nicht zwingend im WordPress-Editor.<\/li>\n\r\n\n
  2. Ein PowerShell-Skript<\/strong> übersetzt den Text in das Format, das WordPress intern für den Block-Editor braucht, und legt einen Entwurf<\/strong> an oder aktualisiert ihn.<\/li>\n\r\n\n
  3. Veröffentlichen<\/strong>, Titelbild und letzte Korrekturen mache ich bewusst selbst<\/strong> im WordPress-Backend \u2014 nichts geht ohne meinen Klick live.<\/li>\n\r\n<\/ol>\n\r\n\n

    Der Rest des Textes geht in die Tiefe: Begriffe, Motivation, Ablauf, Grenzen und (am Ende) die technische Karte für Entwickler.<\/p>\n\r\n\n

    Was WordPress hier überhaupt ist<\/h2>\n\r\n\n

    WordPress<\/strong> ist die Software hinter fabricioruch.ch<\/a>: Sie speichert Beiträge, Kategorien, Tags, Bilder und liefert die Seiten aus. Man spricht oft von einem CMS<\/strong> (Content-Management-System) \u2014 einer Verwaltungsoberfläche für Inhalte, ohne dass jeder Artikel handcodiertes HTML sein muss.<\/p>\n\r\n\n

    Für Autoren gibt es das Backend<\/strong> (wp-admin): Login, Beitragsliste, Editor. Für Besucher gibt es das Theme<\/strong> \u2014 das Aussehen (Typografie, Abstände, Code-Blöcke, Kategorie-Navigation). Mein Theme liegt im gleichen Git-Repository wie die Skripte; der Blog bleibt also \u201eWordPress\u201c, nicht eine komplett separate Website.<\/p>\n\r\n\n

    Wie ein Artikel \u201enormalerweise\u201c entsteht<\/h2>\n\r\n\n

    Der Block-Editor<\/strong> (seit WordPress 5 auch Gutenberg<\/strong> genannt) zeigt den Text als Blöcke<\/strong>: Absatz, Überschrift, Liste, Code, Bild, Tabelle, \u2026 Jeder Block hat Einstellungen in der Seitenleiste. Das ist flexibel und für viele Autoren genau richtig.<\/p>\n\r\n\n

    Typischer Ablauf:<\/p>\n\r\n\n

      \r\n\n
    1. Im Backend \u201eBeitrag erstellen\u201c.<\/li>\n\r\n\n
    2. Titel und Blöcke im Editor bauen.<\/li>\n\r\n\n
    3. Kategorie und Schlagwörter wählen.<\/li>\n\r\n\n
    4. Vorschau ansehen.<\/li>\n\r\n\n
    5. Veröffentlichen oder als Entwurf speichern.<\/li>\n\r\n<\/ol>\n\r\n\n

      Entwurf<\/strong> (draft<\/code>) bedeutet: Der Beitrag ist gespeichert, aber für normale Besucher noch nicht sichtbar (nur mit spezieller Vorschau oder als eingeloggter Autor). Genau diesen Status setzt mein Import \u2014 bewusst, damit nichts versehentlich live geht.<\/p>\n\r\n\n

      Was ich anders mache \u2014 und warum<\/h2>\n\r\n\n

      Ich schreibe viele technische Texte wie Quellcode<\/strong>: in Git<\/strong> versioniert, mit klaren Zeilenänderungen (git diff<\/code>), oft zusammen mit Theme- oder Skript-Änderungen. Dafür eignet sich Markdown<\/strong> besser als Klicken im Editor.<\/p>\n\r\n\n

      Markdown<\/strong> ist eine einfache Schreibweise für strukturierten Text: ##<\/code> für Zwischenüberschriften, **fett**<\/code>, Listen mit -<\/code>, Code in Zeilen mit drei Backticks, Tabellen mit |<\/code>. Die Datei bleibt lesbar als Plain Text<\/strong> \u2014 in VS Code, Cursor oder jedem Editor.<\/p>\n\r\n\n

      \r\n\r\n\r\n\r\n\r\n\r\n\r\n
      Was ich brauche<\/th>\r\nBlock-Editor allein<\/th>\r\nMarkdown-Datei + Import<\/th>\r\n<\/tr><\/thead>\r\n
      Änderungen nachvollziehen<\/td>\r\nWordPress-Revisionen; schwer mit Code zu vergleichen<\/td>\r\nGit zeigt jede Zeile<\/td>\r\n<\/tr>\r\n
      Text von KI \/ Skript erzeugen<\/td>\r\nCopy-Paste, Format geht kaputt<\/td>\r\nAgent schreibt eine Datei<\/td>\r\n<\/tr>\r\n
      Gleichen Artikel erneut hochladen<\/td>\r\nManuell im Editor nachziehen<\/td>\r\nGleicher Dateiname\/Slug \u2192 Update<\/td>\r\n<\/tr>\r\n
      Lesen wie auf der Website<\/td>\r\nVorschau im Backend<\/td>\r\nEntwurf im echten Theme nach Import<\/td>\r\n<\/tr>\r\n
      Kategorien & Tags<\/td>\r\nPer Klick<\/td>\r\nIn der Datei als Metadaten<\/td>\r\n<\/tr>\r\n<\/tbody><\/table><\/figure>\n\r\n\n

      Das ist nicht<\/strong> \u201eWordPress abschaffen\u201c. Besucher merken nichts. Es ist nur ein anderer Eingang<\/strong> für die Artikel, die ich schon im Repository denke.<\/p>\n\r\n\n

      Content-as-Code<\/strong> heißt hier schlicht: Der Entwurf ist eine Datei im Projekt \u2014 ähnlich wie Konfiguration oder Tests \u2014 nicht nur ein Eintrag in der Datenbank. Live-Schalten bleibt eine bewusste menschliche Entscheidung im Backend.<\/p>\n\r\n\n

      Begriffe, die im Text vorkommen<\/h2>\n\r\n\n
      \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
      Begriff<\/th>\r\nKurz erklärt<\/th>\r\n<\/tr><\/thead>\r\n
      Slug<\/strong><\/td>\r\nDer URL-Teil des Beitrags, z.\u202fB. markdown-entwuerfe-wordpress-ohne-block-editor<\/code>. Sollte stabil bleiben, wenn du denselben Artikel aktualisierst.<\/td>\r\n<\/tr>\r\n
      Frontmatter<\/strong><\/td>\r\nMetadaten oben in der Datei<\/strong> zwischen ---<\/code> Zeilen: Titel, Slug, Kategorien, Tags. Kein Markdown, sondern YAML (eine listenfreundliche Konfigurationssyntax).<\/td>\r\n<\/tr>\r\n
      Kategorie<\/strong><\/td>\r\nGrobe Einordnung im Blog (hierarchisch, z.\u202fB. System Engineering \u2192 Automation). Im Theme zählt die erste<\/strong> Kategorie in der Liste als \u201eHaupt\u201c-Kategorie.<\/td>\r\n<\/tr>\r\n
      Tag<\/strong><\/td>\r\nFeineres Schlagwort (z.\u202fB. wordpress<\/code>, field-note<\/code>). Keine ><\/code>-Pfade wie bei Kategorien.<\/td>\r\n<\/tr>\r\n
      Taxonomie<\/strong><\/td>\r\nSammelwort für Kategorien und Tags \u2014 die \u201eSchubladen\u201c des Blogs.<\/td>\r\n<\/tr>\r\n
      REST API<\/strong><\/td>\r\nEine HTTP-Schnittstelle, mit der Programme Beiträge lesen\/schreiben können \u2014 statt nur der Maus im Browser.<\/td>\r\n<\/tr>\r\n
      Application Password<\/strong><\/td>\r\nEin von WordPress erzeugtes App-Passwort<\/strong> (nicht dein Login-Passwort), nur für Skripte. Liegt lokal in einer Datei, die nicht<\/strong> ins Git kommt.<\/td>\r\n<\/tr>\r\n
      Gutenberg \/ Blöcke<\/strong><\/td>\r\nWordPress speichert Inhalt intern als Blöcke mit speziellen HTML-Kommentaren. Der Import muss dieses Format treffen, sonst warnt der Editor.<\/td>\r\n<\/tr>\r\n
      Dry-Run<\/strong><\/td>\r\nSkript läuft durch, schreibt aber nichts<\/strong> \u2014 du siehst nur, was passieren würde<\/em>.<\/td>\r\n<\/tr>\r\n
      Preflight<\/strong><\/td>\r\nAutomatische Checks im Repository (Tests, Theme-Regeln), bevor etwas deployt wird.<\/td>\r\n<\/tr>\r\n<\/tbody><\/table><\/figure>\n\r\n\n

      Wenn du nur lesen<\/strong> willst, reichen Einleitung, Begriffe, Ablauf und \u201eWas bleibt manuell\u201c \u2014 der Abschnitt Technische Vertiefung<\/strong> ist für Menschen, die selbst am Repository arbeiten.<\/p>\n\r\n\n

      Von der Datei zum WordPress-Entwurf (Schritt für Schritt)<\/h2>\n\r\n\n

      Stell dir drei Stationen vor:<\/p>\n\r\n\n

        [1] Textdatei auf dem PC          [2] Skript auf dem PC           [3] WordPress (Server)\r\n      content\/drafts\/mein-post.md  \u2192  import-post-draft.ps1      \u2192   Beitrag als Entwurf\r\n      Titel, Kategorien, Markdown     übersetzen & prüfen            im Backend sichtbar<\/code><\/pre>\n\r\n\n
      Station 1: Die Datei anlegen<\/h3>\n\r\n\n
      Die Arbeitskopie liegt unter content\/drafts\/<\/code> (bewusst nicht<\/strong> im öffentlichen Git \u2014 Entwürfe sind privat auf der Festplatte). Oben steht das Frontmatter, darunter der Artikeltext in Markdown.<\/p>\n\r\n\n
      Ein minimales<\/strong> Beispiel (nur zur Illustration):<\/p>\n\r\n\n
      ---\r\ntitle: "Kurznotiz: REST-Route"\r\nslug: kurznotiz-rest-route\r\ncomments: closed\r\ncategories:\r\n  - "System Engineering > Automation"\r\ntags:\r\n  - field-note\r\n  - german\r\n---\r\n\r\n## Ein Abschnitt\r\n\r\nEin Absatz Text. Keine Überschrift mit einer einzelnen `#` Zeile \u2014 der **Titel** oben im Frontmatter ist die einzige H1; das Theme zeigt sie auf der Seite.<\/code><\/pre>\n\r\n\n
      Kommentare<\/strong> sind bei mir standardmäßig geschlossen<\/strong> (comments: closed<\/code>), außer ich schreibe explizit open<\/code>.<\/p>\n\r\n\n
      Station 2: Skript ausführen (erst ohne Schreiben)<\/h3>\n\r\n\n
      Im Projektordner (PowerShell):<\/p>\n\r\n\n
      pwsh .\/scripts\/content\/cmd\/import-post-draft.ps1 -Path content\/drafts\/mein-post.md<\/code><\/pre>\n\r\n\n
      Ohne Zusatzflag ist das ein Dry-Run<\/strong>: Du siehst u.\u202fa. welche Kategorie-IDs gesetzt würden, wie lang der Inhalt ist, ob ein neuer<\/strong> Entwurf oder ein Update<\/strong> ansteht. Nichts wird an WordPress geändert.<\/p>\n\r\n\n
      Wenn die Ausgabe passt, kommt der echte Upload (Produktion nur mit extra Bestätigung):<\/p>\n\r\n\n
      pwsh .\/scripts\/content\/cmd\/import-post-draft.ps1 `\r\n  -Path content\/drafts\/mein-post.md `\r\n  -Apply -AllowProduction<\/code><\/pre>\n\r\n\n
      -AllowProduction<\/code> ist eine Sicherheitsleine<\/strong>: Das Skript verweigert sonst Schreibzugriffe auf die Live-Website \u2014 damit ein Tippfehler im Terminal nicht sofort den echten Blog überschreibt.<\/p>\n\r\n\n
      Lokal testen<\/strong> (WordPress in Docker auf dem Rechner) geht mit anderer URL und anderer Credential-Datei \u2014 siehe docs\/development\/local-development.md<\/code>.<\/p>\n\r\n\n
      Station 3: Im Backend fertig machen<\/h3>\n\r\n\n
      Nach erfolgreichem Import:<\/p>\n\r\n\n
        \r\n\n
      1. Im WordPress-Backend den Entwurf<\/strong> öffnen.<\/li>\n\r\n\n
      2. Prüfen, ob der Block-Editor keine<\/strong> Meldung \u201eungültiger Block\u201c zeigt.<\/li>\n\r\n\n
      3. Beitragsbild<\/strong> (Featured Image) setzen \u2014 das macht das Skript (noch) nicht.<\/li>\n\r\n\n
      4. Vorschau<\/strong> im echten Theme: Code, Tabellen, Fußnoten.<\/li>\n\r\n\n
      5. Veröffentlichen<\/strong> \u2014 oder als Entwurf lassen.<\/li>\n\r\n<\/ol>\n\r\n\n
        So bleibt die redaktionelle Kontrolle<\/strong> bei mir; das Skript ist Transport und Formatierung, nicht der rote Knopf \u201elive\u201c.<\/p>\n\r\n\n
        Was das Skript intern tut (ohne Code lesen zu müssen)<\/h2>\n\r\n\n
        In groben Worten:<\/p>\n\r\n\n
          \r\n\n
        1. Datei lesen<\/strong> und Frontmatter von Body trennen.<\/li>\n\r\n\n
        2. Prüfen<\/strong> (z.\u202fB. Pflichtfelder, kaputte Fußnoten, gefährliche Link-Arten).<\/li>\n\r\n\n
        3. Markdown in Block-Markup umwandeln<\/strong> \u2014 nicht nur \u201eHTML\u201c, sondern das spezielle Gutenberg-Format mit Kommentaren wie <!-- wp:paragraph --><\/code>.<\/li>\n\r\n\n
        4. Kategorien und Tags auflösen<\/strong> (existieren sie? sonst optional anlegen \u2014 mit denselben Regeln wie andere Taxonomie-Skripte im Repo).<\/li>\n\r\n\n
        5. Per REST API<\/strong> den Beitrag als Entwurf anlegen oder aktualisieren.<\/li>\n\r\n\n
        6. Merken<\/strong>, welche WordPress-Post-ID zu welchem Slug gehört (lokale Datei .import-log.json<\/code>, gitignored), damit ein erneuter Import denselben Beitrag aktualisiert statt einen Duplikat anzulegen.<\/li>\n\r\n<\/ol>\n\r\n\n
          Wenn ein Beitrag schon veröffentlicht<\/strong> war, wird er beim Update nicht<\/strong> automatisch wieder auf \u201eEntwurf\u201c zurückgestellt \u2014 das Skript ändert den Status dann nicht.<\/p>\n\r\n\n
          Was bewusst nicht<\/em> automatisiert ist<\/h2>\n\r\n\n
          \r\n\r\n\r\n\r\n\r\n\r\n
          Thema<\/th>\r\nWarum manuell<\/th>\r\n<\/tr><\/thead>\r\n
          Veröffentlichen<\/strong><\/td>\r\nKein versehentliches Live-Schalten durch Skript oder CI<\/td>\r\n<\/tr>\r\n
          Beitragsbild<\/strong><\/td>\r\nBildauswahl und Rechte sind redaktionell<\/td>\r\n<\/tr>\r\n
          Letzte Feinheiten im Editor<\/strong><\/td>\r\nManchmal ein Wort, ein Block-Abstand \u2014 schneller im Auge als in Regeln<\/td>\r\n<\/tr>\r\n
          Vollständiges \u201ejedes Markdown der Welt\u201c<\/strong><\/td>\r\nNur die Formate, die der Konverter und das Theme sauber darstellen<\/td>\r\n<\/tr>\r\n<\/tbody><\/table><\/figure>\n\r\n\n
          Plugins vom Typ \u201eMarkdown einfügen und fertig\u201c habe ich nicht<\/strong> als Kernlösung gewählt: Ich will Regeln, Tests und Agent-Briefings im gleichen Repository<\/strong> wie Theme und Skripte \u2014 nicht eine Blackbox im WordPress-Plugin-Verzeichnis.<\/p>\n\r\n\n
          Warum der Block-Editor trotzdem wichtig bleibt<\/h2>\n\r\n\n
          WordPress erwartet<\/strong> für viele Inhalte Blöcke<\/strong>, nicht beliebiges HTML in einem Rutsch. Wenn der Import nur <p>Hello<\/p><\/code> schreibt, ohne die Block-Kommentare, kann der Editor warnen oder alles in einen \u201eklassischen\u201c Block packen \u2014 unhandlich für spätere Bearbeitung.<\/p>\n\r\n\n
          Deshalb baut die Pipeline editor-taugliche<\/strong> Blöcke: Absätze, Überschriften, Listen, Code, Tabellen, Bilder, Trennlinien, Zitate. Das kostet Wartung (WordPress-Updates, Serialisierung), aber der Entwurf sieht im Backend aus wie ein normal geschriebener Post<\/strong>.<\/p>\n\r\n\n
          Praxis-Tipp für Neugierige:<\/strong> Code-Blöcke werden absichtlich schlicht<\/strong> importiert (ohne extra Sprach-Attribut im Block), weil mein Editor sonst \u201eungültiger Inhalt\u201c meldete; die Syntax-Farben auf der Website<\/strong> kommen vom Theme (code-highlighting.js<\/code>), nicht zwingend vom Editor.<\/p>\n\r\n\n
          Workflow mit KI (Cursor o.\u202fÄ.) \u2014 in Alltagssprache<\/h2>\n\r\n\n
            \r\n\n
          1. Ich gebe Kontext aus einer Briefing-Datei im Repo (Sprache, Art des Posts, Kategorie-Vorschläge).<\/li>\n\r\n\n
          2. Der Assistent erzeugt oder erweitert eine .md<\/code>-Datei unter content\/drafts\/<\/code>.<\/li>\n\r\n\n
          3. Ich lese die Änderung wie bei Code (Diff<\/strong>), korrigiere Frontmatter (z.\u202fB. erste Kategorie = Hauptkategorie).<\/li>\n\r\n\n
          4. Dry-Run, dann Apply.<\/li>\n\r\n\n
          5. Im Backend: Bild, Vorschau, Publish.<\/li>\n\r\n<\/ol>\n\r\n\n
            Die KI ersetzt<\/strong> nicht die Verantwortung fürs Veröffentlichen; sie beschleunigt<\/strong> das erste und zweite Entwerfen in einem Format, das das Skript versteht.<\/p>\n\r\n\n
            Typische Probleme (auch ohne Entwickler-Jargon)<\/h2>\n\r\n\n
            \r\n\r\n\r\n\r\n\r\n\r\n\r\n
            Was du siehst<\/th>\r\nWas es meist bedeutet<\/th>\r\n<\/tr><\/thead>\r\n
            Skript bricht mit \u201eFootnote\u201c ab<\/td>\r\nIm Text steht eine Fußnote ohne Erklärung am Ende der Datei<\/td>\r\n<\/tr>\r\n
            \u201eRefusing \u2026 production\u201c<\/td>\r\n-AllowProduction<\/code> fehlt beim echten Upload<\/td>\r\n<\/tr>\r\n
            \u201eSlug already exists\u201c<\/td>\r\nEs gibt schon einen Beitrag mit dieser URL; Import-Log oder -AdoptExistingSlug<\/code><\/td>\r\n<\/tr>\r\n
            Gelber Banner im Editor \u201eungültiger Block\u201c<\/td>\r\nFormat passt nicht zu WordPress \u2014 Pipeline anpassen oder Post im Editor bereinigen<\/td>\r\n<\/tr>\r\n
            Login schlägt fehl<\/td>\r\nApplication Password oder Benutzername in .env\/wp<\/code> prüfen (Login-Name, nicht Anzeigename)<\/td>\r\n<\/tr>\r\n<\/tbody><\/table><\/figure>\n\r\n\n
            Nach dem Anlegen neuer<\/strong> Kategorien oder Tags im Import lohnt sich im Repo noch ein Taxonomie-Audit \u2014 damit die Schubladen langfristig sauber bleiben.<\/p>\n\r\n\n
            Checkliste vor dem Veröffentlichen<\/h2>\n\r\n\n