Ich bin latent auf der Suche nach einem neuen Blogsystem. #Serendipity ist stabil und hat mich in den letzten Jahren zuverlässig begleitet, aber es gibt ein paar Schwerpunktsetzungen, die mich daran grundsätzlich stören. In erster Linie bin ich aber kein Freund der übermäßigen Abwärtskompatibilität, die fühlt sich für mich an wie ein Festhalten an überholten Paradigmen auf Kosten von frischen Ansätzen. Ich habe inzwischen einfach das Gefühl, ich brauche diese frischen Ansätze. Die zähle ich hier mal lose auf.
Es geht mit der Erstellung von Content los, das ist ein weites und komplexes Feld. Beginnen wir mit dem Editor. Das Blogsystem #Ghost hat einen in meinen Augen großartigen und revolutionären Ansatz fürs Content-Editing: Ein zweigeteiltes Fenster mit einem Feld für #Markdown und einem für die Live-Anzeige des Verbrochenen direkt in der späteren Umgebung. Das alleine finde ich schon großartig, aber es wird noch besser: Man kann Bilder einfach in den Editor ziehen und im Hintergrund wird das Bild auf den Server geladen und ein entsprechender Markdown-Code erzeugt und an der Stelle eingefügt. Punkt. Simpel, elegant, schnell. Ein Grund, wieso ich so ungerne Bilder beim Bloggen verwende, ist das elende Gefummel mit Mediendatenbanken und all dem Scheiß. Beim Bloggen hängen Bilder für mich am Artikel dran und werden auch dort verwaltet. Die Frage ist nur, wie komfortabel lässt sich das an der Stelle möglichst abstrakt lösen? Was ist mit Galerien? Wo werden die Bilder physisch und logisch gespeichert? Da ich mich ein paar Stunden nach der Einrichtung von meiner Ghost-Testinstallation nicht mehr einloggen konnte, kann ich gerade nicht testen, wie das funktioniert. Aber der Ansatz ist schon mal gut, sowas will ich haben, also mindestens diese großartige Live-Preview, aber eigentlich auch die direkte Art der Bildereinbindung.
Dann ist da die Content-Abstraktion. Lange war ich großer Verfechter von (vorzugsweise selber geschriebenem) HTML-Code in der Datenbank, vor allem, weil dieser Code im Gegensatz zu etwa Textile absolut gar nicht mehrdeutig ist. Inzwischen sehe ich da in erster Linie ein Alterungsproblem. Dabei geht es weniger um Absätze und ein paar Inline-Tags, sondern um Sachen wie Embed-Tags, Bilder, was auch immer. Hier bin ich zur Auffassung gelangt, dass eine möglichst abstrakte bzw. semantische Speicherung von Inhalten über die Jahre haushoch überlegen ist. Ob das nun Shortcodes wie bei #Wordpress sind oder Kirbytext wie bei #Kirby ist mir latte. Wichtig ist, dass in der Datenbank in abstrakter Form steht, dass an der Stelle ein Youtube-Video eingebunden werden soll, das diese ID und jene Höhe und Breite haben soll, ggf. noch ein Alternativtext dazu. Das muss mit einer maschinenlesbaren (und damit verbunden eindeutigen) Syntax passieren. Diese Elemente müssen individuell erweiterbar sein, denn wo der eine Vimeo-Tags braucht, braucht der andere Amazon-Marketplace-Links. Das Rendering des dann letztlich im Code erscheinenden Snippets muss bei der Ausgabe passieren, damit das YouTube-Video, das ich vor fünf Jahren eingebunden habe, heute den aktuellsten Embed-Mechanismus bekommt. Zudem möchte ich ja möglicherweise im Feed oder einem automatischen Maildigest oder weiß der Geier wo mein Content noch ausgespielt wird, andere Snippets sehen, vielleicht ja nicht mal HTML.
Da kommt dann wieder Markdown ins Spiel. In diesem Fall in der Rolle als universellem Austauschformat für textliche Inhalte. Nur der abstrahierte Content darf in die Datenbank. Auch ein schönes Beispiel ist ein Wechsel der Lightbox. In der Datenbank darf halt nur eine Liste von Bildern stehen, dazu ein paar Metadaten wie die Angabe, ob sie zu einer gemeinsamen Galerie gehören, dass normalerweise nur ein (automatisch erstelltes) Thumbnail einer bestimmten Größe angezeigt werden soll und Alternativtexte, sowie ggf. Bildunterschriften. Wie und ob das für welche Lightbox in fünf Jahren als HTML gerendert wird und ob dabei Retina berücksichtigt wird, darf nicht fest am persistierten Content kleben. Bei #TYPO3 arbeite ich aus diesem Grund schon immer mit TemplaVoilàs FCEs, die genau diese Abstraktion beherrschen. Ich definiere für den Redakteur eine Eingabemaske und in der Datenbank landet eine abstrakte XML-Struktur, deren Rendering später beim Rendering der Seite konkretisiert wird. TemplaVoilà ist abgesagt, aber ich denke #FluidTYPO3 ist ein noch viel besserer Ersatz und kann das alles und noch viel mehr. Aber so möchte ich meine Blogeinträge nicht schreiben, das ist viel zu umständlich. Für statische Seiten ist das hingegen in meinen Augen genau richtig und der Weg, den man gehen sollte, ich fahre jedenfalls seit 10 Jahren exzellent damit und Redakteure verstehen das auch überraschend problemlos.
Wenn man in der Datenbank abstrakten Content hat, der erst beim Rendering mit Magie bearbeitet wird, kann man auch so schöne Spielereien wie Hashtags leicht implementieren. In der Datenbank steht einfach ein #Hashtag im Text und nichts weiter. Beim Rendering im Blog wird das mit der Suche des Blogs nach diesem Hashtag verlinkt und bekommt eine hashtag
-Klasse. Dann kann, wenn man das will, ein JavaScript darüberlaufen und noch mehr lustige Sachen damit anstellen, etwa ein kleines Popup, das auch eine Suche nach diesem Hashtag bei Twitter oder in 5 Jahren sonstwo anbietet oder per Ajax eine Liste mit ein paar Blogeinträgen mit diesem Hashtag holt oder was auch immer man sich irgendwann mal zum Thema Hashtags ausdenkt. Vielleicht findet man die auch irgendwann doof und schmeißt den ganzen Mist weg. Alles kann, nichts muss. Momentan favorisiere ich sowohl aus Schreibersicht, als auch aus Lesersicht die Nutzung von Hashtags statt extern am Artikel klebender Tags. Die sind bei mir über die nunmehr 10 Jahre Blogging zu einer unwartbaren Mischung aus kategorienähnlicher Taxonomie und Einzelfallverschlagwortung herangewachsen; sehr unangenehm und ein Grund für mich, viele Sachen lieber mal schnell bei #Google+ reinzuschreiben. Mein nächstes Blogsystem muss also entweder von sich aus Hashtags auf diese Weise unterstützen oder eine Möglichkeit haben, dass ich mit einem Plugin vor dem Rendering noch mal über den Text gehen kann, um die Hashtags zu verarbeiten. Da sind etliche Blogsysteme schon mal raus.
Mal weg vom Content, das Thema ist zwar noch um einiges komplexer, aber das muss erst mal reichen. Reden wir über Codequalität. Wann immer ich in irgendwelchen Wordpress-Code, womöglich auch noch von Plugins oder Themes, reingucke, wird mir augenblicklich schlecht und ich verspüre den Drang, mich zu sofort waschen. Das kann es einfach nicht sein. Alleine der Umstand, dass Wordpress grundätzlich eine infame Mischung aus vom WYSIWYG-Editor mehr oder weniger erfolgreich zusammengezimmertem HTML-Code und den an sich genialen Shortcodes in der Datenbank speichert, gruselt mich schon. Aber viel ekelerregender finde ich die nach wie vor nicht behobene und schon immer unfassbar dämliche Designentscheidung, in der Datenbank immer und überall volle URLs mit Protokoll und Domain zu speichern. Wer um alles in der Welt denkt sich in welchem Zustand geistiger Umnachtung sowas aus? Und warum? Wenn man, etwa für die Syndizierung per RSS oder so, volle absolute URLs im Content braucht, kann man die doch immer noch ohne Weiteres beim Rendering vervollständigen. Und wenn das nur beim Content so wäre, das wär ja noch tragbar. Aber diese scheiß URLs sind überall in der Datenbank, inkl. mit serialize()
serialisierten PHP-Arrays, die dafür sorgen, dass auch ein einfaches Search&Replace in der Datenbank (etwa bei einem Domainumzug) fast alle Configs zerstört. Warum nur serialisiert man PHP-Arrays für die Persistierung in einer Datenbank mit serialize()
? Was spricht gegen JSON oder XML oder irgendwas, das nicht unfassbar mimosig direkt vollständig kaputt geht, wenn in der Persistierung mal ein Zeichen dazukommt oder wegfällt? Da kann ich mich wirklich leidenschaftlich drüber aufregen. Im Ergebnis kann man mit Wordpress faktisch keine Seite betreiben, die wahlweise mit oder ohne HTTPS genutzt werden können soll. Ich wiederhole mich, aber wer denkt sich bloß sowas aus?
Aber ich möchte gar nicht über Wordpress reden, das kommt für mich ohnehin nicht in Frage. Mein nächstes Blogsystem braucht keine fertigen Themes, sondern muss mir die volle Kontrolle über den ausgegebenen HTML-Code geben. Mit voller Kontrolle meine ich wirklich volle Kontrolle. Das System darf mich unterstützen, etwa mit CSS- und JavaScript-Zusammenfassern (und -Minimierern), die auch die CSS- und JavaScript-Dateien von eventuellen Plugins mit einschließen. Das ist in Wordpress passabel gelöst, inkl. einem simplen System zur Auflösung von Abhängigkeiten (jQuery zuerst, dann Plugins dafür, dann Theme-Code), sowas sollte ein modernes Blogsystem haben oder zumindest eine Schnittstelle anbieten, mit der man sowas leicht implementieren kann.
Randnotiz: Würde ich diesen Text mit Textile schreiben, würde der Ausschnitt da oben jetzt folgendermaßen aussehen und ich könnte nichts dagegen tun. Das ist der Grund, wieso ich die durch die Implizitheit entstehende Mehrdeutigkeit von Metasprachen für ein ernsthaftes Problem halte:
[…]CSS- und JavaScript-Zusammenfassern (und
Minimierern), die auch die CSSund JavaScript-Dateien[…]
Jedenfalls muss mein nächstes Blogsystem mir die volle Kontrolle über meinen Code geben. Serendipity etwa ordnet sich da in meinen Augen zu sehr dem zugegeben super cool einfachen Themewechsel unter. Das brauche ich nicht, auch wenn das damals der ausschlaggebende Grund für mich war, zu Serendipity zu wechseln. Aber dadurch gibt es quasi einen gewissen Goldstandard, was den HTML-Output von Themes und Sidebar-Plugins angeht, der der vollen Quelltext-Kontrolle massiv im Weg steht. Ich habe das bei meinen eigenen Sidebar-Plugins dadurch zu kompensieren versucht, dass man pro Plugin mit einem einfachen Theming den Code anpassen kann, aber das ist irgendwie auch keine perfekte Lösung und ich war auch ziemlich alleine damit. Ich kann auf ein riesiges Plugin-Repository und vor allem Sidebar-Plugins allerdings im Gegenzug gut verzichten und bin auch da Freund von Eigeninitiative bzw. Weglassen. Weniger ist da echt mal mehr, wenn es um Blogs geht. Mein Blog wird vermutlich in Zukunft auch gar keine klassische Sidebar mehr haben, denn auch da gibt es frischere Ideen. Der Content braucht seinen exklusiven Raum, denn darum geht es ja in erster Linie.
Was mir gerade noch einfällt: Markdown kann gut mit Fußnoten, das sagt mir zu. Ich träume ja schon immer davon, mehr mit Fußnoten bzw. eigentlich lieber mit Randnotizen zu arbeiten. Mit Markdown lässt sich das abstrakt lösen und dann kann ja immer noch ein JavaScript daherkommen und die in einer Randspalte an der richtigen Stelle anzeigen. Und im Feed ist es einfach eine Fußnote oder je nach Inhalt auch eine Absatzendnote.
Ich kann mir übrigens gut vorstellen, dass mein nächstes Blogsystem ohne Datenbank auskommt und stattdessen Markdown-Dateien und dazugehörige Bilder in einer Ordnerstruktur ablegt. So wie Kirby CMS das macht. Solange ich einen komfortablen Editor dazu habe, brauche ich keine Datenbank. Die Frage ist halt, wie sowas in Sachen Suche performt. Also gar nicht mal nur, was konkrete Frontend-Suche durch Besucherinnen der Seite angeht, sondern auch so Sachen wie Tagwolken. Wobei ich keine Tagwolke haben will, aber Ihr wisst hoffentlich, worauf ich hinaus will, wenn Ihr bis hierher gelesen habt ;). Vielleicht will man ja mal eine Auflistung aller in letzter Zeit verlinkten YouTube-Videos in eine eigene Ansicht packen oder sowas.
Damit verbunden: Ich brauche im Backend eine Funktion, um den Überblick über externe Ressourcen zu behalten, allen voran externe Links. Da wäre es gut, wenn das System mir unter die Arme greifen würde und einen Linkchecker anbieten würde, der gerne als Cronjob von der Kommandozeile aus und in Häppchen arbeitet. Und der mich (aktiv oder auf einem Dashboard) warnt, wenn und wo defekte externe Ressourcen referenziert sind. Das wäre großartig!
Ghost kommt übrigens für mich nicht in Frage. Zum Einen, weil es vorne und hinten noch nicht fertig ist, noch lange nicht. Zum anderen bin ich nur mäßig begeistert von einem System, das nach ein paar Stunden jede Zusammenarbeit einstellt, sich nicht wieder wecken lässt und auf einem Software-Stack läuft, den ich nicht überblicke, so dass ich mir nicht mal selber helfen kann. Wenn bei einem PHP-System was kaputt ist, kann ich das finden und reparieren. Wenn so ein node.js-Ding einfach nicht mehr reagiert und auch ein Neustart nicht hilft, dann nervt mich das. Von der Anforderung, überhaupt erst mal einen geeigneten Hoster zu finden, mal ganz abgesehen. Das würde bei Uberspace ja immerhin schon mal funktionieren. Ich werde aber noch mal einen genaueren Blick auf Kirby werfen, wobei mir da der coole Editor mit Live-Preview und simplem Bilderhandling fehlt, auf letzteres kann ich dabei noch am ehesten verzichten. Aber Kirby hat schon mal seine klare Syntax für YouTube und Co. am Start, die auch erweiterbar ist und sich gut mit Markdown verträgt.
Wenn jemand Ideen hat, immer her damit.
P.S. Ach ja, Podcasts. Das wäre so ein Ding für eine andere Ansicht. Also letztlich müsste man einen extra Feed generieren, der sich aus Einträgen mit einer bestimmten Eigenschaft zusammensetzt (hier: ein gewisser Hashtag plus eine Datei eines bestimmten Typs = MP3-Feed einer Podcast-Publikation). Das ist noch lange kein Podlove Publisher, aber für den Hausgebrauch wär das schon mal ganz nett.