OpenSocial mit Elgg

Die Dokumentation von Elgg – einer Open Source Social Networking Plattform – wirbt damit, über das Apache Shindig Plugin zum Container für OpenSocial Widgets zu werden. Es gibt bloß ein Problem: Im Auslieferungszustand funktioniert das Plugin nicht. Schlimmer noch, bei der Installation sind schnell alle Tipps der README verbraucht und man steht mit den auftretenden Problemen allein da. In Konsequenz scheint sich das Plugin seit 2008 nicht weiterentwickelt zu haben – im Gegensatz zu Elgg und Apache Shindig selbst. Während Shindig mittlerweile bei OpenSocial 0.9 angekommen ist (in Version 1.1), unterstützt das Plugin OpenSocial 0.7.

So recht kann man den Elgg Entwicklern keinen Strick daraus drehen. Apache Shindig erweist sich selbst nicht als simples Tool, das Einrichten geht fernab der präferierten Installation auf einem eigenen (virtuellen) Host nicht leicht von der Hand, zumal hier unterschiedliche Konfigurationsdateien anzupassen sind. Ferner bestehen Unterschiede zwischen den Versionen: nachdem ich Shindig 1.0 (OpenSocial 0.8.1) einmal als Elgg Plugin zum Laufen hatte, bin ich mit meiner selbst geschriebenen Installationsanleitung für Shindig 1.1b5 kläglich gescheitert. Im Gegenteil, dass sie bei allen Spielereien und Versuchen mit den Konfigurationen irgendwann funktionierte, war eher unerwartet. Herausgekommen ist eine Version, die keine guten Werte in den Compliance Tests erreicht (68 Tests bestanden, 40 nicht bestanden), schlecht dokumentiert ist bzw. keine ausführliche Installationsanleitung mitbringt, und in denen noch hart verdrahtete Pfadangaben existieren.

Nichtsdestotrotz kann diese Version hier heruntergeladen werden. Ich hoffe damit auf ein Publikum aus Entwicklern zu stoßen, die das Plugin mit eigenen Ideen stabilisieren und verbessern. Anstehende Aufgaben sind zum aktuellen Zeitpunkt:

  • Entfernen der hart verdrahteten Pfade (.htaccess, PHP Konfig: local.php, JavaScript Konfig: container.js).
  • Umstellen der Shindig Interfaces auf MySQL statt JSON (möglicherweise mit Partuza Code), um es mit der Elgg Datenbank zu nutzen.
  • Reload des Widgets nach Verschieben im Dashboard
Advertisements

CodeIgniter installieren und einrichten

Auf der Suche nach dem richtigen Framework habe ich schon die ein oder andere Alternative ausprobiert und bislang alle wieder verworfen. Einige bekannte Vertreter waren dabei, z.B. CakePHP, und viele unbekannte, denen ich eine Chance geben wollte. Mein derzeitiger Liebling ist CodeIgniter, weil sich damit bei extrem flacher Lernkurve schnell Anwendungen erstellen lassen. CodeIgniter punktet mit großem und leicht handhabbarem Funktionsumfang und komfortabler Erweiterbarkeit durch eigene Libraries (oder die Anpassung bestehender Libraries).
Den Ausschlag CodeIgniter einzusetzen hat letztlich eine Serie von Videotutorials auf Nettuts namens „CodeIgniter From Scratch“ gegeben. Die Tutorials betrachten jeweils unterschiedliche Aspekte des Frameworks, angefangen von MVC über Datenbankzugriffe bis hin zu den eingebauten Kalender- und Shop-Libraries. Jedes Tutorial beginnt mit einer frischen Installation und mit der Zeit bekommt man eine ganze Reihe von Tipps und Tricks, die man bei der Konfiguration beachten sollte.

Der Einfachheit halber hier eine Checkliste aller notwendigen oder hilfreichen Einstellungen.

Installation

  • Download des Packages und Entpacken in ein Ordner unter htdocs (in diesem Beispiel ci).
  • Verschieben des Ordners ci/system/application nach ci/application
    Dieser Schritt ist nicht notwendig, sorgt aber für eine sichtbare Trennung des Basissystems und den anwendungsspezifischen Skripten
  • Löschen des Ordners ci/user_guide, sofern er nicht noch zum Nachschlagen während des Programmierens gebraucht wird.
    Ohne die Dokumentation entpuppt sich CodeIgniter als Leichtgewicht mit knapp einem Megabyte Platzbedarf.


Konfiguration

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /ci/index.php?/$1 [L]
</IfModule>

  • Einstellungen an der Datei ci/application/config/config.php

$config['base_url']    = "http://host/ci/"; //Standardpfad für den Zugriff per Browser
$config['index_page'] = ""; //nur dann das voreingestellte index.php entfernen, wenn die .htaccess verwendet wird
$config['encryption_key'] = "fzDfe64dsL§dsiitDvFoFD%3DrekDw1!"; //zufälliger Schlüssel für encode/decode Funktionen und die Sessionverschlüsselung
$config['sess_cookie_name']        = 'ci'; //Name passend zur Webseite
$config['global_xss_filtering'] = TRUE; //Automatische sicherheitsbedingte Eingabeprüfung

  • Festlegen der vorab geladenen Libraries, Helper, Models, etc. in der Datei ci/application/config/autoload.php
    Normalerweise werden benötigte Features in den Methoden der Controller per $this->load geladen. Anstatt eine häufig benutzte Library aber in jedem Controller einzeln einzubinden, z.B. die Datenbankanbindung, kann man diese zentral laden lassen.
  • Pflege der Zugangsdaten bei Verwendung einer (relationalen) Datenbank wie MySQL in der Datei ci/application/config/database.php

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "";
$db['default']['password'] = "";
$db['default']['database'] = "";

  • Definition des Controllers, der standardmäßig, also bei Aufruf von http://host/ci angezeigt wird (Einstellung in ci/application/config/routes.php)
    Im Auslieferungszustand enthält CodeIgniter einen beispielhaften Controller namens Welcome, der lediglich eine Nachricht im Browser ausgibt. Diesen kann man getrost löschen, muss dann aber in der routes.php Datei eine Alternative angeben.

$route['default_controller'] = "controllername"; //Standard ist welcome