Agenturen aus der Hölle – Teil n+1: Der Cache

Mal wieder ein Burner aus der Reihe „Agenturen aus der Hölle“.

Eine Tragödie in vier Akten.

  1. Ein Kunde von uns (wir sind eine Art Provider) wird von einer Agentur über den Tisch gez… äh.. wohlwollend und gutmeinend beraten ein anderes CMS zu nehmen, als das welches wir vorinstalliert und kostenfrei bereitstellen.
  2. Die Agentur holt sich den Auftrag. Denn eines können sie gut: Überzeugen. Und sie tun dann Dinge.
  3. Nun erhielten wir eine E-Mail mit der Forderung, wir mögen doch bitte den Cache ausschalten. Wenn man die Seite aktualisiert und dann im Browser neu läd, sähe man die Änderungen nicht sofort…Hintergrund: Wir cachen da nicht, haben auch keinen Zwangsproxy für unsere Kunden. Der Loadbalancer, der die Seiten von den Apaches ausliefert, speichert ebenfalls nicht zwischen.
  4. Der Webadmin schaut sich also das Webroot des Webauftritts an. Und findet das, was zu erwarten war:
    Das CMS, das von der Agentur empfohlen, selbst installiert und gewartet wird, hat ein Verzeichnis Namens „cache“, in der sich bereits mehrere Dutzend nicht bereinigte Unterverzeichnisse mit alten Inhaltskopien befinden.

 

Flattr this!

WordPress als Multisite-CMS: Basisinstallation

Eine kurze Übersicht, was zu tun und zu beachten ist, wenn man WordPress als Multisite-CMS einsetzen möchte. (Zum Stand von WordPress 3.3).

 

1. Basisinstallation von WordPress

Zuerst gilt es natürlich, die aktuelle Basisversion von WordPress zu laden und die notwendigen Schritte zur Installation durchgehen; Darunter auch Datenbank einrichten etc.
Das Dokument beschreibt dies: http://codex.wordpress.org/Installing_WordPress

Zu beachten ist, dass man sich schon an dieser Stelle einen sinnvollen generischen Domainnamen für die Basisinstallationen wählen sollte, falls dieser dann später gegenüber den Autoren, Redakteueren oder anderen sichtbar werden sollte.

Beispiel:

cms.example.de   oder noch besser gleich auf  example.de . Die Subdomains bekommen dann:  name.example.de

2. Installation Sprachdatei

Möchte man die deutsche Oberfläche nutzen, ist die Installation der deutschen Sprachdatei und deren Aktivierung notwendig. Die dazugehörigen Schritte werden unter folgender Adresse beschrieben: http://doku.wpde.org/Installation_der_deutschen_Sprachdatei .

Möchte man gleich schon in Schritt 1  ein deutsches Bundle installieren, kann man dies auch tun. Auf der deutschen Projektwebsite findet sich im Downloadbereich ein entsprechendes Bundle zum Download  http://wpde.org/download/

3. Multisite akivieren

Als nächtes wird die Multisite-Funktion aktiviert. Das Vorgehen ist hier beschrieben: http://codex.wordpress.org/Create_A_Network .
Ergänzende Informationen dazu finden sich auch im Blog von Frank Bültge:

Obwohl man sich an alles gehalten hat, was die Anleitung vorgibt, kann es zu der Meldung kommen, dass ein Datenbankfehler vorliegt.  In diesem Fall hilft es, dies zusätzlich zu den anderen Anweisungen in der wp-config.php einzufügen:

(Siehe dazu auch: http://wordpress.org/support/topic/installing-multisite-yields-error-establishing-database-connection-error)

4. WordPress Mu Domain Mapping installieren und aktivieren.

Da wir in Schritt 3 bereits die Netzwerkinstallation aktiviert haben, müssen wir nun für die Installation neuer Plugins in den Netzwerkbereich wechseln. Dort rufen wir die Funktion „Plugins“ – „Installieren“ auf und geben in die Suchmaske  „WordPress Mu Domain Mapping“ ein.  Das gefundene Plugin wird über die Oberfläche installiert.

Als nächstes sind folgende Schritte vorzunehmen:

  •   Kopieren von
    wp-content/plugins/wordpress-mu-domain-mapping/sunrise.php
    nach
    wp-content/sunrise.php
  •   in wp-config.php ergänzen:
    define( 'SUNRISE', 'on' );

5. Apache-Konfiguration

Im Apache ist die Konfig so anzupassen, dass der Domainname und Aliase auch zu der Blog-Site gehen. Bei einer Apache-Installation mit mehreren weiteren virtuellen Hosts, verwendet man einen Wildcard bei den Serveralliasen:

<VirtualHost *:80>
Servername cms.example.de
ServerAlias *.cms.example.de
..
</VirtualHost>

 

Wenn man keine anderen virtuellen Hosts betreibt, reicht der normale erste VHost-Eintrag des Apaches, der als Default auf die Bloginstallation verweist. Dies funktioniert aber dann nur für die Domains die dann auch wirklich mit einen Namen *.cms.example.de aufgerufen werden.

Wenn eine Domain aber mit Hilfe des Domainmappings einen anderen Namen zugewiesen bekam (z.B. blafasel.example.de oder eine ganz andere 2nd Level Domain www.meineigenertest.blub) muss dieser Name explizit als weiterer Serveralias eingetragen werden:

<VirtualHost *:80>
Servername cms.example.de
ServerAlias *.cms.example.de blafasel.example.de www.meineigenertest.blub meineigenertest.blub
..
</VirtualHost>

Wenn dann www.meineigenertest.blub aufgerufen wird, wird der VHost-Eintrag dafür sorgen, dass das WordPress CMS aufgerufen wird. In der Domain Mapping wird nachgeschaut, welcher Blog (mit einer angegebenen ID) dieser Domain zugeordnet ist. Zusätzlich steht da noch der Eintrag, ob die Domain ein Primary-Eintrag ist oder nicht.

Der Primary-Eintrag dient dabei zur Umleitung auf den jeweiligen Domainnamen, für den Fall dass einer der anderen möglichen Namen aufgerufen wurde.

Beispiel:

Die Blogsite test.cms.example.de wurde eingerichtet. Es erhielt die Id 2.
Nach der Erstellung werden unter Einstellungen -> Domains folgende Einstellungen hinzugefügt:

  • Site ID: 2, Domain: meineigenertest.blub, Primary: Yes
  • Site ID: 2, Domain: www.meineigenertest.blub, Primary: No

Wenn nun per Browser auf www.meineigenertest.blub     zugegriffen wird, wird zunächst auf meineigenertest.blub umgeleitet. Danach wird dann auf der URL meineigenertest.blub die Blogsite mit der Id 2 angezeigt.

 

Damit ist die Basisinstallation von WordPress als Multisite CMS erledigt. Danach kommen die jeweiligen Plugins und Themes. Bei trafficstarken Sites werden zusätzlich noch Plugins und Serverkomponenten installiert, die sich um die Performance kümmern.

Dies ist jedoch Gegenstand anderer Artikel.

 Weitere hilfreiche Informationen zum Betrieb von WordPress als CMS finden sich in folgenden Artikeln:

 

Flattr this!

Konzepte zur Datenhaltung für Webseiten in einem Web-Content-Management-System

Web-Content-Management-Systeme (WCMS) dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst viele administrative Aufgaben abzunehmen. Hierzu gehört auch, daß das WCMS den Content, sprich den textuellen Inhalt einer Seite, in einer bestimmten, vordefinierten Art und Weise speichert.
Man unterscheidet hierbei mehrere unterschiedliche Konzepte, sowie ihre Mischformen. Populär sind dabei besonders die Konzepte des Publishing-/Staging-Server und des dynamischen Publishing.

1. Publishing-/Staging-Server

Beim Konzept des Publishing-/Staging-Servers benutzt man zwei verschiedene Bereiche zur Ablage und Bearbeitung der Seiten. Der Publishing-Server enthält das eigentliche WCMS und beantwortet die Anfragen der Autoren, Redakteure und Administratoren. Dieser Server befindet sich meist im Intranet und ist für die Öffentlichkeit nicht erreichbar. Alle Texte die von Autoren erstellt und bearbeitet wurden, werden auf diesem Server gespeichert.

Sollen die Inhalte veröffentlicht werden, wird durch das WCMS ein Prozeß gestartet, welches aus allen vorhandenen Texten HTML-Dateien erstellt. Diese HTML-Dateien werden dann auf dem Staging-Server gelegt und so für die Öffentlichkeit abrufbar gemacht.

Die folgende Abbildung verdeutlicht dieses Konzept: Autoren, Redakteure und Administratoren greifen zur Bearbeitung der Texte auf den Publishing-Server zu. Dies geschieht in der Abbildung je nach Wahl durch ein server- oder clientseitiges Interface. (Gegebenenfalls muß ein Webserver die Requests zwischen Autoren und Publishing-Server entgegennehmen und weiterleiten.) Schema Publisching/Staging-Server

Auf dem Publishing-Server werden alle Texte verwaltet und bearbeitet. Bei gewünschter Veröffentlichung werden dann daraus die HTML-Dateien erstellt und auf den Staging-Server geschoben.

Die HTML-Dateien auf dem Staging-Server sind dabei statisch (sieht man von eingebundenen Webtechniken, wie JavaScript, Flash oder ähnlichem ab).
Die Bearbeitung von Texten kann nur auf dem Publishing-Server erfolgen. Wird eine HTML-Datei auf dem Staging-Server geändert, wird diese bei der nächsten Veröffentlichung durch den Publishing-Server überschrieben. Zwar bringt dies ein organisatorisches Problem mit sich, jedoch bietet dieses Vorgehen den Vorteil der Redundanz: Fällt der Staging-Server aus, kann trotzdem noch auf dem Publishing-Server gearbeitet werden, bzw. fällt der Publishing-Server aus, können immer noch die Webseiten vom Staging-Server gelesen werden.

Die Vor- und Nachteile für die Verwendung von statischen Seiten über den Staging-Server lassen sich wie folgt zusammenfassen:

+ Gute Performance
+ Unkompliziertes Backup
+ Statische Seiten werden von Suchmaschinen erfasst
Nicht geeignet für häufige Aktualisierungen
-/+ Seitenrecherche für Benutzer durch eigene, aber ggf. spezialisierte, Suchmaschine nötig.
Layoutänderungen für mehrere Dateien aufwendig

Eingesetzt wird dieses Konzept zum Beispiel in dem VIP Content Manager von Gauss Interprise oder von SchemaText.

2. Dynamisches Publishing

Beim dynamischen Publishing werden angeforderte Seiten direkt aus der Datenbank publiziert. Die Abbildung schematisiert dieses Konzept: Beim Aufruf einer Webseite über den Webbrowser des Benutzers gibt der Webserver den Request weiter an das WCMS, welches die Seiteninhalte aus einer Datenbank anfordert, diese mit dem Layout verknüpft und dann die HTML-Ausgabe an den Webserver und damit den Benutzer zurückgibt. Schema Dynamisches Publishing

Die verwendete Datenbank des WCMS‘ kann in diesem Verfahren auch die eines anderen Herstellers, wie Oracle, Informix oder sogar mySQL sein.
Da die eigentlichen HTML-Seiten erst bei der Anfrage durch einen Benutzer erstellt werden, spricht man hier von dynamischen Seiten. Man erkennt diese leicht daran, daß die URL zu diesen Seiten nicht fest ist, sondern meist eine kryptische Gestalt besitzt und Parameter betreffend des Aufrufes enthält. Ein Verzeichnis mit statischen HTML-Dateien existiert nicht mehr.

Die Vor- und Nachteile des dynamischen Publishing sind:

+ Leichte Aktualisierungen
+ Einfache Verwaltung der Seiten
+ Flexible Nutzung der Datenbanken von Drittherstellern
+ Seitenrecherche eingebaut
Für ausreichend Performance sind hohe Rechner-Ressourcen nötig
Nachteile bei der Erfassung durch Suchmaschinen: Viele Suchmaschinen erfassen keine dynamischen Seiten, so daß diese bei einer Suche nicht gefunden werden.

Dieses Konzept wird unter anderem von SIXCMS verwendet. Der Einsatz kann dabei zum Beispiel auf der Site des Internet-Magazins „Internet World“ betrachtet werden.

3. Mischformen

Eine Erweiterung des dynamischen Publishing stellt das Caching dar. Hier wird dem Fakt, das einige Seiten stärker frequentiert werden als andere, Rechnung getragen. Um lange Ladezeiten für die jeweilige Neuerstellung von Seiten aus der Datenbank zu vermeiden, werden solche Seiten, die häufig angefordert werden entweder statisch an festen Positionen abgelegt, oder aber in ihrer fertigen Form als HTML-Seite in einen Cache-Bereich gespeichert. Der Cache ist dabei entweder ein Speicherbereich auf dem Webserver oder aber ein temporärer Bereich auf der Festplatte des Servers.

Die Frage, welche Seiten gecached werden, kann automatisch über die Anzahl der Zugriffe, als auch über die Administration durch Redakteure beantwortet werden.
Um Aktualität zu garantieren muß der Cache automatisch aktualisiert werden, wenn im WCMS sich Inhalte der betreffenden Seiten geändert haben.
Aufgrund seiner Struktur ist das Caching eine Mischung der Konzepte des dynamischen Publishing und des Publishing-/Staging-Servers.

4. PSE-Konzept

Ein weiteres Konzept, welches im Januar durch die Diplomarbeit des Autors erstmals vorgestellt wurde, ist das Publishing-, Staging- und Extract-Konzept, kurz PSE-Konzept.
Das Konzept baut auf dem des Publishing-/Staging-Servers auf und erstellt auf dem Webserver statische Webseiten. Neu ist jedoch die Art der Speicherung und die Verarbeitung und Verwaltung neuer Seiten.

DIe Abbildung schematisiert das Konzept. In dem Konzept sind die HTML- und Objektdateien, welche von WCMS bearbeitet wurden, für den Webserver voll les- und schreibbar. Dies bedeutet nichts anders, als daß das WCMS die vollständige Kontrolle über alle Inhalte aufgibt und es erlaubt, das andere Applikationen darauf Zugriff nehmen dürfen. Einzige Prämisse dabei ist, daß die Dateien statisch auf dem Webserver liegen.
Für den Benutzer, der eine Seite abruft, verhält es sich daher wie ein normales statisches System. Schema PSE-Konzept

Ebenso verhält es sich, wenn ein Redakteur eine neue Seite publiziert: Aus den Inhalten und dem vorgegebenen Layout wird unmittelbar eine HTML-Datei erstellt und auf dem Webserver gespeichert. Die Inhalte der Datei werden, sofern es sich nicht um eingebundene Mediendateien handelt (Bilder, Grafiken,..), ebenfalls in dieser HTML-Datei gespeichert. Einzige Ausnahme: Meta-Angaben wie „Titel“, „Description“, „Keywords“, „Autor“, „Version“, usw. werden in eine Meta-Datenbank geschrieben.
Soll nun eine HTML-Datei verändert werden, wird das WCMS sie vom Webserver laden. Danach wird das Layout, mit dessen Hilfe die Datei erstellt wurde, genutzt um alle Layout-Angaben in der HTML-Datei zu löschen. Es handelt sich also um die Inversion des Prozesses der Seitenerstellung aus der Addition von Inhalt und Layout: Die HTML-Seite, abzüglich dem HTML-Layout ergibt den Inhalt.
Nach diesem Schritt bleiben nur noch die Inhalte übrig und können somit direkt geändert werden.
Die Meta-Datenbank ist nötig um Daten, die nicht in der HTML-Datei gespeichert werden, zu sichern. Darunter auch Angaben zum verwendeten Layout, Kontroll- und Zugriffsdaten. Die in der Abbildung zusätzlich angegebenen Layouts können ebenfalls als HTML-Dateien abgespeichert und somit verwaltet und geändert werden. Basiert das Konzept auf serverseitige Interfaces ist es möglich eine Selbstadministration zu erreichen, indem alle Layout- und Kontrollausgaben zur Verwaltung durch Redakteure und Autoren ebenfalls Teil der änderbaren Seiten sind.

Vor- und Nachteile dieses Konzeptes:

+ Gute Performance
+ Unkomplizierte Backups
+ Einfache Aktualisierungen
+ Erlaubt die gleichzeitige Verwendung anderer WCM-Lösungen, die nach dem Pushing-/Staging-Konzept arbeiten
+ Erlaubt Autoren mittels eigener Editoren direkt in HTML-Dateien zu arbeiten
+ Import bestehender Seiten einfach
Benötigt Abbildung des File-Systems innerhalb der Meta-Datenbank
Wenig Praxiserfahrungen, da neu
-/+ Seitenrecherche für Benutzer durch eigene, aber ggf. spezialisierte, Suchmaschine nötig.
Layoutänderungen für mehrere Dateien aufwendig

Das Konzept wurde im OpenSource-WCMS Altjira implementiert, welches auf Sourceforge gefunden werden kann.

Anmerkung

Dieser Artikel ist ein überarbeiteter Auszug aus der Diplomarbeit „Konzeption und Realisierung eines Web-Content-Management-Systems“ von Wolfgang Wiese. Diese Arbeit kann über die Diplomarbeitenbörse Diplom.de käuflich erworben werden.

Flattr this!