htaccess - mod_rewrite Konzept

[Benjamin Keil]

Hallo,

ich habe Probleme mit einem neuen Projekt (www.oldschool.de).
Die einzelnen Seiten werden alle dynamisch (php) generiert,
beispiele:

a) http://www.oldschool.de/index.php?page=about_links
Inhalt wird geladen aus: /content/about_links.inc

b) http://www.oldschool.de/index.php?page=skate/history/
Inhalt wird geladen aus: /content/skate/history/index.inc

Das Prinzip ist, endet der Get-Wert mit einem '/',
dann hänge ein 'index.inc' dran, ansonsten nur ein '.inc'.

Der Pfad aus dem die Inhalte geladen werden ist 'content/'.

Nachdem die ersten Suchmaschinen die Seite aufgenommen haben, habe ich  festgestellt, dass dynamische Seiten mit Get-Parametern nicht
indiziert werden und natürlich schon in Erfahrung gebracht, dass
ich das Problem mit mod_rewrite in einer htaccess umgehen kann.

Die neuen Verweise würden dann so aussehen:

a) http://www.oldschool.de/page/about_links

b) http://www.oldschool.de/page/skate/history/

Bevor ich hier an mod_rewrite gehe und mich in einigen Wochen wieder
über die Suchmaschinen ärger, meine Frage:

Wenn ich das so umsetze, muss ich dann damit rechnen, dass
die Suchmaschinen in Beispiel a einen abschließenden Slash '/'
dranhängen und mir damit den Parameter zerstören würden?

Falls ja, gibt es eine elegante Lösung dieses Problem zu umgehen?

Versaut mod_rewrite eigentlich die Pfadangaben? Ich meine,
aus allen Dateien verweise ich z.B. bei Bildern zu images/bild.* ,
müsste ich dann bei Beispiel b) auf ../../../../images/bild.*
verweisen? Das wäre sehr ungünstig...

Wie die ModRule aussehen müsste frage ich lieber nicht, ich weiß
dafür gibt's ein tutorial...

Schöne Grüße,
Ben

[Sven Rautenberg]

Moin!

Nachdem die ersten Suchmaschinen die Seite aufgenommen haben, habe ich  festgestellt, dass dynamische Seiten mit Get-Parametern nicht
indiziert werden und natürlich schon in Erfahrung gebracht, dass
ich das Problem mit mod_rewrite in einer htaccess umgehen kann.

Diese Indizierungs-Aussage würde ich zwar so direkt nicht treffen wollen (bei Google gibt es genug Fundseiten, die das Gegenteil beweisen), aber nichtsdestotrotz ist der Ansatz, vernünftige, ausgeschriebene URLs zu benutzen, die keine Parameter haben, natürlich viel besser.

Die neuen Verweise würden dann so aussehen:

a) http://www.oldschool.de/page/about_links

b) http://www.oldschool.de/page/skate/history/

Tu dir selbst einen Gefallen und nimm vernünftige URLs.
/about_links.html
/skate/history/index.html

Warum /page/ da reinfriemeln? Ist überflüssig und bringt der URL nichts, macht sie nur unnötig lang. Es sei denn, du hast einen strukturbedingten, guten Grund, "Seiten" in ein Verzeichnis "page" zu pflanzen.

Andererseits sind die .html-Geschichten ihrerseits nicht verkehrt. Da ist mehr "Macht der Gewohnheit" dabei, aber Seiten haben nun mal typischerweise eine Endung, weil Dateien aus Unterscheidungsgründen bei den meisten Betriebssystemen auch eine haben.

Wenn ich das so umsetze, muss ich dann damit rechnen, dass
die Suchmaschinen in Beispiel a einen abschließenden Slash '/'
dranhängen und mir damit den Parameter zerstören würden?

Nein. Das kann dein Webserver schon ganz alleine. Ist alles eine Frage, wie er reagiert (jetzt aktuell), wenn du eine existierende URL ohne Endslash aufrufst, und der Webserver einmal eine Datei gleichen Namens, und einmal ein Verzeichnis entdeckt.

Falls ja, gibt es eine elegante Lösung dieses Problem zu umgehen?

Ich setze mod_rewrite für solche Aktionen, wie du sie vorhast, sehr gerne und erfolgreich ein. Ich hatte bislang noch keinerlei Probleme mit meiner Vorgehensweise.

Versaut mod_rewrite eigentlich die Pfadangaben? Ich meine,
aus allen Dateien verweise ich z.B. bei Bildern zu images/bild.* ,
müsste ich dann bei Beispiel b) auf ../../../../images/bild.*
verweisen? Das wäre sehr ungünstig...

Ja, die Pfadangaben werden "versaut". Das ist aber nicht Schuld von mod_rewrite, sondern vom Browser. Bzw. deiner URL-Gestaltung.

Mit deinen Parametern hast du immer dieselbe Seite abgerufen: /index.php. Relativ zu dieser Seite befinden sich natürlich dann immer die gleichen Bilder, bzw. egal welche Seite du aufrufst, eine relative Adressierung auf ein vorhandenes Bild ist immer gleich.

Aus diesem Grunde gibt es die segensreiche Erfindung der absoluten Adressierung. Die funktioniert dann zwar nicht mehr auf der heimischen Festplatte, sondern nur noch mit Server - aber das ist mit PHP ja nicht anders. Anstatt als unterschiedliche Kaskaden von "../../../../images/bild.jpg" je nach Verzeichnistiefe deiner URL einzubauen, setzt du den Bildsrc direkt auf "/images/bild.jpg". Und fertig.

Da du deine Links auf allen Seiten ja auch auf die neue URL-Schematik umändern mußt (da sind Parameter natürlich verboten, weil genau deshalb die Suchmaschine ja erst drauf kommen, Parameter bei dir zu verwenden, bzw. einfach den existierenden Links folgen), ist das also nur eine kleine Zusatzaufgabe. Kann man mit dateiübergreifendem Suchen/Ersetzen sehr schnell hinbekommen.

Wie die ModRule aussehen müsste frage ich lieber nicht, ich weiß
dafür gibt's ein tutorial...

...und tolle Einträge im Archiv, die mir alle viel zu kompliziert erscheinen.

Klar, man _kann_ das Auseinandernehmen und Umsetzen der Eingangs-URL in eine Ausgangsurl mit tollen Parametern auch im Rewriting-Modul machen.

Muß man aber nicht.

Meine Variante ist relativ puristisch, verlangt aber etwas Mitarbeit vom angeschlossenen PHP:

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -s
  RewriteRule ^/.+.html$ /backoffice/page.php

Das leitet _alle_ Requests, die auf ".html" enden, auf das Seitenauslieferungsskript um. Die RewriteCond prüft, ob im Verzeichnisbaum eine entsprechende Datei tatsächlich existiert.

Der Sinn dahinter ist: Die URL-Struktur ist, wie oben angedeutet:
/index.html
/andere_seite.html
/verzeichnis/index.html
/verzeichnis/seite.html

Exakt diese Dateien existieren auf dem Server auch. Allerdings sind das keine vollwertigen, statischen HTML-Seiten, sondern eben die Fragmente, die du ja auch zu einer fertigen Seite zusammensetzen willst. Heißen nur halt nicht ".inc", sondern ".html".

Das Seitenauslieferungsskript hat dann die Aufgabe, die angeforderte URL auseinanderzunehmen und einfach die richtigen Fragmente zusammenzusetzen. Die angeforderte URL steht (das macht mod_rewrite, wenn es eingeschaltet ist) in $_SERVER['SCRIPT_URL'] drin. Diese Variable kannst du jetzt natürlich entweder auseinandernehmen, oder auch direkt einsetzen. Es empfiehlt sich vielleicht, zu prüfen, ob die URL gewissen strengeren Anforderungen genügt.

Aber man muß sich an dieser Stelle keinerlei Sorgen mehr machen, dass irgendwelche Dateien außerhalb des DOCUMENT_ROOT oder nichtexistierende Dateien aus Versehen eingebunden werden. Diese Prüfung erledigt mod_rewrite schon. Wenn es eine Datei nicht gibt, reagiert der Webserver, ganz ohne PHP anschmeißen zu müssen, mit einem 404 (den man natürlich mit eigener Fehlermeldung versehen kann). Und Zugriffe außerhalb des DOCUMENT_ROOT sind auch keine möglich, auch nicht mit "/../../.."-Zugriffsversuchen.

Ich hoffe, mein Prinzip ist dir klargeworden. :) Würde mich freuen, wenn es Sinn macht und übernommen würde.

- Sven Rautenberg

[Benjamin Keil]

Hallo Sven,

Diese Indizierungs-Aussage würde ich zwar so direkt nicht treffen wollen (bei Google gibt es genug Fundseiten, die das Gegenteil beweisen), aber nichtsdestotrotz ist der Ansatz, vernünftige, ausgeschriebene URLs zu benutzen, die keine Parameter haben, natürlich viel besser.

Ich habe es heute noch irgendwo bei google gelesen, finde den Link aber nicht, teilweise werden wohl solche Seiten indiziert,
teilweise aber auch nicht, aus Perfomancegründen, keine Ahnung
wie die da eine Auswahl treffen.

Tu dir selbst einen Gefallen und nimm vernünftige URLs.
/about_links.html
/skate/history/index.html

Mit dem .html habe ich ein Problem, unter .html verstehe
ich vollwertige HTML-Seiten (mit doctype & co), daher
habe ich den dateinamen .inc gewählt - das funktioniert
dann in der URL natürlich nicht.

Warum /page/ da reinfriemeln? Ist überflüssig und bringt der URL nichts, macht sie nur unnötig lang. Es sei denn, du hast einen strukturbedingten, guten Grund, "Seiten" in ein Verzeichnis "page" zu pflanzen.

Wieder so ein Konflikt, der URL schadet's, aber meine
Ornderstruktur wird dadurch übersichtlicher, naja, das
ist ja erstmal nebensächlich.

Wenn ich das so umsetze, muss ich dann damit rechnen, dass
die Suchmaschinen in Beispiel a einen abschließenden Slash '/'
dranhängen und mir damit den Parameter zerstören würden?

Nein. Das kann dein Webserver schon ganz alleine. Ist alles eine Frage, wie er reagiert (jetzt aktuell), wenn du eine existierende URL ohne Endslash aufrufst, und der Webserver einmal eine Datei gleichen Namens, und einmal ein Verzeichnis entdeckt.

Der Fall wird nicht eintreten, da ich keine gleichnamige Datei
unterhalb eines Verzeichnisses einbinden werde, ist ja auch unlogisch: wenn ich eine Datei page/shop/index.inc habe, dann ist
die Datei page/shop.inc ja überflüssig. Mit den Suchmaschinen bist Du Dir sicher?

Aus diesem Grunde gibt es die segensreiche Erfindung der absoluten Adressierung. Die funktioniert dann zwar nicht mehr auf der heimischen Festplatte, sondern nur noch mit Server - aber das ist mit PHP ja nicht anders. Anstatt als unterschiedliche Kaskaden von "../../../../images/bild.jpg" je nach Verzeichnistiefe deiner URL einzubauen, setzt du den Bildsrc direkt auf "/images/bild.jpg". Und fertig.

Logisch! Danke! Brauche ja nur vor jedes images/ und *.css einen Slash setzen. Das mit der heimischen Festplatte ist kein Problem,
die liegt auf nem kleinen Debian-Server ;-) Obwohl,
werden die Pfade innerhalb der css von allen Browsern
von dieser ausgehend gewertet? Bin gerade etwas verwirrt.

Da du deine Links auf allen Seiten ja auch auf die neue URL-Schematik umändern mußt (da sind Parameter natürlich verboten, weil genau deshalb die Suchmaschine ja erst drauf kommen, Parameter bei dir zu verwenden, bzw. einfach den existierenden Links folgen), ist das also nur eine kleine Zusatzaufgabe. Kann man mit dateiübergreifendem Suchen/Ersetzen sehr schnell hinbekommen.

Das wäre das kleinste Übel, das kann man ja nach und nach machen,
wichtig ist ersteinmal die Navigation, damit die wichtigsten Seiten
indiziert werden. Habe schon an eine robots.txt gedacht,
da bin ich mir aber auch nicht sicher ob die Suchmaschinen
dann die Parameter in der URL akzeptieren würden.

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -s
  RewriteRule ^/.+.html$ /backoffice/page.php

Das könnte ich ja dann auch auf mein page/ Verzeichniss beschränken,
dann besteht nur noch mein Gewissenskonflikt mit den html-Dateien,
die keine vollwertigen html-Dateien sind.

Das leitet _alle_ Requests, die auf ".html" enden, auf das Seitenauslieferungsskript um. Die RewriteCond prüft, ob im Verzeichnisbaum eine entsprechende Datei tatsächlich existiert.

Die Condition brauche ich ja dann auch eigentlich nicht, oder (?),
denn wenn eine Seite nicht existiert, dann zeige ich doch
lieber die Startseite an, oder das nächste existierende
Unterverzeichniss, als ein 404 auszugeben, auch wenn
ein 404 ja auch auf die Startseite verweisen kann.

Ich hoffe, mein Prinzip ist dir klargeworden. :) Würde mich freuen, wenn es Sinn macht und übernommen würde.

Hat etwas gedauert, aber ich glaube es ist klar. Vielen Dank
für Deine Mühen!!! Ein paar Kritiken hatte ich ja noch,
es geht ja nicht nur um ein einziges Projekt, sondern um
eine logische und einfache Grundstruktur für alle
kommenden kleinen oder riesengroßen Projekte.

Wie sieht es eigentlich in Deinen Statistiken aus,
werden dann die eingetippten URL's aufgelistet,
oder Dein Script?

Ben

[Sven Rautenberg]

Moin!

Tu dir selbst einen Gefallen und nimm vernünftige URLs.
/about_links.html
/skate/history/index.html

Mit dem .html habe ich ein Problem, unter .html verstehe
ich vollwertige HTML-Seiten (mit doctype & co), daher
habe ich den dateinamen .inc gewählt - das funktioniert
dann in der URL natürlich nicht.

Das Problem ist aber ja nur höchst ansichts- und gefühlshalber. Also kein echter Grund.

Ich habe als HTML-Dateien zwar welche mit echtem DOCTYPE etc., aber das sind Templates, die vom Skript noch ausgefüllt werden müssen. Außerdem kann man sich in einzelnen Verzeichnissen beliebige Freiheitsgrade mit mod_rewrite konfigurieren. Beispielsweise die gesamte Produktpalette eines Shops über eine Gruppe vernünftiger URLs auf das Anzeigeskript mappen, welches dann lediglich _eine_ Templatevorlage lädt und z.B. die Artikelnummer aus der URL entnimmt - wohlgemerkt nicht aus irgendeinem Parameter, der "artnr" oder so heißt.

Warum /page/ da reinfriemeln? Ist überflüssig und bringt der URL nichts, macht sie nur unnötig lang. Es sei denn, du hast einen strukturbedingten, guten Grund, "Seiten" in ein Verzeichnis "page" zu pflanzen.

Wieder so ein Konflikt, der URL schadet's, aber meine
Ornderstruktur wird dadurch übersichtlicher, naja, das
ist ja erstmal nebensächlich.

Deiner _jetzigen_ Struktur schadet es vielleicht. Wenn du sämtliche Anzeigeskripte in ein entsprechendes Verzeichnis packst, hast du im Hauptverzeichnis viel Platz für den Content.

Es ist im Prinzip egal, ob du nun alles in "/pages/" drinstehen hast, oder in "/".

Der Fall wird nicht eintreten, da ich keine gleichnamige Datei
unterhalb eines Verzeichnisses einbinden werde, ist ja auch unlogisch: wenn ich eine Datei page/shop/index.inc habe, dann ist
die Datei page/shop.inc ja überflüssig. Mit den Suchmaschinen bist Du Dir sicher?

Warum ist das unlogisch? Beispiel: /page/shop.html ist die Erklärungsseite einer Agentur, dass sie auch Shops anbieten, und /page/shop/index.html ist die Startseite eines Demoshops.

Finde ich sehr logisch. Es wäre unklug, diese Beschränkung einfach nur wegen der Beschränkung machen zu wollen. Wenn du programmtechnisch daraus irgendeinen Vorteil ziehen könntest, dann könnte ich es verstehen. Sowas sehe ich aber nicht.

Die Suchmaschinen nehmen nur die Links, die sie als href auf deiner Seite finden. Wenn dort Slashes am Ende sind, wird der entsprechende Link genommen. Wenn da keine sind, wird ohne Slash gearbeitet. Wenn dein Webserver eine Anforderung nach einer URL ohne Slash redirectet in eine URL mit Slash (wenn du auf ein Verzeichnis gelinkt hast, ohne dass du am Ende einen Slash gemacht hast), dann wird das die Suchmaschine unter Umständen beeinflussen, und sie wird die URL mit Slash indizieren. Ist ja auch sinnvoll, weil exakt diese URL den Content übermittelt hat.

Obwohl,
werden die Pfade innerhalb der css von allen Browsern
von dieser ausgehend gewertet? Bin gerade etwas verwirrt.

Nein. Alle Browser bis auf Netscape 4 gehen bei der URL-Bildung in einer externen CSS-Datei von der URL-Position der CSS-Datei aus. Das ist sinnvoll.

Netscape 4 geht bei der URL-Bildung in einer externen CSS-Datei von der URL-Position der anzuzeigenden Seite aus. Das ist meistens böse, weil man bei unterschiedlichen Verzeichnistiefen praktisch keine vernünftige relative Adressierung vornehmen kann. Absolute Adressierung ist notwendig. Nur in ganz wenigen theoretischen Anwendungsfällen ist dieses Verhalten des NS4 irgendwie sinnvoll. Beispielsweise, um je nach Verzeichnis andere Bilder mit CSS einzubinden, z.B. einen anderen Hintergrund.

wichtig ist ersteinmal die Navigation, damit die wichtigsten Seiten
indiziert werden. Habe schon an eine robots.txt gedacht,
da bin ich mir aber auch nicht sicher ob die Suchmaschinen
dann die Parameter in der URL akzeptieren würden.

Eine robots.txt sagt vernünftigen Suchmaschinen, welche Verzeichnisse auf dem Server sie NICHT indizieren sollen. Willst du Bereiche ausschließen, mußt du die da reinschreiben. Willst du keine Bereiche ausschließen, lass sie weg. Willst du die dummen 404-Fehler vermeiden, lege eine leere Datei an.

Was die Umstellung angeht: Entweder ganz, oder gar nicht, würde ich sagen. Logisch, dass du da vielleicht etwas unter Zeitdruck stehst, weil demnächst ja schon wieder eine Suchmaschine reinschauen könnte. Das tun sie nach meiner Erfahrung aber andauernd, und lesen immer mal wieder eine neue Seite ein.

Was du bei der Umstellung keinesfalls vergessen solltest: Permanente Redirects zumindest von den wichtigsten in den Suchmaschinen vertretenen URLs zu deinen neuen Seiten anlegen. Eine Suchmaschine ändert dann vielleicht schneller ihren Index und aktualisiert ihre Fundergebnisse. Außerdem kriegt ein Besucher mit einem alten Suchergebnis dann immerhin eine vernünftige Seite, und keinen Fehler.

Das leitet _alle_ Requests, die auf ".html" enden, auf das Seitenauslieferungsskript um. Die RewriteCond prüft, ob im Verzeichnisbaum eine entsprechende Datei tatsächlich existiert.

Die Condition brauche ich ja dann auch eigentlich nicht, oder (?),
denn wenn eine Seite nicht existiert, dann zeige ich doch
lieber die Startseite an, oder das nächste existierende
Unterverzeichniss, als ein 404 auszugeben, auch wenn
ein 404 ja auch auf die Startseite verweisen kann.

Nein. Wenn bei dir alle URLs gültig sind, und auf allen Seiten immer die Startseite angezeigt wird, ist das eher schlecht.

Eine nicht gefundene Seite, basierend auf der Definition dessen, was du an Seiten angelegt hast, muß immer mit Statuscode 404 ausgeliefert werden. Andernfalls wird sie sozusagen "durch die Hintertür" doch noch zum Leben erweckt.

Natürlich kannst du den Statuscode auch per header() ausgeben, und dann deine Startseite dranklatschen. Ich würde es aber besser finden, nicht die Startseite, sondern eine Fehlermeldung zu sehen. Dass deine Navigationselemente auf dieser Seite enthalten sein können, ist ja nicht verboten. Dann kommt der Besucher zumindest schon mal thematisch weiter - entweder zur Startseite, oder direkt dorthin, wohin er eigentlich wollte.

Ein paar Kritiken hatte ich ja noch,
es geht ja nicht nur um ein einziges Projekt, sondern um
eine logische und einfache Grundstruktur für alle
kommenden kleinen oder riesengroßen Projekte.

Ich empfehle, die Dinge nicht zu groß und unübersichtlich werden zu lassen. Die Trennung zwischen zwei voneinander als unabhängig zu betrachtenden Projekten ist im Zweifel immer die Domaingrenze (auch Subdomains bilden diese Grenzen). Für jedes Projekt allein muß die URL-Umschreibung stimmig sein und passen. Sie darf natürlich überall gleichartig sein - dann setzt es sich leichter Links.

Wie sieht es eigentlich in Deinen Statistiken aus,
werden dann die eingetippten URL's aufgelistet,
oder Dein Script?

Da werden praktischerweise die eingetippten URLs aufgelistet.

Und der Vorteil solch einer Sache ist ja: Du bist von der Art der Seitenerzeugung her vollkommen frei in der Wahl deiner Mittel. Wenn du irgendwann feststellst, dass du performancemäßig mit PHP-generierten Seiten nicht mehr hinkommst, kannst du (sofern das vom Inhalt her geht) die Seiten ja auch als statische Kopie generieren lassen und auf dem Server ablegen.

Oder du setzt ein anderes Skript ein. Das kann einen Teilbereich der URLs komplett anders behandeln und ausliefern. Also beispielsweise ein Forumsskript, welches groß ist, viel Power zum Skriptstart benötigt, aber nicht sehr häufig aufgerufen wird - warum soll man das auch für die simple Seitengenerierung beim statischen Content einsetzen, da reicht doch ein schnelles, kleines Skript.

Gegenüber der Außenwelt (Bookmarks, externe Links, Suchmaschinen) sieht dein Server immer gleich aus.

- Sven Rautenberg

[Benjamin Keil]

Moin auch!

Lag schon im Bett, aber wie das so ist hatt man da
ja die besten Ideen,... die Du soeben mit Deiner
wieder Antwort verworfen hast ;-)

Das Problem ist aber ja nur höchst ansichts- und gefühlshalber. Also kein echter Grund.

Das ist auch eine Verwaltungssache, es gibt ja auch statische
Inhalte, die die Endung .html tragen. Wenn ich an einem
z.B. Kunden-Projekt lange nicht gearbeitet habe, dann ist es
für mich direkt ersichlich was ich da fabriziert habe:
*.html sind statische html-seiten
*.inc sind Inhalte die unvollständig sind und inkludiert werden müssen
*.ini initialisierungsdateien, z.B. lege ich oft zu *.inc's gleichnamige *.ini's ab, wo dann weitere sachen in arrays drinstehen
(z.B. Seitentitel, welche banner eingeblendet werden sollen, usw.)
*.shtml - statische seiten in die dann noch eine Kleinigkeit hinzugefügt werden kann (eher selten)

Sowas kann man natürlich auch dokumentieren und bei Bedarf nachlesen,
aber für mich ist es einfacher wenn der Dateiname Aufschluss über den
Inhalt gibt.

Eine ideale Lösung wäre meiner Meinung nach, wenn ich
schon in der htaccess das .html , falls eines in der URL steht,
durch ein .inc ersetzen könnte, also URL im Broser:

www.oldschool.de/pages/skate.html
Per 'Condition' wird aber /content/skate.inc abgefragt.

www.oldschool.de/pages/skate/
/content/skate/index.inc wird abgefragt.

Geht aber eher nicht, oder?

In diesem Fall habe ich noch den Ordner 'pages' drin,
den Du rauslassen würdest, das ist vorerst unwichtig, ich muss erstmal über den Rest klarwerden.

Warum ist das unlogisch? Beispiel: /page/shop.html ist die Erklärungsseite einer Agentur, dass sie auch Shops anbieten, und /page/shop/index.html ist die Startseite eines Demoshops.

Das würde ich nicht so machen, der Demoshop wäre dann im
Ordner 'demoshop', aber das war ja nur ein Beispiel und
wenn jamand anders am Projekt arbeitet, dann wird er es
u.U. nicht verstehen warum es nicht funktioniert, du hast recht.

Was die Umstellung angeht: Entweder ganz, oder gar nicht, würde ich sagen. Logisch, dass du da vielleicht etwas unter Zeitdruck stehst, weil demnächst ja schon wieder eine Suchmaschine reinschauen könnte. Das tun sie nach meiner Erfahrung aber andauernd, und lesen immer mal wieder eine neue Seite ein.

Naja, der Zeitdruck liegt eher an meiner Abschlussarbeit,
an der ich gerade arbeite, oldschool.de ist momentan Nebensache
und auf die Besucher in den paar Wochen kommt es mir weniger an,
alsauf meinen Perfektionismus, der mich nicht schlafen lässt...

Was du bei der Umstellung keinesfalls vergessen solltest: Permanente Redirects zumindest von den wichtigsten in den Suchmaschinen vertretenen URLs zu deinen neuen Seiten anlegen. Eine Suchmaschine ändert dann vielleicht schneller ihren Index und aktualisiert ihre Fundergebnisse. Außerdem kriegt ein Besucher mit einem alten Suchergebnis dann immerhin eine vernünftige Seite, und keinen Fehler.

Auch deshalb bin ich gegen 404-Seiten mit Fehlermeldung,
ein Besucher der auf www.oldschool.de/skate/tricks/ollie.html
geht, kann immer noch auf www.oldschool.de/skate/tricks/
weitergeleitet werden, falls es die 1. Seite nicht gibt,
und wenn es die nicht gibt, dann halt auf www.oldschool.de/skate/
Allerdings indizieren die Suchmaschinen dann u.U. den content
doppelt und sehen das als Manipulierungsversuch an,
404-muss ich dann trotzdem ausgeben, naja vielleicht eine
Weiterleitung danach nach 0 sec. zum nächstnäheren Content.

Im Moment werden die Besucher noch sofort von der 404-Seite
zur Startseite weitergeleitet. Als Entwickler ist eine
404-Fehler-Seite vielleicht interessant, aber einen potentiellen
(durchschnitts-)Besucher fange ich lieber mit einer Übersicht dessen ab,
was ich zu bieten habe, als mit einem Fehler, aber vielleicht
sollte ich dann noch eine kleine aber auffällige Information
einbauen, wie z.B. "Die Adresse ..., die Sie aufgerufen haben,
existiert nicht, daher wurden Sie zu unsere Startseite
geleitet."

Vielen Dank nochmal für alles,
ich muss das morgen früh alles nochmal genau bedenken.

Du hast auf jeden Fall sehr geholfen!!!

Falls Du noch  einen kleinen Moment Zeit hast,
das mit der Abfrage in der htaccess, s.o. (*.html -> *.inc),
würde mich noch sehr interessieren.

Schöne Grüße und gute Nacht,

Benjamin

[Benjamin Keil]

Hallo nochmal,

ich habe mich mal durch's mod_rewrite gekämpft und
nun folgenden Eintrag in meiner htaccess:

RewriteEngine  on
RewriteRule    ^de/(.+).html$  index.php?page=$1
RewriteRule    ^de/(.+)/$  index.php?page=$1/

Das funktioniert wunderbar und an meinen Seiten brauche
ich nichts ändern, als die Pfadangaben absolut zu setzten.
Das ist natürlich doch lokal ein Problem, wie Du ja
vorausgesagt hast - was ich erst nicht glauben wollte :-(,
dazu habe ich aber ein neues Thema eröffnet.

Gibt es jetzt noch eine Möglichkeit eine Conditions zu
setzen, die vor dem Rewrite checkt, ob eine gleichnamige
Datei, nur mit anderer Endung (inc statt html) existiert
und im zweiten Fall, ob eine 'Pfad'/index.inc existiert?

Grüße,
Ben

[Sven Rautenberg]

Moin!

Das ist auch eine Verwaltungssache, es gibt ja auch statische
Inhalte, die die Endung .html tragen.

Ok. Ist natürlich sinnvoll, interne Gewohnheiten beizubehalten.

Eine ideale Lösung wäre meiner Meinung nach, wenn ich
schon in der htaccess das .html , falls eines in der URL steht,
durch ein .inc ersetzen könnte, also URL im Broser:

www.oldschool.de/pages/skate.html
Per 'Condition' wird aber /content/skate.inc abgefragt.

www.oldschool.de/pages/skate/
/content/skate/index.inc wird abgefragt.

Geht aber eher nicht, oder?

Klar geht das. Ist nur eine Winzigkeit komplizierter zu realisieren.

Du kannst ja in regulären Ausdrücken, also auch im Suchmuster der RewriteRule, Klammern setzen, um auf deren Inhalt später wieder zuzugreifen.

Du kannst in der RewriteCond auf die Klammerinhalte der RewriteRule zugreifen. Du kannst in der RewriteCond selbst auch wieder reguläre Ausdrücke haben, mit Klammern drin. Auf diese Klammern kannst du in anderen RewriteCond, und in der Ergebnisbildung der RewriteRule wieder zugreifen.

Du kannst also in der Summe ziemlich komplexe Transformationen machen, sie man im Endeffekt vermutlich nur noch als "krank" bezeichnen würde, und durch die fast niemand mehr durchblickt.

Aber so kompliziert ist es ja gar nicht.

Die Modifikation der bisherigen Lösung ist so: Du mußt irgendwie die URL-Endung ".html" vom Rest der URL isolieren. Diesen Teil setzt du in der RewriteCond anstatt der REQUEST_URI ein, und hängst noch ein ".inc" hinten dran, damit nachgesehen wird, ob eine inc-Datei auf dem Server existiert.

Dein PHP-Skript kriegt von der Incifizierung der URL zwar nichts mit, aber es dürfte leicht sein, mit Kenntnis der angeforderten URL den Pfad zur inc-Datei passend zu modifizieren.

Du kannst an dieser Stelle übrigens auch den Pfadteil "page" reinbringen. In der URL hat er nichts zu suchen - aber intern in deiner Verzeichnisstruktur vielleicht. Also kannst du ihn in der RewriteCond mit reinsetzen, damit in einem anderen Verzeichnis geprüft wird, als die URL, zusammen mit dem DOCUMENT_ROOT, vorgibt.

Statt

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -s
 RewriteRule ^/.+.html$ /backoffice/page.php

also:

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
 RewriteCond %{DOCUMENT_ROOT}/pages$1.inc -s
 RewriteRule ^(/.+).html$ /backoffice/page.php

Änderungen: Die Klammern in der RewriteRule sorgen dafür, dass man in den darüberstehenden RewriteCond (man kann ja mehr als eine haben) über $1 (weitere Klammern mit $2, $3 etc.) auf den gefundenen Inhalt zugreifen kann. Da ".html" dort nicht mit drinsteht, wird es in der RewriteCond einfach durch Anhängen von ".inc" ersetzt. Und auch das Verzeichnis "/pages" taucht dort auf, damit mod_rewrite im richtigen Verzeichnis die Existenz der Datei prüft.

Schau dir unbedingt die Doku-Seite von mod_rewrite an: http://httpd.apache.org/docs/mod/mod_rewrite.html. Da steht insbesondere drin, was man bei RewriteRule und RewriteCond so an Möglichkeiten zur Abfrage hat, und das Diagramm, welche Info wann wo durchfließt, ist auch von großem Nutzen.

Die Abwandlung habe ich nicht ausgetestet. Also keine Garantie, dass das direkt so funktioniert.

Warum ist das unlogisch? Beispiel: /page/shop.html ist die Erklärungsseite einer Agentur, dass sie auch Shops anbieten, und /page/shop/index.html ist die Startseite eines Demoshops.

Das würde ich nicht so machen, der Demoshop wäre dann im
Ordner 'demoshop', aber das war ja nur ein Beispiel und
wenn jamand anders am Projekt arbeitet, dann wird er es
u.U. nicht verstehen warum es nicht funktioniert, du hast recht.

Dann ist im Zweifel /page/demoshop.html die Erklärseite, wie man sich im Adminbereich des Demoshops anmeldet. :)

Naja, der Zeitdruck liegt eher an meiner Abschlussarbeit,
an der ich gerade arbeite, oldschool.de ist momentan Nebensache
und auf die Besucher in den paar Wochen kommt es mir weniger an,
alsauf meinen Perfektionismus, der mich nicht schlafen lässt...

Das ist eine gute Voraussetzung. Es macht keinen Sinn, schrittweise umzustellen. Entwickle und ändere alles auf einmal.

Auch deshalb bin ich gegen 404-Seiten mit Fehlermeldung,
ein Besucher der auf www.oldschool.de/skate/tricks/ollie.html
geht, kann immer noch auf www.oldschool.de/skate/tricks/
weitergeleitet werden, falls es die 1. Seite nicht gibt,
und wenn es die nicht gibt, dann halt auf www.oldschool.de/skate/

Ich finde es aber wichtig, den Besucher über das Nichtvorhandensein seiner gewünschten Ressource aufmerksam zu machen. Denn du weißt nichts über die Gründe, warum er einen 404-Fehler verursacht hat.

Kann ja sein, dass die Seite mal existierte, und jetzt weggekommen ist. Dann hat das Entfernen einen Grund. Wenn du von extern verlinkt wurdest mit den Worten "Super beschrieben ist es <link>hier</link>", und du hattest tatsächlich mal eine tolle Beschreibung von etwas, dann bringt es dem Besucher nichts, wenn er stattdessen auf eine Auflistung aller möglichen Beschreibungen oder einer thematischen Indexseite landet, wenn er doch viel lieber diese Beschreibung gelesen hätte.

404-Fehlerseiten machen klar, dass die gewünschte Seite nicht mehr verfügbar ist. Fertig. Aus die Maus. Wenn der fremde Verlinker mal einen Linkchecker über seine Site laufen läßt, wird der ihm ebenfalls anzeigen, dass sein Link auf die tolle Beschreibung leider tot ist.

Sofern du diese imaginäre Beschreibung nur auf eine andere Seite gesetzt hast, wäre es im Sinne ewig lebender URLs notwendig, einen individuellen Redirect auf die neue Seite zu setzen.

Das bedeutet unter dem Strich: Nichtexistierende Seiten haben grundsätzlich erstmal 404 zu sein. Die Fehlermeldung kann ja durchaus hilfreich sein und Links zu den existierenden, übergeordneten Seiten anbieten. Allein das Einbinden der Sitenavigation, mit der 404-Meldung als Content, ist oftmals schon ausreichend, vielleicht ergänzt um (aktuell auf Existenz geprüfte) Links zu den übergeordneten Informationsknoten.

Wenn eine Seite existiert hat, ist die so gültig gemachte URL auf ewig gesondert zu pflegen. Entweder wird die Seite erfolgreich ausgeliefert (Status 200), oder die Seite wird irgendwann mal unter einer anderen URL angeboten (Status 302 oder 301 als Redirect), oder die Seite wird irgendwann einmal wieder entfernt (Status 404 "not found" bzw. 410 "gone" - war da, ist es jetzt aber nicht mehr).

Allerdings indizieren die Suchmaschinen dann u.U. den content
doppelt und sehen das als Manipulierungsversuch an,
404-muss ich dann trotzdem ausgeben, naja vielleicht eine
Weiterleitung danach nach 0 sec. zum nächstnäheren Content.

Ich würde nichts weiterleiten. Der Benutzer hat ein Recht auf seine Fehlermeldung.

Stell dir vor, du bestellst in einer Kaffeebar einen "großen Schoko-Cappuchino mit Himbeersoße". Der Kellner nimmt die Bestellung entgegen, verschwindet hinter dem Tresen und macht. Und bringt dir schließlich eine Tasse mit Getränk darin. Nur ist das kein großer Schoko-Cappuchino mit Himbeersoße, sondern ein ganz normaler Kaffee, aber mit Vanillearoma. Himbeersoße war nicht mehr da, nur noch Vanillearoma, große Tassen sind im Geschirrspüler und waren noch nicht bereit, also nahm er eine normale Tasse, und die Capuchinomaschine ist gerade kaputt, also hat er einen Kaffee eingegossen und viel Milch dazugegeben.

Wärest du glücklich, wenn du für die im Vergleich zur Bestellung doch stark abweichende Lieferung auch noch bezahlen müßtest?

Wäre es nicht besser gewesen, der Kellner hätte dich informiert, dass deine Bestellung aus gewissen Gründen nicht ausführbar wäre, und dir vielleicht die möglichen Alternativen aufgezählt?

Ich spreche mich wirklich energisch gegen jede Art von automatischer Weiterleitung aus. Ich spreche mich genauso energisch für jede Art der Benutzerunterstützung in solch einem Fall aus. Aber die Form so einer Unterstützung kann eben sehr verschieden aussehen. Ein heiteres "URL-Raten" (so wie das Käse-Raten im Monty-Python-Sketch "Cheese Shop" - http://www.minderella.com/words/cheeseshop.htm) wird jedenfalls beim Besucher nicht stattfinden - und es sollte auch seitens des Servers nicht stattfinden.

- Sven Rautenberg

[Benjamin Keil]

Hallo und danke nochmal,

das war alles sehr interessant und ich denke das mit der Condition
bekomme ich hin. Die Struktur des Projektes gefällt mir
und ist logisch und der Besucher glaubt auf *.html seiten zu sein,
alles perfekt!! Die Sache mit dem 404 muss ich nochmal durchdenken
und vielleicht mal eine kleine Umfrage starten.

Dein Beispiel mit dem Cappucino überzeugt mich nicht so ganz,
es muss sich um einen kostenlosen Cappucino handeln (die
Onlinegebühren und verlorene Zeit haben damit nichts zu tun,
auf eine Anfrage kommt eine Antwort, entweder 404 oder Inhalt),
jetzt ist nur die Frage, ob ich es gut finden würde
anstelle eines kostenlosen Cappucinos einen Kaffee gebracht
zu bekommen inkl. einer Karte mit Übersicht über das was
es noch so kostenlos gibt, den Kaffee muss ich ja nicht trinken
(bzw. den Content lesen), der Geruch und Anblick (Headline)
reicht ja schon um ein Urteil zu fällen und um mich dann
vielleicht umzuentscheiden auf ein Käsebrötchen. Also
ich glaube der Kaffe + Karte + Entschuldigung wäre mir lieber,
als nur die Karte + Entschuldigung. Daraus schlussfolgere
ich, annähernd gewünschten Content zu zeigen, allerdings
als 404-Seite, mit einem Hinweis 'Die angeforderte Seite
http://www.bistro.de/kostenloses/kaffe_und_cappucino/cappucino.html'
wurde nicht gefunden.' Und man befindet sich auf der Seite
http://www.bistro.de/kostenloses/kaffe_und_cappucino/index.html',
auf der es einen ganz tollen marokanischen Kaffee (und den 404-Hinweis) gibt, echt lecker!!

Schöne Grüße,
Ben