htaccess: auf datei mit GET-variable umleiten

[Stromer]

ich möchte gerne ein kleines projekt realisieren. um die urls für den besucher übersichtlicher zu machen möchte ich die GET-variablen wie verzeichnisse aussehen lassen. tönt jetzt wohl ein bisschen unverständlich. hier ein beispiel

"domain.de/index.php?page=home" ist zu erreichen über "domain.de/home"
"domain.de/index.php?page=info" ist zu erreichen über "domain.de/info"

ich hab gesucht, aber nichts gefunden...

[Horst]

Hallo,

ich hab gesucht, aber nichts gefunden...

Apache Rewrite Rules...

Hotte

[Tom]

Hello,

ich hab gesucht, aber nichts gefunden...

Apache Rewrite Rules...

Das klingt immer so, als wäre damit alles schon erledigt.
Aber die Regeln bilden ja nur beim request die URL auf die Parameter des Scriptes ab

Wenn man dan eine etwas größere Seite hat, muss man schließlich auch noch die Response umbauen. Wenn da vorher Links im Text erschienen, die eben so aussahen

http://example.org/?page=2788&cmd=search&fields=all&order=name_dec

wie schreibt man die dann am geschicktesten um in eine Verzeichnisschreibweise?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

http://example.org/?page=2788&cmd=search&fields=all&order=name_dec

wie schreibt man die dann am geschicktesten um in eine Verzeichnisschreibweise?

Der einzige Parameter, der offensichtlich konstant ist, ist page=2788. Alles andere sind offensichtlich Parameter einer Suche. Die schreibt man nicht um.

Ergo:

http://example.org/page2788.html?cmd=search&fields=all&order=name_dec

Ja, "page2788.html" ist doof und unaussagekräftig, aber dein Beispiel gibt nichts her, was an diese Stelle etwas schlaueres platzieren läßt. Gäbe es irgendeine eindeutige Abbildung eines besseren Schlüsselwortes zur Seiten-ID, geräte die Umsetzung optisch schöner.

- Sven Rautenberg

[Tom]

Hello,

http://example.org/?page=2788&cmd=search&fields=all&order=name_dec

wie schreibt man die dann am geschicktesten um in eine Verzeichnisschreibweise?

Der einzige Parameter, der offensichtlich konstant ist, ist page=2788. Alles andere sind offensichtlich Parameter einer Suche. Die schreibt man nicht um.

Ergo:

http://example.org/page2788.html?cmd=search&fields=all&order=name_dec

Ja, "page2788.html" ist doof und unaussagekräftig, aber dein Beispiel gibt nichts her, was an diese Stelle etwas schlaueres platzieren läßt. Gäbe es irgendeine eindeutige Abbildung eines besseren Schlüsselwortes zur Seiten-ID, geräte die Umsetzung optisch schöner.

Ja, geb ich zu, ist ein doofes Beispiel.
Das Problem ist ja schon älter.

Es gab da ein CMS. Das hatte quasi für die Navigation aus einer Datenbank Kategorien.

Wohnen                        page=20
    mieten/vermieten               Page=34
    kaufen                         Page=35
    renovieren                     page=36
      Farben und Tapeten             page=80
      Stoffe und Bodenbeläge
      Sanitär
      Elektro
    Mitwohnbörse                   page=40

Stadt
    Gastlichkeit
      Bierkneipen
      Speiserestaurants
      Imbiss
      Partyservice

Umland

Na und so weiter.
Die Seiten wurden in der DB gespeichert und die Auslösung war dann eben z.B. für Farben und Tapeten statt

/wohnen/renovieren/farben_und_tapeten

?target=80&parent=36

was nun wenig aussagefähig war.

Und nun kann hier ja keine statische Regel für das Umschreiben stattfinden, da Kategorien ind Unterkategorien hinzugefügt, gelöscht und was viel schlimmer war, auch verschoben werden konnten.

Das rewrite muss also in beide Richtungen irgendwie über die Datenbank laufen.

Und _das_ ist bis heute die Kernfrage geblieben. Wie baue ich ein System auf, dass das Rewriting dynamsich vornimmt, sodass ich auch mal einen Schreibfehler in Alektro gegen Elektro korrigieren könnte... Was natürlich schon wieder schädlich wäre, wenn der Pfad schon in den Suchmaschinen gespeichert wäre.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Die Seiten wurden in der DB gespeichert und die Auslösung war dann eben z.B. für Farben und Tapeten statt

/wohnen/renovieren/farben_und_tapeten

?target=80&parent=36

was nun wenig aussagefähig war.

Und nun kann hier ja keine statische Regel für das Umschreiben stattfinden, da Kategorien ind Unterkategorien hinzugefügt, gelöscht und was viel schlimmer war, auch verschoben werden konnten.

Aber selbstverständlich kann hier eine statische Regel helfen. Die Regel mappt alle URLs (bzw. sinnvollerweise nur die, die zu HTML-Content führen, Bilder o.ä. natürlich nicht) auf ein auslieferndes Skript, welches dann das Lookup der gefragten URL in der Datenbank vornimmt und dadurch die passenden Parameter ermittelt, sofern das dann tatsächlich noch notwendig ist.

Das rewrite muss also in beide Richtungen irgendwie über die Datenbank laufen.

"Beide Richtungen" nur insofern, als dass die Herstellung des Content berücksichtigen muß, dass die Links natürlich als ausführliche Text-URL zu erfolgen haben, nicht mit Parametern.

Und ob es sinnvoll ist, in so einem Konstrukt Verschiebeoperationen im Content auch in neue bzw. verschobene URLs umzumünzen, wäre im Einzelfall zu betrachten.

Und _das_ ist bis heute die Kernfrage geblieben. Wie baue ich ein System auf, dass das Rewriting dynamsich vornimmt, sodass ich auch mal einen Schreibfehler in Alektro gegen Elektro korrigieren könnte... Was natürlich schon wieder schädlich wäre, wenn der Pfad schon in den Suchmaschinen gespeichert wäre.

Man kann seine URLs aufwendig managen, oder simpel lassen. Will man der Nachwelt mehr als ein aussageloses 404 hinterlassen, endet die Lebenszeit einer URL nicht mit der Löschung des dazugehörigen HTML-Inhalts, sondern erfordert eine darüber hinausgehende Verwaltung der Ressource, wahlweise als 410 oder 301/302.

- Sven Rautenberg

[Tom]

Hello,

Aber selbstverständlich kann hier eine statische Regel helfen. Die Regel mappt alle URLs (bzw. sinnvollerweise nur die, die zu HTML-Content führen, Bilder o.ä. natürlich nicht) auf ein auslieferndes Skript, welches dann das Lookup der gefragten URL in der Datenbank vornimmt und dadurch die passenden Parameter ermittelt, sofern das dann tatsächlich noch notwendig ist.

Soweit waren wir ja auch gekommen...
Allerdings der Ordnung halber alles Requests umgeleitet, weil die ohnehin alle von Scripten bedient wurden.

"Beide Richtungen" nur insofern, als dass die Herstellung des Content berücksichtigen muß, dass die Links natürlich als ausführliche Text-URL zu erfolgen haben, nicht mit Parametern.

Und das erfordert dann den Eingriff in die Applikation. Den wollten wir vermeiden...

Und ob es sinnvoll ist, in so einem Konstrukt Verschiebeoperationen im Content auch in neue bzw. verschobene URLs umzumünzen, wäre im Einzelfall zu betrachten.

Dann sind die sicher schädlich fürs Ranking usw.

Man kann seine URLs aufwendig managen, oder simpel lassen. Will man der Nachwelt mehr als ein aussageloses 404 hinterlassen, endet die Lebenszeit einer URL nicht mit der Löschung des dazugehörigen HTML-Inhalts, sondern erfordert eine darüber hinausgehende Verwaltung der Ressource, wahlweise als 410 oder 301/302.

Ja, der Tipp ist mMn der entscheidende. Das CMS kann die Seite ja trotzdem eine Weile weiterführen, auch wenn sie nicht mehr lebt oder verschoben wurde.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom