Neben Wordpress, Joomla und Drupal gehört das freie CMS TYPO3 zu den meist verwendeten Systemen für das Content Management. Unser Autor Gregor Gold, Geschäftsführer der Agentur denkfabrik, beschreibt die Schwächen von TYPO3 - resultierend aus den Ergebnissen von knapp einem Dutzend Revisionsprojekten, in denen er die Qualität der jeweiligen Systeme begutachtet hat.
Viele Programmierstile verderben das System
TYPO3-Projekte charakterisieren sich oft dadurch, dass in der Entwicklungsphase viele Menschen erstmals zusammenarbeiten. Insbesondere wenn Web- oder Werbeagenturen entsprechende Vorhaben starten, werden häufig freie Programmierressourcen hinzugezogen. Die Vorteile bezüglich Flexibilität und Kosten werden mit erheblichen Nachteilen erkauft. Die Analyse von TYPO-3-Systemen belegt ein Nebeneinander sehr unterschiedlicher Programmiermethoden, weil die beteiligten Techniker ihren individuellen Stil einbringen. Als Konsequenz entstehen labile und schwer administrierbare Systeme.
Vor Beginn eines umfangreicheren TYPO-3-Projekts sollte deshalb immer eine grundlegende Programmierrichtlinie definiert werden. Dazu gehören beispielsweise methodische Prinzipien zum Programmierstil, Festlegungen zu den Konfigurationseinstellungen und Vorgaben für die Dokumentation. Zudem ist es sinnvoll präzise festzulegen, welche ergänzenden Hilfsmittel wie etwa zu verwendende Javascript-Bibliotheken, Konventionen für Namensgebung etc. herangezogen werden sollen, um Kompatibilitätsprobleme zu vermeiden und eine höhere Transparenz des Codes zu erzielen.
Unstrukturierte Typoscript-Templates
Die Typoscript-Templates, in denen ein Großteil der Systemkonfiguration des Content Management Systems (CMS) erfolgt, sind die Basis für TYPO 3. Sowohl für einen reibungslosen Betrieb der Website als auch für die spätere Pflege, Veränderung oder Ergänzung des Systems ist eine durchgängig klare Strukturierung und Zusammenfassung logischer Gruppen im Code zwingend erforderlich.
Das wird in der Praxis, insbesondere bei komplexeren Systemen, oft vernachlässigt. Besonders bei der Strukturierung oder der logischen Zusammenfassung von zusammengehörigen Typoscript-Konfigurationen sind erhebliche Schwächen zu beobachten. Das resultiert aus dem hohen Flexibilitätsgrad, den Typoscript den Programmierern bietet. Er betrifft sowohl stilistische Aspekte, etwa die Zusammenfassung von Code-Abschnitten, als auch die Frage, wo welche Einstellungen im System hinterlegt werden. Zudem zeigt sich TYPO3 tolerant gegenüber mehrfacher Definition oder Konfiguration einzelner Funktionen, was die korrekte Ausführung der Befehle angeht.
Besonders bei größeren Web-Projekten empfiehlt es sich, die Richtlinien für das Typoscripting genau festzulegen. Eine solche Regel wäre etwa, dass logisch und/oder funktional zusammenhängende Konfigurationsblöcke grundsätzlich zusammengefasst werden und alle Konfigurationseinstellungen für eine Funktionalität immer in einem Template angelegt werden. So lässt sich direkt zu Beginn ein in sich konsistentes Ergebnis sicherstellen, wodurch der spätere Administrationsaufwand deutlich reduziert wird.
Fehlende Dokumentation der Typoscript-Templates
Auch wenn Typoscript eine relativ einfach zu lesende und zu interpretierende Konfigurationssprache ist, heißt das nicht, dass eine Dokumentation der entsprechenden Codes bedarfsweise oder eher zufällig erfolgen kann. In TYPO3-Systemen ist das aber meistens der Fall. Sie sind durch endlose Aneinanderreihungen von Plugin-Konfigurationen oder Anpassungen der Core-Funktionen charakterisiert, die kaum oder gar nicht dokumentiert im System abgelegt werden.
Die Ursache ist meistens trivial: Die Entwickler sind nicht gleichzeitig auch die späteren Administratoren, deshalb sparen sie sich den Dokumentationsaufwand - zum Leidwesen derer, die anschließend für den Support oder die Weiterentwicklung zuständig sind. Je nach System werden sie mit einem undurchdringlichen Dschungel an Code konfrontiert. Jede Fehlersuche und Änderung erfordert dann deutlich mehr Zeit und produziert höhere Kosten.
Wer sich ein TYPO3-System entwickeln lässt, sollte deshalb unbedingt auf eine vollständige und für Dritte leicht nachvollziehbare Dokumentation des gesamten Typoscript-Codes achten. Konfigurationseinstellungen, die von bestimmten Systemvariablen, User-Interaktionen oder sonstigen Faktoren abhängig sind, sollten eindeutig als solche gekennzeichnet und genau dokumentiert werden. Das schafft Transparenz und reduziert das Risiko, dass versehentlich einzelne Funktionen durch nachträgliche Änderungen nicht mehr korrekt arbeiten.
Keine klare Linie bei der Entwicklung von Extensions
TYPO3 bietet als Open-Source-CMS mit seinem Framework für eigene Erweiterungen die prinzipiell grenzenlose Freiheit, individuelle Anforderungen direkt im System abzubilden. Dieser große Vorteil kann sich jedoch für den Anwender schnell zu einem deutlichen Nachteil entwickeln, wenn die eigenen Erweiterungen vom Standard des CMS abweichen.
Das betrifft etwa die Frage, ob bei der Programmierung bewährte und für TYPO3 optimierte Methoden für Datenbankabfragen, die Manipulation von Inhalten oder die Ausgabe des Content genutzt werden oder ob der Entwickler eher auf kreative Eigenlösungen setzt, die aber weder unbedingt Upgrade-fähig noch effizient sein müssen. Zudem sind Schwierigkeiten vorprogrammiert, wenn bei den Extensions ohne Not die Caching-Mechanismen von TYPO3 ungenutzt bleiben oder sogar deaktiviert wurden.
Wichtig ist zudem, dass sich die extern hinzugenommenen Erweiterungen zumindest grundlegend an den Programmierrichtlinien für TYPO3 orientieren und auf das Funktionsangebot des CMS zurückgreifen. Das ist beispielsweise für die Generierung des Outputs oder den Zugriff auf Variablen relevant, weil es den Pflegeaufwand begrenzt und die vollständige Funktionalität auch nach einem Upgrade des Kernsystems gewährleistet. Auch hier sollte wieder eine ausführliche Dokumentation zum Pflichtprogramm gehören.
Mangelhafte Prüfung externer Erweiterungen
Mit mehreren Tausend Extensions steht den TYPO3-Anwendern ein breiter Fundus an ergänzenden Funktionen zur Verfügung. Dieser scheinbar paradiesische Zustand kann sich jedoch schnell in einen Albtraum verwandeln, wenn es nach der Installation einer neuen Extension oder eines Updates plötzlich zu erheblichen Funktionsstörungen kommt.
Deshalb ist gerade bei "exotischeren" Erweiterungen, die kaum verbreitet sind, eine gesunde Skepsis angebracht, bevor diese in ein produktives System integriert werden. Eine zumindest allgemeine Überprüfung des Quellcodes auf Auffälligkeiten im Zusammenhang mit den Sicherungsfunktionen und eine wenigstens rudimentär vorhandene Dokumentation sollten Pflicht sein. Auch gilt es zu überprüfen, ob eine Anleitung für die Erweiterung besteht und wie genau diese ist. Für das Verwenden externer Erweiterungen ist es daher sinnvoll, einen Test-Workflow einzuführen, in dem die Verträglichkeit mit dem bestehenden System geprüft wird und der grundsätzlich bei allen Extensions zum Einsatz kommen sollte.
Geringer Fokus auf Sicherheitsaspekte
Als Content Management System interagiert TYPO3 naturgemäß intensiv mit der zugrundeliegenden Datenbank und je nach Einsatzzweck auch mit externen Systemen. Deshalb muss das CMS gründlich gegen unberechtigte Manipulation von Inhalten oder sogar die Übernahme des kompletten CMS durch einen unbekannten Dritten geschützt werden. Dies betrifft besonders die verwendeten Erweiterungen, die Daten von der Client-Seite Richtung Datenbank transportieren. Ebenso gehören die Typoscript-Templates dazu, wenn dort beispielsweise ergänzende PHP-Skripte eingebunden sind.
Um eine maximale Sicherheit zu gewährleisten, ist darauf zu achten, dass Datenbankabfragen immer über die von TYPO3 zur Verfügung gestellten Funktionen abgewickelt werden. Diese bereinigen alle Parameter der SQL-Queries von eventuell enthaltenem Schadcode und führen weitgehend gesicherte Datenbankabfragen durch. Besonders Erweiterungen Dritter, die über keine hohe Zahl an Installationen verfügen und somit weniger oft einem Live-Test unterliegen, müssen diesbezüglich gründlich überprüft werden. Ein Augenmerk sollte hierbei auch auf eine Validierung von Parametern gelegt werden, damit Sicherheitsrisiken ausgeschlossen werden können.
Nicht zu vergessen ist ein gelegentlicher "Frühjahrsputz" einschließlich dem Deinstallieren nicht mehr verwendeter Extensions. Sie werden nicht mehr von Administratoren aktualisiert und können dadurch unbemerkt Sicherheitslücken im System aufreißen.
Diffuse Berechtigungskonzepte im CMS
Sobald eine Unternehmens-Website als komplexeres Projekt verschiedene Unternehmensbereiche abdecken soll, wird ein Berechtigungskonzept für den Zugriff auf einzelne Bereiche der Website zur Notwendigkeit. Dies dient sowohl dem Schutz des Systems als auch dem der User, die bei vollständigem Zugriff auf alle Funktionen schnell überfordert würden. Soweit die Theorie, die Realität sieht jedoch nicht selten ganz anders aus. Vielfach werden nicht alle erforderlichen Funktionen verfügbar gemacht, überflüssige Felder oder Features angezeigt oder sogar eigentlich gesperrte Inhalte geöffnet. Ein Berechtigungskonzept ist deshalb immer einer ausführlichen Prüfung zu unterziehen.
Dafür sollte nach der Anlage der User mit individuellen oder gruppenbezogenen Rechten explizit ein Benutzer simuliert werden. So lässt sich sicherstellen, dass erforderliche Inhalte entsprechend den Berechtigungen verfügbar und ausgeblendete Inhalte auch tatsächlich nicht erreichbar sind. Werden zusätzlich Freigabe-Workflows implementiert, muss auch hier genau geprüft werden, ob alle beteiligten User über die entsprechenden Rechte verfügen und der Zugriff jeweils auf die erforderlichen Arbeitsumgebungen beschränkt ist.
Fehlende Systematik bei Inhalts-Templates
Die weit verbreitete Extension Templavoila ermöglicht es, in TYPO3 ein flexibles und leistungsstarkes Mapping von Inhalten auf beliebige HTML-Templates zu realisieren. Dieser Komfort für die Benutzer, die dann keinerlei Formatierungen oder Design-Vorgaben mehr berücksichtigen müssen, erfordert besonders bei umfangreicheren Website-Projekten mit einer Vielzahl von Inhalts-Templates eine systematische Herangehensweise.
Besonderes Augenmerk ist deshalb beim Erstellen von sogenannten Flexiblen Inhaltselementen auf die Namensgebung zu legen. Ein Element mit der Bezeichung "Kurzer Text, 2 Bilder, rot" wird nur für den betreffenden Designer aussagekräftig sein. Ein Titel wie "Marketing - Promo neues Produkt" signalisiert hingegen auch anderen, zu welchem Zweck das Inhaltselement im System angelegt wurde. Hier kann auch die Möglichkeit genutzt werden, für jedes Element eine eigene Kurzbeschreibung zu hinterlegen sowie Vorschaubilder für die betreffenden Inhaltselemente einzubinden.
Gleiches gilt für Seiten-Templates, die möglichst präzise in Titel und Beschreibung wiedergeben sollten, für welchen Zweck sie gedacht sind. Werden in den so genannten Flexiblen Inhaltselementen zusätzliche Typoscript-Blöcke verwendet, um umfangreichere Formatierungen von Inhalten zu erzielen, ist eine ausführliche Dokumentation absolute Pflicht. Das gilt besonders dann, wenn Typoscript-Abschnitte aus den Inhaltselementen ausgelagert werden. Hier sind präzise Informationen beispielsweise dazu erforderlich, wo die entsprechenden Konfigurationen abgelegt und wo sie überall verwendet werden.
Unnötig lange Ladezeiten durch ineffizienten Output
In Sachen Output des System am Frontend bietet TYPO3 grundsätzlich weitreichende Möglichkeiten, da eine vollständige Trennung der Inhalte vom zugrundeliegenden Design besteht. Diese Flexibilität bedeutet jedoch nicht in allen Fällen auch eine optimale Ausgabe der Inhalte. Vielmehr ist es oft so, dass der Quellcode-Struktur sowie den Stylesheets, Javascripts und Bildern keine große Aufmerksamkeit mehr gewidmet wird, sobald Funktion und Design den Erwartungen entsprechen. Doch gerade hier schlummert meist ein großes Potenzial zur Performance-Steigerung, wobei sich ladezeiten um 50 Prozent und mehr reduzieren lassen. Je nach Konfiguration bindet TYPO3 eine Vielzahl von Stylesheets oder Javascript-Dateien als separate Verweise in die Seite ein, generiert auf Basis der Templates ein meist ineffizientes HTML oder unnötig große Bilddateien.
Letzteres lässt sich einfach dadurch korrigieren, dass bei den Grundeinstellungen im Install-Tool des CMS die Bildqualität solange testweise verändert wird, bis eine minimale Bildgröße bei gleichzeitig gewünschter Qualität erreicht wird. Damit reduziert sich die Ladezeit einer Seite erheblich, ohne dass weitere Änderungen notwendig werden. Zudem unterstützt TYPO3 eine vollautomatische Komprimierung des Outputs. Ergänzende Erweiterungen schaffen zusätzlich weitere Optimierungsmöglichkeiten. Beispielsweise lassen sich vollautomatisch alle Stylesheets und Javascripts komprimieren, zusammenfassen und gepackt ausliefern. Zusätzliche Techniken wie Cookieless Domains für alle statischen Inhalte, ein statisches Caching von HTML-Output auf dem Server etc. können helfen, Ladezeiten im Browser und auch die Serverlast zu reduzieren.
Lückenhaftes Update-Management des Systems
Als Open Source System profitiert TYPO3 von einer hohen Entwicklungsdynamik des Core-Systems und der Extensions. Das als Konsequenz notwendige Update-Management findet seitens der Systembetreiber allerdings nur selten in angemessener Form statt. Nützliche neue Funktionen werden somit nicht genutzt, auch die mögliche Behebung von Sicherheitslücken unterbleibt. Wichtig ist beim Update ein erneutes ausführliches Testing von TYPO3 nebst der verwendeten Extensions auf einem Testsystem, bevor das entsprechende Update oder der Patch auch auf der Live-Website zum Einsatz kommt. Besonders kritische Aspekte sind beispielsweise eine sich ändernde Abhängigkeit von PHP-Versionen als auch Veränderungen bei der Extension-Konfiguration.
Ein vollständiger Testdurchlauf auf dem internen System sollte daher den Installationsvorgang selbst inklusive eventuell erforderlicher Änderungen an Datenbanktabellen als auch einen umfangreichen Test der Website selber beinhalten. Hierbei muss dann die Frage im Fokus stehen, ob der generierte Content nach dem Update weiterhin den Vorgaben entspricht. Zusätzlich empfiehlt sich ein stichprobenartiger Test der übrigen Website-Funktionen, ob beispielsweise eine bestimmte Javascript-Bibliothek, die andere Extensions ebenfalls verwenden, nicht mehr automatisch eingebunden wird etc. (hv)