Test des CMS TYPOlight 2.5.5

Logo TYPOlightDa ich sowohl beruflich als auch privat viel mit Content Management Systemen (CMS) zu tun habe, bin ich natürlich immer interessiert, mal neue System kennenzulernen. Zum einen um sich vielleicht für die Arbeit das ein oder andere abzuschauen und zum anderen, weil ich irgendwann meine alte handgecodete Highlanderseite relaunchen möchte, was ich nur mit einem wirklich optimalen System machen kann.

Diesen Ostersonntag-Abend habe ich mir mal etwas Zeit genommen, das CMS TYPOlight zu testen. Auf den ersten Blick könnte man meinen, es würde sich dabei um eine abgespeckte Version von „Typo 3″ handeln, was aber nicht der Fall ist. Das CMS ist eine eigenständige Neuentwicklung auf Basis von PHP und erschien zuerst 2004. Entwickelt wird es hauptsächlich von dem Deutschen Leo Feyer.

Im Folgenden beschreibe ich kurz einen lokalen Test des Systems unter WAMPP. Achtung: Dies ist keine offizielle Installationsanleitung! Ich lerne das System auch gerade erst kennen. Ich habe auch absichtlich keine Doku gelesen, um mal zu schauen wie intuitiv das System ist.

Installation

InstallationsansichtZur Installation legt man einfach den Inhalt des zip-Archivs im gewünschten Ordner ab und schaltet diesen im httpd.conf-File des Apache für den Webzugriff frei. Dann braucht man noch eine neue, leere Datenbank mit entsprechendem Nutzer (MySQL in meinem Fall). Und dann kann man im Browser einfach die Datei typolight/install.php aufrufen.

In einer sehr sauberen und einfachen Oberfläche wird man jetzt durch die verschiedenen Installationsschritte geführt. Erledigte Schritte sind dabei mit einem grünen Häkchen gekennzeichnet. Alles passiert auf einer Seite, die sich immer wieder neulädt.

Das Passwort für das Install-Script steht in der Readme im zip-Archiv. Als erstes fordert einen das Script auch auf, dieses PW zu ändern. Das klingt schon mal gut, Security ist ja wichtig. Dann wird ein Encryption-Key generiert (wozu auch immer). Dann kann man die DB-Daten eingeben und das Script schreibt die Tabellen in die Datenbank.

Man kann ein Template importieren. Für den Test nehme ich das mitgelieferte Example-Template. Habe noch keine Ahnung, was das genau heißt. *g* Da hier vor Datenverlust gewarnt wird, wird der Begriff „Template“ aber wohl nicht im üblichen Sinne verwendet.

Und das war’s mit der Installation auch schon. Relativ einfach. 😉

Der erste Blick ins Backend

Unten auf der Installationsseite führt ein Link zum Backend-Login. Hier kann man die Sprache des Backends auswählen (Deutsch oder Englisch), was auch schon mal nett ist. Der Nutzername, den man hier zu benutzen hat, wurde offenbar zusammen mit dem Template importiert. Er steht am Ende der Installationsseite unter „Create an admin user“. Kann man leicht übersehen, aber dafür hat der Browser ja einen Zurück-Button.

Das Backend von TYPOlight präsentiert sich auf den ersten Blick ebenfalls sehr übersichtlich. Der Bildschirm ist in drei Bereiche geteilt. Eine schmale Kopfzeile enthält Links zum Frontend, zum Benutzerprofil und zum Logout. Links wird eine Seitenleiste angezeigt mit Links zu den verschiedenen Ansichten des Backends und dann gibt es den größeren Inhaltsbereich.

Kurz überprüft… Das HTML der Seite validiert (XHTML 1.0 Strict), was leider keine Selbstverständlichkeit ist. Dass CSS-File validiert nicht, aber nur wegen der Benutzung von CSS-3-Tags und einiger Mozilla-Tags. Also schon mal ein guter Eindruck soweit.

BackendOk, erst einmal der Inhaltsbereich. Ganz oben werde ich unter der Überschrift „Systemnachrichten“ darauf hingewiesen, dass zwei überfällige Aufgaben existieren. Es fehlt aber ein Link, der mich zu den Aufgaben oder den vollständigen Nachrichten bringt. Hm, dann eben nicht.

Weiter. Eine Erklärung der Tastaturkürzel. Nett zu wissen, muss meinetwegen aber nicht immer ganz oben im Backend stehen. Bei Webseiten benutze ich eigentlich nie Tastaturkürzel.

Es folgt eine Liste an Links zu den Verwaltungsseiten der verschiedenen Inhaltstypen (denke ich). Artikel, Nachrichten, „Flash Inhalte“ (sic – Deppenleerzeichen, autsch), Formulargenerator, Kalender/Events, Kommentare, Newsletter, FAQ. Hm, das deckt schon mal die Bedürfnisse der meisten kleineren Seiten ab. Nicht schlecht. Die spannende Frage, die sich mir hier wie bei jedem CMS-Test stellt: Wie kann man eigene Inhaltstypen definieren? Kann man den Seitentyp „Buch-Rezension“ anlegen, mit speziellen Feldern dafür? Muss man das in dem am Anfang importierten Template definieren? Ich bin gespannt…

Nach den Inhalten kommt die Rubrik „Layout“. Hier gibt es Module, Stylesheets, Seitenlayouts, Seitenstruktur und Templates zur Auswahl. Hm, ist klar soweit, interessiert mich aber im Moment noch nicht.

Dann kommen Links zur Benutzerverwaltung. Offenbar wird zwischen Website-Besuchern und Redakteuren unterschieden, es gibt zwei getrennte Seiten für die jeweiligen Benutzer und Benutzergruppen. Also interne und externe Nutzer gewissermaßen. Das handhabt jedes CMS scheinbar anders. Von WordPress her bin ich mittlerweile den Ansatz gewöhnt, nur eine Nutzerbasis zu haben, mit entsprechenden Rechten, und aus meiner Programmiererfahrung heraus ziehe ich das auch vor. Aber gut, hier muss ich ja nichts programmieren, also ist das auch ok.

Unter „System“ finden sich Links zu Dateiverwaltung, System-Log, Einstellungen, Systemwartung, Modul-Creator und einem Tool zum Finden fehlender Labels in Sprachdateien. Ganz unten sind dann noch drei Benutzerfunktionen, das interessanteste davon sicher das „Task Center“. Meine Güte, bestimmt schon das vierte überflüssige Leerzeichen auf einer Seite, und das nur beim Überfliegen gesehen. 🙁

Einstellungen

Ok, schaue ich mir mal die Einstellungen an. Auf einer einzelnen Seite kann man hier alles mögliche an Einstellungen eingeben. Seitentitel, Mail-Adresse des Admins. Da geht es schon los, meine lokale Mailadresse „sender@localhost“ wird nicht akzeptiert. Ja Jungs, eine andere habe ich hier aber nicht. 🙁

Weitere Optionen: Zeitformate, Zeitzone, lokaler Pfad, Zeichensatz, Datensätze pro Seite. Die Option „Maximale Frontend Bildbreite“ sieht nett aus. Nicht das Deppenleerzeichen natürlich, aber die Funktion klingt praktisch. Ich trage mal „700″ ein. Bilder, die größer sind, werden dann wohl entsprechend verkleinert. Es fehlt natürlich eine Angabe, welche Einheit gemeint ist oder ob man diese mit eingeben muss (CSS-Syntax?!).

Es gibt scheinbar wie bei WordPress ein Permalink-Feature. Nett.

„Fehler anzeigen“: Man kann auswählen, ob Fehler am Bildschirm angezeigt werden sollen, standardmäßig werden sie es nicht. Ein Fehlermanagement, sehr nett. Das hat WordPress z.B. nicht, und es bleibt dem Nutzer überlassen, seine PHP-Installation korrekt zu konfigurieren.

Die weiteren Optionen sind nicht so spannend. Nebenbei stelle ich noch fest, dass erweiterte Optionen eingeblendet werden, wenn sie benötigt werden, z.B. Felder für den SMTP-Server erst bei Auswahl der Option dafür. Man kann das Backend scheinbar stylen, auch wenn standardmäßig nur der Default-Skin zur Auswahl steht. Wenn man ein CMS für Kundenprojekte einsetzt, ist das eine wichtige Fähigkeit.

Ganz am Ende kann man noch eine einfache Matrix aus Rechten und Benutzergruppen managen. Ok, das hätte ich der Übersichtlichkeit halber auf eine eigene Seite gepackt.

Ok, kurzer Test. Beim Verlassen der Einstellungsseite wird nicht vor ungespeicherten Änderungen gewarnt. Obwohl ich nun keine Mailadresse eingetragen habe, hat sich TYPOlight erfreulicherweise alle anderen Einstellungen aber gemerkt. Sehr schön. Dabei stelle ich auch gleich noch fest, dass eine Inline-Hilfe existiert: Am von mir eingegebenen und offenbar falschen Datumsformat klebt ein kleines Fragezeichen-Achtung-Schild. Dahinter verbirgt sich ein Popup mit Erklärungen zu diesem Punkt. Sehr schön. Nicht so gut: Wenn man nicht auf „Speichern“ klickt und die Seite verlässt, kommt keine Warnung. Ebenfalls nicht ganz optimal: Den Speichern-Button gibt es nur einmal ganz unten, und die Seite ist recht lang. Ja, ich weiß, Tastaturkürzel. Aber wer hätte es gedacht, Alt+S ist in meinem Browser offenbar mit was anderem belegt.

Frontend

So, Zeit überhaupt mal das Frontend anzuschauen. „Objekt nicht gefunden“ sagt mir der Browser. Muss ich erst einen Inhalt anlegen? Aber das könnte mir das System ja auch mal sagen. Die FollowSymLinks-Option hatte ich im Apache eingetragen, das bin ich ja schon von den WordPress-Permalinks gewohnt. Ok, stellen wir die Permalink-Option erstmal wieder aus. Und siehe da, es geht. (Beim Gegenlesen fällt mir auf, dass ich das an diesem Abend dann nicht mehr weiter verfolgt habe.)

Die importierte Testseite nennt sich „Music Academy“. Irgendwie wundert es mich, dass der Seitentitel, den ich im Backend eingetragen hatte, nicht auftaucht. Ansonsten sehr hübsch. Brotkrumennavigation, „Print as PDF“-Feature… Die Demoseite enthält Erklärungen zu verschiedenen Features des CMS, aber ich schaue mich erst mal weiter im Backend um.

Taskcenter

TaskcenterZeit, sich um die überfälligen Aufgaben zu kümmern. Im Taskcenter entpuppen sich diese als Beispieltasks. Ich lege aus Spaß mal eine neue Aufgabe an. Titel, Deadline, dann kann man die Aufgabe einem User zuweisen.

Ups, da haben wir einen Fehler erzeugt. Ja klar, ohne eingetragene Mailadresse oder laufenden Mailserver kann TYPOlight natürlich den Beispielnutzer auch nicht über seine Aufgabe benachrichtigen. Immerhin ist die Fehlerseite insofern hilfreich als sie direkt auf das Logfile hinweist. Dort stellt sich heraus, dass TYPOlight das Datumsformat nicht mag. Meine Güte, sollte das so einen Fehler auslösen? Kann man dann nicht einfach ein Standardformat nehmen? Was fehlt ist ein Link zurück zum Backend.

Zurück zu den Einstellungen. Ja, Hilfetexte sollte man auch lesen. TYPOlight mag mein favoritisiertes Datumsformat „d. M Y“ nicht. Gut, dann halt nicht.

Datumsformat geändert und jetzt klappt das Anlegen neuer Tasks. Sonst ist hier nichts spannendes, ich hatte eigentlich gedacht, das System würde einen hier vielleicht mit voreingestellten Tasks beim Anlegen der Seite unterstützen. Das wäre vielleicht sinnvoller als die vorhandenen Beispieltasks.

Artikel-Verwaltung

ArtikelverwaltungOk, gehe ich mal weiter zur Artikelverwaltung. Hier kann man einen Baum aufklappen, der verschiedene Seiten bzw. Artikel enthält. Über Icons kann man den Artikel bearbeiten, verschieben, duplizieren, löschen etc. Klickt man auf „Bearbeiten“, kommt man zu einer Seite, welche die verschiedenen Elemente der Seite auflistet, z.B. Textbausteine und Überschriften.

Nebenbei bemerkt sind die Icons nicht gerade groß. Ob es das auch in „accessible“ für Leute mit schlechten Augen gibt? Vielleicht als spezielles Backend-Theme? Die Schrift kann man im Browser ja vergrößern, die Icons leider nicht.

Über die gleichen Icons kann man nun die einzelnen Seitenbausteine bearbeiten, löschen, verschieben etc. Ich editiere mal den ersten Baustein. Es wird eine neue Seite geladen. Das hätte ich jetzt fast per AJAX inline erwartet, aber die Seite enthält doch eine ganze Reihe an Infos. Meine Güte, da kann man ja einiges einstellen.

Das CMS kennt verschiedene Elementtypen, quasi die kleinsten Inhaltsbausteine. Das wären z.B. Überschrift, Text, HTML, Aufzählung, Tabelle, Akkordeon, Code, Hyperlink, Top-Link, Bild, Bildergalerie, Download, Downloads, Alias, Artikelteaser, Formular, Modul, Flashgalerie, Kommentare. Nicht schlecht, damit kann man ja schon einiges bauen. Von anderen System bin ich es gewohnt, dass ein Artikel doch relativ starr definiert ist. Hier ist das scheinbar pro Artikel variierbar.

Für die Überschrift kann man die Stufe von h1 bis h6 auswählen. Das irritiert mich. Ist es nicht Aufgabe des Templates zu entscheiden, mit welchem H-Tag die Überschrift ausgegeben wird? EDIT: Da hier beliebig viele Textbausteine kombiniert werden können, macht es schon Sinn, dass man eine Hierarchie für die Überschriften angeben kann, um z.B. unter einer H2 mehrere H3s schachteln zu können. Und ich nehme mal an, dass ein Template bei Bedarf die Überschrift auch anders ausgeben könnte, wenn z.B. die jeweils ersten Überschriften aller Artikel auf einer Seite dargestellt würden oder etwas in der Art. Dass die manuelle Vergabe der Überschriften-Hierarchie zumindest nicht ganz simpel ist, zeigt die Startseite der Beispiel-Seite, welche drei H1-Überschriften untereinander enthält (h1 ist der Default-Wert der Auswahl-Box).

Der Text des Artikels kann in einem graphischen Editor bearbeitet werden. Das wird doch nicht TinyMCE sein? Doch, ist es. Der Editor hat von WordPress her keinen guten Ruf, aber das kann auch an der Einbindung in WordPress liegen. Wird sich zeigen müssen, wie gut der Editor in diesem System funktioniert.

Man kann Artikeln natürlich auch Bilder hinzufügen. TYPOlight verwaltet Bilder im Dateisystem im Ordner tl_files, auf den ersten Blick offenbar ohne weitere Infos dazu in der DB zu speichern. Öffnet man den Dateimanager in einem Popup, kann man dort auch neue Bilder hochladen. Das Interface ist hier nicht direkt intuitiv, aber wenn man es erst mal kapiert hat, ist das kein Problem.

DateiverwaltungDas Folgende ist das erste, was mich an diesem CMS wirklich irritiert: Ich habe den Dateimanager in einem Popup geöffnet und ein Bild hochgeladen. Es gibt keinen Button, um dieses Bild zum Hinzufügen zum Artikel auszuwählen. Klickt man darauf, öffnet sich nur das Bild in einem weiteren Popup. Also versuche ich das erste Popup zu schließen und kriege eine merkwürdige Javascript-Meldung voller falsch codierter Umlaute. Klickt man auf „OK“ wird die Editorseite neu geladen (Warum???) und es sind tatsächlich gemachte Änderungen weg. Keine Ahnung, was das soll. Ok, beim zweiten Versuch nicht auf OK geklickt. Das Bild muss ich also ohne das Popup auswählen.

Im Folgenden kann man zum Bild noch einige Sachen eingeben wie ein alternativer Text und eine Bildunterschrift. Das ist für mich in Hinblick auf meine Highlanderseite wichtig, denn einer der größeren Nervfaktoren beim händischen Bearbeiten der Seite war das Managen der Bilder: Das gleiche Bild taucht oft auf verschiedenen Seiten auf und ich musste da dann immer wieder alt-Text und Untertitel ergänzen, entweder den gleichen oder einen neuen. Das zentral speichern zu können wäre wünschenswert.

Man kann einzelne Inhaltselemente nur bestimmten Nutzergruppen anzeigen oder für angemeldete Nutzer verstecken. Sehr nett.

Für die Bildanzeige im Frontend genau wie für AJAX-Funktionen im Backend wird im übrigen Slimbox verwendet, ein Lightbox-Klon. Funktioniert tadellos, gefällt mir persönlich vom Aussehen her aber nicht so gut. Das sich drehende Kleeblatt (oder was auch immer?!) beim Nachladen von Content via AJAX sieht im Backend auch etwas deplaziert aus, finde ich. Aber gut, das sind Details. Für JS-Effekte wird MooTools eingesetzt. Habe ich persönlich noch nichts von gehört, ich bin letztens eher bei jQuery auf den Geschmack gekommen.

Aufgrund der Länge des Artikels habe ich ihn in zwei Teile geteilt. Weiter geht es auf der nächsten Seite.

3 Gedanken zu „Test des CMS TYPOlight 2.5.5

  1. Sehr ausführlich, sehr präzise und informativ. Hat auf jeden Fall dazu beigetragen, mich für dieses wirklich empfehlenswerte CMS zu entscheiden. Vielen Dank.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte beachte die Kommentarregeln: 1) Kein Spam, und bitte höflich bleiben. 2) Ins Namensfeld gehört ein Name. Gerne ein Pseudonym, aber bitte keine Keywords. 3) Keine kommerziellen Links, außer es hat Bezug zum Beitrag. mehr Details...

So, noch mal kurz drüber schauen und dann nichts wie ab damit. Vielen Dank fürs Kommentieren! :-)