Website-Baukästen

Freie Content-Management-Systeme und andere Werkzeuge für dynamische Internet-Auftritte

Wissen | Hintergrund

Bei häufig zu aktualisierenden Inhalten machen statische HTML-Seiten keinen Spaß; erst recht nicht, wenn Kollegen ständig neue Inhalte anschleppen. Wir zeigen, wo man ein Content-Management-System braucht oder der Web-Baukasten des Providers ausreicht.

Eigentlich sind CMS ganz einfach: Während auf einer statischen Website Inhalt und Layout zusammengerührt sind (woran in der Praxis auch Stylesheets nicht viel ändern), unterscheidet ein CMS zwischen diesen Bestandteilen - ganz im Sinne des Model-View-Control-Paradigmas, wobei „Model“ den in der Datenbank oder im Dateisystem abgelegten Inhalten entspricht, „View“ den Layout-Vorlagen und „Control“, die Ablaufsteuerung, dem Kern der Anwendung.

Das CMS gibt seinen Benutzern auch die Möglichkeit, neue Texte, Bilder und Dokumente aller Art ins System einzupflegen. Eine neue Webseite zu schreiben, ist mit einem zeitgemäßen CMS nicht schwieriger, als ein Word-Dokument anzulegen. Dazu braucht es einen intuitiv bedienbaren WYSIWYG-Editor und einfache Bildbearbeitungsfunktionen zum Skalieren, Zuschneiden und Einstellen von Illustrationen. Das Backend, also die Dateneingabe und die Systemverwaltung, muss ebenso über den Browser funktionieren wie die Ausgabe der Inhalte im Frontend - Software-Installation ist nur auf dem Server notwendig.

In Sachen Nutzerverwaltung sind unterschiedliche Rechte für Bearbeiter und Administratoren das Minimum. Größere Systeme brauchen aber noch viel mehr: Bearbeiter, die nur bestimmte Bereiche der Site ändern können, Designer mit Zugriff aufs Layout, Freischalter, die neue Beiträge absegnen müssen. Damit ergibt sich die Notwendigkeit, Arbeitsabläufe (Workflows) abzubilden. Vordefinierte Rollen helfen beim Anlegen neuer Benutzer, die Feinabstimmung geschieht über die Zuweisung von Rechten.

Auch im Frontend muss das System oft unterschiedliche Anwender verwalten, wenn bestimmte Inhalte oder Kommentare nur nach Registrierung freigegeben sind. Da so etwas nicht in allen CMS-Installationen gebraucht wird und die Programmpakete ohnehin schon zur Unübersichtlichkeit neigen, lagern die meisten Programmhersteller Funktionen wie diese in Module aus. Bei den Modulen finden sich auch die ganzen Extras, die für viele erst ein CMS interessant machen: Galerie, Newsletter und Shop für den ambitionierten Fotografen, Diskussionsforum und RSS-Aggregator für den Netz-Aktivisten, Kalender, Chat, Gästebuch und vieles mehr. Populäre CMS haben Hunderte von Modulen, doch unterscheiden sie sich enorm in Sachen Code-Zustand und Dokumentation.

Die Qualität der ausgespuckten Webseiten hängt in erster Linie von den Vorlagen ab, doch kann auch ein schlechter WYSIWYG-Editor oder Template-Mechanismus eine standardkonforme, in allen Browsern laufende und womöglich barrierefreie Vorlage ruinieren. Bleibt noch daran zu erinnern, dass ein CMS im Web an vorderster Front steht und natürlich in puncto Sicherheit vertrauenswürdig sein muss. Das schließt auch eine bequeme Backup-Funktion und eine Versionsverwaltung ein, die bei Schnitzern eines Bearbeiters vergangene Zustände wiederherstellen kann.

Die Entscheidung für ein bestimmtes Content-Management-System muss gut bedacht sein, denn beim Wechsel des Systems gerät jeder Webmaster ins Schwitzen; Import- und Exportschnittstellen sind Mangelware. Probleme gibt es sogar schon, wenn von einem kleinen Server auf einen größeren gewechselt wird - zumindest, wenn der CMS-Hersteller nicht an solche Migrationen gedacht hat.

Content-Management-Systeme im engeren Sinn zählen nach Hunderten - in allen möglichen Programmiersprachen, manche quelloffen und kostenlos, andere im sechsstelligen Euro-Bereich. Dennoch ist ein Feature-schweres Vollblut-CMS nicht immer die optimale Lösung.

So gibt es Fälle, in denen sich der Umstieg auf ein CMS ganz einfach nicht lohnt. Selbst kleine Content-Management-Systeme verlangen dem Anwender einiges an Konfiguration und Einarbeitung ab. Wer nur alle paar Wochen eine neue Seite hochlädt, schafft das wahrscheinlich schneller mit Editor und FTP-Client.

Außerdem haben die gängigen Webeditoren [1] Werkzeuge für die Site-Verwaltung zu bieten, die dem Hobby-Webmaster zumindest einige der lästigsten Routinearbeiten abnehmen: Sie können Links Site-übergreifend anpassen und überprüfen. Das von einigen Programmen unterstützte Vorlagenformat DWT macht es leicht, für die ganze Site das gleiche Design zu benutzen und erlaubt es sogar, Bereiche für den Bearbeiter zu sperren; Navigations-Links lassen sich damit an zentraler Stelle einfügen. Der integrierte FTP-Client lädt nur die geänderten Dateien hoch, sodass die Aktualisierung zügig von der Hand geht. Außer Expression Web gibt es alle Anwendungen in der Tabelle unten auch für den Mac, Nvu auch für Linux.

Angesichts der gewaltigen Zahl von Fertiglösungen wirkt ein Selbstbau-CMS widersinnig. Interessant ist es wohl nur für Ein-Mann-Websites, denn der größte Vorteil des Hausgemachten ist, dass der Entwickler sein Werk genau kennt und exakt an seine Bedürfnisse anpasst; viel Lust aufs Programmieren ist ohnehin Voraussetzung. So kann der Entwickler die bei Fertig-CMS übliche Datenbank umgehen - zwar enthalten die meisten skriptfähigen Hosting-Angebote eine MySQL-Datenbank, doch erweist diese sich oft als Performance-Flaschenhals. Eine Eigenentwicklung kann stattdessen Daten direkt im Dateisystem ablegen oder als Offline-CMS die Webseiten auf dem lokalen PC zusammenbauen, was auch auf Billigst-Webspace ohne Skriptsprache funktioniert.

Ein Mittelweg zwischen statischer Website und Eigenbau-CMS sind Server Side Includes (SSI) [2]. Ein Satz von einfachen Befehlen bindet externe Dateien ein, gibt Umgebungsvariablen aus (etwa das Datum oder die aktuelle URL) und beherrscht sogar Bedingungen und reguläre Ausdrücke. Die Anforderungen an Hard-, Soft- und Brainware sind minimal, auch Nichtprogrammierer können mit Anweisungen wie beispielsweise eine Navigationsleiste einbetten, ohne jedes Mal den gleichen HTML-Container per Copy & Paste auf die Webseite zu kleben. Große Programmierkunststücke sind mit der von Apache und Microsofts IIS bereitgestellten Mini-Skriptsprache freilich nicht möglich. Als lästig erweist sich in der Praxis, dass die Apache-Standardkonfiguration eine Umbenennung der mit SSI erweiterten HTML-Dateien auf .shtml (oder .sht) verlangt.

Für das Zusammenleimen der Website aus mehreren, wiederverwendbaren Bestandteilen eignet sich natürlich auch die Skriptsprache Ihrer Wahl - sei es PHP, ASP.NET, ColdFusion oder Perl. Die Apache-Bordmittel reichen auch für einen Zugangsschutz, der einzelne Bereiche der Website für die Allgemeinheit sperrt: Mit den Dateien .htaccess und .htpasswd kann der Webmaster Verzeichnisse registrierten Anwendern vorbehalten [3].

Der nächste logische Schritt sind Template-Engines. Sie sind sozusagen Content-Management-Systeme in einer Nussschale: ohne RSS- und Forumsmodule, ohne Benutzerverwaltung, ohne WYSIWYG-Editor. Alles, was sie können, ist Inhalte und Vorlagen zusammenzuführen. Zum Standardumfang gehören Bedingungen und Iteration von Listen.

Auch hier stehen sich wieder niedriger Nutzungskomfort und hohe Flexibilität gegenüber. Die Template-Sprachen sind einfach zu verstehen und arbeiten dank Caching der erzeugten Seiten performant. PHP lässt sich direkt als Template-Sprache benutzen, aber Engines wie Smarty trennen den Anwendungscode von den Vorlagen, sodass sich Programmierer und Designer nicht auf die Füße treten [4]. Caching-Mechanismen sorgen für hohe Geschwindigkeit.

Serveranwendungen wie phpCMS bringen Extras wie Statistiken, automatisch erzeugte Sitemaps, Volltextsuche und Plug-ins mit. Dass sich diese Engines nicht nur für Hobby-Websites eignen, beweist das mächtige Mason: es steckt hinter Amazon.com. Akademisch orientierte Entwickler dürften eher zu XML-Transformationen (XSLT) tendieren, die in allen üblichen Programmiersprachen möglich sind. (heb)

Den vollständigen Artikel finden Sie in c't 11/2007.

"Website-Baukästen"
Artikel zum Thema "Website-Baukästen" finden Sie in der c't 11/2007:
Das optimale CMS S. 88
Provider-Beigaben S. 96
Joomla-Praxis S. 100

[1] Herbert Braun, Webdesign-Schlachtschiffe, Microsofts FrontPage-Nachfolger mischt Dreamweaver & Co. auf, c't 24/06, S. 176

[2] Sven Lennartz, Dynamische Seiten, Server Side Includes richtig einsetzen, c't 20/01, S. 224

[3] .htaccess in Apache: http://httpd.apache.org/docs/2.2/howto/htaccess.html

[4] Oliver Lau, Matthias Weigel, Schablonenzauber, Arbeitsteilige PHP-Programmierung mit Hilfe von Templates, c't 11/04, S. 216

Kommentare

Anzeige
Anzeige