QVINTVS · SCRIBET

Alternativen zu PHP-Foren

Ich habe gestern den ganzen Tag damit zugebracht, mir verschiedene Foren-Implementierungen anzusehen und auf ihre Nutzbarkeit zu überprüfen. Das ernüchternde Ergebnis bis hierhin ist: Wirklich ernstzunehmende Alternativen zu PHP-basierten Foren gibt es wohl nur für Optimisten. Aber ich habe trotzdem mal ausprobiert…

Wenn man ein Forum aufsetzen möchte und dabei kein PHP auf dem Server haben will, gestaltet sich die Sache etwas schwierig. Ich wollte eben etwas haben, dessen Code nicht aussieht wie unkommentiertes Flickwerk, wo außer dem Autor keiner mehr durchblickt… Was bei PHP ja scheinbar der Normalfall zu sein scheint. Nachdem ich mich also zunächst mit diverser Ruby-Forensoftware auseinandergesetzt habe, bin ich ob deren Unbenutzbarkeit beim Feind wildern gegangen und habe mir in Python geschriebe Forensoftware angeschaut.

Was mir durchweg aufgefallen ist: Kein einziges der hier vorgestellten Foren hat je ein Release veröffentlicht. Alle Foren sind nur direkt vom aktuellen master/trunk/etc. verwendbar, mit allen Bugs die Entwicklerversionen halt so mit sich bringen. Das allein gibt schon ein sehr trauriges Bild ab.

Ruby-Foren

Zunächst meine Evaluationen im Bereich Ruby, schließlich bin ich ja eigentlich ein Ruby-Programmierer. Wenig überraschend setzen alle Lösungen auf RubyOnRails, entweder in Version 3 oder sogar schon Version 4.

forem

Keine Foren-App als solche, sondern eine Engine, die dazu gedacht ist, in eine größere Rails-Anwendung als Nebenprodukt eingebaut zu werden. Bis das so aussieht, wie man es sich wünscht, muss man viel Arbeit in CSS und Code stecken, featuretechnisch erscheint das Ganze sehr minimalistisch. Da mir das zu viel Arbeit war und ich eine funktionierende Lösung wollte, habe ich an dieser Stelle aufgehört. Eine Demo-Seite gibt es auch.

heterotic_beast

Ein Fork von altered_beast, welches nicht mehr weiterentwickelt wird. Macht einen wirklich guten Eindruck, allerdings war ich nicht in der Lage, eine lokale Installation ans Laufen zu bekommen. Die Asset-Pipeline dieser Anwendung erscheint irgendwie total kaputt — weder Stylesheets noch Javascripts werden eingebunden. Konkret heißt das, dass diese Zeilen:

/* ...
* require_tree .
* require_self
*/

Einfach ignoriert werden. Sie tauchen literal im fertigen application.css auf. Und nein, die Asset-Pipeline ist in der Konfiguration aktiviert.

Ich kann also nicht mehr über diese Software sagen als die Demo-Seite hergibt.

thredded

thredded ist das einzige in Ruby geschriebene Forum, das lokal bei mir ohne Zicken funktionierte. Das Projekt ist recht aktiv, etwa alle zwei Monate gibt es ein paar neue Commits. Leider hat das Forum ein dickes Manko: Es gibt keinen Administrationsbreich. So ist es weder möglich, Nutzer zu sperren noch Moderatoren zu ernennen, die beschränkte Administrationsrechte ausüben. Zur Demo-Seite.

forum_monster

Forum monster befindet sich angeblich mitten in einem Rewrite, der allerdins seit ein paar Monaten zum Stillstand gekommen zu sein scheint. Die Demo-Seite macht wirklich Lust auf mehr. Leider geht auch forum_monster mehr in Richtung Engine als in diejenige einer eigenständigen Foren-Anwendung, Authentifikation und Autorisierung muss man selbst implementieren. Laut README besteht der empfohlene Weg gar darin, die Controller direkt selbst zu hacken:

Since you have Forum Monster’s controllers in your main application, you can customize them for your specific solution just like the rest of your application!

Discourse

Discourse ist vor allem eines: Riesig. Die Software ist Ausdruck des üblichen Selbstverständnisses der Rails-Nutzer und spiegelt die Affinität zu schnellem Web, Mac OS, extremem Gebrauch von JavaScript und Rücksichtslosigkeit im Bezug auf Hardware wider. „Wie, geht nicht? Steck mehr Geld in deine Server-Hardware!“, hört man von hier rufen. Die Abhängigkeitsliste ist außerordentlich lang und als Datenbank wird man auf PostgreSQL gewzungen.

Die Software selbst geht einen anderen Weg als klassische Bulletin-Systeme. Statt aufgeräumt in vorgegebenen Kategorien zu erscheinen, fließen die Topics nach Aktualität die Startseite herunter — natürlich mit der Möglichkeit, diese zu taggen. Wer mag, kann sich über den „Kategorien“-Button auch die Topics sortiert nach Kategorie anschauen. Was allerdings in meinen Augen wenig Ordnung in das Chaos bringt, die Seite wirkt trotzdem zu verspielt und durchgewürfelt. Zur Demo.

Von der reinen Funktionalität her kann Discourse alles, was man von einem Forum erwarten würde. Administatoren, Moderatoren, Nutzersperre, Sticky Topics, etc (auch wenn man die Sticky-Topics in der Kategorienansicht garantiert übersieht). Offiziell ist Discourse noch Beta, läuft allerdings — mit der entsprechenden Server-Hardware — schon recht stabil. Da mein Server aber nur knapp die Minimalanforderungen für Discourse erfüllt und da auch noch andere Dinge drauf laufen, fiel diese Option für mich persönlich flach.


Damit beschließen wir die Foren-Software aus der Ruby-Ecke. Mehr habe ich nicht gefunden, außer vielleicht die in ChiliProject eingebauten Foren, die sich aus diesem aber nicht auslösen lassen und nur als Bestandteil einer gesamten Chili-Installation existieren. Wer seinen Bugtracker also schon immer mal mit einem Forum aufrüsten wollte, findet in ChiliProject eine wirklich gute Gesamtlösung (auch der Bugtracker selbst ist wirklich gut).

Python

Die Python-Welt hat sich mittlerweile über Django ebenfalls einen Namen im Web gemacht. Das Webframework erinnert entfernt an Rails, ist aber doch irgendwie anders. Es mag mir als Python-Unkundigem nur so erscheinen, aber irgendwie wirkt es leichtgewichtiger. Ich muss ernsthaft sagen, ich bin versucht, Python mal einen genaueren Blick zukommen zu lassen.

So überrascht es kaum, dass so wie in der Ruby-Welt alle Foren auf Rails aufsetzen, man es in der Python-Welt eben mit Django hält. Nunmehr also zu den Kandidaten…

Inyoka

Ganz ehrlich, als ich an Python + Forum + Web suchte, habe ich erstmal an Inyoka, die Software hinter den Ubuntuusers-Foren gedacht, die augenscheinlich marktreif ist. Leider verschließt sich das Entwicklerteam hartnäckig der Veröffentlichung des Quellcodes und nur dann und wann dringen mal Gerüchte über Inyoka an die Außenwelt. Mir als grobem Mitleser der Ubuntuusers-Foren ist bisher nicht vielmehr bekannt, alsdass man auf Python mit Django setzt. Tja. Wirklich außerordentlich bedauerlich.

LBForum

Die Demo von LBForum sieht nach solidem Standard aus. Leider ist sie Momentan Ziel allzu aggressiver Spambots und deswegen für die Augen nicht wirklich erträglich. Dieser Eindruck wird leider nicht dadurch gebessert, dass ich es lokal bei mir nicht zum Laufen bekam — scheinbar ist dies nicht kompatibel mit neueren Django-Versionen (ich habe 1.4 und 1.5 probiert). Umso befremdlicher ist, dass das Projekt auf GitHub zumindest eine leichte Aktivität verzeichnet. Vielleicht muss ich mich hier noch einmal intensiver bemühen.

Dinette

Dinette krankt an mangelnder Dokumentation. Ich als Nicht-Pythonista weiß nicht so recht, wie ich das installieren soll. Ansonsten sieht es gar nicht mal so schlecht aus, ich hoffe nur, dass man das in der Demo gezeigte Theme ändern kann. So viel Bootstrap tut meinen Augen nicht gut.

PyBBM

Der Platzhirsch unter den Django-Foren ist wohl PyBBM. Leider handelt es sich auch hier um eine Engine, und nicht um eine fertig nutzbare Anwendung. Die README sagt folgendes:

The main point in development of pybb is to build it so it could be easily integrated to existing django based site. This mean that pybb does not provide features like user registration, password restoring. It does not provide authentication page.

Tja, schön. Ich habe aber keine existierende Django-Anwendung, ich will doch nur ein Forum… Grundsätzlich bin ich zwar bereit, ein paar kleinere Code-Änderungen vorzunehmen, aber das darf nicht in eine eigene Anwendung ausarten, die ich dann auch noch selbst maintainen muss. Da habe ich so schon genug zu tun…

Die Demo beglückt uns momentan mit 502 Bad Gateway. So kann ich mir nichtmal ansehen, wie es denn aussehen würde.

DjangoBB

Meine letzte Anlaufstelle (bis jetzt) heißt DjangoBB. Diese Software scheint noch ein wenig im Flux zu sein, funktioniert annehmbar gut und sieht ganz hübsch aus. Es gibt sogar Themes (allerdings gefällt mir das Standard-Theme, das man auch in der Demo sieht, am besten). Die Administration ist möglich, aber übersichtlich gehalten — Posts können gelöscht und bearbeitet werden, Nutzer kann man löschen (aber nicht sperren). Positiv hervorzuheben ist die gelungene Kombination aus Gravatar und selbst hochladbarem Avatar, der dann den Garavatar ersetzt. Allerdings kann man wohl keine Verwarnungen aussprechen und der Hauptteil der Administration besteht einfach darin, den Record direkt über ein Formular zu editieren; so unterscheidet sich der Administrationsbereich für Nutzer überhaupt nicht von den persönlichen Einstellungen der einzelnen Nutzer.

DjangoBB ist verdammt schlecht dokumentiert. Der Entwickler ist ein Russe und seine gesamte (!) Installationsanleitung beschränkt sich auf (Quelle):

wget https://bitbucket.org/slav0nic/djangobb_project/get/tip.tar.gz
 tar zxvf tip.tar.gz
 cd slav0nic-djangobb_project-tip/
 pip install -r requirements.txt
 cd basic_project/
 touch local_settings.py
 # set DATABASE
 ./manage.py syncdb --all
 ./manage.py collectstatic
 ./manage.py runserver

Der Hinweis will be soon unter Dokumentation steht da bestimmt schon seit Jahren. Deswegen hier eine etwas ausführlichere Anleitung:

DjangoBB besteht aus einer einhängbaren App und einem Gesamtprojekt. Mithilfe der App ist es möglich, DjangoBB in die eigene, bereits bestehende Django-Anwendung zu integrieren, wohingegen das Gesamtprojekt für eine Installation als Einzelanwendung gedacht ist. Was aus der nicht vorhandenen Dokumentation allerdings nicht hervorgeht, ist, dass das Gesamtprojekt-Repository nicht vollständig ist und noch ein paar Handgriffe erfordert, bevor das Forum läuft. Dazu ist zunächst der aktuelle Trunk herunterzuladen und zu entpacken:

$ mkdir ~/djangobb
$ cd ~/djangobb
$ wget https://bitbucket.org/slav0nic/djangobb_project/get/tip.tar.gz
$ tar -xvzf tip.tar.gz

Danach hat man ein Verzeichnis djangobb_project vorliegen, in dem sich eine unvollständige requirements.txt für PIP sowie ein Unterverzeichnis basic_project befinden, um die wir uns entgegen der Mikro-Anleitung erstmal nicht kümmern. Vielmehr ist es zunächst erforderlich, die DjangoBB-App herunterzuladen und zu entpacken:

$ wget https://bitbucket.org/slav0nic/djangobb/get/stable.tar.gz
$ tar -xvzf stable.tar.gz
$ mv slav0nic-djangobb-* djangobb

Der letzte Befehl vereinfacht die Sache für uns, da das Archiv nur ein von Bitbucket automatisch erstellter Snapshot ist und das enthaltene Verzeichnis den gekürzten Commit-Hash enthält, der einfach nur sperrig ist. Nun gilt es zunächst, die App in das Gesamtprojekt zu integrieren:

$ cd djangobb_project/basic_project
$ mv ../../djangobb/djangobb_forum ./

So und nur so weiß Django überhaupt, wo es das Modul djangobb_forum suchen soll, dessen Fehlen es sonst moniert:

ImportError: No module named djangobb_forum

Nun gilt es zuächst, eine isolierte Umgebung für die Installation der Zusatzlibraries zu erhalten und sodann ebendiese zu installieren. Dazu erst einmal in unser als erstes angelegtes Verzeichnis zurückwechseln:

$ cd ~/djangobb

Bei meiner Kurzeinarbeitung in Django habe ich gelernt, dass das, was man in Ruby mit RVM-Gemsets zu lösen pflegt, mit virtualenv gemacht wird. Wir legen also ein Isolationsverzeichnis für unsere Bibliotheken an und laden virtualenv in unsere Shell (das Verzeichnis .env ist wohl Konvention, man kann aber auch ein beliebiges anderes wählen):

$ virtualenv .env
$ . .env/bin/activate # Beachte den . am Anfang!

Das setzt eine Bash oder Z-Shell voraus. activate wird jedoch auch für die CSh und Fish angeboten.

Jetzt können wir also daran gehen, die Abhängigkeiten zu installieren. Wie schon weiter oben geschrieben, ist die die im Gesamtprojekt enthaltene requirements.txt unvollständig. Sie enthält nämlich nur die für das Gesamtprojekt erforderlichen Abhängigkeiten, nicht aber jene für die DjangoBB-App. Um eine vollständige requirements.txt zu erhalten kleben wir die zwei einfach zusammen:

$ cat djangobb/extras/requirements.txt djangobb_project/requirements.txt > requirements.total.txt
$ echo psycopg2 >> requirements.total.txt

Die letzte Zeile installiert den PostgreSQL-Adapter für Python, sodass wir als Datenbank Postgres verwenden können. Möglich wären auch MySQL, SQLite3 oder was auch immer Django alles unterstützt. Dann müsst ihr die obige Zeile an euren Adapter anpassen.

Jetzt das ganze installieren:

$ pip install -r requirements.total.txt

Erst jetzt kommen wir auf die Mikro-Anleitung zurück. In das Gesamtprojekt wechseln und dort die Datenbank konfigurieren:

$ cd djangobb_project/basic_project
$ $EDITOR settings.py

Man kann wohl auch eine Datei local_settings.py anlegen, aber ich habe mich der Einfachheit wegen entschlossen, einfach direkt settings.py zu bearbeiten. Darin müssen vor allem zwei Dinge gesetzt werden:

  1. Die Datenbankverbindung
  2. Die Zeitzone

Die Datei ist da ziemlich selbsterklärend, hier die Ausschnitte aus meiner Konfiguration:

# ...

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'djangobb',                      # Or path to database file if using sqlite3.
        'USER': 'quintus',                      # Not used with sqlite3.
        'PASSWORD': 'quintus',                  # Not used with sqlite3.
        'HOST': '127.0.0.1',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

# ...

TIME_ZONE = 'Europe/Berlin'

# ...

Weiter geht es mit den drei abschließenden Befehlen der Mikro-Anleitung, die die Datenbank vorbereiten und dann den Server starten:

$ python manage.py syncdb --all
$ python manage.py collectstatic
$ python manage.py runserver

Der erste Befehl fragt nach, ob ein Admin-Account erstellt werden soll. Dem sollte auf jeden Fall nachgekommen werden, da es sonst keine Admins in der fertigen Installation gibt. Der zweite Befehl warnt vor der Überschreibung vorhandener Daten, was aber getrost ignoriert werden darf. Und der letzte Befehl schließlich starten den Django-Server, sodass wir unser neues Forum testen können. Dazu einfach http://localhost:8000/forum besuchen.

Fazit

Ich weiß noch nicht. DjangoBB hat mich einiges an Zeit gekostet, aber ich wollte unbedingt mal das Admin-Interface sehen, welches mich dann aber doch enttäuscht hat. Die anderen Alternativen sind entweder Engines oder noch nicht wirklich ausgegoren (oder miserabel dokumentiert). Mag sich jeder selbst ein Bild machen — zurück bleibt der säuerliche Geschmack, dass nur die PHP-basierten Foren wirklich benutzbar sind. Dies dann aber auf Kosten brauchbaren Quellcodes.

Valete.