Skip to content

Serendipity und das Markdown-Plugin

Bereits seit dem Relaunch meines Blogs anno 2014 nutze ich - wie schon berichtet - Markdown zur Eingabe meiner Blogbeiträge. Ich entwerfe sie in der Regel in einem externen Editor (MarkdownPad auf meinen Rechnern oder online mit Draft, wenn ich unterwegs bin) und kopiere sie dann in das Backend von Serendipity, getrennt in “Eintrag” und “erweiterter Eintrag”. Dabei nutze ich seit einigen Monaten “Eintrag” nur noch als Teaser, mit der Folge, dass die Beiträge auf der Startseite und bei Suchergebnissen auch nur noch “angeteasert” werden; bringt mehr Übersicht und eine handlichere Startseite, erfordert andererseits aber für jeden Beitrag einen weiteren Klick, um ihn zu lesen, ermöglicht es also nicht ohne weiteres, sich “an einem Stück” durch das Blogarchiv zu lesen.

Sei dem, wie dem sei - mir geht es heute um das Markdown-Plugin für Serendipity namens serendipity_event_markdown. Intern verwendet das Plugin PHP Markdown von Michel Fortin und bietet (aus mir nicht ganz klaren, wohl vor allem historischen Gründen) zwei Varianten (oder, wie es in der Konfiguration heißt: Versionen) des Markdown-Parsers an: einmal ein “klassisches” Plugin “für Wordpress, Smarty, etc.”, das aber durch den Autor seit Februar 2013 nicht mehr unterstützt wird, und die PHP Markdown Lib, die immerhin 2015 zuletzt released wurde. Auch werden zwei “Geschmacksrichtungen” unterstützt: das originale Markdown von John Gruber und eine erweiterte Version, PHP Markdown Extra, von Michael Fortin selbst, die - ähnlich wie MultiMarkdown oder GitHub Flavored Markdown - einige Erweiterungen unterstützt, namentlich Tabellen, Definitionslisten, HTML-IDs und -Klassen und Fußnoten.

Ich habe bisher immer die PHP Markdown Lib verwendet, mich aber darüber gewundert, dass - trotz Aktivierung von Markdown Extra in der Konfiguration - die erweiterten Funktionen nicht richtig umgesetzt wurden. Im Nachgang zum Serendipity-Camp 2017 hatte ich mir vergangene Woche dann einmal den entsprechenden Code des Plugins näher angesehen und den Grund für das Problem gefunden: das “klassische” Plugin stellt, je nach eingebundener Markdown-Geschmacksrichtung, über dieselben Funktionsaufrufe Markdown und Markdown Extra bereit, je nachdem. Die PHP Markdown Lib hingegen bietet zwei verschiedene Funktionsaufrufe; es muss also nicht nur die richtige Library eingebunden werden, es muss zusätzlich auch die Markdown-Extra-Funktion (und nicht die Markdown-Funktion) aufgerufen werden, damit die zusätzlichen Möglichkeiten von Markdown Extra zur Verfügung stehen.

Das habe ich dann im Code entsprechend umgesetzt und zugleich die derzeit aktuellste Version der PHP Markdown Lib in das Plugin eingebunden. Jetzt lassen sich endlich mit einfach Mitteln “Sprungmarken” im Text setzen und Fußnoten verwenden (und Tabellen usw. natürlich auch)!

Die Verwendung von Fußnoten zieht noch zwei weitere Probleme nach sich, die beide darin begründet liegen, dass die Fußnote im Text mit einem Link zum Fußnotentext hinterlegt wird und der Fußnotentext - am Ende des Beitrags eingefügt - dann einen Link zurück zur Fußnoten enthält. Eines der Probleme entsteht, wenn (bspw. auf der Startseite oder in einem Suchergebnis) mehrere Beiträge angezeigt werden, die Fußnoten enthalten. Dann gibt es nämlich mehrere identische Fußnoten (bspw. “1”) und damit auch mehrere identische Sprungmarken (IDs), und ein Klick auf die Fußnoten führt in der Regel zum falschen Fußnotentext, nämlich immer zu dem der ersten Fußnote “1” auf der Seite. Dieses Problem lässt sich lösen, indem die Fußnotenlinks jeweils um die interne Nummer des Beitrags ergänzt werden, zu dem sie gehören. Für die PHP Markdown Lib habe ich das implementiert; das “klassische” Plugin ermöglicht eine solche Funktionalität hingegen nicht (und müsste ggf. gepatcht werden, wenn man es nicht schlicht aus dem Code entfernen will, was m.E. näher liegt).

Das andere Problem ergibt sich aus der Designentscheidung, in Serendipity den “Eintrag” und den “erweiterten Eintrag” als getrennte Textfelder zu realisieren. Das führt dazu, dass auch für Plugins “Eintrag” und “erweiterter Eintrag” getrennte Textelemente sind, und dementsprechend Fußnoten im “Eintrag” an dessen Ende - also vor dem “erweiterten Eintrag” eingefügt werden. Andererseits hat das den Vorteil, dass man nicht das Problem von Wordpress und anderen Blogsystemen hat, die “Eintrag” und “erweiterten Eintrag” einfach durch eine spezielle Markierung wie <!-- more --> voneinander trennen; dann kann es nämlich passieren, dass man die Fußnote sieht, aber den Fußnotentext nicht anspringen kann, da dieser hinter <!-- more --> steht und daher nicht angezeigt wird.

Insgesamt freue ich mich aber, dass Markdown Extra nun auch in Serendipity zuverlässig zur Verfügung steht.1 (Wie soll man auch bloß Texte verfassen können, ohne sie mit Dutzenden, ja Hunderten von Fußnoten zu schmücken?! Einem Juristen muss das schon von Berufs wegen völlig unverständlich sein.)


  1. Jedenfalls, sobald der entsprechende Pull Request akzeptiert wird. :-) ↩︎

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

onli am :

onli

Ich glaube, keiner von uns anderen nutzt wirklich Markdown, damit bist du der geeignetste Tester und Maintainer des Plugins. Wobei Markdown eigentlich die beste Wahl für ein Standard-Formatierungsplugin nach der Installation wäre.

Wie auch immer, der PR ist nun gemerged.

Thomas Hochstein am :

Thomas Hochstein

Wie auch immer, der PR ist nun gemerged.

Danke!

Germo Görtz am :

Germo Görtz

ich würde auch gerne MarkDown in s9y verwenden (bin ganz neu bei s9y, erst seit letztem Wochenende), weil ich keine brauchbare Methode finde, Code mit dem WYSIWYG Editor als Code zu markieren (Zeilenumbrüche werden entfernt, da gibt es nur ein "wrap code").

Markdown wäre also eine Lösung, meine WIKI’s schreibe ich ja auch alle in Markdown, und das funktioniert sehr gut. Was mich allerdings stört: Markdown zusammen mit WYSIWYG funktioniert nicht, also muss man das abschalten. Dann bleibt aber nur ein extrem rudimentärer Editor übrig. Also müsste man alles erst in einem externen Editor in Markdown erstellen (Visual Studio Code nehme ich dafür oft). Aber das kann doch nicht der Weg sein? Oder erstellst du deine Markdown Texte auch immer noch mit externen Editoren? Gibt es da nichts brauchbares in s9y, um direkt dort etwas einfacher Markdown zu erstellen?

Thomas Hochstein am :

Thomas Hochstein

Was mich allerdings stört: Markdown zusammen mit WYSIWYG funktioniert nicht, also muss man das abschalten.

Das ist vermutlich richtig, der WYSIWYG-Editor setzt darauf, dass man ihn benutzt, und er erzeugt im Hintergrund HTML; das ist mit dem Markdown-Plugin nicht kompatibel.

Dann bleibt aber nur ein extrem rudimentärer Editor übrig. Also müsste man alles erst in einem externen Editor in Markdown erstellen (Visual Studio Code nehme ich dafür oft). Aber das kann doch nicht der Weg sein?

Im Grundsatz würde ich sagen schon; typischerweise verwendet man doch entweder einen WYSIWYG-Editor oder eine Markup-Sprache wie HTML, Markdown, Textile, BBCode oder Wikimarkup. Das ist ja auch bei der Wikipedia nicht anders; entweder man editiert mit dem "visuellen" Editor, oder man editiert den Quellcode. Der Unterschied zum WYSIWYG-Editor bei s9y ist eigentlich nur, dass der im Hintergrund alles in HTML umwandelt und nicht in das Wikipedia-Markup. Eigentlich ist Markdown vom Konzept her ja auch dafür gedacht, möglichst einfach "mit der Hand" geschrieben werden zu können.

Der andere Punkt ist natürlich, dass der WYSIWYG-Editor bei s9y ein echtes Sorgenkind ist. Der bräuchte dringend etwas Liebe - das wird allerdings dadurch nicht erleichtert, dass ihn m.W. keiner der Entwickler selbst nutzt …

Oder erstellst du deine Markdown Texte auch immer noch mit externen Editoren?

Das tue ich (fast immer) tatsächlich; das liegt allerdings nicht am s9y-Editor, ich mache das prinzipiell so, auch früher bei Wordpress und jetzt bei Ghost, die sehr fortgeschrittene Editoren haben, die alles mögliche irgendwie ineinander umwandeln. Das ist allerdings nicht mein Ding; ich möchte gerne, dass an dem von mir erstellten Text niemand mehr herumfummelt und ihn umformatiert. Gerade bei Wordpress habe ich da einige Erlebnisse der dritten Art gehabt; erstellt war der Text in Markdown, und so wurde er auch gespeichert. Irgendwann war das Markdown aber plötzlich fast überall in HTML umgewandelt, das gefiel mir nicht so sehr. Insbesondere blöd, wenn man den Text gerne exportieren würde (und zwar in der ursprünglichen Form). :-/

Gibt es da nichts brauchbares in s9y, um direkt dort etwas einfacher Markdown zu erstellen?

Ich denke nicht, dass es sinnvoll umsetzbar ist, Editoren vorzuhalten, die mit HTML, Markdown, Textile und Co. als Ausgabe umgehen können. Das Ziel sollte m.E. sein, einen stabil funktionierenden (!!) WYSIWYG-Editor vorzuhalten, mit dem man alle darstellen kann, was üblicherweise in einem Blog zu erwarten ist (ja, natürlich auch Code!), und alternativ einen einfachen Editor, in dem man den Quellcode für die Markup-Plugins eingeben kann.

Germo Görtz am :

Germo Görtz

Dann bin ich also nicht der erste, der über die Funktionalität des WYSIWYG Editors gestolpert ist. Der Vorteil ist, man kann auch bestehende formatierte Texte reinkopieren und es passt. Code habe ich aber oft, und wenn das nicht funktioniert, dann nutzt mir der Wysiwyg Editor nicht viel.

Und natürlich ist Markdown extra so, dass man das von Hand schreiben kann. Allerdings bin ich eben doch auch einige Markdown Editoren gewohnt, die die Formatierung etwas vereinfachen.

Ich muss mal sehen, was bei mir einfacher funktioniert: Markdown, oder vielleicht gibt einen anderen brauchbaren WYSIWYG Editor, mit dem man Code formatieren kann.

mitch am :

mitch

Wenn Du viel Code im Blog hast, schau Dir mal das geshi-Plugin an, das kann Syntax-Highlighting. Vermutlich ist das aber auch nicht in den WYSIWYG-Editor eingebunden (ich kenn den gar nicht).

Ich selbst schreibe meine Artikel in Emacs/Orgmode und hab mir einen eigenen Exporter nach s9y-HTML gebastelt (mit geshi-Tags für Code, aber noch ohne Mediendatenbank-Anbindung). Das kopiere ich dann einfach in das Textfeld ;-)

Wenn Du bereit bist, Orgmode als "so ähnlich wie WYSIWYG" zu sehen, kann es prinzipbedingt mehr als alle echten WYSIWYG-Editoren.

Germo Görtz am :

Germo Görtz

Ich habe den WYSIWYG Editor wieder abgeschaltet, obwohl das alles durch yellowled ganz schnell gefixt wurde.

Meine Artikel werde ich in MarkDown schreiben, funktioniert sehr gut, die Artikel sind auch ohne WYSIWYG Editor gut zu bearbeiten und zu lesen. Wenn man einen WYSIWYG-Editor verwendet, dann braucht man den auch zum Lesen, weil ja dann der Artikel in HTML gespeichert wird.

Der Editor ist zwar limitiert, aber so viele verschiedene Elemente verwende ich ja auch nicht, das kann man manuell schreiben. Die Syntax zum Einbinden von Bildern, für Links usw. muss man sich dann eben merken. Bisher funktioniert es sehr gut und gefällt mir besser, als WYSIWYG.

Was mir normalerweise gut gefällt, wenn ich irgendwo in Markdown schreibe, und was für s9y schön wäre, ist eine sofortige Live-Anzeige eines Preview. Sei es nun mit Visual Studio Code oder in einer WIKI online, wenn der Editor das unterstützt.

Und was Code betrifft, so sind das bei mir wohl nur SQL Bestandteile, die lassen sich auch ohne Syntax-Highlighting ganz gut lesen. Vielleicht baue ich aber dafür auch mal ein Plugin ein. Dann müsste das aber direkt im Markdown erkennen, dass ich den code als SQL markiere, etwa so:

Select
   a
  ,b
FROM
   qwertz

und wie ich sehe, hast du die eweiterten MarkDown Eigenschaften im Plugin nicht aktiviert, sonst würde obiger Code mit Zeilenumbrüchen angezeigt werden. Kannst du ja mal einschalten.

mitch am :

mitch

Es gibt Browser-Plugins, mit denen Du ein Textfeld aus dem Browser live in einen richtigen Texteditor spiegeln und dort bearbeiten kannst. Wenn der Texteditor eine Live-Vorschau für Markdown hat, kannst Du die nutzen.

Für z.B. Atom und Sublime gibt es GhostText: https://github.com/GhostText/GhostText

Für emacs habe ich das mal beschrieben (bezüglich Live-Vorschau habe ich mich noch nicht umgeguckt): https://www.cgarbs.de/blog/archives/1172-Emacs-im-Browser.html

Thomas Hochstein am :

Thomas Hochstein

Es gibt Browser-Plugins, mit denen Du ein Textfeld aus dem Browser live in einen richtigen Texteditor spiegeln und dort bearbeiten kannst.

Das ist ja cool! Trotzdem glaube ich fast, dass mir das zu kompliziert ist und ich im Zweifel bei c&p bleiben werde …

Germo Görtz am :

Germo Görtz

Für z.B. Atom und Sublime gibt es GhostText: https://github.com/GhostText/GhostText

Danke für den Hinweis, das scheint auch für Visual Studio Code zu funktionieren, was ich für MarkDown mit Previw, Syntax-Prüfung, HTML-Export, Excel-Tabellen-Import usw. verwende.

Da werde ich jetzt auch mal dieses GhostText anschauen.

Germo Görtz am :

Germo Görtz

Habe ich mir angeschaut, die Verbindung mit Visual Studio Code funktioniert. Allerdings verwende ich das "Markdown All in One" plugin, und das zeigt einen PreView nur für Dateien mit der Endung ".md" an, GhostText erstellt aber temporäre Dateien mit der Endung ".tmp". Mal sehen, ob es dafür eine Lösung gibt…

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck