Warum Serendipity nur noch ein Blog ist

Irgendwann hatte ich mich mal an die Version 1.3.1 gesetzt und etwas aufgeräumt; also versucht, den Quelltext PHP5-mäßig zu gestalten. Folgende Ziele wollte ich erreichen:

1. Mit Serendipity sollte nur noch eine Shared-Installation möglich sein. Jeder Programmcode, der nicht über das Internet erreichbar sein muss, sollte in einen versteckten Bereich ausgelagert werden.
2. Von mehreren Programmen genutzt Bibliotheken an eine Stelle unterbringen. Pfade sollten dynamischer, leichter skalierbar sein.
3. Schaffung einer API, mit der man auch eigene Programme entwickeln und sehr leicht auf die Funktionen von Serendipity zugreifen kann.

Das war erfolgreich:

1. Alle Bibliotheken aus dem bundled-libs-Verzeichnis wurden in ein bereits von mehreren Anwendungen genutztes gemeinsames library-Verzeichnis verschoben. Durch Nutzung von set_include_path() und require_once() konnten viele Konstanten eingespart werden.
2. Umschreiben der Plugin-API nach PHP5 (sehr rudimentär)
3. Umstellen der Klasse serendipity_property_bag nach Zend_Config

Und hier verlor ich die Geduld:

1. Das templates_c aus dem Webseiten-Verzeichnis in ein verstecktes Verzeichnis auslagern (es gibt keinen praktischen Grund warum ein Cache für die Views in einem Ordner liegt, der über das Internet erreicht werden kann, wenn man keine .htaccess-Datei nutzt)
2. Serendipity von den Pear-Bibliotheken befreien und gegen das Zend-Framework austauschen (ich mag die PEAR-Bibliotheken nicht, weil diese bei PHP4 zu PHP5-Umstellungen die meisten Probleme bereitet haben)
3. Datenbank-Layer austauschen (Zend_Db) (nichts gegen den Serendipity-Layer. Aber den Zend-DB-Layer finde ich komfortabler)
4. ACLs einfügen (Zend_Acl)
5. Caching wo caching möglich ist (Zend_Cache)
6. Template-Engine vom reinen Smarty auf Zend_View umstellen, um mehrere Engines nutzen zu können (als Standard natürlich Smarty, aber andere Engines sollen auch nutzbar sein)

Wie gesagt, ich habe irgendwann die Lust verloren. Der Aufwand war zum Schluss größer als was der Gewinn gewesen wäre. Nicht nur, das man ständig HTML-Code im Quelltext hat, auch das Refactoring war sehr mühsam. Alleine den Datenbank-Layer auszutauschen entwickelte sich zur Qual. Auch gab es ständig neue Stellen, an denen Smarty plötzlich kein templates_c mehr fand. Und und und ... Zum Schluss wäre Serendipity nicht nur inkompatibel zu alten Versionen, sondern eine komplett neue Software gewesen. Und die kann ich mir auch einfacher schreiben.

Ein weiterer Grund gegen Serendipity ist der Programmierstiel an sich. Ein Programmierer lernt: Man soll gegen Schnittstellen programmieren, nicht für Anwendungen. Das beste Anti-Beispiel ist das Event-Handling. Dieses in eine eigene Anwendung zu integrieren war für mich nicht mit einem vertretbaren Aufwand machbar. Vielleicht ist es möglich, aber auch hier war mir das Aufwand-Nutzen-Verhältnis zu sehr auf Seiten des Aufwandes. Und zur Ehrenrettung muss man sagen: Serendipity ist zu tiefsten PHP4-Zeiten entstanden, als Objektorientierung noch ein Alibi war.

Natürlich hat Serendipity seine guten Seiten. Als Blog macht es das, was es machen soll. Es ist schnell installiert, es gibt unzählige Plugins. Garvin ist der beste Maintainer den man sich vorstellen kann. Die Community ist sehr aktiv und hilfsbereit. Das sind Gründe, warum ich Serendipity auch weiterhin als Blog behalten werde. Aber leider, leider, nicht mehr als Software, mit der ich meine Webseite verwalte.

Meine Bemühungen, S9y PHP5-tauglich zu machen, lege ich jedenfalls zunächst auf Eis. Wer aber weitere Infos zu meinen Ideen und Versuchen haben möchte, kann sich gerne bei mir melden.

In den nächsten Wochen möchte ich den einen oder anderen Artikel schreiben, wie man die Funktionen von S9y für seine eigene Homepage nutzen kann. Ein Entwurf zur Userverwaltung ist bereits vorhanden. Ich hoffe anhand dieses Artikels auch erläutern zu können, was ich an objektorientierter Programmierung schätze und an Serendipity vermisse. Und wer weiß in wie weit diese Ideen doch noch in Serendipity einfließen.