Diskussion:Htaccess: Unterschied zwischen den Versionen

Aktuelle Version vom 29. Januar 2012, 10:50 Uhr

Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung

Mir aktuell heute passiert: Diverse Rewrite-Regeln (z.B. php) werden auf dem Server meines Massenhosters benötigt, welche durch einfachen Import der Contao-Grundeinstellungen sofort überschrieben wurden.

Somit lief der Contao-Core nur noch mit php4 - mit dem entsprechenden, erschreckenden Ergebnis... Drum' sichere, bevor Du testest (hatte ich in diesem Fall Gott sei Dank beherzigt...).

An dieser Stelle fehlt die Möglichkeit, zuerst einmal bestehende Einstellungen in das Modul importieren zu können....

Muster- .htaccess (wie schiefgelaufen):

# Enable mod_rewrite
RewriteEngine On
RewriteBase /
AddType x-mapp-php5 .php

# Block any URI protocol in the query string
RewriteCond %{QUERY_STRING} (ftp|https?):|/etc/ [NC]
RewriteRule .* - [F,L]

# Block any URI protocol in the request
RewriteCond %{REQUEST_URI} (ftp|https?):|/etc/ [NC]
RewriteRule .* - [F,L]

# Rewrite TYPOlight URLs
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .*\.html$ index.php [L]

Gruß -Mpns

Also das Parsen der alten Datei ist nahezu unmöglich Fehlerfrei zu bewältigen. Wie wäre es mit einer Vorschaltseite nach der Erstinstallation, der auf die Probleme hinweist, ein Backup der vorhandenen Datei macht usw.

Tril 18:32, 25. Jan. 2012 (CET)

Auch, wenn ich so gut wie keine Ahnung von PHP und den Möglichkeiten habe: Eine Bestehende Datei zu parsen und bei Auftreten diverser Schlüsselworte (z.B. PHP-Versions Rewrite-Regel) diese Regeln entsprechend aufzunehmen (z.B. in den Block eigener Regeln) sollte aber doch möglich sein. Denn dieser Kardinalfehler hat dann ja auch zur Folge, das auch das Backend nicht mehr nutzbar ist ... Alternativ wäre ja auch Java für diese Funktion denkbar ...

-Mpns 23:31, 28. Jan. 2012 (CET)

Das Problem ist nicht, dass man grundsätzlich in der Lage ist die .htaccess zu parsen, aber wie willst du die "automatischen Regeln" von den "benutzerdefinierten Regeln" unterscheiden? Dafür hat sich die .htaccess über die Versionen auch viel zu sehr verändert, mal abgesehen davon dass man auch gänzlich eigene .htaccess Dateien schreiben kann. Ich müsste am Ende sowieso den Benutzer fragen was er importieren möchte oder nicht, weil es nicht sicher automatisiert möglich ist.

Und wieso sollte Java eine Lösung sein? Ein Applet lässt sich auch nicht mehr vom Backend laden, geschweige denn eine Java2EE Application, wenn die .htaccess den Apache in einen Internal Server Error "zwingt". Dann geht außer FTP gar nichts mehr! Und selbst wenn man das Applet via FTP Kommunizieren lässt und vorher geladen hat, so merkt man den "Fehler" meistens erst dann, wenn man einen neuen Link anklickt -> Applet weg und nicht wieder aufrufbar wegen 500er Fehler. Wie man es dreht und wendet, ob man jetzt per FTP die .htaccess bearbeitet oder mit diesem Editor, ist die Datei Fehlerhaft und der Apache läuft in einen 500er Fehler, muss man auf Low-Level Lösungen zurück greifen weil nichts anderes mehr geht!

Eine Möglichkeit wäre allerdings, Hoster spezifische Optionen einzubauen, die eventuell auch automatisch vorgeschlagen werden. Z.B. um bei Strato oder AllInkl jeweils PHP5 zu aktivieren.

Tril 10:50, 29. Jan. 2012 (CET)