Diskussion:Htaccess - Versionsgeschichte

Tril: /* Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung */

2012-01-29T09:50:55Z

‎Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung

Mpns: Parsen und Aufnehmen einer Bestands-Datei

2012-01-28T22:31:33Z

Parsen und Aufnehmen einer Bestands-Datei

Tril: /* Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung */

2012-01-25T17:32:45Z

‎Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung

Mpns: /* Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung */

2012-01-24T17:14:16Z

‎Vorsicht beim Einsatz von diesem Modul ohne entsprechende Erfahrung

Mpns: Fehlende Import-Möglichkeit

2012-01-24T17:13:19Z

Fehlende Import-Möglichkeit

Neue Seite

==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...

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

Muster- .htaccess (wie schiefgelaufen):
<pre>
# 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]
</pre>

Gruß
-[[Benutzer:Mpns|Mpns]]

← Nächstältere Version		Version vom 29. Januar 2012, 09:50 Uhr
Zeile 39:		Zeile 39:

	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 ...		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 ...
		+
	-[[Benutzer:Mpns\|Mpns]] 23:31, 28. Jan. 2012 (CET)		-[[Benutzer:Mpns\|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.
		+
		+	[[Benutzer:Tril\|Tril]] 10:50, 29. Jan. 2012 (CET)

← Nächstältere Version		Version vom 28. Januar 2012, 22:31 Uhr
Zeile 37:		Zeile 37:

	[[Benutzer:Tril\|Tril]] 18:32, 25. Jan. 2012 (CET)		[[Benutzer:Tril\|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 ...
		+	-[[Benutzer:Mpns\|Mpns]] 23:31, 28. Jan. 2012 (CET)

← Nächstältere Version		Version vom 25. Januar 2012, 17:32 Uhr
Zeile 32:		Zeile 32:
	Gruß		Gruß
	-[[Benutzer:Mpns\|Mpns]]		-[[Benutzer:Mpns\|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.
		+
		+	[[Benutzer:Tril\|Tril]] 18:32, 25. Jan. 2012 (CET)

@@ Zeile 4: / Zeile 4: @@
 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...
+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....