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.