.htaccess: AddType in Unterverzeichnis überschreiben
Ron Wernecke
- webserver
0 Maja0 Maja0 Ron Wernecke
0 Calocybe
Hallo Alle!
Ich möchte meinen Server mittels .htaccess so einstellen, dass .htm-Dateien als PHP-Dateien ausgewertet werden. Soweit klappt das auch, nur habe ich ein Problem, wenn das ganze nur in einem Unterverzeichnis geschehen soll. Das ist notwendig, da ich die neue Seite erst einmal in einem Unterverzeichnis aufbaue, bis sie fertig ist. Ich vermute, dass es an der .htaccess im Hauptverzeichnis liegt.
In meiner .htaccess im Test-Verzeichnis habe ich folgenden Eintrag:
AddType x-mapp-php4 .htm
Im Hauptverzeichnis in der .htaccess:
AddType text/html .htm
AddHandler server-parsed .htm
Damit wird mir eine .htm-Datei im Testverzeichnis nur zum Download angeboten. Wenn ich jetzt das ganze ändere auf .html, also Dateiname und die Zeile in der .htaccess, dann wird die Seite korrekt als PHP-Datei ausgewertet.
Entsteht das Problem aus der doppelten AddType-Anweisung? Wenn ja, kann ich das irgendwie umgehen bzw. für das eine Verzeichnis die erste AddType-Anweisung aufheben?
Bin für jeden Tipp dankbar!
Viele Grüße,
Ron Wernecke
Hi Ron!
Eigentlich sollte im entsprechenden Unterverzeichnis eine .htaccess mit dem Eitrag
AddType application/x-httpd-php .html
bzw. .htm reichen.
Die Angaben
AddType text/html .htm
AddHandler server-parsed .htm
sorgen nur dafür, dass auch *.htm-Dateien als SSI (eigentlich *.shtml) behandelt werden analog folgender Einstellung in der httpd.conf:
AddType text/html .shtml
AddHandler server-parsed .shtml
Gerade lese ich (http://www.php-center.de/faq/faq-webserver.html), dass bei 1&1 und Resellern die Angabe AddType x-mapp-php4 .php .html nötig ist, wenn PHP als Modulversion istalliert ist und (unabhängig von 1&1) in der CGI-Version
AddType application/x-httpd-php3 .php3 .html
Action application/x-httpd-php3 /cgi-bin/php
angegeben werden muss. Dann wären Deine Angaben oben aber richtig. Bist Du bei 1&1? Wenn nicht versuche mal AddType application/x-httpd-php .html
Gruß Maja
Nachtrag:
Scheinbar kommen sich die Anweisungen für SSI und PHP in die Quere (habe gerade mal getestet). Solltest Du die SSI-Angaben nicht benötigen, dann einfach diese .htaccess löschen, dann sollte es gehen.
Scheinbar kommen sich die Anweisungen für SSI und PHP in die Quere (habe gerade mal getestet). Solltest Du die SSI-Angaben nicht benötigen, dann einfach diese .htaccess löschen, dann sollte es gehen.
Ja, die benötige ich leider für die aktuelle Version. Ich baue die Seite gerade komplett neu, und das mache ich eben in einem Unterverzeichnis. Wenn die Seite fertig ist kann der Eintrag weg, aber bis dahin hab ich wohl ein Problem...
Viele Grüße,
Ron Wernecke
Ja, die benötige ich leider für die aktuelle Version. Ich baue die Seite gerade komplett neu, und das mache ich eben in einem Unterverzeichnis. Wenn die Seite fertig ist kann der Eintrag weg, aber bis dahin hab ich wohl ein Problem...
Wenn Du die Seiten sowieso neu gestaltest, was spricht dann gegen *.php und *.shtml?
Wenn Du die Seiten sowieso neu gestaltest, was spricht dann gegen *.php und *.shtml?
Die Seite ist relativ gut in Suchmaschinen vertreten (täglich mindestens 400 Besucher über Suchmaschinen), außerdem sind viele Unterseiten direkt von anderen Seiten verlinkt. Deshalb möchte ich die ganzen Links nicht ins Leere laufen lassen oder umlenken. Ist ja rein theoretisch auch kein Problem, wenn nicht das Testen und Programmieren im laufenden Betrieb wäre...
Viele Grüße,
Ron Wernecke
Wenn Du die Seiten sowieso neu gestaltest, was spricht dann gegen *.php und *.shtml?
Die Seite ist relativ gut in Suchmaschinen vertreten (täglich mindestens 400 Besucher über Suchmaschinen), außerdem sind viele Unterseiten direkt von anderen Seiten verlinkt. Deshalb möchte ich die ganzen Links nicht ins Leere laufen lassen oder umlenken. Ist ja rein theoretisch auch kein Problem, wenn nicht das Testen und Programmieren im laufenden Betrieb wäre...
URL-Rewriting ist dein Freund (sofern das mit deinem Webspace geht). Es gibt zum Glück ein Beispiel für dein Problem im Guide zu mod_rewrite:
---schnipp---
Backward Compatibility for YYYY to XXXX migration
Description:
How can we make URLs backward compatible (still existing virtually) after migrating document.YYYY to document.XXXX, e.g. after translating a bunch of .html files to .phtml?
Solution:
We just rewrite the name to its basename and test for existence of the new extension. If it exists, we take that name, else we rewrite the URL to its original state.
# backward compatibility ruleset for
# rewriting document.html to document.phtml
# when and only when document.phtml exists
# but no longer document.html
RewriteEngine on
RewriteBase /~quux/
# parse out basename, but remember the fact
RewriteRule ^(.*).html$ $1 [C,E=WasHTML:yes]
# rewrite to document.phtml if exists
RewriteCond %{REQUEST_FILENAME}.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# else reverse the previous basename cutout
RewriteCond %{ENV:WasHTML} ^yes$
RewriteRule ^(.*)$ $1.html
---schnapp---
Weitere englische Infos dazu: http://httpd.apache.org/docs/misc/rewriteguide.html. Doku zu mod_rewrite: http://httpd.apache.org/docs/mod/mod_rewrite.html
Warnung am Anfang: "Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo." ;)
- Sven Rautenberg
URL-Rewriting ist dein Freund (sofern das mit deinem Webspace geht).
Hallo Sven,
danke für den Tipp, das klappt. Dann kann ich also jetzt komplett auf .php umsteigen, innerhalb der seite auch mit .php verlinken, und .htm funktioniert weiter. Dann "verdoppelt" sich ja sozusagen die Seitenzahl, freuen sich die Suchmaschinen... Bleibt nur abzuwarten, ob die .htm-Dateien dann irgendwann aus den Suchergebnissen verschwinden oder nicht. Ich schätze mal, dass ein Spider nix von dem Rewriting mitbekommt, oder?
Viele Grüße,
Ron Wernecke
Moin nochmal!
danke für den Tipp, das klappt. Dann kann ich also jetzt komplett auf .php umsteigen, innerhalb der seite auch mit .php verlinken, und .htm funktioniert weiter. Dann "verdoppelt" sich ja sozusagen die Seitenzahl, freuen sich die Suchmaschinen... Bleibt nur abzuwarten, ob die .htm-Dateien dann irgendwann aus den Suchergebnissen verschwinden oder nicht. Ich schätze mal, dass ein Spider nix von dem Rewriting mitbekommt, oder?
Du kannst in der letzten Zeile den Parameter "R" setzen:
RewriteRule ^(.*)$ $1.html [R]
Das führt einen Redirect aus (also der komplette Zirkus mit "302 Moved temporarily" etc.). Das bekommt der Browser mit, fordert dann die richtige, neue PHP-Datei an. Dadurch sollte dann auch die URL-Anzeige angepaßt werden. Ebenfalls kriegen es die Suchmaschinen mit, und ändern dann irgendwann mal ihren Index - hoffentlich alles ohne große Schmerzen. :)
- Sven Rautenberg
Du kannst in der letzten Zeile den Parameter "R" setzen:
Hallo Sven,
danke für die Tipps, Du hast mir das Wochenende gerettet. :-)
Viele Grüße,
Ron Wernecke
Eine Möglichkeit wäre noch - wenn Du auf SSI im root verzichten kannst - die .htaccess-SSI-Anweisungen in alle Unterverzeichnisse (der ersten Ebene) zu kopieren und nur im Testverzeichnis die Anweisung für PHP.
Hallo Maja,
danke für die Antwort.
angegeben werden muss. Dann wären Deine Angaben oben aber richtig. Bist Du bei 1&1? Wenn nicht versuche mal AddType application/x-httpd-php .html
Nicht bei Puretec, aber bei Schlund&Partner. Das ist ja technisch das gleiche. Für eine andere Datei-Endung funktioniert es ja auch einwandfrei, nur eben nicht bei der Endung, die ich im Hauptverzeichnis schon 'bearbeitet' habe...
Viele Grüße,
Ron Wernecke
Hi!
Entsteht das Problem aus der doppelten AddType-Anweisung? Wenn ja, kann ich das irgendwie umgehen bzw. für das eine Verzeichnis die erste AddType-Anweisung aufheben?
Du kannst eine AddType-Anweisung rueckgaengig machen mit RemoveType:
http://httpd.apache.org/docs/mod/mod_mime.html#removetype
So long