Die Auswahl eines passenden Content Management Systems ist nicht ganz einfach. Zu unübersichtlich ist der Markt, zu viele Anbieter mit zu vielen Produkten versprechen dem hart umkämpften Kunden, ihr jeweiliges Produkt sei der heilbringende Alleskönner von Gottes Gnaden. Wem soll man nun Glauben schenken? Bei genauerer Betrachtung des Marktes wird klar: Keinem. Denn das ultimative Content Management System, das allen Ansprüchen gerecht wird, gibt es nicht - und wird es vermutlich auch nie geben. Der Schlüssel zum Glück ist es also, sich erst einmal über die eigenen Anforderungen im Klaren zu sein. Diese Schlüsselfragen können dabei eine Rolle spielen:

• Möchte ich mehr als eine Website verwalten?
• Soll meine Website in mehreren Sprachen erscheinen?
• Wie viele Redakteure werden später die Inhalte pflegen?
• Brauche ich eventuell ein mehrstufiges Workflowsystem für Artikelfreigaben?
• Spielt die Möglichkeit eines statischen HTML-Exports eine Rolle?
• Erwarte ich höhere Benutzerzahlen und brauche daher ein performanceoptimiertes System?
• Müssen bereits bestehende Anwendungen/Datenquellen integriert werden - wenn ja, welche und in welchem Umfang?
• Reicht die Erzeugung der Website in HTML aus, oder müssen auch multimediale Inhalte wie Flash oder Streaming Video integrierbar sein?
• Was genau wird sich auf meiner Website später abspielen? Welche Interaktionsmöglichkeiten soll der Besucher haben? Sind personalisierte Inhalte gefordert?
• Benötige ich Usertracking oder Bannermanagement?
• Wie hoch sind meine Anforderungen an den Produkt- und Projektsupport?
• Habe ich klare Budgetvorgaben oder einen guten Bekannten bei der Bundesbank?

Je präziser und umfassender die Anforderungen an das CMS formuliert sind, umso mehr erhöht sich die Chance, ein passendes System zu finden. Viele Hersteller schmücken sich mit einem großen Featureumfang, bei dem der Teufel jedoch im Detail steckt: So werden die meisten Hersteller beispielsweise bei der Frage nach der Möglichkeit, Flash-Inhalte einzubinden, noch enthusiastisch nicken. Hakt man jedoch nach und fragt, ob denn das System auch in der Lage ist, die im Browser des Anwenders installierte Flashversion zu erkennen und gegebenenfalls Alternativinhalte anzubieten, oder ob gar systemseitig die Einbindung von dynamischem Flash-Content vorgesehen ist, so stellt sich schnell entweder betretenes Schweigen ein oder es erfolgt eine sehr beliebte Standardantwort: Der Verweis auf das Projekt-Customizing.

Kostenfaktor Customizing

Um dies klarzustellen: Je höher die Ansprüche an ein CMS sind, um so geringer ist die Wahrscheinlichkeit, dass sich ein System findet, welches alle diese Ansprüche von Haus aus erfüllt. Ab einer bestimmten Projektgrößenordnung ist also ein gewisses Maß an Customizing, also der projektbezogenen Hinzuprogrammierung von Features, die nicht Bestandteil des normalen Leistungsumfangs sind, unvermeidbar. Die hierfür entstehenden Kosten sind nicht zu unterschätzen - eine branchenübliche Faustregel besagt, dass die reinen Lizenzkosten des gewählten Produkts noch einmal für das Customizing zu veranschlagen ist. Auf viele Szenarien trifft dies auch zu, während diese Regel bei bestimmten Projekten von vornherein auszuschließen ist: Bei Produkten mit Lizenzpreisen von deutlich unter 5.000 Euro sowie bei Open Source-Produkten dürfte der Customizing-Anteil erheblich höher liegen (sofern diese Produkte ein Customizing überhaupt ermöglichen). Gleiches dürfte für Projekte zutreffen, bei denen es gilt, zahlreiche Schnittstellen zur bestehenden EDV-Infrastruktur aufzubauen (z.B. SAP).

Usability: Der oft unterschätzte Akzeptanzfaktor

Da sich laut obiger Annahme also ohnehin das perfekt ohne Anpassungen passende System kaum finden lassen wird, ist es bei der Produktauswahl um so wichtiger, von vornherein auf die Usability, also die möglichst intuitive und effiziente Benutzerführung, zu achten. Das ist leichter gesagt als getan, denn Lösungsansätze für den grundsätzlichen Aufbau eines CMS gibt es fast so viele, wie es unterschiedliche Systeme gibt - und das jeweilige Grundkonzept schlägt sich natürlich in der Benutzerführung nieder. Um die Qualität der Benutzerführung beurteilen zu können, muss man sich also zunächst mit der grundsätzlichen Funktionsweise und dem Aufbau des Systems vertraut machen. Eine genaue Empfehlung, nach welchen Kriterien hier zu bewerten ist, kann und soll an dieser Stelle nicht gegeben werden - letzten Endes ist es auch immer ein wenig eine Geschmacksfrage, ob die Bedienung eines Programms als einfach oder umständlich empfunden wird. Dennoch sollte auf diesen Faktor großen Wert gelegt werden, denn es hilft nichts, ein technisch überzeugendes CMS aufzusetzen, das von den Redakteuren, die die Inhalte pflegen sollen, nicht akzeptiert wird. Meine persönlichen Tipps zur Vorgehensweise:

• Das Konzept und Design für die zu erstellende Website noch vor der endgültigen Produktauswahl fertig stellen.
• Zwei oder drei Produkte benennen, die in die Endauswahl kommen.
• Von den Herstellern dieser Produkte Testsysteme für einen Zeitraum von mindestens 30 Tagen einrichten und einen Projektcoach zur Verfügung stellen lassen, der nach einführender Schulung der Administratoren diese bei der Umsetzung eines Prototypen unterstützt, der dem erstellten Konzept möglichst weitestgehend entspricht bzw. wichtige Teile davon exemplarisch abbildet (die Administratoren sollten während der Testphase nach Möglichkeit von anderen Aufgaben freigestellt sein). Anschließend bewerten die Administratoren die Flexibilität des Systems beim Aufbau einer Website sowie den Bedienkomfort aus Administratorensicht.
• Nach der Erstellung der Prototypen werden Redakteure benannt, die nach einer kurzen Einweisung exemplarisch Inhalte in die verschiedenen Systeme einpflegen sollen. Diese berichten anschließend über ihre Erfahrungen und bewerten den Bedienkomfort der einzelnen Systeme.

Mit dem in der Gesamtwertung bei der Schnittmenge aus geplanten Projektkosten, Systemleistung und Benutzerakzeptanz am besten abscheidenden System fährt man in der Regel nicht schlecht. Natürlich stellt sich die Frage, ob sich der oben beschriebene Aufwand in jedem Fall lohnt. Das ist selbstverständlich situationsabhängig. Wenn ohnehin nur ein begrenztes Budget zur Verfügung steht, steht dieser Aufwand in keinem Verhältnis zum Anschaffungs- bzw. Projektpreis. Andererseits hört man auch immer wieder von Projekten im sechs- bis siebenstelligen Kostenbereich, die entweder an der Benutzerakzeptanz scheitern oder bei denen Zeit- und Kostenrahmen deutlich gesprengt werden, weil das System in der Praxis nicht alle auf dem Papier wohlklingenden Features so reibungslos und einfach anbietet, wie ursprünglich vermutet. Oftmals hätte dies durch eine solche Testphase vermieden werden können - und in diesen Kostendimensionen wirkt sich diese im Verhältnis auch nicht mehr so stark aus, während sich jedoch die Aussicht auf ein erfolgreiches Projekt stark verbessert. Kommt eine so aufwändige Testphase nicht in Frage, sollte man sich zumindest die Mühe machen und einige Referenzkunden abtelefonieren - so mancher hat bestimmt wertvolle Hinweise anzubieten.

PHP als Systemplattform

Der geneigte Leser des PHP-Magazins hat es auf jeden Fall schon mal ein Stück leichter, sich im Dschungel der Content Management Systeme zu orientieren, denn legt man sich von vornherein auf PHP als Systemplattform fest, sind nur noch knapp 70 Systeme im Rennen. Das ist natürlich immer noch eine ganze Menge. Um die Vorauswahl ein wenig zu erleichtern, finden Sie PDF-Dokumente mit einer Featuretable für die wichtigsten dieser Systeme. Zusätzlich möchte ich im Folgenden auf die bekannteren Systeme aus der PHP-Welt etwas näher eingehen.

SixCMS 5.0

Bei SixCMS handelt es sich um ein klassisches Vorzeigeprojekt, wenn man nach einem auf PHP basierenden Content Management System fragt. Der Grund dafür liegt sicherlich auch darin, dass SixCMS eines der ersten kommerziell erfolgreichen Systeme war - und in der Tat liest sich die Kundenliste mit Namen wie Bertelsmann, Burda, Sony, Siemens und Beate Uhse recht beeindruckend. Technisch zeigt sich die erste Besonderheit darin, dass SixCMS zwar grundsätzlich auf PHP aufsetzt, die Kernfunktionalität jedoch in einer PHP-Extension gekapselt ist, die als solche natürlich in C++ geschrieben wurde. Dies hat den Vorzug, dass die Systemfunktionen bereits vorkompiliert zur Verfügung stehen, also nicht bei jedem Seitenaufruf erneut interpretiert und initialisiert werden müssen - ein klarer Performancegewinn. Über die von der Extension zur Verfügung gestellte Funktion cms_loadvars() kann in eigenen PHP-Scripts dennoch auf Systemvariablen von SixCMS zugegriffen werden. Diese liefert ein mehrdimensionales Array mit allen relevanten Daten über den aktuellen Artikel zurück - beispielsweise dessen Titel, den aktuellen Container und die dazugehörigen Datenbank-IDs bis hin zu den eingebetteten Dateien (z.B. Bilder) oder Beziehungen zu anderen Artikeln. Grundsätzlich besteht eine Website in SixCMS aus so genannten Containern. Diese Bereiche zeichnen sich dadurch aus, dass alle in einem Bereich liegenden Artikel eine identische Datenstruktur aufweisen, die vom Administrator frei definiert werden kann. So kann beispielsweise festgelegt werden, dass alle Artikel innerhalb des Containers Pressemitteilungen grundsätzlich aus einem Titel, dem Text der Pressemitteilung sowie einer Datei zum Download im PDF-Format bestehen sollen. Genau diese Felder können vom Redakteur beim Anlegen eines Artikels in diesem Container dann später bearbeitet werden. Innerhalb eines Artikels kann unter anderem auch ein Datenfeld für die Rubrikzugehörigkeit definiert werden, sodass auch eine tiefer gehendere Rubrizierung möglich ist, als nur über die Container allein. Besitzt der Redakteur entsprechende Rechte, kann er seinen Artikel als ein Highlight deklarieren. Über einen speziellen Abfragetyp lassen sich Listen von als Highlight gekennzeichneten Artikeln ausgeben - zum Beispiel für eine Newsübersicht auf der Startseite. Abfragen sind in SixCMS über die browserbasierte Oberfläche bequem einstellbare Sammlungen von Parametern, mit denen bestimmte Informationen aus dem System ausgelesen werden können - zum Beispiel alle Rubriken innerhalb eines Containers oder alle Artikel, denen das Schlagwort PHP zugewiesen wurde. Zur Darstellung der Ergebnisse kann jeder Abfrage individuell ein eigenes Listentemplate zugewiesen werden, in dem die Werte aus der Abfrage bequem über die SixCMS-eigenen Templatebefehle ausgelesen werden können. In gewissem Umfang sind bereits mit der Basisversion von SixCMS personalisierte Websites möglich: Das System bietet die Möglichkeit, Benutzerprofile anzulegen, mit deren Hilfe ein Benutzer beispielsweise auch eMail-Agenten abonnieren kann, welche ihn bei Veränderungen bestimmter Teile der Website automatisch benachrichtigen. Auch ist es möglich, über Templatebefehle festzulegen, dass einige Inhalte nur für Benutzer zugänglich sind, die einer bestimmten Gruppe angehören. Die auf der diesjährigen CeBIT frisch vorgestellte Version 5.0 bringt außerdem einige interessante Neuerungen mit sich: So ist es jetzt möglich, über in LaTeX verfasste Layoutvorlagen dynamisch PDF-Dokumente aus in SixCMS erfassten Artikeln zu generieren. Redakteure, die schon einmal mehrere Dutzend Artikel für die Onlinestellung frei schalten mussten, werden die neuen Mehrfachoperationen sicherlich zu schätzen wissen, mit denen durch Markieren mehrerer Artikel eine Aktion gleichzeitig auf alle markierten Objekte angewendet werden kann. Durch die Unterstützung von MySQLs Fulltext Index verfügt SixCMS zudem nun über eine leistungsfähige Volltextsuche. So ganz nebenbei bringt Version 5 auch ein völlig neues Usermanagement mit sich, infolge dessen auch ein Workflowsystem integriert wurde: Benutzer lassen sich jetzt neben Benutzergruppen auch Rollen zuweisen, denen in frei definierbarer Reihenfolge Aufgaben zugeteilt werden können. Fällt für die betroffenen Benutzer innerhalb des Workflows eine neue Aufgabe an, so werden diese automatisch per eMail benachrichtigt. Über ein separat erhältliches Zusatzmodul ist außerdem eine Versionsverwaltung für Artikel möglich. Zum Zeitpunkt des Erscheinens dieser Ausgabe des PHP-Magazins soll neben der Vollversion von SixCMS 5.0 auch eine Update-Version erhältlich sein, die ein Tool für die automatische Migration von Version 4.0 nach Version 5.0 mitbringt. In der Regel, so heißt es, soll keine manuelle Nacharbeit für die Migration nötig sein. Insgesamt macht SixCMS einen runden und ausgereiften Eindruck, wenngleich das Konzept von Container, Rubriken und Relationen am Anfang etwas kompliziert erscheint - eine großzügige Einarbeitungszeit seitens der Administratoren sollte eingeplant werden. Wenn Sie eine externe Agentur mit der Ersteinrichtung des Systems betrauen, achten Sie darauf, dass diese über ausreichende Vorerfahrung mit SixCMS verfügt. Für den reinen Anwender, also den Redakteur, ist SixCMS hingegen recht überschaubar und relativ einfach zu bedienen - was allerdings nach wie vor schmerzlich vermisst wird, ist ein WYSYWIG-Editor, mit dessen Hilfe ein Redakteur ohne HTML-Kenntnisse zumindest einfache Textauszeichnungen wie Fett- oder Kursivschrift vornehmen und deren Auswirkungen gleich sehen kann. Derzeit wird bei Six noch nach einer möglichst plattformunabhängigen Möglichkeit gesucht, einen solchen Editor zu realisieren, denn die meisten gängigen Editoren dieser Art nageln den Anwender unweigerlich auf den Internet Explorer unter Windows fest. Ein Pluspunkt von SixCMS ist die sehr einfach und verständlich gehaltene Dokumentation - leider auch in dieser Preisklasse (ab 9.900 Euro aufwärts) nicht immer eine Selbstverständlichkeit.

Aman_RedSYS

Die erste Version von RedSYS lief noch unter PHP/FI 2.0, womit RedSYS zweifelsohne zu den dienstältesten PHP-basierten Content Management Systemen gehören dürfte. Dementsprechend groß ist auch die Anwenderbasis mit rund 350 Installationen, zu denen ebenfalls bekanntere Namen wie die Weka Firmengruppe, Acclaim sowie W&V gehören. Bei der Standardeinrichtung von RedSYS fällt auf, dass eine physikalische Trennung zwischen Redaktions- und Lifeserver nicht stattfindet - es wird zwar intern eine Unterscheidung durchgeführt, um die Vorschau auch von Artikeln zu ermöglichen, die noch nicht für das Lifesystem freigeschaltet sind, dennoch findet alles auf der gleichen Maschine statt. Das System kann jedoch auch so konfiguriert werden, dass ein per NFS angebundener zweiter Server die Funktion des Lifeservers übernimmt. Prinzipiell sind auch andere Übertragungswege wie z.B. FTP vorhanden, allerdings wird hier gerade noch einiges in der Entwicklung getan. Üblicherweise werden Argumente wie Lasttrennung und höhere Systemsicherheit für eine Trennung von Life- und Redaktionsserver angeführt. Das Argument der Systemsicherheit zieht dabei aber nicht so ganz, denn letztendlich muss ja auch ein Kommunikationsweg zwischen Redaktions- und Lifeserver vorhanden sein, den ein findiger Finsterling im Zweifelsfalle genauso gut kompromittieren könnte wie eine normale Login-Maske. Allerdings fände er bei getrennten Systemen auf einem reinen Lifesystem wenigstens nur Inhalte vor, die ohnehin für die Öffentlichkeit bestimmt sind. Das Argument der Lasttrennung wird von RedSYS insofern relativiert, als dass es über einen systemeigenen Cache verfügt. Dabei wird nicht wie beim Zend Cache der Bytecode der PHP-Skripte an sich gecached, sondern der Inhalt der ausgelieferten Seiten. Wer mit dem Prinzip von Userland Cachesystemen vertraut ist (wie zum Beispiel PEAR::Cache), weiß, dass allein hierdurch gegenüber rein dynamischer Seitenauslieferung schon beachtliche Performancesteigerungen möglich sind. Bei zusätzlicher Verwendung eines Bytecode-Cache werden Performancedimensionen erreicht, die so manch komplizierte Loadbalancing-Lösung überflüssig machen können. Während den reinen Inhaltscache mittlerweile auch andere Systeme anbieten, geht der Cache von RedSYS ein Stück weiter: Eine beliebte Methode, um den Traffic und die Übertragungszeit der Seiten zum User zu reduzieren, ist die Output Compression via gzip. Der Pferdefuß hierbei ist eine erhöhte CPU-Last auf dem Server, da bei jedem Request die Daten erneut komprimiert werden müssen. Der Cache von RedSYS kann jedoch die gespeicherten Inhalte von vornherein komprimiert ablegen und in dieser Form direkt wieder an den Browser ausliefern, sodass der Rechenaufwand für die Kompression nur einmal auftritt. Werfen wir als Nächstes einen Blick auf das Bedienkonzept: Nach dem Login präsentiert sich RedSYS mit einer aufgeräumten Oberfläche. Auf der linken Seite befindet sich eine Baumstruktur, der die Inhalte des jeweiligen Moduls hierarchisch geordnet abpictureet. Als Module stehen dabei Administration, Filemanager, Plugin-Verwaltung und Mediendatenbank sowie die Onlinedokumentation zur Verfügung. Die rechte Bildschirmseite ist Detaileinstellungen vorbehalten, die sich auf den jeweils angewählten Punkt aus der Baumstruktur beziehen. Im Administrationsmodul können allgemeine Systemeinstellungen vorgenommen sowie beispielsweise Benutzer, Gruppen und Rollenzuordnungen verwaltet werden. Ebenso findet sich hier eine zentrale Linkverwaltung, in der sich sowohl normale statische Links als auch SQL-Abfragen für Links auf Seiten mit integrierten Datenbankabfragen ablegen lassen (die Ausgabe der Abfrageergebnisse wird über das Template der verlinkten Seite gesteuert). Die hier angelegten Links stehen im gesamten System zusätzlich zu der intern verwalteten Navigationsstruktur der Website zur Verfügung, wenn ein Redakteur einen Link anlegen will. Der Filemanager ist des Redakteurs täglich Brot. Hier wird die Navigationsstruktur der Website über das Anlegen neuer Ordner in der Baumstruktur festgelegt. Jedem Ordner kann ein eigenes Template sowie eine individuelle Startseite festgelegt werden. Innerhalb der Ordner können wiederum beliebig Seiten angelegt werden, die ähnlich präsentiert werden wie in gängigen Dateibrowsern. Die Seiteninhalte können auf vielfältige Weise bearbeitet werden: Per Textbox, per WYSIWYG-Editor oder per externem Editor (für Letzteres wird die Seite komplett auf den lokalen Rechner geladen, kann dort bearbeitet und anschließend wieder hochgeladen werden). Weiterhin können für jede Seite bestimmte Metatags festgelegt werden. Neben den aus HTML bekannten suchmaschinenrelevanten Tags sind dies unter anderem Angaben zur Sprache, zur Position innerhalb der aktuellen Navigationsebene oder, falls das Community-Zusatzmodul installiert ist, zur Zugehörigkeit zu bestimmten Gruppen oder Rollen aus der Lifeuserverwaltung. Templates werden nicht direkt über die Oberfläche verwaltet, sondern über einen FTP-Zugang aufgespielt. Jedes Template (bzw. Schema, wie es in RedSYS genannt wird) hat eine Entsprechung in einem Verzeichnis auf dem FTP-Server, in dem neben dem Template selbst alle dafür relevanten Dateien wie Bilder oder Stylesheet-Definitionen ihren Platz haben. Innerhalb von Templates kann beliebig PHP verwendet werden - RedSYS stellt hier ein System-API zur Verfügung, mit dem man auf die meisten Werte innerhalb der Systemumgebung zugreifen kann. Eine per PHPDoc generierte API-Dokumentation steht innerhalb der Onlinehilfe zur Verfügung. Für einfachere Aufgaben können innerhalb der Templates aber auch systemspezifische XML-Tags verwendet werden, mit deren Hilfe sich zum Beispiel eine Navigationsleiste, eine Sitemap und ähnlich häufig vorkommende Elemente erzeugen lassen. RedSYS ist gewöhnungsbedürftig. Das zugrundeliegende Konzept ließe zwar prinzipiell einen schnellen und unkomplizierten Einstieg zu, jedoch macht die noch stark lückenhafte Onlinedokumentation gerade Administratoren das Leben schwer. Eine gedruckte Dokumentation ist zwar ebenfalls verfügbar, diese soll allerdings mit der Onlinedokumentation weitestgehend deckungsgleich sein und zusätzlich in der Hauptsache einführende Tutorials enthalten. Die Visualisierung bestimmter Zustände, beispielsweise ob ein Artikel auf Freischaltung wartet, könnte ebenfalls übersichtlicher gelöst werden als mit der reinen Veränderung des Dokument-Icons - zumal zum Zeitpunkt der Entstehung dieses Artikels in der Dokumentation nichts darüber zu finden war, welches Icon welche Bedeutung hat. Laut Hersteller soll die Dokumentation in der neuen Version 3.7, die etwa zum Erscheinungszeitpunkt dieser Ausgabe erhältlich sein sollte, stark überarbeitet worden sein - auch die Visualisierungen sollen eine Verbesserung erfahren haben. Von der zunächst gewöhnungsbedürftigen Bedienung und den Dokumentationsmängeln abgesehen, ist RedSYS allerdings ein solides System, das vor allem durch die umfangreiche API viele Erweiterungsmöglichkeiten bietet. So ist es sicher auch kein Zufall, dass das System oft und gerne von Systemintegratoren in speziell auf die Bedürfnisse des Kunden zugeschnittenen Versionen eingesetzt wird.

Powerslave

Was Powerslave nicht kann, braucht auch keiner. Dieser Gedanke drängt sich zumindest auf, wenn man auf die Featureliste dieses CMS schaut - kaum ein Leistungsmerkmal, das dieses Programm nicht beherrschen soll. Dabei liegt es preislich weit unter vom Leistungsumfang her vergleichbaren (nicht PHP-basierten) Lösungen wie RedDot oder Gauss. Kann das wirklich wahr sein? Ja, kann es - solange man nicht erwartet, ein schlüsselfertiges System in die Hand zu bekommen, in dem alle diese Features sofort aktiv genutzt werden können. Denn obwohl Powerslave als Internet-/Intranet Komplettlösung und High-End-Redaktionssystem beworben wird, sagt der Untertitel unter dem Programmnamen viel mehr über das System aus: Rapid Prototyping Server. Und genau das ist es auch. Allerdings kann mit den Funktionen, die das System mitliefert, sehr einfach ein Content Management System erstellt werden. Powerslave liefert verschiedene Funktionsmodule mit, die beliebig miteinander verknüpft werden können, um daraus ein komplexes System zur Verwaltung von Datenstrukturen pictureen zu können. Um ein einfaches Content Management System für eine Website zu erstellen, benötigt man beispielsweise ein so genanntes Baummodul, in dem die Navigationsstruktur verwaltet wird, sowie ein Contentmodul, in dem die Artikel abgelegt werden. Damit nicht jeder einfach daherkommen und Inhalte in die Gegend stellen kann, werden beide Module mit einem Rechteverwaltungsmodul verknüpft. Dieses muss wiederum wissen, wo denn die User herkommen sollen, deren Rechte verwaltet werden sollen - also benötigt man ein Modul Benutzerverwaltung, wahlweise in der Datenbank- oder LDAP-Variante. Wenngleich man seinen Usern nun also das Recht geben kann, Artikel zu verfassen, ist es trotzdem oft gewünscht, dass noch einmal jemand kontrolliert, ob auch alles der Wahrheit oder auch den Designrichtlinien entspricht (sicher ist sicher) - also wird ein Modul Freischaltliste angelegt. Anschließend wird das Contentmodul mit der Freischaltliste verknüpft. Standardmäßig können in Powerslave bis zu zwei aufeinanderfolgende Freischaltstufen verwaltet werden (über zwei miteinander verknüpfte Freischaltmodule). Dabei gibt es jedoch kein Rollenkonzept, sondern nur je ein Freischaltrecht für jede Stufe, das pauschal an bestimmte Benutzer oder Gruppen vergeben werden kann. Wer mehr will, braucht das Zusatzprodukt Powerslave Enterprise Workflow Engine, mit dem sich beliebige Workflows in einem browserbasierten grafischen Editor frei definieren lassen. Damit wäre ein - sehr einfaches - Setup für ein Content Management System hergestellt. Will man weitere Websites verwalten, legt man einfach weitere Kombinationen aus je einem Baum- und Contentmodul an - diese können ebenso an die bestehenden unterstützenden Module angebunden werden oder ganz eigene Modulverknüpfungen haben. Eine zentrale Medien- oder Dokumentendatenbank für Bilder oder Download-Dateien können ebenfalls in Form von solchen Modulen realisiert werden - diese muss man jedoch nicht selbst aufsetzen, da Powerslave für diese sehr häufig gebrauchten und in der Regel immer gleichartigen Anwendungen Modulvorlagen mitbringt, die einfach eingespielt und in Betrieb genommen werden können. Bevor nun aber munter Templates gebaut werden können, muss man sich noch Gedanken machen, welche Art von Daten verwaltet werden soll: Zum Beispiel wäre es für eine Rubrik recht hilfreich, wenn diese einen Titel hätte - außerdem macht sich ein grafischer Button inklusive Mouseover-Effekt in einer Navigationsleiste ganz gut. Im Tabelleneditor für das Baummodul, der ein Frontend für die dahinterliegende Datenbank darstellt, müssen also die Felder Titel, Bild und BildMouseOver angelegt werden. Ersteres als Textfeld, die anderen als Bildobjekte. Damit eine hierarchische Einteilung der Rubriken in verschiedene Navigationsebenen möglich ist, muss zudem ein Feld für die Verknüpfung mit der jeweils übergeordneten Rubrik her. Jetzt kann ein erstes Template gebaut werden, das die entsprechenden Datenfelder enthält. Soll an einer bestimmten Stelle zum Beispiel der Titel der Rubrik erscheinen, so schreibt man simpel $Titel in den Quelltext, für ein Bild schreibt man (fast) wie gewohnt: < img src=$Bild width="32" height="32" >. Über die Powerslave-Templatesprache lassen sich neben solchen Feldersetzungen beispielsweise auch einfache Kontrollstrukturen und Schleifen realisieren, ansonsten läßt sich an jeder Stelle auch einfach PHP-Code verwenden, über den man dann auf von der Powerslave-Umgebung zur Verfügung gestellte Objekte zugreifen kann. Beim Einspielen eines Templates mittels des Layoutkonverters werden alle Powerslave-Templatebefehle automatisch in native PHP-Aufrufe übersetzt. Damit ein Redakteur nun auch möglichst effektiv seine Rubrikdaten eingeben kann, muss zusätzlich zum Ausgabetemplate ein Eingabetemplate definiert werden. Dazu gibt es zwei Möglichkeiten: Ganz klassisch mit HTML-Formularelementen, die von jedem beliebigen Browser auf jeder Plattform bearbeitet werden können, oder mit dem neuen DOM-Editor. Dieser funktioniert derzeit nur mit dem Internet Explorer ab Version 5.5 in voller Pracht, Netscape 6 und Mozilla machen noch Probleme. Da dieser Editor auf Javascript und dem W3C-DOM basiert, hat er auf jeden Fall das Potential, in Zukunft auf jedem modernen Browser zu laufen. Und das wäre wünschenswert, denn mittels des DOM-Editors kann direkt im Originallayout der Seite, so wie sie später auch erscheinen würde, gearbeitet werden. Es lassen sich beliebig komplexe Objekte, wie zum Beispiel automatisch skalierte Bilder mit Bildunterschrift oder in ein komplexes Layout eingebettete Dateidownloads, definieren, die dann mittels Drag & Drop direkt in das Originaldokument gezogen werden können. Das Layout passt sich dabei dynamisch den neuen Gegebenheiten an, sodass man zu jeder Zeit die Seite so sieht, wie sie im fertigen Zustand aussieht. Wer oft mit komplexen Tabellen arbeiten muss, kann auch auf einen templatebasierten interaktiven Tabelleneditor zurückgreifen, durch den gewährleistet ist, dass unbedarfte Anwender zwar leicht komplexe Tabellenstrukturen anlegen, sich dabei aber nicht außerhalb der Designvorgaben der Layoutvorlagen bewegen können. Mehr WYSIWYG-Komfort bekommt man derzeit nur in Offline-Editoren wie Dreamweaver oder Golive geboten. Diese Prozedur (Tabellenstruktur festlegen, Ausgabelayout(s) erstellen, Eingabelayout(s) erstellen) setzt sich im Contentmodul fort, in dem später die Artikel eingegeben werden. Wenn man möchte (zum Beispiel weil man die Originaloberfläche von Powerslave nicht mag oder zusätzliche Funktionen braucht), kann man über Skin-Templates auch die komplette Benutzeroberfläche der einzelnen Powerslave-Module anpassen und eine individuelle, an das Firmen-CI und die speziellen Bedürfnisse der Mitarbeiter angepasste Oberfläche erstellen. Über vorgefertigte Plugins lassen sich, wenn die Standardfunktionalität von Powerslave nicht reicht, externe Programme einbinden. So lassen sich beispielsweise einfache Bildskalierungen, zum Beispiel für die Darstellung von Thumbnails, über das Ansprechen von ImageMagick realisieren. Navigationsbuttons können automatisch anhand von Designvorlagen erzeugt werden, indem man über Skript-Fu, an das der Text für den Button weitergegeben wird, einen ständig im Hintergrund arbeitenden Gimp anspricht, der anschließend das fertige Bild zurückliefert. Über PDFLaTeX werden die einmal eingepflegten Artikelinhalte mittels eines LaTeX-Templates zu PDF-Dokumenten gewandelt. Mittels eines speziell gepatchten Pavuk können statische HTML-Seiten exportiert werden. Für die individuelle Erweiterung der Systemfunktionalität steht neben der Möglichkeit, PHP in Templates einzubetten, auch eine Plugin-Schnittstelle zur Verfügung. Powerslave-Plugins können dann an beliebige System-Events gebunden werden, zum Beispiel immer ausführen beim Onlinesetzen eines Artikels oder immer unmittelbar vor dem Einfügen eines neuen Artikels ausführen. Das Plugin-SDK sowie die dazu passende Dokumentation sind jedoch an das Belegen einer speziellen Entwicklerschulung geknüpft. Ein kleiner Geniestreich ist die neue WebDAV-Unterstützung: Hierüber ist es möglich, die Mediendatenbank, den Dokumentenmanager und die Layoutdatenbank als Netzlaufwerke unter Windows einzubinden. Diese können ganz normal als solche genutzt werden. Möchte man also mehrere Bilder, Dokumente oder Templates hoch laden, markiert man diese einfach im Windows Explorer und zieht sie mittels Drag & Drop auf das dem Modul entsprechende Netzlaufwerk - einfacher geht es nicht. Gegenüber der langsamen und nervenden Methode, Dateien einzeln über das Browserinterface hoch laden zu müssen, stellt dies einen immensen Produktivitätsgewinn dar. Doch wo Licht ist, ist auch Schatten: Punktabzug gibt es eindeutig für die Dokumentation. Zum aktuellen Zeitpunkt ist die letzte Aktualisierung der Dokumentation knapp 5 Monate alt, obwohl zahlreiche neue Features ihren Weg in das Programm gefunden haben - nicht, dass alle Features der Vorgängerversionen bereits vollständig beziehungsweise umfassend dokumentiert wären. Zum anderen muss man sich, bevor man sich für ein solches System entscheidet, einiges klarmachen: Es klingt natürlich sehr verlockend, ein System zu haben, das eigentlich alles nur erdenkliche kann und das quasi beliebig erweiterbar ist. Im Umkehrschluss bedeutet dies aber auch, dass man ständig nacharbeiten muss - denn kommt eine neue Programmversion, sind die langersehnten neuen Features noch lange nicht verfügbar. Schließlich müssen die neuen Features in die vorhandenen Templates, Skins oder Plugins eingearbeitet werden, bevor sie genutzt werden können. Bei größeren Umwälzungen im System und einer entsprechend großen Anzahl Templates bedeutet das ein gutes Stück Arbeit - und damit bares Geld. Zudem wird das Fehlermanagement in einem so frei konfigurierbaren System zunehmend schwierig: Hat beim Auftauchen eines Fehlers jetzt die interne IT-Abteilung Mist gebaut, die externe Agentur die Templates vermurkst oder ist es schlicht ein Bug im System? Überhaupt werden Fehler in Powerslave nur unzureichend abgefangen, oft sieht man nackte PHP-Fehlermeldungen. Sicherheitsabfragen bei kritischen Einstellungen auch in der Systemkonfiguration finden selten statt. Der Datenbankunabhängigkeit wurden wichtige Features wie referentielle Integrität geopfert. So ist es problemlos möglich, eine Rubrik zu löschen, in der noch Dutzende von Artikeln liegen. Glücklicherweise werden eben auch wieder aufgrund der nicht vorhandenen Datenintegrität die Artikel dabei nicht wirklich aus der Datenbank gelöscht, sodass sich die Rubrik samt der Artikelbeziehungen über ein Tool wie phpMyAdmin wiederherstellen lässt, sofern man die ursprüngliche Rubrik-ID herausfindet. Die Übertragung von Templates zwischen Develop- und Lifesystem findet über eine XML/RPC-Schnittstelle statt, deren Verbindung zum aktuellen Zeitpunkt nicht verschlüsselt werden kann. Hier wird vermutlich erst PHP 4.2.0 Abhilfe schaffen, ab dem eine SSL-Verschlüsselung auch ohne cURL-Extension möglich ist. Bis dahin ist dies ein potentielles Sicherheitsloch, sofern Develop- und Lifeserver über eine ungesicherte Internetverbindung kommunizieren müssen - denn schließlich können so übertragene Templates auch beliebigen PHP-Code enthalten. Sieht man über diese Nachteile hinweg, ist ein flexibleres und innovativeres System im Lager der kommerziellen Anbieter derzeit kaum zu bekommen - planen Sie jedoch die Implementationszeit großzügig, denn schließlich muss auch die bei den anderen Systemen vom Start weg vorhandene Oberfläche erst noch gebaut werden. Denken Sie auch daran, ein Budget für die laufende Pflege des Systems einzuplanen, um keine bösen Überraschungen zu erleben. Der Fairness halber sollte erwähnt werden, dass ich bereits seit knapp 1,5 Jahren mit Powerslave arbeite, während ich mit den übrigen hier vorgestellten Systemen im Rahmen meiner Recherchen für diesen Artikel erstmals zu tun hatte. Es ist also durchaus wahrscheinlich, dass auch diese Systeme so manche Tücke haben, über die ich in der Kürze der Zeit nicht gestolpert bin.

Astarte webEdition

Mit einem Listenpreis von 159 Euro zielt Astarte mit webEdition auf das bislang von CMS-Herstellern sträflich vernachlässigte KMU-Segment. Dennoch muss sich webEdition in vielerlei Hinsicht nicht vor den großen Systemen verstecken, zumal es durch den Erwerb von Zusatzmodulen im Funktionsumfang erweitert werden kann. Die Basisversion von webEdition ist auf einen einzigen Benutzer beschränkt, der als Administrator über alle Rechte verfügt. Er kann gleichermaßen Vorlagen erstellen und Inhalte einpflegen. Wer mehr braucht, kann das Benutzerverwaltungsmodul erwerben, mit welchem eine Trennung zwischen Administratoren und Redakteuren in beliebiger Anzahl möglich ist. Eine große Benutzerverwaltung, die zusätzlich über eine Rechteverwaltung und ein Workflowsystem verfügt, ist in Vorbereitung. Diese soll außerdem die Möglichkeit bieten, externe User zu verwalten, die auf der Website wiederum bestimmte Access Levels haben können, die bestimmen, auf welche Inhalte sie Zugriff haben. Die Installation setzt einen Webserver mit PHP 4, MySQL und FTP-Zugang voraus. Da die mir beruflich zur Verfügung stehenden Server aus Sicherheitsgründen das unverschlüsselte FTP-Protokoll nicht erlauben, habe ich mein zum Glück noch vorhandenes privates Puretec-Paket bemüht - angesichts der anvisierten Zielgruppe sicher keine unübliche Umgebung. Für die Installation ist keine zusätzliche Software wie etwa ein FTP-Programm notwendig: webEdition liefert einen bequemen Installer mit - wahlweise für Windows oder für Macintosh. Der Installer macht die Installation auch für weniger versierte Benutzer zum Kinderspiel - Schritt für Schritt führt er durch alle Phasen der Installation und bietet zur näheren Erklärung hinter den Eingabefeldern für die Systemeinstellungen auch eine Hilfefunktion, die eine Beschreibung für die aktuelle Einstellmöglichkeit parat hat. Im Zuge der Installation werden alle notwendigen PHP-Skripte aufgespielt und die MySQL-Tabellen angelegt. Die Benutzerfreundlichkeit setzt sich nach erfolgtem Login in der Oberfläche fort: Wie von normalen Desktop-Anwendungen gewohnt, findet sich am oberen Fensterrand ein Pulldown-Menü mit den bekannten Bezeichnungen Datei, Bearbeiten und Hilfe. Die linke Seite enthält - wie sollte es anders sein - eine Baumdarstellung der Website-Struktur und auf der rechten Seite befindet sich ein großer Bereich für Detailansichten, auf dem sich direkt nach dem Login die am häufigsten gebrauchten Funktionen anbieten, damit man sofort loslegen kann. Außerdem gibt es hier einen Link zu einer Flash-basierten Guided Tour, die den Umgang mit dem System anschaulich beschreibt. Wie eigentlich alle Systeme trennt auch webEdition durch den Einsatz von Templates den Content vom Design - doch Astarte hat ein Herz für Einsteiger und Anglizismenhasser und nennt diese hier Vorlagen. Diese können entweder direkt in einem Texteingabefeld bearbeitet oder als Datei hochgeladen werden. Die dabei häufig vorkommenden Arbeitsschritte (Vorlage herunterladen, bevorzugten HTML-Editor starten, Vorlage wieder hochladen) lassen sich über ein separat erhältliches Editor-Plugin automatisieren. Die Systemfunktionen, wie beispielsweise das Darstellen einer Navigationsleiste, das Plazieren von Bildern und vieles mehr, werden durch so genannte we:tags realisiert. Diese stellen eine Sammlung von XML-konformen Tags dar, die einfach in die HTML-Vorlage eingebettet werden und diese unter anderem um die beschriebenen Funktionen erweitern. Auch einfache Kontrollstrukturen können abgepictureet werden. So veranlasst zum Beispiel das Tag das System dazu, auf die Seite mit der Datenbank-ID 98 zu springen, falls der Browser des Users kein Javascript beherrscht. Für die we:tags steht im Vorlageneditor ein Assistent zur Verfügung, sodass man sich nicht alle Tags gleich merken muss. In diesem sind alle verfügbaren Tags gelistet. Wählt man eines aus, erscheint ein neues Fenster mit der Beschreibung des Tags und Eingabefeldern für dessen mögliche Parameter. So muss dank dieser Eingabefelder die Datenbank-ID aus dem obigen Beispiel nicht per Hand ermittelt werden: Per Klick auf einen Button neben dem Eingabefeld für den entsprechenden Parameter erscheint ein Dateisystem-Browser, mit dessen Hilfe man einfach die gewünschte Seite auswählt. Nach der Bestätigung steht die dazugehörige ID im Eingabefeld. Da die Bezeichnungen der Tags in den meisten Fällen selbsterklärend ist (sofern man ein paar Fetzen Englisch beherrscht), benötigt man in vielen Fällen weder Handbuch noch Hilfefunktion, um einfache Funktionen einzubauen. Sollten die we:tags nicht ausreichen oder möchte man eigene Skripte einbinden, lässt sich übrigens auch problemlos PHP-Code in die Vorlagen einbetten. Weil webEdition außerdem in der Lage ist, Seiten statisch zu publizieren und deren Dateiendung individuell festzulegen, ist auch die Verwendung von ASP oder JSP denkbar. Damit das Arbeiten des Redakteurs mit webEdition möglichst einfach vonstatten geht, gibt es den Mechanismus der Dokumenttypen. Diese sind frei definierbar und lassen sich beim Erstellen einer neuen Seite dieser zuweisen. Eine zu einem Dokumenttypen zugeordnete Seite weiß automatisch, in welchem Verzeichnis auf dem Server sie abgelegt wird, welche Vorlagen sie verwenden darf und ob die Seite von einer Suchfunktion erfassbar sein soll. Darüber hinaus kann einem Dokument auch eine Kategorie zugewiesen werden - auch Kategorien sind natürlich frei definierbar. Diese haben den Zweck einer inhaltlichen Einordnung des Dokuments, sodass abseits der sonstigen Navigationshierarchie auch Übersichten über inhaltlich gleiche Dokumente generiert werden können. Beim Bearbeiten von Dokumenten steht dem Redakteur an den Stellen, die durch we:tags als HTML-Text gekennzeichnet sind, ein komfortabler WYSIWYG-Editor zur Verfügung - sofern der Internet Explorer 5.5 oder höher unter Windows das Tool der Wahl ist. Ein Java-Editor, der auch Anwendern anderer Browser und Macintosh-Usern das Leben leichter machen soll, befindet sich noch in der Entwicklung. Auch Bilder können eingesetzt werden - wahlweise an durch we:tags hierfür vorbestimmte Positionen oder direkt im WYSIWYG-Editor. Hier offenbart sich allerdings eine erste große Schwäche: Es gibt keine zentrale Mediendatenbank, in der Bilder, Flash-Movies und andere Medien gesammelt zur Verfügung stehen. Stattdessen werden Bilder (wie auch alle anderen Dateitypen) direkt im Filesystem des Webservers verwaltet. Hält man sich an eine einigermaßen saubere Verzeichnisstruktur, ist das an sich nicht weiter schlimm - dennoch erübrigen sich hierdurch natürlich erweiterte Features wie zum Beispiel eine Versionsverwaltung oder das zentrale Vorhalten von Metadaten. Ein weiteres Problem ist, dass eine automatische Skalierung von Bildern nicht möglich ist. Daher müssen Bilder immer in genau der physikalischen Auflösung hochgeladen werden, in der sie auf der Seite auch tatsächlich erscheinen sollen. Kommt es also vor, dass in einer Übersichtsseite ein Bild in einem kleineren Format und auf einer Detailseite dann in einem größeren Format erscheinen soll, muss das Bild in beiden Auflösungen auf den Server gespielt werden. Zwar kann in webEdition eine Skalierung für das Bild angegeben werden, allerdings beeinflusst diese lediglich die width und height Attribute des Tags. Die Skalierung wird dabei also dem Browser überlassen - das Ergebnis sieht in der Regel eher suboptimal aus und die Dateigröße wird nicht verringert. Der Redakteur muss also in einem Bildbearbeitungsprogramm fit sein, um seine Bilder selbst auf ein webtaugliches Format zu bringen - die meisten normalen Anwender dürften hiermit überfordert sein. Größere Unternehmen mit entsprechender IT-Infrastruktur werden schmerzlich die Möglichkeit vermissen, die Benutzerverwaltung über LDAP laufen zu lassen. Das Herausragendste an webEdition ist mit Sicherheit die ausführliche, sehr einsteigerfreundliche Dokumentation. Auch die Onlinehilfe ist vorpicturelich. Angelehnt an die Windows-Hilfefunktion kann wahlweise eine hierarchische Ansicht der Themengebiete, ein Stichwortindex oder eine Volltextsuche verwendet werden. Überhaupt ist die gesamte Benutzeroberfläche stark an die von Desktop-Betriebssystemen angelehnt (vom Look and Feel her werden sich MacOS X User schnell zu Hause fühlen). Das hat allerdings seinen Preis: Über eine ISDN-Verbindung vollzieht sich der Seitenaufbau eher schleppend, das eine oder andere Mal erwischt man sich doch glatt beim Däumchendrehen oder Kaffee holen. Mit DSL kommt allerdings fast Desktop-Feeling auf.

Typo3

Last but not least: Typo3 ist gemessen an den zuvor beschriebenen Systemen der einsame Außenseiter - denn Typo3 ist ein kostenlos erhältliches Open Source-System und steht unter der GPL. Das bedeutet allerdings keinesfalls, dass Typo3 weniger leistet oder komplizierter zu bedienen wäre. Die Systemanforderungen deuten bereits an, dass Typo3 großen Wert auf den einfachen und vor allem automatisierten Umgang mit Grafiken legt: Neben dem obligatorischen PHP4 nebst MySQL sind auch GDlib, Freetype und ImageMagick erforderlich. Schon beim Login offenbart sich die Anpassungsfähigkeit des Systems: Es gibt gleich zwei Benutzeroberflächen (genau genommen eigentlich drei), aus denen der User ganz nach Geschmack wählen kann. Das so genannte Classic Interface könnte man mit webEdition auf Speed vergleichen: Auch hier war der Autor bemüht, eine Oberfläche zu schaffen, die möglichst interaktiv und nah an dem ist, was man vom Desktop her kennt - exzessiver Gebrauch von DHTML mit über 6.000 Zeilen Javascript-Code ist die Folge. Klar, dass damit nur glücklich wird, wer über eine schnelle Internetverbindung und einen modernen Browserboliden (IE 5.5 oder Netscape ab 6.1) verfügt. Aus diesem Grunde gibt es in der Version 3.3 glücklicherweise das Alternative Backend. Dieses ist wesentlich einfacher und klarer gehalten - meiner ganz subjektiven Meinung nach ist die Bedienung dadurch nicht nur schneller, sondern auch intuitiver geworden. Auch mit Browsern abseits des Mainstreams, zum Beispiel Opera, kommt das alternative Backend gut klar, wenngleich Benutzer des Internet Explorers unter Windows mal wieder in den Genuss eines WYSIWYG-Editors kommen, der Benutzern anderer Browser oder Betriebssysteme versagt bleibt. Die erwähnte dritte Oberfläche ist eigentlich nicht wirklich eine solche, denn im Frontend wird die Website angezeigt, wie sie sich auch dem Endanwender präsentieren würde. Ein auffälliger Unterschied zum normalen Erscheinungspicture ist jedoch, dass sich bei allen Elementen, die vom gerade angemeldeten Benutzer bearbeitet werden dürfen, ein kleiner Bleistift befindet. Klickt man diesen an, befindet man sich im Bearbeitungsmodus für dieses Element. Ein ähnliches Konzept findet man auch in großen Systemen wie Powerslave oder, beim Blick über den PHP-Tellerrand, RedDot. Typo3 treibt das Spiel aber noch ein Stück weiter: Am unteren Ende der Seite befindet sich ein so genanntes Admin Panel, über das der Benutzer je nach Rechten und Vorlieben noch weitere Einstellungen vornehmen kann. So kann er beispielsweise bestimmen, dass der Bearbeitungsmodus in einem neuen Fenster stattfindet (wie bei RedDot), die Seite komplett in den Bearbeitungsmodus wechselt (wie bei Powerslave) oder aber die Seite an sich bestehen bleibt und nur das gewählte Element in einer editierbaren Ansicht dargestellt wird. Auf einer Seite mit mehreren Elementen, die als Liste dargestellt werden, können weiterhin zu jedem Element Buttons eingeblendet werden, mit denen man das Element in der Reihenfolge verschieben, ausblenden, löschen, inklusive aller Unterelemente bearbeiten oder ein neues Element darunter anlegen kann. Direkt im Admin Panel können außerdem (je nach Userrechten) weitere Informationen zur Seite angezeigt werden - etwa die Zeit, die zum Aufbau benötigt wurde, die Datenbank-ID, Informationen zum Cacheverhalten und einiges mehr. Darüber hinaus kann mittels Einstellungen im Panel eine Anzeige der Seite unter simulierten Bedingungen erzwungen werden - zum Beispiel kann einer Seite, die zu bestimmten Terminen jeweils andere Elemente anzeigt, ein falsches Datum vorgegaukelt werden. Gleiches funktioniert auch mit Benutzergruppen, sofern die Seite auf unterschiedliche Benutzergruppen jeweils anders reagiert. Beim Bearbeiten von Inhalten fällt auch gleich eine der großen Besonderheiten von Typo3 im Umgang mit Bilddaten auf: Fügt man mittels des WYSIWYG-Editors Bilder in den Fließtext ein, hat man die Wahl zwischen normalen Bildern und Zauber-Bildern. Zunächst scheinen beide Bildarten sich nicht besonders zu unterscheiden: Im (sehr komfortablen) Dateibrowser wird ein Bild ausgewählt, welches in das Editorfenster eingefügt wird. Im WYSIWYG-Editor bekommt das Bild so genannte Anfasser, wie man sie aus Programmen wie Dreamweaver oder Golive kennt. Diese dienen dazu, das Bild frei zu skalieren, bis es sich gut in den Fließtext einpasst. Der Text fließt dabei dynamisch um das Bild herum. Auch wenn das für eine browserbasierte Anwendung schon beachtlich klingt, ist dies zunächst nichts Besonderes - diese Funktionalität ist in dem ActiveX-Control des Internet Explorers, das für diese Art von Editoren genutzt wird, Standard. Die Besonderheit in Typo3: Das System erkennt die Änderungen an der Bildskalierung automatisch und wandelt auch die physikalischen Abmessungen des Bildes um. Dabei wird jedoch nur eine Kopie mit Referenz auf das Originalpicture erzeugt, sodass bei späteren Skalierungen immer wieder auf dieses als Ausgangsquelle zurückgegriffen werden kann, ohne dass unnötige Qualitätsverluste auftreten. Eine derart intuitive Form der Bildskalierung sucht in kommerziellen Systemen Ihresgleichen vergeblich. Dies ist jedoch nicht die einzige Grafikfunktion, mit der Typo3 trumpfen kann: Auch dynamisch erzeugte Navigationsleisten, Überschriften und vieles Andere kann als Grafikelement on-the-fly erzeugt werden. Hierzu muss über die integrierte Konfigurationssprache TypoScript ein Regelwerk definiert werden, wie die zu erzeugenden Grafiken auszusehen haben. Dabei können nicht nur Schriftart, Farbe und Größe definiert werden, sondern auch die Beschaffenheit des Hintergrunds - und sei dies eine aufwändig erstellte Grafikvorlage, über die die Schriften einfach übergeblendet werden. Auf diese Weise können Navigation, Artikelüberschriften und Ähnliches exakten Designvorgaben bis hin zur verwendeten Schriftart (abseits von Arial, Helvetica, Verdana & Co.) folgen, ohne dass für jede neue Rubrik oder jede neue Artikelüberschrift ein Grafiker bemüht werden muss. Die mittels der GDlib und ImageMagick möglichen Bildmanipulationen sind zwar nicht so mächtig wie beispielsweise die GIMP-Anbindung, wie Powerslave sie bietet, allerdings wird über eine Unterstützung von GIMP auch bei den Machern von Typo3 nachgedacht - schließlich hat man einen Ruf zu verlieren. Der Umgang mit TypoScript ist vom Grundprinzip her nicht schwer - es ist eigentlich keine vollständige Programmiersprache (wenngleich das Wort Script ähnliches vermuten lässt), sondern mehr eine Auflistung von Konfigurationsanweisungen, die einer Objekthierarchie folgen. Trotzdem sind sehr einfache Kontrollstrukturen möglich, zum Beispiel um den Browsertyp des Users abzufangen und dann fallbasiert andere Inhalte oder Designstile zu zeigen. Dennoch sollte man als angehender Typo3-Administrator eine nicht zu kurze Einarbeitungszeit einplanen - denn die Zahl der Konfigurationsmöglichkeiten ist beeindruckend. Ebenso beeindruckend ist auch der Berg von PDF-Dokumenten vor dem man steht, wenn man nach Dokumentationen für das System sucht - in dieser Qualität und Menge bei weitem nicht selbstverständlich (und dies leider nicht nur im Maßstab eines Open Source-Produkts). Der Großteil der offiziellen Dokumentationen ist allerdings in englischer Sprache gehalten. Das ist nicht weiter verwunderlich, denn immerhin stammt Kasper Skårhøj, der Initiator des Projekts, der auch heute noch den größten Teil der Programmierarbeit leistet, aus Dänemark - mit Englisch haben wir also noch mal Glück gehabt. Während es Administratoren durchaus zugetraut werden kann, mit englischsprachiger Dokumentation umzugehen, sehen Endanwender (Redakteure) dies in der Regel ein wenig anders. Glücklicherweise gibt es auch in Deutschland sehr aktive Typo3-Developer, die entsprechende Enduserdokumentationen in Deutsch bereitstellen, zum Beispiel die Firma Netfielders aus Düsseldorf. Dort wird übrigens im Verbund mit einigen anderen Typo3-affinen Unternehmen gerade an einem Firmennetzwerk geknüpft, das kommerziellen Support, Schulung und Beratung für dieses CMS in Deutschland sicherstellen soll. Eine Website mit entsprechenden Informationen ist derzeit in Vorbereitung und sollte beim Erscheinen dieser Ausgabe verfügbar sein. Was taugt Typo3 für den Einsatz in großen Unternehmen? An sich viel - durch die Kombination von PHP mit TypoScript oder gar die Programmierung von kompletten eigenen Funktionsmodulen in PHP ist Typo3 fast beliebig erweiterbar. Die Bedienung für den Redakteur über die Frontend-Oberfläche gestaltet sich intuitiv, die Oberfläche ist nebst 12 weiteren Sprachen auch in Deutsch verfügbar, jedes einzelne Eingabefeld ist mit einem Button versehen, über den eine Kontexthilfe aufgerufen werden kann - absolut vorpicturelich. Wermutstropfen sind derzeit auch hier die fehlende LDAP-Unterstützung für die Benutzerverwaltung sowie der (noch) nicht vorhandene Workflow (derzeit ist nur ein einfacher Freischaltmechanismus verfügbar). Beides befindet sich jedoch derzeit in Arbeit, sodass Typo3 sich schon bald im Kreise der absoluten High-End-Systeme bewegen könnte. Was dem allerdings dann noch entgegensteht ist darüber hinaus der Mangel an standardisierten Im- und Exportschnittstellen (zum Beispiel XML) sowie, weit gravierender, die derzeitig nicht stattfindende physikalische Trennung zwischen Life- und Developserver und das Fehlen einer Mediendatenbank.

Content Management oder Portalsystem?

Was ist unter dem Begriff Content Management zu verstehen? Darüber scheiden sich die Geister. So manch einer wird vermutlich protestieren, dass sich so bekannte Systeme wie APPortal, PHPNuke oder PostNuke nicht in der CMS-Übersichtstable befinden. Der Grund dafür ist, dass sich diese Programme eher in der Kategorie Portalsysteme oder auch Community-Builder einordnen lassen. Diese haben in der Regel einen sehr fixen Funktionsumfang und sind immer sehr ähnlich aufgebaut: Jeder Benutzer kann direkt für bestimmte Themengebiete Artikel verfassen. Diese werden auf der Startseite des jeweiligen Themas verlinkt und können von anderen Usern kommentiert oder bewertet werden. Garniert wird das Ganze meist mit weiteren Diskussionsforen, einem Umfragesystem, Download-Areas und Linklisten (deren Inhalte ebenfalls bewertet und kommentiert werden können) und gelegentlich sogar einem Chat. Der Aufbau von solchen Websites ist meistens sehr ähnlich und alles ist an dem Zweck ausgerichtet, über die Interaktion mit den Usern die Seiten zum Leben zu erwecken. Dies alles kann ebenso ein Aspekt eines Web Content Management Systems sein, allerdings sind diese Features für ein solches eher in der Kategorie nice to have einzuordnen. Die Schwerpunkte eines WCMS liegen statt im Front- eher im Backend. Mit einem CMS kann eine Website mit völlig beliebiger Struktur, Optik und Funktionalität von Grund auf aufgebaut werden. Die Inhalte kommen in aller Regel nicht von externen, sondern von internen Usern (Redakteure), deren Rechte für die einzelnen Content-Bereiche sehr fein abstimmbar sind. Ähnlich einem moderierten Forum können die Redakteure meistens die Inhalte nicht direkt frei schalten - im Rahmen eines Workflows müssen diese erst noch eine oder mehrere Instanzen passieren, zum Beispiel den Bildredakteur, der sich um das passende Bildmaterial zum Artikel und die dafür nötigen Verwertungsrechte kümmert, sowie einen Ressortleiter, der alles auf inhaltliche Richtigkeit prüft und am Ende womöglich noch einen Chefredakteur, der sich darum kümmert, den Artikel korrekt einzuordnen, der die Erscheinungszeiten kontrolliert und den Artikel dann letztendlich für die Allgemeinheit freigibt. Im Idealfall sind diese Prozesse frei konfigurierbar, es gibt aber auch Content Management Systeme, die keine Workflows beherrschen - meistens gibt es aber zumindest eine Freischaltinstanz.

Fazit

Es ist wie immer im Leben: Jedes System hat seine ganz eigenen Stärken und Schwächen, keines ist perfekt. Will man ein grundsolides System, das zwar nur in gewissen Grenzen erweitert werden, bei dem man aber auch nicht viel falsch machen kann, ist sicher SixCMS eine gute Wahl. Das andere Extrem ist Powerslave: Erweiterbar an allen Ecken und Enden, ein riesiger Baukasten an Features, die individuell zusammengesetzt werden können und brilliante, innovative Ideen, die man bei kaum einem anderen System findet - auf der anderen Seite jedoch deutliche Schwächen in der Implementation und Dokumentation sowie konzeptionell bedingt ein ständiges Nacharbeiten, will man die Features neuer Versionen auch wirklich nutzen. Aman RedSYS liegt irgendwo dazwischen, hat jedoch ebenfalls mit gewissen Schwächen in der Dokumentation zu kämpfen und ist nur in geringem Maße intuitiv zu bedienen. webEdition bietet ein für ein kommerzielles System herausragendes Preis-/Leistungsverhältnis, erkauft sich dieses aber mit stark eingeschränkter Funktionalität. Dafür sind Bedienbarkeit und Dokumentation auf einem sehr hohen Niveau. Typo3 ist als Open Source-System auf dem besten Weg, in die Profiliga aufzusteigen - vom Leistungsniveau her liegt es deutlich über webEdition, allerdings dürfte die Zielgruppe von Astarte bereits an der Installation von Typo3 scheitern; auch das Erlernen von TypoScript verschlingt deutlich mehr Zeit als die sehr simpel gehaltenen we:tags. Sind Workflow und LDAP-Anbindung erst fertiggestellt, können die kommerziellen Hersteller sich schon einmal warm anziehen. Sollte Ihnen keines der vorgestellten Systeme so richtig zusagen, ist das kein Beinbruch - schließlich gibt es allein im PHP-Lager noch genügend andere Systeme zur Auswahl. In bestimmten Fällen kann es sich ansonsten auch lohnen, die Entwicklung eines speziell auf die eigenen Bedürfnisse zugeschnittenen Systems in Erwägung zu ziehen - abseits des Content Managements ist dies zum Beispiel im eCommerce-Sektor kein Tabuthema. Das Einzige, was als sichere Empfehlung gesagt werden kann: Machen Sie sich vor der Auswahl eines CMS genau klar, was Sie wollen. Anschließend machen Sie sich klar, was Sie davon auch tatsächlich brauchen. Und versuchen Sie, sich vorzustellen, welche Anforderungen innerhalb eines Jahres nach Inbetriebnahme der neuen Lösung noch auf Sie zukommen könnten. Danach können Ihnen nur noch drei Dinge helfen: Eine solide Kosten-/Nutzenanalyse, gesunder Menschenverstand und eine gute Portion Bauchgefühl.

Übersichtstable aller CMS als PDF-File (131 kb)

Markus Wolff ist Mitgründer und Geschäftsführer der Hamburger Multimedia-Agentur 21st Media, wo er in der Hauptsache für die Kundenberatung und Projektleitung sowie technische Konzeption zuständig ist. Neben der PHP-Entwicklung beschäftigt er sich außerdem mit Datenbankapplikationen unter Windows.