WP-Markdown

Vor einiger Zeit habe ich angefangen, Texte, die ich im Web veröffentlichen möchte, in Markdown zu formatieren. Ziemlich schnell habe ich bei Tumblr die Eingabe auf Markdown umgestellt. Bis auf kleine Hakeleien aufgrund von Schwächen von Tumblr geht das sehr gut. Gestern habe ich WP-Markdown installiert, um mein WordPress mit einer Markdown-Unterstützung zu versehen.

Eigentlich brauche ich keine Markdown-Unterstützung in WordPress. Den Entwurf dieses Postings schreibe ich mit iA Writer auf dem iPad. Die Datei landet in meiner Dropbox und kann von dort mit jedem beliebigen Editor (weiter)bearbeitet werden. Zum Schluss benötige ich nur noch eine Editor, der Markdown in HTML umwandeln kann (z.B. iA Writer), und paste das HTML ins Web-Backend von WordPress oder in das Eingabefeld einer WordPress-kompatiblen App. Et voilà!

Dennoch reitzte es mich, meinem WordPress Markdown zu verpassen. Zum Einen als Unterstützung bei der Überarbeitung von Artikel und der Erstellung von Kommentaren. Zum Anderen, ums es auszuprobieren.

Als die beste Erweiterung erscheint erschien mir das Plugin WP-Markdown. Es bietet eine Toolbar oberhalb des Eingabebereiches sowie eine Preview darunter.

WP-Markdown speichert nicht das eingegebene Markdown, sondern schreibt beim Speichern HTML in das entsprechende Feld der Datenbank. Sofern man einen bereits vorhandenen Artikel bearbeiten will, wird das HTML aus der Datenbank geladen und als Markdown aufbereitet.

Diese Vorgehensweise hat mir gleich bei der ersten Nutzung Probleme eingebracht. Ich wollte beim Artikel über die Verbindungsprobleme mit meinem Sonos ein Update hinzufügen. Beim Konvertieren des gespeicherten HTML nach Markdown sind einige der Absatztrennungen verloren gegangen. Ich musste das Layout des gesamten Artikel überprüft und teilweise die fehlenden “Absatzmarken” ergänzen. Kein guter Start.

Auch bietet mir die Toolbar zu wenig Funktionen. Es werden nur die Markdown-Optionen abgebildet. Die weitergehenden Optionen des eingebauten HTML-Editors oder gar des WYSIWYG-Editors fehlen. Nicht, dass ich sie viel nutzen würde, aber wenn man sie braucht, dann braucht man sie auch wirklich.

Die Link-Funktion des eingebauten Editors bietet die Möglichkeit des Vorgabe eine Link-Titels sowie eine Auswahlliste mit Artikeln des Blogs (Es lebe die Selbstbezüglichkeit!). WP-Markdown bietet nichts Entsprechendes.

Ich habe daher WP-Markdown für die Erstellung von Artikeln und Seiten wieder deaktiviert. Mein bisheriger Workflow erlaubt mir die Nutzung von Markdown bis zur Übernahme in WordPress. Für das letzte Polishing ist der WYSIWYG-Editor vielleicht sogar die bessere Wahl.

Bei den Kommentaren lasse ich WP-Markdown (zunächst noch) aktiviert (allerdings mit deaktivierter Toolbar). Hier würde ich mir wünschen, dass das Aktivieren für Gäste und registrierte Nutzer getrennt vorgenommen werden könnte. (Genauso fehlt mir eine per User Aktivierung.)

1 thought on “WP-Markdown

  1. -thh

    Das aktuelle Jetpack-Plugin beherrscht auch Markdown; dabei hat es den Charme, Quelle (in Markdown) und Ausgabeformat (HTML) getrennt zu speichern. So ist eine – fehlerbehaftete – Rückkonvertierung nicht erforderlich, im Editor wird immer die Quelle angezeigt. Dennoch wird der Beitrag in HTML gespeichert, was einerseits die Notwendigkeit einer Konvertierung für jeden Aufruf vermeidet und zum anderen eine Rückfallebene darstellt, wenn das Plugin einmal deinstalliert wird.

    Was den Editor angeht: Markdown hat für mich gerade den Charme, dass man es flüssig selbst schreiben kann, ohne sich mit HTML-Tags abquälen zu müssen. Daher ersetzt Markdown für mich gerade die Notwendigkeit eines gesonderten Editors mit entsprechenden Schaltflächen und vermeidet insbesondere WYSIWYG-Editoren, bei denen man nie so genau weiß, was sie als Ausgabe erzeugen (und wie standardkonform das ist). Insofern stört noch das Fehlen eines ausgefeilten Editors dann nicht. (Der zweite Vorteil von Markdown ist die gute Lesbarkeit des Quellformats; der dritte Vorteil, dass sich die Quelltexte deshalb gut in einem Versionsverwaltungssystem speichern lassen, spielt in einem Blogsystem/CMS er ebenso wenig eine Rolle wie der vierte Vorteil der Konvertierung in andere Ausgabeformate.)

    Für einen Workflow, bei dem ich die Textquellen außerhalb des Blogs nicht nur – manchmal – editiere, weil ich die Vorteile eines echten Texteditor nutzten möchte, sondern sie auch extern verwaltet und sie dann – ggf. nach Konvertierung in ein Ausgabeformat – ins Blog einkopiere, konnte ich mich bisher nicht entscheiden. Wenn ein solcher Workflow besteht, sollte man aber ernsthaft erwägen, das Blog von einem Blogsystem/CMS umzustellen auf einen statischen Seitengenerator (nanoc, Jekyll und wie sie alle heißen). Je nach Postingfrequenz und Maß der Interaktivität kann sich das lohnen. „Dynamische“ Anwendungen wie Kommentare müssen dann natürlich extern, bspw. über Disqus, gelöst werden. Solange man ändert nicht das ganze Blog mit Web 2.0 vollgestopft hat, kann das ein gangbarer Weg sein. Vorteil ist der Entfall der ganzen schwergewichtigen Technik (Blogsystem, Datenbank, dynamische Seitengenerierung) und die einfache Erstellung und Verwaltung der Beiträge mit externen, eigenen Tools, die optimal auf die eigenen Bedürfnisse zugeschnitten sind (Editoren, Versionsverwaltung, pp.) sowie die weitgehende Kontrolle über die Abläufe. Nachteil ist die Notwendigkeit, vieles, was Plugins bieten, anders und dann oft selbst implementieren zu müssen (wobei gerade für die Umwandlung von Quell- in Ausgabeformate eine reichhaltige Toolchain vorhanden ist, gerade wenn man lieber „native“ Lösungen wie Multimarkdown anwendet statt spezialisierter Plugins) – und natürlich der Wegfall interaktiver Elemente, die allerdings – meiner Erfahrung nach – nicht selten in ihrer Bedeutung überschätzt werden.

    Danke jedenfalls für die interessanten Beiträge und Einblicke!

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kommentare abonnieren

Es erfolgt keine Weitergabe von Daten an externe Dienste wie WordPress.com.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.