Ich bin gerade ein wenig beim Frühjahrsputz hier und habe im Rahmen meiner Aufräumarbeiten hier im Blog Feedburner rausgeworfen.
Was das bedeutet? Ganz einfach, dass der RSS-Feed dieses Blogs wieder direkt vom Server hier und nicht mehr von Googles Infrastruktur geliefert wird. Es sollte zwar normal alles klar gehen, kann aber ggf. nötig sein, dass ihr den Feed neu abonniert.
http://blog.no-carrier.info/feed/ ist dabei die URL zum normalen Feed des Blogs hier.
Alle Welt nutzt ja heutzutage mehr oder minder WordPress als Blogengine, es ist der 800-Pfund-Gorilla der Szene und nicht mehr wegzudenken. Was nicht allzu viele wissen ist aber, dass das am Anfang der Entstehung von WordPress sehr wohl anders gewesen ist. WordPress war am Anfang seiner Entstehung der Underdog, der daherkam dem damaligen Platzhirschen Movable Type der Firma Six Apart Ldt. sein Revier streitig zu machen – und letzten Endes gewann.
Früher war alles besser… oder?
Movable Type war früher das, was WordPress heute ist – der Marktführer im Bereich der Blogengines. Das war im Jahr 2004 gewesen. Movable Type ist bis heute in Perl geschrieben, und war einen ganzen Tacken statischer als WordPress. Man darf sich das so vorstellen: Movable Type ist eine Ansammlung von Skripten, die wenn ein neuer Post geschrieben wird, einen Haufen von statischen Seiten neu erstellt und auf dem Webserver anlegt. Solange nichts neues dazu kommt, werden nur die Seiten statisch geliefert, wenn jemand Kommentare schreibt, werden sie neu geschrieben. Das funktionierte anfangs ganz gut, bis es denn die ersten Blogs mit einigen Tausenden Postings und zigtausenden Kommentaren gab, da wurde die damalige Version von Movable Type dann mitunter sehr, sehr langsam. Inzwischen ist das aber kein Thema mehr.
Gleichwohl ist es eben so: wenn es dem Esel zu gut geht, dann geht er aufs Glatteis. Movable Type war früher in der Nutzung kostenlos, aber mit der Einführung der Version 3.0 dann wurde es auf einmal je nach Nutzungsart kostenpflichtig. Das führte dazu, dass eine Menge Benutzer sich auf einmal nach einer Alternative umschauten, weil sie die Kosten nicht zahlen konnten oder wollten für ein Hobby, mit dem sie kein Geld verdienen. Andere wiederum waren der Meinung, was gut ist dürfe ruhig etwas kosten – und blieben.
Enter: Cafelog!
Es war schon damals so gewesen, dass es im Bereich der Blogs eine aktive Programmiererszene gab, und ein recht erfolgversprechendes Skript namens Cafelog. Das kennt heutzutage keiner mehr, weil es nicht mehr weiter entwickelt wird, aber bildete die Grundlage für die Entwicklung von WordPress. Anders ausgedrückt: WordPress ist ursprünglich ein Fork von Cafelog. Eine weitere Entwicklung ist B2evolution.
Die Version WordPress 1.0 erschien dann am 3. Januar 2004, enthielt unter anderem einen Importer für Movable Type Blogs und war für alle Nutzungsarten kostenlos. Bis heute ist das so geblieben. Recht bald kam die Unterstützung für Plugins und statische Seiten dazu, so dass sehr viele ihre Blogs dann von Movable Type auf WordPress umzustellen begannen und Movable Type massiv an Marktanteilen verlor.
Es kam dabei dann so, wie es kommen musste: Six Apart hatte seine Community nicht richtig eingeschätzt, sie machten zwar auch weiterhin Umsätze und Gewinn, aber WordPress zog an ihnen sehr schnell weit und groß vorbei. Im Jahr 2007 entschied man dann, dass man nicht mehr auf die bisherige Weise mit WordPress konkurrieren könne, und Movable Type wurde zu Opensource. Das ist es bis heute geblieben, 2011 wurde die Firma an eine japanische Unternehmung verkauft.
Wie es sich übrigens gehört, betreibt auch Six Apart einen professionellen Bloggingdienst. Wer also die Mühen einer Installation von Movable Type nicht selber auf sich nehmen will, der wird bei Typepad fündig. Dabei ist es hier auch wie sonst überall, dass die Basisfunktionen kostenlos sind, wer mehr will der zahlt entsprechend.
Der bekannteste bei Typepad gehostete Blog zu Second Life ist „Second Thoughts“ von Prokofy Neva.
Fazit
Movable Type ist eine ausgereifte Blogengine, die durchaus ihre eigene Stärken und Schwächen hat. Heutzutage spielt sie kaum noch eine wirkliche Rolle, da WordPress einfach zu dominierend ist, aber wer eine Blogengine will, die vor allem von Haus aus schon statische Seiten generiert, ist mit ihr nach wie vor sehr gut bedient.
Im Moment grübele ich gerade darüber nach, ob ich den Blog hier statifizieren soll oder eben nicht. Die grundlegende Idee dahinter ist einfach: eine statische Seite wird direkt vom Webserver Apache hier ausgeliefert und kostet keine weitere Rechenzeit, da sie nicht zuerst durch die diversen weiteren Schichten hier wie PHP und MySQL genudelt werden muss. Auch ist so etwas, weil eben statisch, viel weniger anfällig für Sicherheitslöcher als die hier von mir verwendete Blogengine WordPress.
Gut, das sind Überlegungen die die meisten der hier verlinkten Blogger nicht haben werden, ganz einfach weil sie ihre Blogs bei Blogging-Providern betreiben und nicht auf einem eigenen Server. Das hier ist aber mein eigener Server und daher sieht es eben bei mir ein wenig anders aus.
Nun ist es so, dass WordPress an und für sich mehrere Vorteile hat: es ist etabliert und gibt Zillionen an frei verfügbaren Themes, die man verwenden und als Child Theme anpassen kann sowieso abermals Zillionen an Plugins, mit denen man die Funktionalität von WordPress beliebig erweitern kann. Auch wird das Skript selber von Automattic Inc. regelmäßig gepflegt, sollten Sicherheitslöcher entdeckt werden, gibt es schnell und zuverlässig Sicherheitspatches, die zudem im Backend extrem einfach eingespielt werden können. Dasselbe trifft für die Plugins zu.
Nur: die Sicherheit bei PHP ist immer so eine Sache, im Prinzip ist PHP inzwischen historisch ein derart chaotisch gewachsener Haufen Scheiße, dass man in PHP geschriebene Skripte eigentlich niemals wirklich sicher bekommen kann, einfach weil PHP selber extrem unsicher und anfällig für Angriffe aller Art ist. Das bei der existierenden Codebasis noch in den Griff zu bekommen ist völlig illusorisch, dumm nur aber, dass die Mehrzahl aller inzwischen im Web verwandten Skripte auf PHP basieren – wie z.B. vBulletin, das u.a. Slinfo als Forensoftware nutzt, WordPress, phpBB, Drupal, Typo3, Joomla und vieles, vieles mehr.
Dazu kommt bei WordPress auch, dass die Kernfunktionen einigermaßen sicher sind, weil Automattic Inc. dahinter steckt, dasselbe aber nicht unbedingt für die Plugins gelten muss. Die Codequalität der Plugins wird beträchtlich schwanken und auch die Zeit die es braucht, bis einer der Autoren dort ggf. Sicherheitslücken schließt.
Also macht das alles in allem den Betrieb eines solchen Blogs eben zu einem ständigen Glücksspiel, man weiß eben nie, ob es nicht doch irgendwo eine Lücke gibt und der Einfallsvektoren gibt es sicher viele, vermutlich viel zu viele.
Andererseits funktioniert WordPress eben aus dem Browser heraus einfach und sehr gut, die Grundfunktionalität stimmt und auch den Rest mit dem langsameren Rendern der Seiten im Vergleich zu statischen Seiten bekommt man durch Einsatz von geeigneten Caches gut in den Griff. Hier in dem Blog setze ich dazu W3TC ein, das ist die dickste und kompletteste Cachelösung überhaupt, und das macht sich mehr als deutlich in der Geschwindigkeit des Blogs hier bemerkbar. W3TC speichert unter anderem einmal gerenderte Seiten als Dateien auf dem Server ab und das nächste Mal, wenn jemand dieselbe Seite ohne Änderung anfordert, liefert W3TC diese Seite direkt aus dem Cache und fertig – das ist fast so gut von der Geschwindigkeit wie bei statischen Seiten, aber dennoch einen Tick langsamer, da es einen gewissen Verwaltungsoverhead dazu braucht. Andererseits aber ist diese Geschwindigkeitsdifferenz wohl so gering, dass man sie kaum merkt und es sich nicht lohnt, alles hier statisch zu machen.
Dem steht nun die Möglichkeit gegenüber, die Seiten hier komplett in ein statisches System wie Jekyll (geschrieben in Ruby) oder Hyde (geschrieben in Python) zu übernehmen, es gibt derer Systeme noch viele weitere, ebenfalls Zillionen. Solch ein System läuft dann normal zweigeteilt, es gibt einen Redaktionsserver (vulgo der PC zuhause), auf dem man seine Seiten schreibt und dann den Seitengenerator anwirft. Der Redaktionsserver lädt dann die Änderungen an den statischen Seiten per FTP oder sonst was auf den Webserver hoch – und das wars dann gewesen.
Das klingt zuerst einmal nach einer schönen und flotten Sache, und das ist es auch – nur steckt der Teufel dabei im Detail, genauer in den Kommentaren: denn wenn man dann auf seinem Webserver nur einen Haufen statischer Seiten liegen hat, der aber als Blog dienen soll, wie bitte soll das mit statischen Seiten dann noch gehen? Die Mehrheit der Leute, die ihr Blog statifizieren, behelfen sich damit, dass sie die Kommentare an einen externen Anbieter namens Disqus auslagern. Der lädt per Javascript entsprechende Felder für Kommentare nach und das läuft dann alles über seine Serverinfrastruktur, die Basisfunktionalität ist zudem kostenlos – und reicht für die Mehrheit allemal aus. Man kriegt per Plugin die Kommentare aus WordPress spielend einfach nach Disqus exportiert und hat sie dann dort drüben zur Verfügung, eine Sache denken sich Viele und machen das auch so.
Das klingt wie eine schöne Sache, nur: ich persönlich habe meine Daten und damit auch meine Kommentare hier unter eigener Kontrolle und keine Lust, sie einem Anbieter in den USA zu verfrühstücken, von dem ich nicht weiß was er damit wirklich anstellt und wie lange es ihn noch gibt. Spätestens dann, wenn er einmal seinen Dienst einstellen würde, müsste man sich nach einer anderen Möglichkeit umtun. Andere Möglichkeit bedeutet dabei entweder einen anderen Anbieter nutzen oder diese Funktionalität selber nachbauen.
Das hat jemand bereits nach Vorbild von Disqus gemacht und eine Webapplikation namens Juvia geschrieben, die in Ruby on Rails realisiert worden ist. Nur: das wäre für mich den Teufel mit dem Beelzebub austreiben, denn ich werfe doch nicht den einen Mist – PHP – raus um mir einen noch größeren Mist, nämlich Ruby on Rails ins Haus zu holen. Da kann ich das dann auch gleich schön sein lassen, oder schauen, ob es nicht vielleicht wo doch noch eine alternative Lösung zu Juvia gibt.
Auch ist bei einer Statifizierung natürlich wichtig, dass die URL-Pfade danach dieselben sein werden, ganz einfach damit die Suchmaschinen nicht ins Himmelblau verweisen und die diversen Sachen wie eingebettete Videos und Bildergallerien noch irgendwie sinnvoll funktionieren. Das wäre dann aber die Kür nach der Pflicht bei der Statifizierung.
Alles in allem ist das alles für mich so oder so recht unbefriedigend, und solange ich keine für mich zufriedenstellende Möglichkeit sehe, das Blog hier in seiner Mächtigkeit wirklich so zu statifizieren, dass ich alles selber betreiben kann, tut eben nach wie vor WordPress erst einmal weiter hier treudoof seinen Dienst. Vielleicht baue ich mir einfach mal lokal mit einem Static Site Generator meiner Wahl lokal einen Working Prototype und spiele dann mit dem ein wenig herum, schaden kann es jedenfalls nicht.
In diesem Post beschreibe ich kurz, welche Plugins für WordPress 3.0.2 in diesem Blog ihren Dienst verrichten. WordPress ist ja die beliebteste Blogengine überhaupt, was dazu führt, dass es gefühlte Gazillionen an freien Themes und Plugins jeglicher Art dafür gibt. Die Frage ist oft nicht „Gibt es das?“, sondern „Welches der Plugins nehme ich für X?“ Anyway, here we go:
Als Theme läuft hier momentan das frei erhältliche Mystique.
Ich habe unter der Haube ein wenig rumgefummelt und rechts noch eine Shoutbox namens „Schreikasten“ hinzugefügt. Als Eingabe wird ein Name und irgend etwas, das wie eine Emailadresse aussieht, erwartet. Die Adresse muss dabei nicht existieren. Kommentare werden dabei erst einmal sofort freigeschaltet.
Es ist ein Experiment, ich bin mal gespannt, wohin das führen wird. Wer ein Gravatar-Bild haben sollte wird sich über eine Darstellung seines Bildchens freuen.
Vielleicht wäre es auch bei Gelegenheit mal ganz interessant einen Artikel darüber zu schreiben, was hier unter der Haube dieser WordPressinstanz inzwischen so an Plugins werkelt. Mal schauen.