PyroCMS

PyroCMS ist ein relativ einfaches Content Management System auf Basis des CodeIgniter-Frameworks.

Nach der Installation bietet das System verschiedene Module (Forum, News, Newsletter, Gallerie) und Widgets (RSS, Twitter, HTML, etc.) an, die man in eine Website einbinden kann. Ansonsten ist die Arbeitweise so, wie man sie von vielen anderen CMS her kennt: man legt eine Seitenstruktur an bei der jede Seite ein eigenes Layout, eigene Meta-Daten, etc. haben kann und definiert dann eine eine hierarchische Navigation in die die Seiten und Module eingebunden werden (man kann also z.B. festlegen, dass der Menüpunkt “Impressum” die Seite “Impressum” anzeigt und z.B. der Menüpunkt “Kontakt” ein Modul “Kontaktformular” aufruft, etc.).

Was ich persönlich ungemein praktisch an PyroCMS finde ist, dass es so einfach ist. Dadurch wird es zu einer guten Basis für eigene Projekte, da das System über eigene Module entsprechend erweitert werden kann und man sich über den “lästigen Kleinkram” (sprich: Erstellung von normalen Seiten und der Navigation) kaum Gedanken machen muss.

Die Version 1.0 von PyroCMS (aktuell ist 0.9.9.6) soll übrigens auch schon CodeIgniter 2 als Basis nutzen was die Performance nochmal erhöhen soll und neue Features erlaubt.

Da ich aber für das Projekt die MySQLi-Variante bevorzuge habe ich mir einmal angeschaut wo das eigentliche Problem liegt. Prinzipiell sollte es ja kein grosses Problem sein die MySQL-Funktionalität zu portieren.

Wenn man sich die Datei mysql_utility.php anschaut wird schnell klar, dass die _backup()-Funktion nur zwei MySQL-spezifische Befehle nutzt: mysql_fetch_field() und mysql_field_type(). Nach ein wenig testen bin ich auf folgende Lösung gekommen um die backup-Funktion sauber mit MySQLi nutzen zu können:

Schritt 1

Man überschreibt die _backup()-Funktion in mysqli_utility.php mit der kompletten Funktion aus mysql_utility.php

Schritt 2

Man ersetzt in der Funktion in mysqli_utility.php den folgenden Code-Block:

[php]$i = 0;
$field_str = ”;
$is_int = array();
while ($field = mysql_fetch_field($query->result_id))
{
// Most versions of MySQL store timestamp as a string
$is_int[$i] = (in_array(
strtolower(mysql_field_type($query->result_id, $i)),
array(‘tinyint’, ‘smallint’, ‘mediumint’, ‘int’, ‘bigint’), //, ‘timestamp’),
TRUE)
) ? TRUE : FALSE;

// Create a string of field names
$field_str .= ‘`’.$field->name.’`, ‘;
$i++;
}[/php]

durch

[php]$i = 0;
$field_str = ”;
$is_int = array();

while ($field = mysqli_fetch_field($query->result_id)) {

$is_int[$i] = in_array((int)$field->type,array(1,2,3,8,9));

// Create a string of field names
$field_str .= ‘`’.$field->name.’`, ‘;
$i++;

}[/php]

Schritt 3

Man freut sich über die nun (hoffentlich ) funktionierende Backup-Funktion.

Meine bisherigen Tests mit ein paar Datenbanken lefern identische Ergebnisse für Beide Varianten.

(( Da der Artikel wahrscheinlich nur für einen Teil der Blog-Besucher interessant ist habe ich ihn Extra nur gekürzt auf der Startseite veröffentlicht – das nur als Hinweis falls sich jemand gewundert hat ))

Solltet ihr jemals auf die Idee kommen die getScript()-Funktion von jQuery zu nutzen um JavaScript-Code auszuführen den ein CI-Controller zurückliefert werdet ihr sehr wahrscheinlich über das Problem stolpern, dass getScript() an die URL die ihr aufruft ein “?_=xxxx” anhängt. Angenommen Ihr wollt also

http://eure-domain/gib/mir/javascript

aufrufen, dann ruft jQuery in Wirklichkeit z.B.

http://eure-domain/gib/mir/javascript?_=1234567890

auf. Dies macht jQuery um das Caching zu verhindern. Für CI ist das aber tödlich und führt zu einem klassischen “404 – Page not found” Fehler.

Man kann dieses Verhalten leider nicht ohne weiteres umgehen (es sei denn, man aktiviert in CI die Nutzung des Query-Strings wieder was aber ein paar Nachteile hat). Allerdings gibt es einen einfachen Ersatz. Statt getScript() nutzt man einfach die ajax() Funktion von jQuery:

$.ajax({
        type:     "GET",
        url:      "http://eure-domain/gib/mir/javascript",
        dataType: "script",
        cache:    true
});

Wichtig dabei ist das “cache: true” weil man sonst wieder in das gleiche Problem läuft. Um das Caching trotzdem zu verhindern sollte man im Controller auf jeden Fall die No-Cache Header mitsenden und man kann natürlich auch statt

http://eure-domain/gib/mir/javascript

einfach

http://eure-domain/gib/mir/javascript/eine_zufällige_zahl

aufrufen. CI stört sich nicht an dem zusätzlichen Parameter und im Controller kann man ihn einfach ignorieren.

Ich hoffe ich kann damit jemandem nervige Debugging-Zeit ersparen

GalleryCMS

GalleryCMS ist eine etwas andere Art von Content Management System. Es dient einzig zur Verwaltung von Bildern. Es können Kategorien angelegt werden in die dann Bilder hochgeladen werden können. Zu jedem Bild legt GalleryCMS dann noch Thumbnails an.

Das Besondere ist, dass GalleryCMS selbst kein Frontend für die hochgeladenen Bilder zur Verfügung stellt sondern lediglich eine XML-Datei mit Allen Informationen ausgeben kann.

Wenn man also z.B. ein Flash-Widget nutzt welches Bilder anzeigen kann und seine Daten aus XML-Dateien ausliest (z.B. http://www.longtailvideo.com/players/jw-image-rotator) kann man die Bilder bequem über GalleryCMS verwalten.

Das Freeware-Script wurde auf Basis von CodeIgniter entwickelt und setzt sowohl PHP als auch MySQL voraus.

Sollte man in der glücklichen Lage sein, dass das Projekt auf CodeIgniter basiert kann man auf ReduxAuth zurückgreifen. RA ist eine Kombination aus einem Model, einer Bibliothek und einigen Views die einige Grundfunktionen für genau diesen Zweck zur Verfügung stellen.

Benutzer können sich registrieren (ggf. mit Account-Aktivierung), Ein- / Ausloggen, ihr Passwort ändern, etc.

Die Bibliothek steht unter der MIT-Lizenz und kann entsprechend frei genutzt werden.