markdown links with parentheses 29. Jan 2009

Wer beim Verfassen von Webinhalten nicht mit unhandlichem HTML-Konstrukten hantieren möchte und darüber hinaus sicherstellen möchte, dass seine Website aus validem HTML-Code besteht, der benutzt in aller Regel Textile oder Markdown um seine Texte zu formatieren. Für letztere Auszeichnungssprache gibt es bekanntermaßen zwei Möglichkeiten Links zu formatieren.


[Beispieltext](http://beispiel.com/)
[Beispieltext][1]
[1]:http://www.beispiel.com/

Das ist alles wunderbar solange man keine Klammern verwendet. Wenn man jedoch bei der ersten Syntax eine schließende Klammer oder bei letzterer Syntax eine öffnende oder schließende Klammer in der URL verwendet dann wird die Umsetzung von Markdown in HTML gestört. Nehmen wir mal an ich würde ein Posting über die neue Platte der Stars verfassen und dabei auf den Wikipedia-Artikel verlinken wollen, dann könnte ich folgendes versuchen:


[Stars](http://en.wikipedia.org/wiki/Stars_(band))
[Stars][1]
[1]:http://en.wikipedia.org/wiki/Stars_(band)

Das Resultat des HTML-Rendering für die jeweiligen URLs wäre wie folgt:

<a href="http://en.wikipedia.org/wiki/Stars_(band">Stars</a>)
<a href="http://en.wikipedia.org/wiki/Stars_" title="band">Stars</a>

Es sind offensichtlich die URLs bei den Klammern abgeschnitten. Um das Problem zu beheben kann man einfach eine manuelle URL-Kodierung durchführen. Man ersetzt einfach die öffnende Klammer durch %28 und die schließende Klammer durch %29 und dann klappts auch mit dem HTML-Rendering.


[Stars](http://en.wikipedia.org/wiki/Stars_%28band%29)
[Stars][1]
[1]:http://en.wikipedia.org/wiki/Stars_%28band%29

Ergibt folgendes:

<a href="http://en.wikipedia.org/wiki/Stars_%28band%29">Stars</a>
<a href="http://en.wikipedia.org/wiki/Stars_%28band%29">Stars</a>

Das nächste mal lernen wir dann wie man referentielle Links in Codeblöcke einfügt ohne dass diese als solche interpretiert werden.

 

why i chose dokuwiki over junebug 10. Feb 2008

Okay, der Vergleich ist nicht ganz fair. Dokuwiki ist produktionstauglich und Junebug ist Alpha. Nichtsdestotrotz mußten sich diese beiden Kandidaten im Laufe der letzten Tage bei mir beweisen. Trotz derer Verschiedenheit bin ich je nach Laune zwischen den beiden hin- und hergeschwankt. Mal wieder ein nettes Feature dort entdeckt und gedacht es wäre ein Alleinstellungsmerkmal, dann gesehen, dass es das auch beim anderen Kandidaten gibt. Mal wieder einen Bug dort entdeckt und gedacht okay, das ist nun wirklich ein KO-Kriterium und dann doch sich dazu hinreißen zu lassen mal in den Quellcode zu schauen und dabei festzustellen, dass zwei Einzeiler das Problem lösen. Welcher Syntax ist nun besser lesbar, welches Defaultlayout hübscher anzusehen ?

Die Ausgangssituation beim Vergleich war ein installiertes DokuWiki und eine gewisse Zufriedenheit damit. Dann bin ich jedoch über sicherheitsrelevanten Beitrag in der Mailingliste gestolpert und da gingen bei mir gleich die PHP-Alarmglocken an. Im Anschluß dann die Frage: Gibt es nicht vielleicht doch eine brauchbare Ruby-Wiki-Lösung ? Nachdem Instiki und Pandora eingeschlafen waren, ergab sich bei mir erstmal eine gewisse Ratlosigkeit. Maurice stieß mich dann in den Kommentaren auf Junebug. Die offizielle Website ist zwar leider immer noch nicht erreichbar, aber es gibt einen Gem und ein Repository bei RubyForge.

Das einzige wirkliche Argument gegen DokuWiki war also, dass es in PHP entwickelt wird, womit sich auch gleichzeitig das größte Proargument für Junebug ergibt, nämlich dass es in Ruby entwickelt wird. Symphathiepunkte gibts bei Junebug außerdem für das Defaultlayout, was schön minimalistisch ist und Textile als Markupsprache ab Werk. Kommen wir aber nun mal zu Nachteilen von Junebug. Erstens es ist Alpha, solange man sich verhält wie der Entwickler das gerne hätte, dann ist es okay, aber sobald man etwas “falsches” macht gibt’s gerne mal eine Fehlermeldung. Man kann keine Unterwikis oder Namespaces anlegen. Es gibt kein Syntax-Highlighting. Es gibt Einschränkungen bei den Seitennamen. Das CSS ist noch nicht wirklich ausgefeilt, es gibt Darstellungsfehler im Safari. Die Überschriften sind keine Anchor. Junebug nutzt RedCloth mit all seinen Einschränkungen und Fehlern. Junebug basiert auf Camping, was eingeschlafen ist. Der aktuelle Gem-Release von Junebug ist nur unter zuhilfenahme des Repository lauffähig. Es gibt keine Mailingliste. Es gibt keine offizielle Website. Bug-Reports und Feature-Requests werden zur Zeit noch ignoriert. Es gibt eine verschwindend geringe aktive Nutzerschaft. Und was mich letzten Ende von der Benutzung abgebracht hat: Es gibt keine Möglichkeit Mediendateien hochzuladen.

Ich werde Junebug weiterhin beobachten um zu schauen, ob sich ein Reifeprozess abspielt, aber bis auf weiteres scheint mir DokuWiki die bessere Wahl zu sein.