www.harrenberg.de

Silverstripe

SilverStripe ist ein freies (Open Source) CMS (Content Management System)

Einleitung

Silverstripe ist einfach aufzusetzen und zu bedienen, daher auch für Anfänger mit Content Management Systemen geeignet, ohne das man gleich zum Systemadministrator werden muss.

Solange man mit dem Standard Theme (eine Art Stil-Datei) oder einem der vielen fertigen Themes zufrieden ist, kann man innerhalb einer halben Stunde loslegen, sofern man einen lauffähigen Webserver mit PHP5 und MySQL Datenbank hat.

Für die ersten Schritte, oder zum Antesten und Ausprobieren nimmt man am einfachsten LAMP/XAMP/WAMP/WAMPServer und installiert die SilverStripe Dateien in das "home"-Verzeichnis des Webservers. Danach einfach http://localhost im Browser aufrufen und das Intallationsprogramm führt webbasiert durch alle Schritte. Danach kann es dann auch direkt losgehen. So ein Testsystem mit einem WAMP-Server läuft selbst auf einem kleinen eEEE-PC mit nur 1GB Speicher unter Windows7 zum Ausporbieren noch akzeptabel gut.

Interessant wird es erst, wenn man so wie ich, mit keinem der Themes so richtig zufrieden ist, oder aber, was eher vorkommt, ich einfach etwas ändern möchte, um zu sehen welche Auswirkungen es hat. Ich habe mich z.B. entschlossen in einem ersten Schritt einfach das Standard Theme etwas breiter zu machen.

Ich habe mich für das (damalige) Standard Theme entschieden weil mir dort das Layout der Navigation am besten gefallen hat (und es im Gegensatz zu den meisten anderen Themes 3 Navigationsebenen unterstützt). Die (wenigen) Änderungen an am Theme werde ich in Kürze hier mal als Beispiel auflisten. Mittlerweile ist das Theme Blackcandy als Standard zwar abgelöst worden, funktioniert natürlich aber immer noch.

Update auf Version 3

Gestartet habe ich mit Silverstripe irgendwo bei der Version 2.3 oder 2.4, seit Mitte 2012 war Version 3 verfügbar, auf die ich dann auch umgestiegen bin. Das ging nicht ganz so einfach wie ich mir das gewünscht hätte. Zum einen hatte ich Probleme mit der Datenbank, anscheinend habe ich mal ein paar in das CMS hochgeladene Files händisch aus dem Verzeichnis gelöscht, das mochte das CMS erst mal nicht. Hauptproblem war aber, das der "Siteexporter", ein Modul zum exportieren von statischen Seiten, nicht mehr funktionierte. Hier musste ich sogar etwas am Code ändern damit der wieder lief. Da dieses Modul nicht mehr unterstützt wird und immer mehr und umfangreichere Änderungen benötigte, bin ich mittlerweile auf StaticExporter aus dem Modul StaticPublisher umgestiegen.

Update auf Version 3.1.0beta1

Nachdem dieses Update seit einiger Zeit hier lief, war es natürlich Zeit für das nächste Upgrade... ,-)

Also kurzerhand die vorhandene Datenbank gesichert und unter einem neuen Namen als Kopie eingespielt, die Beta-Version installiert und auf die Kopie losgelassen. Frontend der neuen Version sieht schon mal aufgeräumter aus und bietet z.B. eine kombinierte Ansicht von Editor und Vorschau. Soweit so gut, aber so ganz problemlos lief es dann leider doch nicht. Zum einen liessen sich keine Links auf Unterseiten erzeugen (Fehler im Frontend), zum anderen lief der "Siteexporter" schon wieder nicht!

Update V3.1.x-dev (Developerversion)

Nachdem das Update auf die 3.1beta im ersten Versuch bei mir nicht so gut lief, habe ich erst mal auf einer Virtuellen Maschine (unter Debian 7 "Wheezy") weiter herumgespielt und dort die Developerversion 3.1.x-dev installiert. Das System läuft mittlerweile so gut und stabil, das ich mich entschlossen habe, meine Webseiten auf dieser Developerversion weiter zu bearbeiten.

Umstieg auf StaticExporter

Da diie nötigen Änderungen am Siteexporter immer umfangreicher und komplexer wurden, bin ich auf ein anderes Modul Namens "StaticPublisher/StaticExporter" umgestiegen. Hiervon nutze ich nur den "StaticExporter", der ähnlich wie der SiteExporter die Seiten als statische html-files in ein Archiv schreibt. Hier gibt es in der originalen Version außer der Angabe der "Ziel-URL" nichts einzustellen.

Ein wichtiger Unterschied zum SiteExporter ist allerdings die Tatsache, das die Verschachtelung der Verzeichnisse und der dazugehörenden Webseiten anders ist!

Der alte SiteExporter hat z.B. für weitere Ebenen in der Web-Hirachie ein Verzeichnis und eine gleichnamige HTML-Datei im akutellen Verzeichnis erstellt. Hierdurch gibt es unter anderem einige Probleme wenn man Unterverzeichnisse über eine .htaccess Datei im Zugriff sperren will. Die zum Verzeichnis gehörende Datei liegt ja außerhald dieses Verzeichnisses, sodass es nicht reicht einfach das Verzeichnis zu sperren.

Im Unterschied dazu legt der StaticExporter ein Verzeichnis an und dann in diesem Verzeichnis eine "index.html". Hier ist es dann viel einfacher und intuitiver den Zugriff zu regeln. Allerdings muss ich jetzt meine Web-Struktur entsprechend anpassen und die .htaccess Datei neu erzeugen.

Nachtrag/Update: Umstieg auf StaticExporter

Leider habe ich erst nach der Umstellung auf StaticExporter und dem Anpassen der  Verzeichnisstruktur und .htaccess Dateien bemerkt, das die von StaticExporter erzeugten Seiten fehlerhaft sind! Die Navigationsleiste mit den Unterseiten in der linken Sidebar wurden beim Export nicht an die erzeugte Seite angepasst, und zeigten immer den gleichen Zustand an.

Dies lag daran, das in einer internen Funktion standardmäßig ein Cache aktiv ist, der in dem Skript nicht gelöscht wird. Ich hatte  mir kurzerhand damit beholfen, in dem PHP-Skript vor dem Erzeugen jeder Seite den globale Cache zu löschen. Diese Lösung ist mittlerweile sogar der offizielle Fix für den Bug. ;-)

Standardmäßig export StaticExporter ALLE Seite, d.h. auch die noch im Entwurf befindlichen Seiten. Da diese Seiten normalerweise NICHT auf den Webserver kopiert werden sollen, muss hier jedesmal händisch gelöscht werden.

Da außerdem standardmäßig immer das Konfigurationsverzeichnis mit exportiert wurde, und ich das dann auch jedesmal löschen musste, dafür aber das "themes" Verzeichnis nicht exportiert wurde, habe ich das PHP-Skript angepasst und kann das Exportieren jetzt über zusätzliche Checkboxen im Webformular konfigurieren.

Die dafür nötige Anpassung sind unter StaticExporter3 beschrieben.

Anpassungen

LastEdit

Bisher habe ich Silverstripe nur sehr geringfügig anpassen müssen, zum einen betrifft dies das Theme selbst, zum anderen das Einfügen des "LastEdit"-Datums, also des Datums mit dem lezten Aktualisierungsdateums. Die Änderung ist sehr einfach und ist hier beschrieben.

Source (PageType)

Um mehr Platz für die Darstellung von Source zu haben, habe ich einen neuen Seitentyp "Source" erzeugt, der keine SideBar anzeigt. Außerdem habe ich die Formatierung von "pre" etwas angepasst. Die Änderungen sind hier beschrieben.

StaticExporter3

Anpassungen am Modul StaticExporter um den Export der statischen Seiten besser steuern zu können. Weitere Informationen zu der Anpassung gibt es hier.