Wenn der Kunde nicht viel Geld in seinen Webauftritt stecken will, aber dennoch auf dem Einsatz eines Content-Management-Systems (CMS) besteht, weil er zwecks Kostenersparnis auch die Inhalte selber einpflegen will, ist guter Rat gefragt. Dass dieser Rat nicht teuer sein muss, zeigt das relativ neue System “SkyBlueCanvas” (SBC). SBC verzichtet auf allerlei Schnickschnack und kann für den Webmaster kleinerer Websites durchaus die maßgeschneiderte Lösung sein. Lassen Sie uns ein/zwei Blicke darauf werfen…

Achtung: Schwerwiegende Problematik!

SkyBlueCanvas (SBC) will sich als das “Lightweight-CMS” positionieren. Dazu passt definitiv die geringe Größe von rund 4 MB im entpackten Zustand. Ebenfalls passend ist der Verzicht auf eine Datenbankanbindung. SBC funktioniert rein unter Verwendung des Dateisystems. An dieser Stelle sei daher gleich der Hauptkritikpunkt genannt. Immerhin wird der eine oder andere Leser danach nicht mehr weiterlesen wollen. Auf den meisten Shared Hosting-Angeboten wird SBC auf Anhieb nur zum Laufen zu bringen sein, wenn man allen Dateien und Ordnern das berüchtigte 777 zuordnet. Mir ist es mit keiner anderen Kombination gelungen, SBC in Betrieb zu nehmen. Natürlich ist ein Produktivbetrieb mit einem völlig schreiboffenen System nicht zu empfehlen. Hier wäre also zunächst mit dem Hoster des Vertrauens abzuklären, wie diesem Problem eventuell begegnet werden kann. Betreiber von Rootservern wissen ohnehin, was zu tun ist. Kann diese Problematik gelöst werden, wird SBC aber durchaus überzeugen.

[SBC sagt, wo 777 erforderlich ist. Das ist aber nur die halbe Wahrheit.]

Die Installation

Hat man SBC herunter geladen und entpackt, schickt man es mit dem FTP-Client seines Vertrauens auf den Webspace. Dieser Vorgang ist aufgrund des geringen “Gewichts” von 4 MB auch deutlich schneller erledigt als bei bekannten Dateiadipösen wie “WebEdition” (36 MB). Eine von anderen Systemen geläufige Konfiguration gibt es bei SBC nicht. Hochladen, Nutzer anlegen, einloggen (jedenfalls im Prinzip). Die Einrichtung einer Datenbank ist nicht nur nicht erforderlich, sondern auch optional nicht möglich, da SBC sämtlichen Content in Dateien speichert.

An just dieser Stelle geriet meine Installation ins Trudeln. Nach Aufruf meiner als Subdomain eingerichteten SBC-Installation erwartete ich den angekündigten Installationsscreen, der mir zeigen würde, ob die Serverkonfiguration den Anforderungen SBCs entspräche. Leider erhielt ich eine PHP-Fehlermeldung, die auf Berechtigungsprobleme schließen ließ. Ich hatte zwar den gesamten SBC-Ordner, wie in der Dokumentation gefordert, mit dem Recht 755 ausgestattet, dies erwies sich jedoch als nicht hinreichend. Auch die Vergabe von 775 brachte keine Verbesserung. Erst, als ich dem Data-Verzeichnis testweise 777 zuordnete, erhielt ich die Installationsübersicht, die mich recht unmissverständlich davon in Kenntnis setzte, dass in meinem Falle eine Serverkonfiguration vorläge, die die Vergabe von 777 an ALLE Ordner und Dateien erforderlich machte. Gleichzeitig riet das Script verständlicherweise davon ab, genau dies zu tun.

Zu Testzwecken warf ich den freundlichen Hinweis über Bord und stellte bei dieser Gelegenheit fest, dass mein FTP-Client (WS_FTP Pro) selbst dann die Rechte nicht an die in den Ordnern befindlichen Dateien weiterreichte, wenn man ihn vermittels Häkchensetzung ausdrücklich dazu zu zwingen meinte. Was folgte, war eine elende Klick-Orgie durch sämtliche Verzeichnisse des SBC, um auch der hinterletzten Datei tatsächlich 777 zuzuordnen. Zwischendurch war ich der Auffassung, ich hätte die wichtigsten Ordner bereits bearbeitet und könnte nun mit der 777ifizierung aufhören. Ein Irrtum, der sich schnell rächte. Als ich letztlich das System vollständig “worldwriteable” gemacht hatte, funktionierte nicht nur die Installation, sondern auch der folgende Betrieb einwandfrei.

Das Benutzerkonzept

SBC verfolgt ein leicht verständliches Konzept. Alle Seiten sind Pages, die Unter- und Oberpages haben können. Die Reihenfolge der Seiten, für die übrigens automatisch Menü-Einträge erzeugt werden, ist frei änderbar. Ebenso können Seiten, also Pages jederzeit ausgeblendet (unpublish) werden. Die Änderung der Inhalte findet nicht In-Context, sondern in einem Editor, also klassisch CMS-sig statt. Zum Einsatz gelangt der WYMeditor, alternativ kann auch TinyMCE gewählt werden. An dieser Stelle lässt das System keinen der gängigen Wünsche unbeachtet. Besonders komfortabel ist das Einbinden von Multimediadaten aus der integrierten Galerie samt Vorschaubildchen, wobei mich hier besonders die Geschwindigkeit des SBC in Erstaunen versetzte. Nahezu ohne Wartezeiten werden die Thumbnails auch bei größeren Galerien geladen. Insgesamt setzt SBC auf schick ajax-ifizierte Dialoge, die stets geradlinig zielführend sind.

Zu jeder Page gibt man in dem mit “Meta Data” betitelten Karteireiter die wesentlichen, die Anzeige steuernden Informationen an. Dazu gehört, ob die Page eine Unterpage ist, wie sie im Browsertitel erscheinen soll, welcher Titel = Dateiname vergeben wird, welches Layout (dazu gleich mehr) zum Einsatz kommt und einiges andere, wie die klassischen Metatags, die Seitenreihenfolge et cetera mehr.

Dateien, wie Bilder, PDFs und so weiter werden im Backend unter dem Punkt “Pictures” verwaltet, der besser “Media” geheißen hätte. Hier jedenfalls lädt man Mediendateien hoch und ordnet sie in verschiedenen Verzeichnissen nach eigenem Gusto. Innerhalb dieser Strukturen kann man die Dateien frei hin und herschieben, umbenennen, löschen oder neu hinzufügen.

Die Entwicklerseite

Der Entwickler findet unter dem Punkt Collections die wesentlichen Zugangsmöglichkeiten zum System. Hier werden sämtliche Systembestandteile, sowie optionales Zubehör verwaltet. Dazu gehören Menüsysteme, Module, Plugins, Fragmente und die noch größeren Funktionseinheiten, die so genannten Manager. An dieser Stelle verliert sich das Entwicklerteam unnötigerweise in Vokabeln, die ansonsten nicht unbedingt zum Üblichen gehören und auch nicht intuitiv, auf den ersten Blick klar voneinander abgegrenzt werden können. Insofern verwundert es nicht, dass der Entwickler selbst davon spricht, das Konzept der Collections sei etwas “tricky”.

Im Wesentlichen: Jegliche Inhalte werden in XML-Dateien an definierten Stellen im Dateisystem abgelegt und auf verschiedene Arten wieder ins Layout zurückgelesen. Die größte Bedeutung kommt dabei den sog. Fragments zu. Fragments stellen die Platzhalter für den dynamischen Content dar und heißen anderswo Tags, Blocks, Hooks oder sonst noch wie. Der Unterschied zwischen Fragments und den statischeren Vertretern aka Tags ist, dass etwa zusätzlich erforderlich werdende Fragments relativ einfach vom Entwickler definiert werden können. Dadurch erreicht das System mit Know-How betrieben eine hohe Flexibilität. Zusätzliche vordefinierte Fragments, Plugins et cetera gibt es auf der Downloadsseite, das Knowhow wird hier vermittelt. Mit den bereits vorhandenen Elementen wird der Standardwebsite allerdings jedenfalls gerecht zu werden sein, sprich, man muss das Prinzip nicht durchdrungen haben, um funktionierende Auftritte zu bauen.

Skins, Themes, Templates, Layouts

Auch mit Blick auf die Frontend-Optik ist der Entwickler nicht eben strikt in seiner Wortwahl. Gern verwendet er das Wörtchen Skin für die optische Darstellung der Website. Da so auch das entsprechende Verzeichnis im Unterverzeichnis “Data” benannt ist, bleiben wir hier auch dabei. Ein Skin besteht im Wesentlichen aus HTML- und CSS-Dateien nebst den dazugehörigen Bildern und Grafiken, sowie erforderlichenfalls Javascripts. Innerhalb eines Skin wird noch zwischen verschiedenen Layouts unterschieden. Unterschiedliche Layouts werden als eigenes HTML-Template im Rahmen einer Untermenge zum Haupttemplate abgelegt und tragen im Namen den klaren Hinweis auf ihre Funktionalität. Das Haupttemplate heißt stets “skin.default.html”. Ein spezifisches Layout beispielsweise für ein Kontaktformular hieße dann “skin.contacts.html”. Gleiches gilt für jegliche anderen etwa erforderlichen Sonderlayouts wie Foren, Bildergalerien et cetera.

Verschiedene, durchaus ansprechende, frei verwendbare Skins können hier heruntergeladen werden.

Die Portierung eines Standard-HTML-Templates in den SBC-Sprachraum beschreibt der Entwickler hier sehr ausführlich, wobei er einen Zeitbedarf von lediglich dreißig Minuten angibt. Für eine im Wesentlichen textlastige Site mit wenig mehr als einem Kontaktformular mag das stimmen, aufwändigere Kompositionen benötigen natürlich ungleich mehr Zeit. Dennoch muss man einräumen, dass das Konzept prinzipiell eingängig und nur mäßig kompliziert ist, vergleicht man es mit anderen, sich selbst als simpel bezeichnenden Systemen am Markt. Auch das beliebte WordPress, das ja vermutlich schon fast jeder Leser dieses Beitrags mindestens einmal gethemed hat, ist vergleichsweise komplizierter.

Reicht dem Entwickler bei besonders aufwändigen Aufträgen das Konzept der Fragments nicht, wird er freudig zur Kenntnis nehmen, dass auch unter SBC weitere Hooks zur Verfügung stehen. Um diese nutzbar zu machen, benötigt man allerdings das SiteVars-Plugin.

Fazit: SBC ist ein auf das Nötigste abgespecktes, dabei aber fast beliebig aufspeckbares System für den kleinen Webauftritt ohne größere Kompromisse. Die Absenz einer Datenbank ist unter Performance-Gesichtspunkten unproblematisch. Die Ablage im Dateisystem ist logisch organisiert. Lediglich die Rechte-Erfordernisse bei vielen Shared Hosting Spaces prädestinieren SBC nicht überall als Mittel der Wahl. Wer jedoch an der filigranen Rechtevergabe etwa eines eigenen Servers nicht gehindert ist oder einen gesprächsbereiten Provider hat, wird nur schwer ein System finden, dass mit einer so geringen Einarbeitungszeit, sowohl auf Benutzer- wie auch auf Entwicklerseite dermaßen moderne, dabei valide Ergebnisse hervorzubringen im Stande ist. ™