mod_rewrite Klarheiten

[lspreee]

Ich würde mich freuen, wenn jemand meine Fragen sortieren könnte und die Widersprüche beseitigen könnte.
Ich bin absoluter mod_rewrite Neuling und möchte diesen Mechanismus von nun an benutzen, bin mir aber noch nicht sicher, wie ich es sinnvoll anwenden kann.

a) Ich lese immer wieder:

/** So transformiere ich z.B. URLs in der Art  
http://localhost/abc/index.php?module=publications&action=readmore&articleID=17  
zu  
http://localhost/abc/artikel/17 **/

gelesen auf: www.tutorials.de/...

oder:

 /**  
Durch mod-rewrite wird bspw. ein Aufruf wie  
http://www.ihredomain.tld/details.php?id=5&det=87  
    umgewandelt zu  
http://www.ihredomain.tld/fernseher/plasmafernseher.php  **/  

gelesen auf: www.grundlagen.com/...

Müsste es nicht eigentlich genau andersrum formuliert sein? Mod_rewrite wandelt die "schönen" URL's zu den "nützlichen" um? Oder habe ich da was falsch verstanden? Es ist total Ernst gemeint, weil ich genau wegen sowas die Geschichte nicht kapiere...

Vielen Lieben Dank für eine Antwort. Die anderen Fragen kommen danach.

[hotti]

hi,

Müsste es nicht eigentlich genau andersrum formuliert sein? Mod_rewrite wandelt die "schönen" URL's zu den "nützlichen" um? Oder habe ich da was falsch verstanden? Es ist total Ernst gemeint, weil ich genau wegen sowas die Geschichte nicht kapiere...

Ich kapiers auch nicht, warum sich jemand sowas antut: Eine Transformation von Request_Uri in eine oder mehrere serverseitige hinterlegte ID's und umgekehrt. Wenn schon Rewrite, dann doch gleich den Req.Uri als ID serverseitig hinterlegen, ist viel einfacher ;)

Auf meiner Site mache ich das schon immer so und hier auch.

Vielen Lieben Dank für eine Antwort. Die anderen Fragen kommen danach.

Schöne URLs? Den Suchmaschinen isses egal wie 'schön' die sind.

Viele Grüße,
Hotti

[lspreee]

Wow, super Post.

Ich kapiers auch nicht, warum sich jemand sowas antut: Eine Transformation von Request_Uri in eine oder mehrere serverseitige hinterlegte ID's und umgekehrt. Wenn schon Rewrite, dann doch gleich den Req.Uri als ID serverseitig hinterlegen, ist viel einfacher ;)

Klar.

Auf meiner Site mache ich das schon immer so und hier auch.

Super Seite, hat sogar zwei Pages. Jetzt habe ich alles kapiert.

Noch jemand?

[hotti]

hi,

Auf meiner Site mache ich das schon immer so und hier auch.

Super Seite, hat sogar zwei Pages. Jetzt habe ich alles kapiert.

Naja, es fehlen noch die Inhalte ;)

Aber teste mal die Ressourcen /service und /preise, da sind die Seiten schon vorbereitet, müssen nur noch geschrieben und verlinkt werden. Anderer Test: /foo oder /bar, das ergibt Status: 404. Für Ressourcen, die weiter in die Hierachie hineingehen (/a/b/c/d/e...) wird eine BreadCrumb-Navigation ans Menü gehängt und dann gibt es noch den internen Doctype "tree", der das Bäumchen aufbaut. Mit Rewrite ist es auch kein Thema, CGIs mit Sonderaufgaben einzubauen, hier ein Beispiel zu.

Aber aufgepasst: Intern muss der Manager wissen, ob /foo/bar ein Folder ist oder eine gewöhnliche HTML-Seite. Das wird objektorientiert mit Attributen (flag's body, folder, tree...) festgelegt, nurso als Anregung.

Hotti

[lspreee]

Ist ja super das Du ganz aufgeregt bist wegen Deiner neuen Seite, aber nerv mich nicht damit. Ich suche hier Hilfe zu mod_rewrite. Du hast mir mit Deinem tollen Gequatsche und Deinen Links zu fertigen Seiten kein bisschen geholfen. Tschüss.

[dedlfix]

Hi!

a) Ich lese immer wieder:

/** So transformiere ich z.B. URLs in der Art

http://localhost/abc/index.php?module=publications&action=readmore&articleID=17
zu
http://localhost/abc/artikel/17 **/

> gelesen auf: [www.tutorials.de/...](http://www.tutorials.de/hosting-webserver/261623-mod_rewrite-und-relative-pfade.html)  
  
URLs der obigen Form sind nur dann interesssant, wenn man bereits ein System hat, das mit solchen Parametern arbeitet und dieses nicht umstellen will. Wenn man neu anfängt, braucht man URLs nicht in die Querystring-Form umzubauen. Stattdessen reicht es, wenn man den Aufruf lediglich an ein Script weiterleitet. Dieses kann dann die Zusatzinformationen auswerten. Das hat den Vorteil, dass die Anzahl der Parameter beliebig sein kann und dass man das Rewriting nicht umschreiben muss, wenn sich mal was ändert. Man kommt mit  
  
  RewriteCond %{REQUEST\_FILENAME} !-d  
  RewriteCond %{REQUEST\_FILENAME} !-f  
  RewriteRule (.\*) index.php/$1 [QSA]  
  
schön übersichtlich zum Ziel. In index.php schaut man sich zunächst mit  
  
  phpinfo(INFO\_VARIABLES);  
  
an, was man übergeben bekommt, wenn man example.com/foo/bar und auch mal example.com/foo/bar?qux=baz aufruft. Je nach Serverkonfiguration findet man den interessanten Teil /foo/bar in PATH\_INFO oder einer anderen $\_SERVER-Variable. REQUEST\_URI kann man auch auswerten, aber da hängt auch der Querystring dran. Den braucht man nicht, denn man bekommt ihn wie üblich über $\_GET. Hat man nur REQUEST\_URI zur Verfügung, muss man den Querystring am ersten auftauchenden ? abschneiden. Das Auswerten von /foo/bar kann man wie folgt erledigen. Zunächst entfernt man mit trim($\_SERVER['PATH\_INFO'], '/') überflüssige / vom Anfang und Ende. Anschließend kann man mit explode() am / die Einzelteile bekommen.  
  
Das Flag [QSA] sorgt übrigens dafür, dass man außerdem noch den Querystring verwenden kann, wenn man will. Ich verwende ihn beispielsweise zur Angabe einer Sortierreihenfolge bei der Ausgabe von Massendaten.  
  
  example.com/foo/bar?sort=qux  
  
Die Daten bleiben ja die selben, nur die Darstellung ändert sich, so dass keine "komplett neue" URL gerechtfertigt ist, sondern nur eine um einen Parameter erweiterte. (Ja, ich weiß - genau genommen macht auch ein (anderer) Querystring bereits eine "neue" URL.)  
  

> oder:  
> ~~~php

 /**  

> Durch mod-rewrite wird bspw. ein Aufruf wie  
> http://www.ihredomain.tld/details.php?id=5&det=87  
>     umgewandelt zu  
> http://www.ihredomain.tld/fernseher/plasmafernseher.php  **/

gelesen auf: www.grundlagen.com/...

Müsste es nicht eigentlich genau andersrum formuliert sein? Mod_rewrite wandelt die "schönen" URL's zu den "nützlichen" um? Oder habe ich da was falsch verstanden? Es ist total Ernst gemeint, weil ich genau wegen sowas die Geschichte nicht kapiere...

Ja, oftmals wird das mit dem Umschreiben im Prinzip falsch herum formuliert. Allerdings sehen das die Autoren wohl eher von ihrer Historie her. Sie haben bisher die "nützliche" Version und schreiben ihr System so um, dass sie nun die "schönen" haben.

Lo!

[lspreee]

Vielen Dank für die Erklärungen. Besonders das

Ja, oftmals wird das mit dem Umschreiben im Prinzip falsch herum formuliert. Allerdings sehen das die Autoren wohl eher von ihrer Historie her. Sie haben bisher die "nützliche" Version und schreiben ihr System so um, dass sie nun die "schönen" haben.

bringt langsam Licht ins Dunkle. Aber auch phpinfo(INFO_VARIABLES); ist ein guter Tipp, um die Variablen durchzusehen.

Ich hoffe ich komme noch zu meinem Ergebniss...

Grüße

[misterunknown]

Moin,

Müsste es nicht eigentlich genau andersrum formuliert sein? Mod_rewrite wandelt die "schönen" URL's zu den "nützlichen" um? Oder habe ich da was falsch verstanden? Es ist total Ernst gemeint, weil ich genau wegen sowas die Geschichte nicht kapiere...

Also ich nutze mod_rewrite genau andersrum, wie du es schon sagtest. Und auch im Internet werden die "einfachen" Domains eigentlich meistens in die "unschönen" umgewandelt.
Der User gibt also example.com/bilder/123 ein und diese Adresse wird dann intern so umgestellt, dass etwas verwertbares dabei rauskommt.

Die "Schönheit" der URLs hat den Vorteil, dass man sich eben auch mal was merken kann, wenn man grade kein Zettel und Stift zur Hand hat.
Denn http://example.com/index.php?&show=news&id=12&page=2 ist nicht so gut zu merken wie
http://example.com/news/12/2
Es sieht auch in der Browserzeile übersichtlicher aus. Ob das nun relevant ist oder nicht sei dahingestellt.

Grüße Marco