Anlässlich des Geburtstages habe ich die Forensoftware upgedatet und das Design erneuert. Außerdem gibt es eine Artikelserie über die ersten Jahre:

• 10 Jahre Downhill Rangers – Wie alles begann
  
• 10 Jahre Downhill Rangers – Die ersten Jahre
• 10 Jahre Downhill Rangers – Die schrägen Highlights
• 10 Jahre Downhill Rangers – Schwere Zeiten
• 10 Jahre Downhill Rangers – Ausblicke

Das Web, wie das World Wide Web häufig kurz genannt wird, ist ein Dienst des Internets, der das HTTP-Protokoll zum Datenaustausch verwendet. Andere Dienste des Internets, die auf anderen Protokollen basieren, sind z.B. E-Mail oder FTP (File Transfer Procol). Da das Web der bekannteste Dienst ist, wurde und wird es häufig mit dem Internet selbst verwechselt oder synonym verwendet.

In den Anfangszeiten des Webs setzte es sich durch, dass Webserver den Hostnamen www erhielten, was zur Folge hatte, dass Webadressen (auch URLs genannt) immer mit www oder genaugenommen mit http://www. angefangen haben. Immer mehr Menschen lernten, dass dieses www etwas mit dem Internet zu tun hat. Diese Webadressen konnte man in einen Webbrowser eingeben und gelangte zur gewünschten Webseite.

Diese Zeit ist aber mittlerweilen einige Jahre her. Heute werden von vielen Menschen auch die Top-Level-Domains .com, .de, .at, .org, .net etc. als Kennzeichen für eine Internet-Adresse erkannt. Marketing-Experten zeigen uns vor, dass das www altbacken wirkt. Viel cooler ist doch ein Domainname ohne www. Als Beispiel kann ich hier auch unsere Seite anführen: Auf den ersten T-Shirts und Aufklebern für unsere Webseite stand noch www.dh-rangers.com. “dh” hatten wir damals gewählt, weil die Url möglichst kurz sein sollte. Aber auf T-Shirts machte sich das www gar nicht gut, und mit “dh” konnten nur Insider etwas anfangen. Wir reservierten also downhill-rangers.com und druckten das auf Aufkleber und T-Shirts. Zumindest unserem Zielpublikum (15 – 40 Jahre) sollte durch das .com klar sein, dass es sich um eine Webadresse handelt. www.downhill-rangers.com wirkt unserer Meinung nach deutlich weniger. Auf T-Shirts oder Aufkleber wären die einzelnen Buchstaben auch kleiner und daher schlechter lesbar.

Verschiedene Domainnamen für eine Webseite

Technisch ist es kein Problem, dass eine Webseite sowohl über www.domain.com als auch über domain.com erreichbar ist. Insofern hätten wir also kein Problem und jeder könnte auf eine Webseite zugreifen wie er will. So einfach ist es aber leider nicht.

Das Hauptproblem ist Google und auch andere Suchmaschinen. Für Google sind www.domain.com und domain.com zwei verschiedene Webseiten. Das hat mehrere unangenehme Folgen: Erstens mag es Google nicht besonders, wenn gleiche Inhalte unter verschiedenen URLs abrufbar sind. Und genau das ist hier der Fall. Es kann sogar passieren, dass Google die Relevanz der Seite oder für Google beider Seiten aufgrund des doppelten Inhalts heruntersetzt. Die Seiten erscheinen im Suchergebnis weiter hinten. [Die Information dieses Absatzes ist mittlerweilen überholt: Google bestraft "dublicate Content" nicht aktiv ab, solange dadurch nicht aktiv Suchmaschinenergebnisse manipuliert werden sollen. Siehe: Die "Dublcate Content-Penalty" - entmystifiziert!]

Wenn es zwei URLs für eine Webseite gibt, werden andere Seiten auch auf diese beiden URLs verlinken. Die Gesamtanzahl der eingehenden Links teilt sich daher auf zwei URLs auf. Die Anzahl der eingehenden Links einer Webseite ist ebenalls ein wichtiges Kriterium für Google die Relevanz einer Webseite zu bestimmen. Zwei verschieden URLs können als wieder zu einer Abwertung innerhalb des Suchergebnisses führen.

Aber nicht nur wegen Google sind zwei verschiedene URLs problematisch. Viele Seiten verwenden Cookies um User-Daten (Einstellungen, Login-Informationen, etc.) zu speichern. Cookies werden aber pro Domain und pro Subdomain gespeichert. (Das www wird hier als Subdomain gesehen). Genaugenommen ist es so, dass Cookies der übergeordneten Domain auch für die untergeordneten Subdomain gilt. Ein Cookie, dass für domain.com geschrieben wurde, kann auch auf www.domain.com gelesen werden. Aber nicht umgekehrt. Von www.domain.com aus kann ein Cookie für www.domain.com und domain.com geschrieben werden.

Wenn eine Seite also über beide URLs zugreifbar ist, kann es zu Verwirrungen von Usern führen, die eventuell unwissentlich einmal mit und einmal ohne www auf eine Seite zugreifen und sich somit eventuell zweimal ein- oder ausloggen müssen.

Zusammenfassend ist es also gar nicht gut, wenn eine Webseite sowohl über www, als auch ohne www zugreifbar ist. Das gleiche gilt übrigens auch für zusätzliche Domainnamen, die auf dieselbe Seite verweisen. Teilweise kann auf eine Webseite auch über die zugehörige IP-Adresse zugegriffen werden.

Umgekehrt kann aber nicht einfach die alternativen URLs deaktivieren. Also z.B. einen Fehler ausgeben lassen. Viele Leute geben automatisch ein www an, auch wenn keines in der URL steht. Andere wiederrum lasse es einfach mal weg, weil’s ja eh meist auch ohne geht. Und es soll sogar Seiten geben, deren URL ohne www beworben werden, aber nur mit www aufgerufen werden können!

Um den oben genannten Problemen aus dem Weg zu gehen, muss sichergestellt werden, dass immer nur eine Form  des Domainnamens (mit oder ohne www) für eine Webseite verwendet wird. Greift ein Seitenbesucher aber über eine andere Form zu, muss er zur einzig gültigen URL weitergeleitet werden. Wie das funktioniert werde ich weiter unten erklären.

Vorher muss aber geklärt werden:

Mit oder ohne www?

Ja, das ist die große Frage. Im Web gibt es dazu einige Kontroversen. Es gibt eigene Seiten pro www aber auch kontra www. Und manchen gefällt das www so sehr, dass sie sogar für zwei www, also www.www. plädieren.

Mit www

• Erkennung für URLs: Mit www verbinden viele Menschen Web-Adressen.
• Historische Gründe: Webadressen haben in der Vergangenheit meist mit www begonnen.
• Automatische URL-Erkennung: Web-Adressen mit www können automatisch in klickbare Links umgewandelt werden. Z.B. in E-Mails oder in Web-Applikationen wie Web-Foren.
• Länge: Soll eine URL ohne www eindeutig als URL erkannt werden, muss http:// vorangestellt werden. Das ist länger als das www (www.domain.com statt http://domain.com).

Ohne www

• Länge: Durch das Weglassen wird die URL kürzer.
• Moderner: Eine Webadresse ohne www wirkt moderner. Vorallem im Offline-Bereich.
• www umständlich zu sprechen: Vorallem im Englischen ist das www unmöglich auszusprechen: Double-U-Double-U-Double-U. Deshalb wird es aber durch Dub-Dub-Dub abgekürzt oder auch beim Sprechen komplett weggelassen.

Ich persönlich wünsche mir die Url ohne www. Es schaut besser aus, wirkt moderner und ist kürzer. Allerdings hat das Fehlen des www für mich einen entscheidenen Nachteil: Wird die Url ohne www geschrieben, wird sie in vielen Programmen nicht automatisch in klickbare URLs umgesetzt. Solange man selber die Links setzt, ist das kein Problem. Man kann ein http:// oder bei entsprechender Weiterleitung (sieh unten) notfalls auch www vor die URL setzen. Das Problem ist aber, wenn andere z.B. in einem Forum einen Link setzen. Ist dieser domain.com, wird er nicht zu einem klickbaren Link. Wäre ein www davorgestanden, hätte die Software diesen eventuell in einen klickbaren Link umgesetzt, den Google erkennt und unter Umständen positiv für die Relevanz der eigenen Seite wertet. Dagegenhalten kann man sicher, dass Urls sowieso häufig aus der Browserleiste kopiert werden, und somit das http:// dabei ist. Oder dass User das www automatisch schreiben, auch wenn es in der Adressleiste der eigenen Seite nicht steht. Auch zählen solche Links in Foren-Beiträgen, die möglicherweise neben vielen anderen ähnlichen Links sind, häufig nicht besonders für die Relevanz einer Seite in Google.

Weiterleitung

Wenn wir uns entschieden haben, ob die gültige URL der Seite mit oder ohne www beginnen soll, dann können wir die Seite so konfigurieren, dass Zugriffe auf die Seite über irgendeine andere URL immer auf die einzig gültige Form weitergeleitet werden.

Die Weiterleitung nennt sich Englisch Redirect. Dieser wird am besten so ausgeführt, dass man beim Zugriff auf eine ungültige Form der URL dem Browser den Redirect mit dem HTTP-Code 301 und der gültigen Form der URL zurücksendet. HTTP-Code 301 steht für einen “Redirect” mit “permanently moved”, also permanent verschoben.

Im einfachsten Fall konfiguriert man das im Webserver. Hat man einen Apache Webserver und Zugriff auf die .htaccess-Datei im Hauptverzeichnis der Webseite kann man dies mit ein paar Zeilen einrichten:

Umleitung mit .htaccess auf die Version ohne www

RewriteEngine On
RewriteCond %{HTTP_HOST} !^domain.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

Umleitung mit .htaccess auf die Version mit www

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.domain.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

In der Zeile mit RewriteCond wird überprüft ob der HTTP_HOST, als der Hostname ungleich (!) domain.com oder www.domain.com ist. Das [NC] bedeutet, dass die Groß-/Kleinschreibung unberücksichtigt bleibt. Im ersten Teil von RewriteRule wird mit ^(.*)$ alles erfasst, das sich hinter dem Hostnamen der URL befindet. Also Pfade, Dateinamen und Parameter. Der zweite Teil ist die neue URL, wobei das $1 für den Teil steht, der mit ^(.*)$ erfasst wurde. Das R=301 steht für den Redirect Code und L dafür, dass dies die letzte Regel für diesen Fall ist.

Umleitung mit PHP auf die Version ohne www

if($_SERVER["HTTP_HOST"] != "domain.com")
{
    if(empty($_SERVER["REQUEST_URI"])) $_SERVER["REQUEST_URI"] = '/';
    header('Location: http://domain.com' . $_SERVER["REQUEST_URI"], true, 301);
    exit();
}

Umleitung mit PHP auf die Version mit www

if($_SERVER["HTTP_HOST"] != 'www.domain.com')
{
    if(empty($_SERVER["REQUEST_URI"])) $_SERVER["REQUEST_URI"] = '/';
    header('Location: http://www.domain.com' . $_SERVER["REQUEST_URI"], true, 301);
    exit();
}

Auch hier wird überprüft, ob der Hostname ungleich domain.com bzw. www.domain.com ist. Wenn ja, wird umgeleitet. Die dritte Zeile ist nicht unbedingt notwendig. Es wird hier nur ein eventuell fehlendes ‘/’ am Ende der Url angefügt, was sonst sowieso der Webserver machen würde. In der vierten Zeile wird auf die URL ohne www weitergeleitet, wobei wieder der Pfad, der Dateiname und die Parameter (REQUEST_URI) angefügt werden. Außerdem wird der HTTP-Code wieder auf 301 gesetzt.

Austesten können Sie das hier: downhill-rangers.com, www.downhill-rangers.com, downhill-racing.com/werbung.php, downhillrangers.com/kontakt.php. Alle Urls führen zu jeweiligen Seite mit http://downhill-rangers.com/.

Umleitung und Cookies

Waren auf einer Webseite bisher beide Varianten – mit www als auch ohn www – gültig und möchte Sie das nun auf eine Variante einschränken, so müssen Sie im Zusammenhang mit Cookies noch eines bedenken: Werden Cookies verwendet um Daten längerfristig (also zwischen Sessions) gespeichert,  so könnten diese bei manchen Usern unter domain.com und bei anderen unter  www.domain.com gespeichert sein. Beliebt ist zum Beispiel das Auto-Login. Führt man jetzt eine Weiterleitung ein, so gehen die Cookies, die für die andere URL gespeichert wurden, verloren. Bei einer Autologin-Funktion werden User nicht mehr automatisch eingeloggt. Dies sollte man bedenken, wenn man ein Forum mit etlichen 1000 User umstellt, und sich plötzlich 100 nicht mehr anmelden können, weil sie Ihr Passwort verloren haben, und natürlich auch die hinterlegte E-Mail-Adresse für das neue Passwort nicht mehr gültig ist …

Andere Artikel zum Thema

mit oder ohne www: Verschiedene Möglichkeiten für ein Redirect
mod_rewrite – Mit oder ohne “www”: Erklärung des mod_rewrite Syntax
Dublicate Content: mit oder ohne “www”: Betrachtung aus SEO-Sicht (SEO: Search Engine Optimization).
domain mit oder ohne www: Google Group Diskussion zum Thema

Englisch:
SEO advice: url canonicalization: Tipps vom Google-Experten Matt Cutts.
With or without www, that is the question… Warum beide Varianten funktionieren müssen.
URLs With or Without “WWW”: Which is Best?: Warum Konsistenz wichtig ist.
Make sure your website works with or without www: Warum beide Varianten funktioneren müssen.

Wichtig war natürlich, dass es sich in mein vBulletin Diskussionsform einbinden lässt. Nicht optisch, aber die User sollten gekoppelt sein. Es sollte verschiedene Kategorien geben, in denen User Fotos uploaden können. Allerdings gefiel mir da weder das Layout von Coppermine noch von Gallery 2. Von Gallery 2 las ich dann, dass es extrem objektorientiert und programmtechnisch sauber programmiert ist, aber deswegen eher langsam und vorallem zum Hacken (Ändern) schwer zu durchblicken ist. Soweit ich mich erinnern kann schied auch Coppermine aus, weil ich zuviel ändern hätte müssen, damit es für mich gepasst hätte. Allerdings habe ich mir Coppermine am wenigsten genau angesehen.

Downhill-Rangers Foto-Galerie mit Photpost

Daher schaute ich mich auch bei den kommerziellen Anbietern um. Und so kam ich auf Photopost. Photopost bietet die vBulletin-Einbindung schon Out-Of-The Box mit. Außerdem können damit z.B. auch die Kommentar-Eingabefelder über vBulletin laufen. Beim Analysieren vom Code von Photopost hat man zwar manchmal den Eindruck, als hätte der Entwickler das Programmieren erst während der Entwicklung von Photopost gelernt, aber die meisten Dinge kann man relativ schnell finden und so auch sehr schnell was reinhacken. Und der Code wird durch’s Reinhacken sicher nicht schlechter

Rausgekommen ist dabei die Downhill-Rangers Foto-Galerie. Ich habe absichtlich die Möglichkeit für eigene Alben entfernt, weil ich nicht wollte, dass massenweise Fotos vom selben Thema raufgeladen werden. Besser einzeln einige gute Fotos raufladen. Außerdem hat Photopost damals sowieso keine sinnvollen Möglichkeiten geboten, viele Fotos in einem Schwung raufzuladen.

Foto-Alben mit Gallery 2

Hin und wieder wäre es aber sinnvoll, doch genau diese Foto-Alben anzubieten, wenn man beispielsweise von einem Event viele Fotos hat und diese öffentlich oder einem beschränktem Besucherkreis zeigen möchte. Wichtig ist dabei allerdings, dass die Bilder schnell und einfach raufgeladen werden können. Und das ist die Stärke von Gallery 2. Es unterstützt unter anderem HTTP-Upload (Browser), eine Java-Applet, WebDAV, XP-Web-Publishing, und Gallery Remot. Gallery Remote ist eine eigene Java-Anwendung für den Desktop, die sich mit der Gallery-Installation im Web verbindet und mit der man schnell und komfortabel Fotos raufladen kann. Vor dem Raufladen könne Fotos gedreht, beschriftet, und skaliert werden.

Ich habe alle Upload-Methoden getestet. Ich habe sie auch alle zum Laufen gebracht. Es ist aber nich unbedingt immer so einfach – vorallem für Laien. Aber wenn es mal konfiguriert ist, geht’s damit umso schneller und bequemer.

Gallery 2 und vBulletin

Gallery 2 bietet mit der Embed-Klasse eine Möglichkeit an, externe Anwendungen einzubinden. Diese Idee ist prinzipiell sehr gut. Außerdem noch weitere Mechanismen, um Gallery innerhalb einer anderen Seite anzeigen zu lassen.

Umgekehrt bietet vBulletin Produkte und Plugins. An bestimmten Stellen im vBulletin-Code sind sogenannte Hooks. Ein Produkt oder Plugin kann sich in so einen Hook einklinken und Code dafür hinterlegen. vBulletin führt dann an diesen Stellen diesen Code aus. Somit können viele vBulletin-Erweiterungen ohne Code-Änderungen an vBulletin selbst auskommen und einfach exportiert, als kompakter Download als Produkt oder Plugin angeboten und in andere vBulletin-Installationen importiert werden.

Es gibt auch eine Gallery 2.1 and vBulletin 3.5.X Integration. Primär geht’s hier allerdings um die optische Intergration, die ich nicht benötige. Als Anhang dort ist noch ein Plugin angehängt, wie die User zwischen vBulletin und Gallery 2 gekoppelt werden können. Genau genommen geht’s dabei um ein Plugin, das beim Ändern von User ausgeführt wird. Genau dann wird diese Änderung an die Embed-Klasse von Gallery 2 weitergeleitet. Und zwar an die Methoden der Embed-Klasse, die User anlegen, ändern oder löschen.

Dabei gibt’s allerdings mehrer Probleme, die eine Einsatz ohne Modifikationen nicht möglich machen:

1. Es werden nur User von vBulletin zu Gallery 2 übertragen, die sich im Forum einloggen. Gibt es das vBulletin Forum schon länger und möchte man alle User übertragen, muss man ein eigenes Programm schreiben, dass diese macht
2. Aufpassen mit den Zeichensätzen der Datenbanken: Meine vBulletin-Datenbank verwendet ISO-8859-1. Gallery 2 wird standardmäßig mit UTF-8 installiert.
3. Gallery 2 erlaubt zwar die Einstellung, welche Hashingmethode für das Passwort verwendet wird. Allerdings verwendet vBulletin einen eigenen Salt-Wert zum Hashen. Gallery 2 unterstützt das nicht. User können sich also in Gallery 2 nach dem Übertragen der Daten von vBulletin zu Gallery 2 nicht einloggen.
4. Das Plugin im oben erwähnten Artikel ist fehlerhaft. Eventuell liegt es daran, dass der Artikel für Gallery 2.1 ist und ich bereits Gallery 2.2 verwende. Der Aufruf der Methode der Embed-Klasse ist schlichtweg falsch.

ad 1) Um alle User zu übertragen, hab eich einfach ein Script geschrieben, dass alle vBulletin User ausliest und jeweils die Methoden der Embed-Klasse ausführt, die den User in Gallery 2 anlegen oder updaten.

ad 2) Die unterschiedlichen Zeichensätze können mit der PHP-Funktion iconv() angepasst werden. Ob es funktioniert, kann z.B. mit Umlauten getestet werden.

Ein Problem habe ich allerdings noch. Gallery 2 erkennt beim Import mit meiner Zeichensatz-Konfiguration User, die sich nur anhand eines Umlauts unterscheiden nicht als unterschiedliche User (”Andi”, “Ändi”). Aber das war im ersten Schritt mal vernachlässigbar.

ad 3) Damit sich die User mit demselbem Passwort in Gallery 2 wie im vBulletin einloggen können, musste ich die User-Tabelle von Gallery 2 um die Spalte für den Salt-Wert erweitern und diese auch über die Embed-Funktion bis zur Datenbankabfrage durchschleusen. Hier stellte sich das als wahr heraus, was ich wie oben beschrieben schon zuvor gelesen hatte. Änderungen in Gallery 2 sind extrem aufwändig. Gallery 2 ist im vielen Schichten geteilt. Sich da durchzuarbeiten und die notwendigen Änderungen zu finden, ist wirklich mühsam und hat mich extrem viel Zeit gekostet. (Änderungen im eher diletantisch programmierten Photopost sind dagegen Kindegarten.) Natürlich musste dann auch die Passwort-Abfrage abgeändert werden, sodass diese auch den neuen Salt-Wert verwendet. Achtung: Auch das Einloggen sollte dann mit Passwörter mit Sonderzeichen, wie Umlauten getestet werden.

ad 4) Wenn man sich die Embed-Funktionien ansieht, sieht man schnell, wie der Aufruft erfolgen muss, und was somit im vBulletin-Plugin geändert werden muss.

Die kurzfristig installierte Gallerie sieht man hier: Downhill-Rangers Foto-Alben.