Die Zeiten ändern sich.
Dieser Beitrag scheint älter als 17 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet.
Habari ist eine freie Open Source Anwendung, die das Veröffentlichen von Inhalten im Web erleichtert. Habari ist eine Blog Engine, ähnlich WordPress oder anderen Blog-Applikationen, geschrieben in PHP und benötigt eine Datenbank, nutzbar mit mySQL, SQLite oder PostgreSQL.
Das Habari-Projekt ist mit Entwicklern aus der WordPress-Szene entstanden. Startschuss war im Oktober 2006, siehe Historie und Hintergründe. Wer schon länger mit WordPress arbeitet, der wird schnell den einen oder anderen Namen wieder erkennen. Derzeit ist die stabile Version 0.4.1 veröffentlicht und die Entwicklung steckt in Version 0.5-alpha. Für alle Interessierten will ich mal einige wenige Punkte ansprechen und bebildern. Habari hat sicher noch nicht den Stand für den „allgemeinen Nutzer“ – ein Blick lohnt aber.
In der aktuellen Version sind viele Veränderungen eingeflossen. Die Adminoberfläche spielt mit AJAX-Technologien und nutzt dafür das Framework jQuery. Die Entwickler kommen seitens WordPress und das merkt man auch bei Habari. Auch wenn Habari in vielen Bereichen andere Wege geht oder sie als Alternative anbietet, so sind doch die Grundüberlegungen und Umsetzungen ähnlich. Hat man mit WordPress einige Erfahrungen, so wird man sich recht gut einfinden und kann recht schnell das System für Plugins und Themes verstehen.
Wichtige Unterschiede
Grundlegender Unterschied ist wohl, dass Habari auf PHP 5.2 aufsetzt, keine Abwärtsversion. Als Datenbank kann man MySQL 4.1* und höher oder SQLite wählen. Wichtig ist noch, dass PHP 5.2 die Unterstützung von PHP Data Objects (PDO) und SimpleXML hat. Beide Erweiterungen müssen aktiv sein!
Ein weiterer großer Unterschied, den ich sehr begrüße, ist die Verwendung von objektorientiertem PHP und Daten via XML. Diese Vorschläge hat auch WordPress schon mehrfach bekommen und bisher wurden sie nicht umgesetzt. Allerdings muss man auch sagen: WordPress steht schon eine Weile am Markt und derartige grundlegende Veränderungen, die eine ganze Serie von Änderungen mit sich bringen, sind in einem bestehenden Projekt nur schwer umzusetzen. Für PHP-Kenner mit Liebe zu OOP und XML ist Habari sicher einen Blick wert.
Im weiteren setzt Habari auf die Atom-Schnittstelle für das Bereitstellen der Feeds. Mit Hilfe eines Plugins kann man auch RSS anbieten. Aber Atom ist aus Programmiersicht sicher schöner, denn es lässt sich besser ansprechen und auslesen.
Weiterer großer Unterschied: Habari kann für mehrere Seiten genutzt werden. WordPress benötigt dazu eine eigene Version – WordPress µ.
Habari wächst
Die aktuelle Version nutzt jQuery als Framework für JavaScript-Umsetzungen, wird sehr viel im Backend eingesetzt. Außerdem kommen Blueprint und TiddlyWiki zum Einsatz. TiddlyWiki wird als Doku-Tool im Backend genutzt und so lassen sich schnell Informationen abrufen und pflegen. Blueprint ist ein Framework für die Umsetzung des Layout, ähnlich YAML. Besser oder schlechter, in jedem Fall andere Schwerpunkte – dazu verweise ich auf Artikel im Web.
Hinweisend ist zu sagen, wenn man das Projekt verfolgt, es finden ständig Veränderungen statt. Das Admininterface hat in meinen Test die dritte Veränderung mitgemacht und ein Ende ist nicht in Sicht. Das Dashboard hatte schon einen ähnlichen Umfang wie WordPress in der Version 2.5 und ist nun wieder schlanker geworden.
Allerdings wachsen die Möglichkeiten auch und damit muss der Backendbereich sich ändern. Die Oberfläche soll einfach und strukturiert bleiben. Eines der Ziele der Entwickler – nicht leicht, wenn die Einstellungen und Funktion immer weiter wachsen. WordPress wurde in diesem Hinblick immer wieder kritisiert und trotzdem empfinden viele Nutzer das Backend überschaubar. Nicht zuletzt kann man das Backend an Rechte und Bedürfnisse anpassen. Solche Bestrebungen hat Habari noch nicht, was aber bei einem Entwicklungstand auch nicht verwundert.
Das Admininterface
Im folgenden mal einige Einblicke in das Backend von Habari in Version 0.5-alpha. Wie sieht es aus und wie fühlt es sich an.
Das Dashboard, bekannt aus WordPress, kommt ähnlich daher und gibt Aufschluss über aktuelle Daten und Aufgaben. Einstellungen können vorgenommen werden.
Das Herz eines Blog sind die Artikel und diese werden im Editor erstellt. Habari wird dabei von Desktoptools unterstützt. Der Editor im Backend kommt sehr schlang daher. Tags und Einstellungen zum Beitrag oder einer statischen Seite werden per AJAX nachgeladen, wenn Bedarf besteht. Allerdings sollte man erwähnen, dass man nicht annähernd die Mächtigkeit von WordPress hat. Der Eingriff in Excerpt, WYSIWYG oder Medien sind nicht ohne weiteres möglich.
Die Kommentarverwaltung zeigt weiterhin die sparsame Oberfläche. Zeiträume können über den oberen dunklen Balken per JS verschoben werden.
Das Aussehen des Blog kann schnell und einfach gewechselt werden. Ein Klick und das neue Theme ist aktiv. Themes kann man aus dem Internet downloaden oder selbst erstellen, dazu im Anschluss mehr.
Habari unterstützt die Nutzung mehrer Nutzer. Die Verwaltung ist ebenso sparsam und wenig mächtig.
Die Schnittstelle zu Plugins ist ähnlich der von WordPress. Die Nutzung findet ebenso statt und schnell kann man das Plugin aktiv oder deaktiv schalten.
Fazit
Ich verfolge Habari nun schon fast seit der ersten Stunde und die Aufmachung in Hintergrund gefällt mir sehr gut, die Entscheidung auf objektorientierte Programmierung zu setzen und damit besser zu kapseln gefällt. Auch wenn es wieder andere Nachteile hat. Der Einstieg in die Erweiterung via Plugin ist nicht ganz so einfach wie bei WordPress, auch wenn man Ideen wie Plugin-Hooks und co. ähnlich umgesetzt hat.
Das Backend betrachte ich nicht als wichtig, es ist eine Umgebung die gefällt, schlicht und einfach daher kommt. Die Möglichkeiten und Effekte via JS sind schön und erleichtern die Arbeit. Die Funktionsmöglichkeiten sind aber auch nicht denkbar so umfangreich wie WordPress und so lässt sich nur schwer ein Vergleich ziehen. Ich denke, um Grunde macht Habari nichts anders, es lagert allerdings alle Zusatzfunktionen aus und lässt sie erst nach einem Klick per JS nutzen. Das ist sicher eine gute Wahl, die man bei WordPress überlegen sollte. Der Editor wirkt sehr aufgeräumt und man fühlt sich wohl. WordPress hat seit Version 2.5 in diesem Bereich an Übersichtlichkeit gewonnen, aber die Bedienung lässt leider nach. Die Umsetzung mit JS wäre eventuell eine Alternative. Aber auch das muss man sagen. WordPress kommt ohne CSS-Framework aus und das Anpassen oder Neuerstellen eines Admininterfaces ist möglich.
Das erstellen von Theme und Plugins ist gut möglich. Dabei orientiert sich Habari an guten Umsetzungen von WordPress. Die bekannten Hooks sind da und die Templates haben eine ähnliche Hierarchie. Außerdem kann man das Theme nach dem bekannten Muster aus einem Mix aus HTML und PHP erstellen, was ich als sehr mächtig und schnell empfinde. Alternativ steht Smarty zur Verfügung.
Trotzdem muss man auch sagen, dass Habari derzeit einen guten Stand hat, aber nicht die Vielfalt von WordPress hat. Aber Habari entwickelt sich, es ist sicher einen Blick wert und die eine oder andere Anwendung wäre gut mit Habari machbar.
Was mir gefällt, ist vorallem die Schlankheit. Bei WordPress wünsche ich mit schon immer ein Light-System bei dem ich viele der nicht immer nützlichen Funktionen zuschalten kann.
Aktuell scheint Habari diesen Weg zu gehen und ich bin gespannt wie es sich entwickelt.
Realistisch gesehen muss man aber auch sehen, dass Habari nicht extrem schnell entwickelt wird und eine ganze reihe anderer Systeme sind ähnlich umfangreich und flexibel, womit ich nicht die bekannten Applikationen wie WordPress, Serendipity oder Movable Type meine. Wenn Habari sich abheben will, dann gehört mehr Umfang in die Entwicklung. Aber eventuell will das Projekt das gar nicht und es bleibt eine Nische im Kreise der Blog-Plattformen, was es in Hinsicht Spam-Aufkommen sicher interessant macht.
Ich für meinen Teil werfe immer wieder einen Blick in das Projekt. Der Blick über den viel zitierten Tellerrand hat noch nie geschadet.
Dokumentation
Sehr schön ist, dass parallel bei der Entwicklung an einer Dokumentation gearbeitet wird. Dies ist nicht immer selbstverständlich und es macht das Verfolgen eines Projektes leichter. Ebenso werden alle Dateien der Applikation mit phpDoc versehen, was WordPress erst seit Version 2.5 konsequenter betreibt.
Ich kann mich auch noch an das alte Admin-Menü erinnern. Dieses Menü, das man in deinem ersten Bild sieht, gefällt mir überhaupt nicht. Ich bevorzuge hier eine Tab-basierte Struktur, die auch WordPress nutzt. Es ist einfacher, als wenn man sich durch ein Menü hangeln muss, das zudem noch langsam öffnet.
Den Editor mag ich gerade auf Grund seiner Schlichtheit. TinyMCE in WordPress nutze ich gar nicht; ebenso wenig diese Medien- und Uploadgeschichten. Ich möchte in der Hauptsache nur schreiben.
Eins ist aber weniger schön: es gibt (noch) keine automatische Vervollständigung bei Tags. Das kann WordPress inzwischen von Haus aus, und man gewöhnt sich dran.
Was mir sehr gut gefällt: Kopien von Klassen erstellen und nutzen. Wenn man eine Funktion vermisst, kopiert man die entsprechende PHP-Datei in den Benutzerordner und bearbeitet diese Kopie. Habari lädt dann eben diese und lässt das Original intakt. So kann man die Software an eigene Bedürfnisse anpassen. Tritt ein Fehler auf, löscht man die Kopie, und alles läuft wieder.
Ich nutze Habari zurzeit nur lokal zum Testen. Ich habe „utf8_encode“ an ein paar Stellen im WordPress-Importer ergänzen müssen, weil das Teil sonst ein Problem mit den deutschen Umlauten hat, aber auch das wird vermutlich noch von den Entwicklern selbst gefixt werden. Wenn noch ein paar andere Dinge korrigiert werden (Tags kann man aktuell weder löschen noch umbenennen, oder ich bin zu blöd, das Prinzip zu verstehen), und wenn die Sprachunterstützung konsequenter durchgeführt wird (nach wie vor gibt es feste Strings, die nicht übersetzt werden können), dann denke ich über einen Wechsel auf Habari nach. Mir geht es nämlich zurzeit ziemlich auf die Nerven, dass WordPress immer nur umfangreicher zu werden scheint.
@Mathias: Deine Punkte sind mir ebenso aufgefallen, vor allem die Probleme mit Sonderzeichen. Denke aber, dass dies alles Tatsachen sind, die in einer der nächsten Versionen entfernt werden. Der Editor sagt mir auch zu, auch wenn ich es genieße, dass ich in WP mit Quicktags anlege. Der WYSIWYG ist sicher nicht so toll und ich habe ihn noch nie in WP genutzt, auch wenn ich es nach jedem Update wieder versuche. Aber für Kunden und nicht HTMLer ist das ein KO-Kritierium. Tags lassen sich in meiner Version verwalten und auch löschen.
Danke für den Hinweis mit den Klassen, schaue ich mir an.
Ja, richtig, mein Fehler. Wie peinlich. 🙂 Natürlich lassen sich die Tags auch bei mir löschen, aber als WordPress-Benutzer schaut man wohl zuerst nach einer Checkbox oder so was. Jetzt habe ich’s kapiert.
Unfassbar wie oft das Wort „mächtig“ in dem Artikel vorkommt 😉
Ich habe mir letztens die 0.4 angeschaut und bin eigentlich begeistert. Saubere Programmierung. Was mich allerdings etwas wundert, ist die sehr langsame Entwicklung. Ich hoffe, da? Habari nicht zum Stillstand kommt, es wäre schade darum.
@Michael: 2mal; ?!
3mal, wenn man „Mächtigkeit“ gelten lässt. 😉
Ich habe heute übrigens gesehen, dass man die fehlende Blogroll per Plugin nachrüsten kann. Da muss ich sagen: manche Dinge gehören einfach von Haus aus in die Software, und die Blogroll zählt für mich dazu.
btw, das hier geschilderte Sicherheitsproblem gilt auch für Habari. Ich hab’s mit 2 Eingriffen in den Dateien „eventlog.php“ und „user.php“ so gelöst, dass die Anmeldeversuche zwar im Log gezeigt werden, dass der Angreifer davon aber nichts sieht. Hier macht es sich bezahlt, dass man die Originaldateien kopieren und erweitern kann. *freu*
@Mathias: prinzipiell kann ich ja bei WP auch jde Funktion kopieren, verändern und nutzen. Allerdings muss ich dann per Hook die alte Funktion deaktivieren und auf die neue Verweisen.
Wenn ich dich richtig verstehe, dann macht Habari das automatisch, wenn die kopierte Funktion den gleichen Namen hat?
Ein konkretes Beispiel, Frank: versuch mal eine Anmeldung mit unbekanntem Benutzernamen und/oder falschem Passwort. Du siehst jedes Mal eine Bildschirmmeldung wie bei WordPress. Danach kopierst du die „/system/classes/user.php“ in Ordner „/user/classes“ und suchst in ihr nach den 3 Meldungen, die sich auf die Fehler (unbekannter Benutzer, falsches Pwd) beziehen. Es sind 3, nicht 2. 😉 Im Funktionsaufruf von „EventLog::log“ änderst du warning in info und machst noch mal eine Anmeldung. Jetzt siehst du keine Bildschirmmeldung mehr, aber die Fehlversuche werden trotzdem geloggt. Habari nutzt also die von dir bearbeitete „user.php“ und nicht mehr die Originaldatei.
@Mathias: Also unterscheidet Habari die gleiche Fkt. auf Grund des Ordners /user/. Was aber wenn ein Update für die Klasse/Fkt. kommt, dass bekomme ich dann nicht mit.
@Matthias: Frank hat Recht, so wird das nichts. Du machst damit die schöne Objektprogrammierung kaputt. Ich habe das jetzt nicht nachvollzogen, aber sowas in der Art von
class myUser extends User {
//tue etwas
}
wäre da eher sinnvoll.
Das ist wohl wahr. Aber das Problem hast du bei WordPress auch. Ich nutze bspw. die SVN-Version und habe mir ein Skript geschrieben, dass a) die neue Version zieht, b) die Dateien in meinen lokalen Blogordner kopiert und c) anhand von diff-Dateien bestimmte Dateien patcht. Die notwendige Änderung habe ich einmal manuell vorgenommen. Wenn sich zuviel ändert, muss ich noch mal ran. Insofern nimmt sich das nicht allzu viel.