dreitehabees kleine CMS-Geschichte

2002-2004: Blogger

Begonnen hat alles mit einem Blog bei Blogger. Blogger wurde kurz, nachdem ich mich angemeldet habe, von Google gekauft und ist (dadurch?) in einen Tiefschlaf verfallen, der anderen Systemen eine riesige Chance bot. Eines dieser Systeme war Movable Type.

2004: Movable Type

Movable Type war mir immer zu behäbig und langsam. Die Oberfläche war überladen und ich fand mich nie wirklich zurecht. Mit Blogger zu Bloggen war, wie wenn man mit einem gut vernetzten Kumpel spricht, der dann die Nachrichten seinen Freunden weitererzählt. Movable Type war eher ein älterer Herr mit einem großen Netzwerk an Kollegen. Die Nachrichtenübermittlung war langsam, aber stetig. Das war vielleicht professioneller, Spaß gemacht hat das aber ganz und gar nicht.

2004-2007: Textpattern

Während ich versuchte, mit Movable Type zurechtzukommen, tauchte ein neues Content Management System (CMS) auf, das versprach, schlanker, schneller und einfacher handhabbar zu sein: Textpattern. Ich lud es auf meinen Server, installierte es in nur wenigen Minuten und die Sache lief.

Textpattern ist ein hervorragendes und sehr sympathisches System. Es arbeitet mit Textile, einer Auszeichnungssprache, die das Verfassen und Formatieren von Texten für das Web erheblich vereinfacht. Für gewöhnlich muss man beispielsweise ein fettgeschriebenes Wort als <strong>Wort</strong> eintippen, mit Textile wurden die beiden <strong> durch ein Symbol ersetzt, wie es auch in Word verwendet wird; um etwas fettgeschrieben darzustellen, tippt man einfach *Wort* ein. Links, Tabellen, Fußnoten – alle häufig verwendeten Auszeichnungselemente wurden von Textile korrekt in HTML konvertiert. Das Schreiben war ein Genuss.

Der größte Vorteil von Textpattern wandelte sich in dessen größten Nachteil: Das System war “fertig”. Es brauchte nichts ergänzt zu werden und was es nicht bot, konnte mit Plugins hinzugefügt werden. Das Programm selbst wurde aber nicht weiterentwickelt, weil es dafür auch keinen Grund gab.

Im CMS-Umfeld jedoch wurde fleißig ein Release nach dem anderen veröffentlicht und irgendwann kam man sich als Textpattern-User etwas hintennach vor. Selbst die treuesten User kritisierten den Stillstand der Dinge. 2007 verlor Textpattern sehr viele User an WordPress, das besonders durch seine schier unendliche Zahl von Plugins und Themes und die kontinuierliche Weiterentwicklung immer mehr an Attraktivität gewann.

2007-2009: WordPress

2007 habe ich mich entschlossen, meine auf Textpattern basierende Seite auf ein neues System umzustellen und importierte die Inhalte in WordPress. WordPress wurde zu meinem neuen Hafen, wenngleich er weniger einem südfranzösischen Yachthafen (das war Textpattern), sondern mehr einem rotterdammer Lageplatz entsprach: Die Möglichkeiten waren praktisch unendlich, doch man musste mit einer hässlichen Oberfläche arbeiten.

Ein Zurück zu Textpattern war jedoch ausgeschlossen. Mittlerweile lag die Entwicklung still und es gab keine Anzeichen, dass das System zu neuem Leben erweckt werden würde. Dean Allen, der Mann hinter Textpattern, hatte das Projekt mittlerweile verlassen und beteiligte sich auch nicht mehr an den Diskussionen zur Zukunft von Textpattern. Was also blieb mir übrig, als bei WordPress zu bleiben? Gar nichts. Unglücklich war ich in dieser Zwangsehe aus Mangel an Alternativen gefangen. Ich habe das auch in mehreren Artikeln beklagt.

Seit 2009: Die Suche nach Alternativen

Der Widerwillen, mit dem ich WordPress benutzte, wurde größer und größer, bis ich 2009 aktiv mit der Suche nach Alternativen begann. Am eigenen Server selbst betriebene CMS kamen immer mehr aus der Mode. Facebook, Twitter und andere Plaudersysteme erlebten einen Aufschwung, während ein CMS- bzw. Blogsystem nach dem anderen für immer von der Bildfläche verschwand. Es gab nach wie vor keine Alternativen.

Sicher, es gab interessante Projekte einzelner “Kämpfer”, hier besonders zu nennen dasSimpleLog von Garrett Murray, doch sie alle versprachen keine Langlebigkeit. Diese Projekte waren nicht nur vom Gutdünken eines einzelnen oder eines (sehr) kleinen Teams abhängig, sondern auch von den finanziellen Mitteln dahinter. WordPress konnte sich durchsetzen, weil es aktiv von der Firma des Chefentwicklers - Automattic - weiterentwickelt, beworben, und in Form von WordPress.com finanziell gewinnbringend eingesetzt wurde. Gehosteten Lösungen gehörte die Zukunft, wurde mir mit einem Mal klar. Schade, eigentlich.

Es gab sehr viele gehostete Lösungen für die Anforderungen eines Bloggers. Viele davon verschrien, einige unbrauchbar, wieder andere mit so viel Werbung überladen, dass es peinlich war, dort auch nur ein einziges Wort abzuspeichern. Ein Dienst, der mit schlagartig sympathisch war, war und ist Tumblr.

2010-2011: Tumblr

Tumblr wird von einem kleinen Team betrieben und stellt momentan den besten Mix aus Benutzerfreundlichkeit, Einfachheit der Bedienung, Leistung und Möglichkeiten dar. Tumblr unterstützt Markdown, ein System, das Textile sehr ähnlich ist, von Haus aus. Tumblr blendet keine (unerwünschte) Werbung ein, ermöglicht es aber seinen Kunden/Mitgliedern, selbst Werbung auf den eigenen Seiten zu zeigen. Tumblr erlaubt die vollständige Anpassung der eigenen Designvorlage und bietet zudem eine große Anzahl fertiger Designvorlagen an. Es macht Spaß, mit Tumblr zu arbeiten. Tumblr ist wieder ein südfranzösischer Yachthafen!

Klar, es gibt Nachteile: Die Suchfunktion von Tumblr existiert praktisch nicht, die Darstellung des Archivs ist lächerlich, von Zeit zu Zeit (leider öfter als seltener) fallen die Server wegen Überlastung aus und wer glaubt, mit einer Site auf Tumblr bei Google gut gereiht zu werden, liegt falsch. Dennoch: Ich hatte noch nie so viel Spaß beim Bloggen und Posten wie auf Tumblr.

Ob kurze oder lange Texte, im südfranzösischen Yachthafen schreibt man besser gelaunt als am rotterdammer Lageplatz.

2011: WordPress.com

Mehrfaches Wechseln zwischen Tumblr und WordPress.com hat mich zu WordPress.com geführt. Tumblr, obwohl ich es nachwievor für einen Yachthafen halte, leistet bei weitem nicht, was ich mit all meinen Anforderungen an ein Content Management System habe. Das beginnt bei einer funktionierenden Suche und endet bei der Möglichkeit, Galeriebilder einzeln anzeigen zu können.

Plugins sind das CMS

In einem etwas älteren Artikel “Textpattern and WordPress take two very different routes to a release” stellt Andrew Travers völlig korrekt fest:

Like Drupal and others, WordPress and Textpattern rely on plugins to deliver much of what its users consider essential functionality. They aren’t a nice to have, they are a part of the CMS from the end-user’s perspective.

As such, the code quality of a CMS isn’t in reality judged by its fiercely protected core, but by its more widely used plugins.

Schlussstrich. Irgendwie halt.

Für meine Verhältnisse sehr lange hatte ich nun das zweispaltige, kottke-ähnliche Design auf 3th.be. Damit ist jetzt endlich Schluss. Überhaupt ist mit ein paar Dingen hier (wiedereinmal) Schluss. Wäre Textpattern nicht in einem andauernden Dornröschenschlaf, ich hätte ja schon wieder dahin gewechselt, wenn aber sogar John Hicks sagt, dass er ein anderes CMS als Textpattern verwenden würde, wenn er nur könnte, warum soll dann nicht auch ich mit WordPress arbeiten. Kann dort bitte irgendwer einmal in den Bienenhaufen hineintreten, damit sich was tut im Textpatternland?

Bleiben wir also bei WordPress, okay, aber der grafische Editor ist und bleibt abgedreht. Was mich dieses Ding, selbst in der neuesten Version (2.5.1) bisher Nerven gekostet hat, man glaubt es nicht. Jedes auch noch so kleine Codetrümmerl wird umgeschrieben und mit der neuesten Version passiert es mir nicht selten, dass ich mich gedanklich in Absätzen bewege, der grafische Editor mir diese Absätze allerdings in div-Layer umwandelt und das Neuformatieren damit zum täglichen Brot wird, auf das ich gerne verzichten könnte. Damit ist nun Schluss. Aber zu purem HTML lasse ich mich auch nicht bewegen. Nicht in Zeiten von Textile und Markdown.

Textile? Markdown!

Am liebsten hätte ich die Textverarbeitungskomponente, die WordPress einsetzt, mit einem genussvollen Klick auf “Delete” vernichtet, so einfach ist es aber nun doch nicht. Mein präferierter Ersatz – Textile – ist ebenso wie Textpattern seit Jahren mehr oder weniger tot. (Und wenn er nicht tot ist, dann kränkelt er zumindest sehr: Die beiden Textile-Plugins für WordPress Textile Wrapper oder Text Control machen mit Umlauten Schwierigkeiten oder zerstören mir bereits vorhandene Artikel. Ja selbst die Weiterentwicklung ist fraglich… Was also bleibt mir übrig, als zum Kontermodell überzugehen und mit John Grubers Markdown näher anzusehen, das vor allem auch als WordPress-Plugin (PHP Markdown) weiterentwickelt wird? Also 3th = Markdown. Soweit bin ich schon.

Asides, wiedereinmal.

Ich mag einfach nicht. Asides sind sowas Blödes, man kann es sich nicht vorstellen (Danke, Blogfever, für diese Erkenntnis!). Jeder schreibt in einem Satz über etwas, das woanders in einem Satz wieder woanders verlinkt und im Endeffekt klickt man dann zig Mal auf irgendwelchen von Schülern geschriebenen Blogs herum und landet bei einem dämlichen YouTube-Video. Ja, kann es das sein? Ne, ne, ne, selbst wenn durch Asides eine Vernetzung stattfindet, die beachtlich sein kann.

Newsreader? Gerne, aber nurmehr als Impetus!

Ganz gefährlich für Blogger sind Newsreader. Sie zerstören mehr als sie bringen, wenn man ihnen anheimfällt. Newsreader sind eine tolle Sache, wenn man damit Informationen sammeln und sie kumuliert verwerten will, sie sind ein Höllenwerkzeug, wenn man der Sucht zu unterliegen beginnt, jeden noch so nutzlosen Quak (wieder und wieder und wieder) zu posten. Obwohl ich die Nachrichtensammlungen eines Robert Basic, John Gruber und die teils hervorragend kommentierten Verweise bei Jason Kottke schätze, wirklich bringen tun’s diese Seiten, außer zu Unterhaltungszwecken, nicht. Lediglich John Gruber hat hin und wieder was zu sagen, Kottke kaum und Basic meist zu viel.

Was also jetzt?

Back to business as usual, zurück zu Einträgen, wie ich sie in Zeiten von Textpattern und gutem Kaffee geschrieben habe. Vielleicht mit einem ein wenig anderen Fokus. Das kann ich mir ja jetzt, mit dem neuen (tiefen) PageRank ja auch erlauben, so eine kleine stille Revolution. Einen Schlussstrich. Irgendwie halt.

Eines kann ich meiner werten Leserschaft auf den Weg mitgeben: Nicht mehr mit grafischen Buttons spielen zu müssen, nicht mehr zusehen zu müssen, bei unwichtigen Neuigkeiten der Erste zu sein, der darüber schreibt, auf all das Getue pfeifen zu können – das ist Bloggen, wie ich es schon lange nicht mehr erlebt habe: es macht Spaß und ist erfrischend!

HTML-formatierte Exportdatei aus Textpattern

Textpattern (TXP) besitzt über keine Exportfunktion für die in der Datenbank gespeicherten Einträge. Andere Content Management Systeme (CMS) müssen diese Daten in ihre eigenen Datenbanken importieren, doch sind aktuelle Skripte für Importe aus einer TXP-Datenbank immer seltener oder sie erfüllen nicht genau den Zweck, den ich in einem Importskript sehe: Die Daten des einen CMS ins Format des anderen CMS zu konvertieren und importieren.

WordPress (WP), beispielsweise, wird mit einem guten Importskript für TXP-Datensätze ausgeliefert, doch gibt es hier zwei große Nachteile:

  • Das Importskript funktioniert nur, wenn WP und TXP die selbe Datenbank benutzen. (Es ist nicht möglich, die Datensätze aus der TXP-Datenbank A in die WP-Datenbank B zu kopieren.)
  • Das Importskript geht davon aus, dass man Textile-verliebt ist und diese Art der Formatierung beibehalten will und importiert die Einträge genau so nach WP. (Ich hätte mir hier eine Konvertierung ins HTML-Format gewünscht.)

Die Lösung: mt-export!

Nach einer Lösung für dieses Problem habe ich lange gesucht und wurde letztlich über Umwege beim Forum für Expression Engine fündig: Wir benutzen das Vorlagensystem von Textpattern, um manuell eine Movable Type Exportdatei zu erstellen, die dann ganz einfach in WordPress importiert werden kann. Diese Datei umgeht beide oben genannten Probleme: Alle Artikel werden in reinstem HTML ausgegeben und es ist völlig egal, aus welcher Datenbank in welche Datenbank kopiert wird.

Das Prozedere

  1. Erstelle eine neue Sektion mit dem aussagekräftigen Namen “export”.
  2. Erstelle eine neue Seitenvorlage mit dem Namen “export” und diesem Inhalt.
  3. Erstelle einen neuen Baustein (Typ: Artikel) mit dem Namen “export” und diesem Inhalt.
  4. Erstelle einen neuen Baustein (Typ: Kommentar) mit dem Namen “exportcomments” und diesem Inhalt.
  5. Um nun an die Exportdatei zu kommen, rufe deinedomain.com/export auf und speichere den Quelltext in eine Textdatei mit dem Namen “mt-export.txt”.

Diese Datei kann nun in alle gängigen CMS importiert werden, da das Movable Type Exportformat einen Quasi-Standard darstellt.

Hinweise bei der Benutzung mit WordPress

Ich habe mit genau dieser Vorgangsweise meine Artikel aus TXP nach WP portiert. Dabei sind allerdings folgende Probleme aufgetaucht:

Alle Artikel wurden in WordPress mit dem Status “Entwurf” angenommen.

Abhilfe dafür ist in den WP-FAQ beschrieben, kurz zusammengefasst: Führe diesen Befehl in phpMyAdmin für die betreffende Datenbank aus. Da gibt es allerdings wieder ein Problem, denn die Artikel haben danach keine Titelform, also keine eigene URL. Bislang gibt es dafür keine Lösung, allerdings habe ich das Problem an die Entwickler von WP weitergegeben und hier manuell gelöst.