====== Fehler ermitteln, aus welchem Grund mod-rewrite nicht läuft ======

===== Ist das mod_rewrite Modul auf dem Server geladen? =====

Um mod_rewrite überhaupt verwenden zu können, müsssen wir zunächst sicherstellen, dass das Modul auf dem Server überhaupt läuft. Dazu rufen wir folgende Datei auf

<code>
www.deinedomain.de/backend/phpinfo.php
</code>

Unter dem Bereich apache sollte dann im Eintrag Loaded Modules das Modul mod_rewrite aufgelistet sein. Ist dies nicht vorhanden, hilft nur noch der Kontakt zum Provider.

===== Funktionstest des mod_rewrite Moduls =====

Um die grundsätzliche Funktionalität des Moduls zu testen, starten wir mit einer einfachen .htaccess-Datei, die wir in das Projektverzeichnis legen. Dort ist schon standardmäßig nach der Sefrgeno-Installation eine Datei htaccess.txt vorhanden, die später für das korrekte Umschreiben der urls sorgt. Für den Funktionstest verwenden wir jedoch im Folgenden eine .htaccess-Datei, die nur folgende Anweisungen enthält:

<code>
RewriteEngine On
RewriteRule ^  http://www.google.de [R,L]
</code>

Diese Einstellung sorgt dafür, dass jede Anfrage, die an unsere Domain geschickt wird, zu google.de weitergeleitet wird. Funktioniert diese Weiterleitung problemlos, so wird auch der mod_rewrite von Sefrengo in aller Regel problemlos laufen.

===== Es kommt zwar keine Fehlermeldung, aber die Weiterleitung funktioniert auch nicht =====

==== Ursache ====

Die Ursache hierfür ist, dass die Direktive **AllowOverride** in der httpd.conf (der Serverkonfigurationsdatei) für deinen <Directory>-Abschnitt auf //none// steht oder nicht erlaubt ist, //FileInfo// zu überschreiben. In AllowOverride wird quasi angegeben, was in .htaccess-Dateien alles genutzt werden kann (bzw. welche Einstellungen aus der httpd.conf überschrieben werden können). Für den Gebrauch von mod_rewrite muss jedoch //FileInfo// überschrieben werden dürfen.

==== Lösung ====

In diesem Fall hilft es nur, den Provider zu kontaktieren und ihn zu bitten, die Serverkonfiguration entsprechend zu ändern. Die Minimalkonfiguration für unser htdocs-Verzeichnis sieht folgendermaßen aus:

<code>
AllowOverride FileInfo
</code>

**Achtung:** Wichtig dabei ist das Setzen von AllowOverride im richtigen <Directory>-Container. Davon gibt es in der httpd.conf mehere. Für uns relevant ist derjenige, der unseren DocumentRoot enthält, also bspw. <Directory /www/htdocs/web999/>, wobei web999 hier unser Account- bzw. Username auf dem Server ist.

===== Fehler 403 Forbidden beim Aufruf =====

==== Ursache ====

In der **error_log**-Datei des Apache-Servers steht dazu folgendes:

<code>
[error] [client ...] Options FollowSymLinks or SymLinksIfOwnerMatch is off
which implies that RewriteRule directive is forbidden: /www/htdocs/web999/
</code>

Die Datei **error_log** findet man meistens in einem Verzeichnis namens **log** auf dem Server, das auf der gleichen Ebene liegt wie das html-Verzeichnis. Auch Sefrengo legt zwei Verzeichnisse //logs// in den Ordnern //backend// und //cms// an. //Diese sind hier nicht gemeint!//

Das Nutzen von mod_rewrite in .htaccess-Dateien ist uns zwar erlaubt (vgl. Punkt 3, also //AllowOverride// ist korrekt gesetzt), jedoch ist bei der Direktive **Options** die Option **FollowSymLinks** oder **SymLinksIfOwnerMatch** abgeschaltet.

FollowSymLinks bedeutet, dass der Server symbolischen Links folgt. SymLinksIfOwnerMatch bedeutet, dass der Server nur symbolischen Links folgt, wo die Benuzerkennung von dem Link mit der Benutzerkennung des Zielverzeichnis / -datei übereinstimmt. Letzteres sollte wenn möglich vermieden werden (Performance).

==== Lösung ====

Wir erweitern unsere .htaccess-Datei folgendermaßen

<code>
Options +FollowSymlinks
RewriteEngine On
RewriteRule ^  http://www.google.de [R,L]
</code>

Das funktioniert allerdings nur dann, wenn wir in der .htaccess die Direktive //Options// überschreiben dürfen. (vgl. das Problem mit AllowOverride unter 3). Wenn das Überschreiben von Options in .htaccess-Dateien nicht freigegeben ist, kommt beim Webseitenaufruf ein **500 Internal Server Error.**

===== 500 Internal Server Error beim Aufruf =====

==== Ursache ====

Erhalten wir diesen Fehler, so dürfen wir die Directive Options nicht überschreiben und können auch nicht die benötigten Optionen einfügen. In der error_log-Datei steht dazu:

<code>
[alert] [client ...] /www/htdocs/web999/.htaccess: Options not allowed here
</code>

==== Lösung ====

Ohne Zugriff auf die **httpd.conf** kann man hier nichts machen. Auch hier müssten wir wieder den Provider kontaktieren und ihn bitten, die Options **FollowSymlinks** oder **SymLinksIfOwnerMatch** in der Server-Config für unser Directory freizuschalten.

Dazu muss in dem <Directory>-Abschnitt für unsere htdocs, also bspw. <Directory /www/htdocs/web999/>

<code>
Options +FollowSymlinks
</code>

einfügt bzw. die vorhandene Options Direktive ergänzt werden.


==== Ursache ====

Manche WebHoster benötigen die Angabe der RewriteBase Direktive, da diese nicht in der Webserverkonfiguration angegeben wurde.

==== Lösung ====

In der //.htaccess// Datei muss folgendes hinzugefügt werden:

<code>
RewriteBase /
</code>

Wenn Sefrengo in einem Unterverzeichnis installiert ist, muss evtl. noch der Pfad angepasst werden.


===== Zusammenfassung =====

Haben wir eine Version der o.g. .htaccess-Datei korrekt zum Laufen gebracht, so sind die ersten beiden Zeilen der standardmäßig von Sefrengo mitgelieferten htaccess.txt entprechend anzupassen. Danach löschen wir unsere o.g. Test-Version der .htaccess-Datei und benennen die mitgelieferte Version von //htaccess.txt// in //.htaccess// um.

Gutes Gelingen!
===== Quellen =====
  * [[http://www.modrewrite.de/foren/ftopic82.html|http://www.modrewrite.de/foren/ftopic82.html]]

<note autor>
  * Smail
</note>