Webseiten programmieren und gestalten

# Content Management System

Grundlagenforschung betreibe ich dann, wenn ich nicht weiß, was ist tue.
– Werner Freiherr von Braun, deutsch-amerikanischer Raketenforscher

Grundlagenforschung werden Sie in den nachfolgenden Kapiteln nicht betreiben müssen, doch sollten Sie sich, bevor Sie ein Projekt in Angriff nehmen, immer überlegen, was sein Ziel ist und wie es zu realisieren ist.

# Das Ziel

In diesem Kapitel möchte ich aufzeigen, wie Sie an ein Projekt herangehen sollten, das möglichst dynamisch sein und bleiben soll, an dem zugleich aber Änderungen schnell und leicht vorgenommen werden können.

Ich habe lange überlegt, was für ein Projekt ich an dieser Stelle beschreiben soll – angefangen bei einem umfangreichen News-System, über verschiedenste E-Shop-Lösungen bis hin zu den allseits beliebten Content-Management-Systemen (auch CMS genannt). Wirklich entscheiden konnte ich mich nicht, da jedes dieser Projekte, um es wirklich gut zu beschreiben, ein eigenes Buch füllen könnte. Schlussendlich bin ich bei einer abgespeckten Variante eines CMS gelandet.

Als Content-Management-System werden in aller Regel webbasierte Softwarelösungen bezeichnet. Während Sie mit einfachen Editoren (meistens) nur HTML-Seiten erstellen, die Sie nach jeder Änderung auf den Server übertragen müssen, bieten Content-Management-Systeme Ihnen die Möglichkeit, den Inhalt einer Webseite über eine browserbasierte Oberfläche zu pflegen. Der Vorteil solcher Systeme liegt klar auf der Hand: Sie selbst bleiben bei der Administration der Webseite stets unabhängig. Egal, wo Sie sich gerade auf der Welt befinden, Ihnen genügt ein Computer mit Zugang zum Internet, um Ihrer Webseite neue Informationen hinzuzufügen oder gar das Aussehen Ihrer Webseite zu verändern. Vorbei sind die Zeiten, in denen Sie mühselig jedes HTML-Dokument von Hand verändern mussten, um anschließend mit einem FTP-Client die Seiten wieder auf dem Server abzulegen.

Unser Ziel ist es nun, mit geeigneten Techniken eine Lösung zu schaffen, die Ihnen die Freiheiten eines CMS, wenn auch auf einer sehr rudimentären Stufe, bietet.

Bevor Sie sich in die Arbeit stürzen und losprogrammieren, um nach ein paar Zeilen Code wieder und wieder von vorn anzufangen, sollten Sie sich erst einmal Gedanken darüber machen, wie das CMS in etwa aufgebaut sein soll und welche Inhalte damit gepflegt werden sollen. Meine Überlegungen haben mich zu dem kleinsten gemeinsamen Nenner der meisten CMS geführt.

Auf allen Seiten, die ein CMS einsetzen, werden Sie Rubriken wie News, Downloads und Links finden. Die News sind häufig das zentrale Ausgangsthema einer auf CMS basierenden Webseite. Wie ich bereits erwähnt habe, werden ohne aktuelle Informationen – und dazu zählen zwangsläufig die neuesten Nachrichten zu einem Thema – die Besucherzahlen einer Webseite nicht unbedingt steigen. Als Schmankerl sind dann häufig die Download-Bereiche zu bezeichnen, die mittlerweile auch schon zum guten Ton einer Webseite gehören. Ein weiterer Service für die Benutzer einer Webseite sind natürlich weiterführende Links zu Webseiten, die sich ebenfalls den behandelten Themengebieten widmen.

Sehr häufig – vor allem auf den Webseiten einschlägiger Fachzeitschriften – gibt es die Möglichkeit, zunächst gedruckt erschienene Artikel auch im Internet zu lesen. Da es in der Regel länger dauert, solche Artikel zu lesen, ist dies für die Betreiber ein sehr positiver Aspekt. Immerhin können Sie die Benutzer so länger auf der eigenen Webseite halten.

Natürlich müssen solche Rubriken – insbesondere die News – regelmäßig, wenn nicht gar täglich, gepflegt werden. Es sollte also auch möglich sein, diese Rubriken und die Inhalte entsprechend schnell und einfach zu pflegen.

Das zu realisierende Projekt, die Light-Version eines CMS, soll also die folgenden Inhalte bieten:

  • News
    Hier sollen regelmäßig neue und kurze Mitteilungen zur Verfügung gestellt werden, um die Besucher anzuregen, regelmäßig die Webseite zu besuchen.
  • Downloads
    Diese Rubrik soll den Benutzern der Webseite einen kleinen Extra-Service bieten und verschiedene Daten, seien es nun Bilder, Videos, Dokumente oder gar Programme, zum Download zur Verfügung stellen.
  • Links
    Damit der Benutzer auch auf anderen, möglichst themenverwandten Seiten weitere Informationen erhalten kann, werden in dieser Rubrik die Verknüpfungen zu den anderen Seiten präsentiert.
  • Artikel
    Da die Rubriken News, Downloads und Links zwangsläufig nur einen sehr dünnen Informationsgehalt und auch Service bieten, soll die Artikel-Rubrik durch harte Fakten in lesbarer Form bestechen. Einen weiteren positiven Effekt der Artikel, wenn sie etwas angepasst wurden, werde ich Ihnen später noch aufzeigen.

Nachdem nun die Rubriken der Webseite festgelegt wurden, sollte das Leistungsgebiet des CMS genauer betrachtet werden. Der wichtigste Aspekt ist sicherlich eine hohe Anpassungsfähigkeit und Flexibilität der Webseite. Es nützt nichts, wenn Sie zwar die Inhalte dynamisch verwalten, die Art und Weise der Ausgabe jedoch letztlich statisch bleibt. Ich möchte Ihnen das ein wenig erläutern.

Wenn Sie demnächst im Internet unterwegs sind und dort auf scheinbar dynamische Webseiten stoßen, versuchen Sie einmal, genau auf den Aufbau der Seite zu achten. Häufig ist es so, dass die Seite zwar serverseitige Scriptsprachen wie Perl oder PHP einsetzt, im Endeffekt aber statisch ist. Der Sinn einer dynamischen Webseite ist es, flexibel zu bleiben und dem Administrator der Seite möglichst viel Spielraum zur Veränderung und Anpassung zu bieten. Dieses Ziel können Sie jedoch nicht erreichen, wenn Sie Hunderte von PHP- oder Perl-Scripts auf dem Server verteilen, die alle lediglich eine kleine Aufgabe lösen. Bei einer Änderung eines einzelnen Scripts ist es daher häufig notwendig, auch noch weitere Scripts anzupassen, die jedoch erst gesucht werden müssen. Wenn das der Fall ist, können Sie auch gleich wieder zu den altbewährten HTML-Dokumenten zurückkehren und müssen sich um Scriptsprachen gar keine Gedanken mehr machen. Die zunächst geplante Dynamik der Webseite läuft sich fest und bleibt irgendwann stecken.

Summa summarum bedeutet dies, dass Sie eigentlich nur ein einziges Script bzw. nur sehr wenige verwenden sollten, um möglichst dynamisch bleiben zu können und nicht ständig Sand ins Getriebe zu schleudern. Also: Die erste zusätzliche Anforderung an das CMS ist die Verwendung sehr weniger Scripts.

Viele dynamische Webseiten arbeiten sehr ineffektiv. Die auszugebenden Daten werden in aller Regel durch bereits im Script fest verankerte Zeichenketten formatiert. So geben die meisten Scripts den Großteil des HTML-Dokuments durch einzelne echo- respektive print-Anweisungen im Browser aus. Soll das Design der Seite einmal anders aussehen, müssen Sie dies in den Scripts selbst verändern. Außerdem wird jede saubere Strukturierung und Kommentierung eines Quelltextes ad absurdum geführt, wenn die Hälfte davon aus echo-/print-Anweisungen besteht, um HTML-Elemente und -Quelltext auszugeben. Die Lösung des Problems ist die Verwendung von so genannten Templates.

Templates haben Sie sicherlich schon in den verschiedensten Momenten eingesetzt. Dokumentvorlagen (engl*. templates*), wie z. B. ein Briefkopf, ein Faxdeckblatt usw., sind solche Templates. Sie verwenden immer die gleiche Vorlage und fügen nur einen anderen Inhalt ein. Dies lässt sich auch für Webseiten einsetzen. Dabei erzeugen Sie ein einziges Mal ein HTML-Dokument, das die Vorlage für die Webseite bildet. In dem HTML-Dokument werden dann an bestimmten Stellen so genannte Platzhalter notiert. Mit PHP oder Perl wird das Template später dann geladen, und die Platzhalter werden durch den entsprechenden Inhalt ersetzt. Das Ganze wird dann an den Browser gesendet. Der Vorteil: Sie müssen bei einer gewünschten Änderung nur ein neues Template erstellen, und schon erstrahlt die Webseite in einem neuen Gewand.

Gewisse Dinge sind immer davon abhängig, bei welchem Provider Ihre Webseite gehostet wird, und wie er den Server aufgebaut und konfiguriert hat. Damit Sie auch im Fall eines Providerwechsels nicht erst mühsam Ihre Webseite an die neue Umgebung anpassen müssen, sollten möglichst alle umgebungsabhängigen Variablen, wie das Datenbankkennwort und Ähnliches, in einer zentralen Konfigurationsdatei abgelegt werden (auf dieses Thema bin ich schon weiter vorn in diesem Buch eingegangen).

# Wählen Sie jetzt!

Der erste Schritt bei der Planung des Projekts ist getan. Sein Ziel wurde relativ eindeutig festgelegt. Nun steht die Entscheidung an, welche Techniken eingesetzt werden sollen.

Zur Verwaltung der Inhalte stehen Ihnen im Endeffekt nur zwei Möglichkeiten offen: Entweder speichern Sie die Inhalte in Dateien oder legen die Inhalte in einer Datenbank ab. Der Vorteil von Dateien ist, dass Sie keinen Provider finden müssen, der Ihnen relativ preisgünstig ein Webhosting-Paket mit einer Datenbank im Hintergrund anbietet. Der Nachteil ist jedoch, dass der Zugriff auf Dateien im Vergleich zu Datenbanken eher schleppend ist. Je größer die Datenmenge also wird, desto langsamer baut sich Ihre Webseite für den Benutzer auf. Am besten ist also die Verwendung einer Datenbank (die sich obendrein auch über die Programmierung wesentlich flexibler ansprechen lässt).

PHP oder Perl, das ist hier die Frage ... Obwohl nahezu alle Provider sowohl PHP als auch Perl zum serverseitigen Programmieren anbieten und sich die Sprachen eigentlich beide für den Einsatz anbieten, gibt es Unterschiede. Meistens ist Perl so konfiguriert, dass es an das cgi-bin-Verzeichnis gebunden ist. Alle Perl-Scripts müssen also im cgi-bin-Verzeichnis abgelegt werden, damit sie ausgeführt werden können. Außerdem ist Perl eine sehr mächtige Sprache, vor allem in Bezug auf die Arbeit mit Dateien. Die Mächtigkeit der Sprache ist jedoch auch ein Nachteil: Perl ist dadurch langsam, zumindest langsamer als PHP. Zudem gestaltet sich der Datenbank-Zugriff mit Perl nicht gerade sehr angenehm. Würden also Dateien eingesetzt, um die Inhalte der Webseite zu organisieren, wäre Perl sicherlich die bessere Wahl. Da aber Datenbanken verwendet werden, werden wir PHP einsetzen.

An HTML führt letztlich kein Weg vorbei. Sie könnten zwar auch versuchen, die Seite als Grafik auszugeben, aber das wäre totaler Unsinn. Als einzige Alternative bietet sich SVG an, aber da der Benutzer dafür entweder ein installiertes Plug-in oder aber den Mozilla-Browser benötigt, ist auch SVG nicht gerade geeignet. Es bleibt also nur HTML übrig. Damit Sie dabei ebenfalls flexibel bleiben, sollte die optische Formatierung mit CSS erfolgen. Dann müssen Sie mit PHP nur die korrekten Elemente zur Ausgabe der Inhalte verwenden und nicht zusätzlich noch die Formatierung wie Schriftart und Farbe vornehmen. Die optische Formatierung der Elemente direkt im Quelltext der Scripts entspräche dem Zucker im Kraftstofftank eines Fahrzeugs.

Gerne hätte ich noch JavaScript und DHTML mit in dieses Projekt eingebunden. Aus zwei Gründen habe ich mich jedoch dagegen entschieden: Erstens werden dadurch die einzelnen Listings unglaublich lang, und zweitens können Sie dies später nach Ihrem eigenen Gusto umsetzen.

# Strukturierung

Sie sollten auf jeden Fall nicht vergessen, sich zu überlegen, wie die Verzeichnisstruktur des Projekts aufgebaut sein soll. Dies hängt ganz von Ihren eigenen Wünschen und Vorstellungen ab. Ich selbst verwende gerne folgende Struktur: Ich unterteile die einzelnen Bestandteile des Projekts thematisch. So sammle ich alle Grafiken, die auf der Webseite zum Einsatz kommen, in einem Unterverzeichnis namens images. Alle Templates, die ich verwende, inklusive der CSS-Dateien (solange ich die Formatierung nicht im Template selbst vornehme), lege ich im Verzeichnis templates ab. Dateien, die Konfigurationsvariablen enthalten oder gar Funktionen und Klassen, die in das Hauptscript eingebunden werden sollen, liegen in einem Verzeichnis namens inc (Abkürzung für include). Des Weiteren lege ich Dateien, die von einem Benutzer heruntergeladen werden können, in einem Verzeichnis namens downloads ab.

Diese Strukturierung führt dazu, dass im Hauptverzeichnis lediglich nur noch eine Datei zu finden ist: die index.php. Sie ist und soll nach Möglichkeit das einzige Script bleiben. Der Rest wird auf die beschriebenen Verzeichnisse verteilt.

Ein Vorteil ist, dass Sie die Dateien so nicht unter Umständen doppelt ablegen und dann beide verwenden. Wenn Sie später nur die eine Datei verändern, wundern Sie sich, warum die Änderung nicht umgesetzt wurde, und suchen lange nach dem Fehler. Außerdem können Sie den Zugriff auf die Verzeichnisse – zumindest beim Apache-Server – regeln, indem Sie die Eingabe eines Passworts verlangen. Mit Ihren Scripts können Sie jedoch ohne die Zugriffsbeschränkung auf die Dateien innerhalb der Verzeichnisse zugreifen. Dies ist gerade für die Konfigurationsdateien mit dem Datenbankpasswort ein zusätzlicher Schutz. Wenn nämlich ein Unbefugter den Benutzernamen und das Kennwort ermittelt, ist höchste Gefahr im Verzuge.

# Verzeichnisschutz

Der erwähnte Verzeichnisschutz mittels Kennwort bzw. Benutzernamen und Kennwort ist eine Apache-spezifische Funktion. Ich werde Ihnen erklären, wie das funktioniert.

Normalerweise wird der gesamte Zugriff auf die Server-Verzeichnisse durch den Apache-Server geregelt. Dazu werden in der httpd.conf die unterschiedlichsten Einstellungen vorgenommen. So z. B. auch, dass Dateien, die im cgi-bin-Verzeichnis abgelegt wurden, ausführbar sein sollen, oder Dateien, die auf .php enden, mit dem PHP-Interpreter zuerst ausgeführt und dann an den Browser gesendet werden sollen. Diese Konfiguration lässt sich aber mit weiteren Dateien in den entsprechenden Verzeichnissen erweitern bzw. überschreiben.

Die Voraussetzung, dass dies funktioniert, sind ein paar Einstellungen in der httpd.conf-Datei. Zunächst muss die Option zum Überschreiben der Konfiguration in der httpd.conf aktiviert werden. Notieren Sie hinter AllowOverride in der httpd.conf die Option AuthConfig. Denken Sie aber daran, dass die Änderung sowohl für <Directory /> als auch für <Directory "c:/apache/htdocs"> gesetzt wird. Die httpd.conf sollte nach der Änderung in etwa folgendermaßen aussehen:

...  
<Directory />  
    Options FollowSymLinks ExecCGI MultiViews  
    AllowOverride AuthConfig  
</Directory>  
...  
<Directory "D:/Apache2/htdocs">  
    Options Indexes FollowSymLinks ExecCGI MultiViews  
    AllowOverride AuthConfig  
</Directory>  
...

Des Weiteren sollte nach dem Eintrag AccessFileName der Dateiname .htaccess folgen. Mögliche Rautezeichen am Anfang der Zeile müssen entfernt werden. Außerdem sollte nach der Zeile noch die Eintragung folgen:

<Files \~ "^\\.ht">  
    Order allow,deny  
    Deny from all  
</Files>

Dies verhindert, dass alle Dateien, die mit .ht anfangen, weder in dem Verzeichnis dargestellt werden noch von jemandem HTML-Do­ku­mente zäh­len nicht dazu, denn der re­gu­läre Aus­druck ver­langt, dass die Datei mit **.ht** an­fan­gen muss und dass davor kein wei­te­res Zei­chen zu fin­den sein darf.abgerufen werden können.

Nun sollte in den zu schützenden Verzeichnissen eine Datei namens .htaccess angelegt werden, die über folgenden Inhalt verfügt:

AuthType Basic  
AuthName "Passwortgeschuetzter Bereich"  
AuthUserFile .../.htpasswd  
Require valid-user

Die Zeichenkette in Anführungsstrichen nach AuthName definiert den Fenstertitel, der bei der Eingabe von Benutzername und Passwort verwendet werden soll. Nach AuthUserName müssen Sie den vollständigen Pfad zu der Datei .htpasswd notieren. Diese Datei enthält dann die Benutzernamen und verschlüsselten Passwörter für die Authentifizierung. Ich erkläre Ihnen gleich noch, wie eine solche Datei erzeugt wird. Die letzte Zeile bedeutet, dass eine gültige Benutzerkennung mit Passwort eingegeben werden muss, damit der Zugriff auf das Verzeichnis von außen gewährt wird.

Die .htpasswd ist folgendermaßen aufgebaut:

Benutzername:VerschlüsseltesPasswort

Der Benutzername wird immer im Klartext notiert. Das Passwort ist jedoch mit crypt (die Funktion kennen Sie aus Perl und PHP) verschlüsselt worden. Um das verschlüsselte Passwort zu erhalten, wird der Benutzername als »Suppe« und das Passwort als »Salz« verwendet. Der Inhalt der Datei könnte dann folgendermaßen aussehen:

websites:$apr1$nr5.....$wR4CCAt6BUaDxDxrVCwQ//

Der Benutzername lautet websites, und das Passwort ist eine wirre Zeichenkette. Niemand kann aus dieser Zeichenkette das richtige Passwort ermitteln.

Weitere Informationen zu passwortgeschützten Verzeichnissen finden Sie in der Apache-Dokumentation unter http://httpd.apache.org/docs-2.0/howto/htaccess.html für den Apache 2.0 und für den Apache 1.x unter http://httpd.apache.org/docs/howto/auth.html.

Sobald nun jemand versucht, auf ein so geschütztes Verzeichnis zuzugreifen, wird er aufgefordert, einen Benutzernamen und ein Passwort einzugeben. Abbildung 1.1 zeigt, wie dies auf dem Rechner des Benutzers aussehen könnte, und Abbildung 1.2 zeigt, was passiert, wenn der Benutzer sich nicht korrekt authentifizieren konnte.

Anmeldeaufforderng für mit .htaccess geschützte Verzeichnisse
Abbildung 1.1: Anmeldeaufforderng für mit .htaccess geschützte Verzeichnisse

Meldung bei einer fehlgeschlagenen Authentifizierung
Abbildung 1.2: Meldung bei einer fehlgeschlagenen Authentifizierung

# Zusammenfassung

  • Das Projekt soll die Rubriken News, Downloads, Links und Artikel bieten.
  • Es sollen Templates eingesetzt werden, die mit HTML und CSS definiert werden.
  • JavaScript und DHTML werden nicht benutzt.
  • Zur Organisation der Inhalte wird eine Datenbank verwendet.
  • PHP dient als serverseitige Scriptsprache.
  • Alle Dateien des Projekts werden nach Themen geordnet und in entsprechenden Verzeichnissen abgelegt.
  • Die Verzeichnisse werden vor Unbefugten durch .htaccess geschützt.

← Die Datenbank →