[dago]

Sicherlich gibt es hier Einige, die sich mit mod_rewrite beschäftigt haben. Hier gibt es auch einige Themen dazu.

Nun ich hab bisher nur diese Methode der URL-Umleitung getroffen, wo die Pfadangaben über die GET-Variablen übergeben werden. Etwas so in der art

Aus der URL:
http://www.domain.tld/pfad1/pfad2/datei

wird dann:
index.php?foo=pfad1&bar=pfad2&file=datei

Es gibt allerdings noch die Möglichkeit über $_SERVER['REQUEST_URI'] auf die Original URI zuzugreifen.

Beipspiel:

# .htaccess File
RewriteEngine on
RewriteBase /

RewriteRule ^(.*) index.php

PHP-Code:

// Beispiel URL: http://www.domain.tld/pfad1/pfad2/datei.php?foo=bar

// gibt aus /pfad1/pfad2/datei.php?foo=bar
print $_SERVER['REQUEST_URI']; 


Nun die erste Methode währe sicherlich die erste Wahl wenn man ein Script auf mod_rewrite umstellen möchte. Allerdings bei Neuentwicklung bittet sich die zweite Methode an.
Die Bootstrap Datei soll dann nur bei aktiviertem mod_rewrite eingesetzt werden. Bei deaktiviertem mod_rewrite können dann auch mehrere Dateien angesprochen werden.

Nun meine Frage ist, gibt es was an $_SERVER['REQUEST_URI'] was auszusetzen? Ich hab es bisher noch nicht eingesetzt. Allerdings sehe ich zur Zeit nur Vorteile bei dem Einsatz bei der Bootsrap Datei.

[dr.e.]

Hallo dago,

ich sehe, du hast verstanden, dass man mit dem ersten Ansatz nur sehr eingeschränkt Dinge tun kann. Ein besserer Ansatz ist es $_SERVER['REQUEST_URI'] zu verwenden und die darin enthaltene URL, z.B.

/param1/value1/param2/value2/param3/value3

in das $_REQUEST zu mappen. Hierfür kann man sich ganz einfach einen Filter bauen, der das Remapping der URL durchführt. Ich habe dazu eine RewriteRule der Form

RewriteEngine on
RewriteCond %{REQUEST_URI} !^(\/frontend) [NC]
RewriteRule !(index.php|css|jpe?g|png|gif|zip|rar)$ /index.php?query=%{REQUEST_URI}&%{QUERY_STRING} [NC,L]

Damit kannst du entweder nur einfache Parameter wie

index.php?param1=value1&param2=value2

,

reine Slash-URLs wie

/param1/value1/param2/value2

oder auch gemischte URLs wie

/param1/value1/param2/value2?param3=value3

übergeben. Der in der Bootstrap-Datei angewendete Filter zieht sich nun die Parameter aus dem $_SERVER['REQUEST_URI']-Array und rewritet diese in das $_REQUEST-Array, so dass sich für die Applikationen keine Änderungen ergeben. Solltest du Hilfestellung zum URL-Parser benötigen, schau dir die Quellcodes der Filter unter /core/filter im aktuellen Release des Adventure-PHP-Frameworks (http://www.adventure-php-framework.o...de_package.zip) an.

[$traight-$hoota]

Zitat von dr.e.

Damit kannst du entweder nur einfache Parameter wie

index.php?param1=value1&param2=value2

,

reine Slash-URLs wie

/param1/value1/param2/value2

oder auch gemischte URLs wie

/param1/value1/param2/value2?param3=value3

übergeben. Der in der Bootstrap-Datei angewendete Filter zieht sich nun die Parameter aus dem $_SERVER['REQUEST_URI']-Array und rewritet diese in das $_REQUEST-Array, so dass sich für die Applikationen keine Änderungen ergeben.

supi und das bringt mir dann nen haufen double content... wenn man schon per mod_rewrite suma- und userfreundliche urls benutzt, sollte das auch der einzige weg sein, eine seite aufzurufen.

die parameterversion sollte dann allerhöchstens auf die richtige form weiterleiten, aber selbst das würde ich zumindest bei einer neuen webseite unterlassen; wie sollte denn auch ein user einen link in der parameterform erhalten, wenn auf der seite nur feinsäuberliche path-urls verwendet werden?

[dago]

Danke für die Antwort dr.e.

Aber dein Beispiel entspricht eher dem ersten Fall:

RewriteEngine on
RewriteCond %{REQUEST_URI} !^(\/frontend) [NC]
RewriteRule !(index.php|css|jpe?g|png|gif|zip|rar)$ /index.php?query=%{REQUEST_URI}&%{QUERY_STRING} [NC,L]

Du tust nämlich die URL umschreiben und abspeichern in die GET-Variable "query"


Man muss allerdings die URL garnicht umschreiben. Man kann nämlcih direkt per $_GET oder $_SERVER['QUERY_STRING'] direkt aus PHP heraus auf die Parameter zugreifen.
Die Frage die ich jetzt eher habe, warum der Pfad in ein GET-Paramater abgespeichert wird. Denn man kann ja auch direkt darauf zugreifen mit $_SERVER['REQUEST_URI']. Es enthält allerdings auch die GET-Parameter.

Spricht was dagegen $_SERVER['REQUEST_URI'] innerhalb der PHP-Scripts einzusetzen? Denn das erscheint mir als der besserer Weg, als der Umweg über einen GET-Parameter.

[dr.e.]

@$traight-$hoota:

supi und das bringt mir dann nen haufen double content... wenn man schon per mod_rewrite suma- und userfreundliche urls benutzt, sollte das auch der einzige weg sein, eine seite aufzurufen.

Diese Reaktion verstehe ich nicht. Ich zeigte lediglich auf, welche Möglichkeiten ich mit der Implementierung vorgesehen habe. Die von mir betriebenen Projekte und auf den Seiten, auf denen die Implementierung der URL-Filter eingesetzt wird, setzen alle auf URLs der Form

/param1/value1/param2/value2

Ich schränkte meine Implementierung jedoch nicht auf diese Methode ein - manche können diese Generik garnicht in den URLs abbilden - sondern gebe dem Entwickler die Möglichkeit, zu entscheiden, wie er seine URLs gestaltet.
Nicht mehr und nicht weniger.

die parameterversion sollte dann allerhöchstens auf die richtige form weiterleiten, aber selbst das würde ich zumindest bei einer neuen webseite unterlassen; wie sollte denn auch ein user einen link in der parameterform erhalten, wenn auf der seite nur feinsäuberliche path-urls verwendet werden?

Die von mir aufgezeigte Mischform setze ich nur zu Test-Zwecken ein um schneller Frontcontroller-URLs schreiben zu können. Die linkHandler, die ich einsetze, generieren entweder ein herkömmliches URL-Layout, oder ein Rewrite-URL-Layout. Die Mischform bekommt keiner mit, das wird durch den HTML-Filter sichergestellt, der am Ende nochmal alle Links in der Seite auf Syntax prüft. Die Mischform einzusetzen - da gebe ich dir Recht - ist für SEO und allein aus Ästhetik-Gründen nicht produktiv.


@dago:

Du tust nämlich die URL umschreiben und abspeichern in die GET-Variable "query"

Ja, ich speichere den kompletten Query-String in der GET-Variable "query".

Man muss allerdings die URL garnicht umschreiben. Man kann nämlcih direkt per $_GET oder $_SERVER['QUERY_STRING'] direkt aus PHP heraus auf die Parameter zugreifen.
Die Frage die ich jetzt eher habe, warum der Pfad in ein GET-Paramater abgespeichert wird. Denn man kann ja auch direkt darauf zugreifen mit $_SERVER['REQUEST_URI']. Es enthält allerdings auch die GET-Parameter.

Das mache ich jedoch nur, damit ich auch Mischformen von Links anbieten kann. Weiter hat das keine Bedeutung, denn wenn ich diese Mischform nicht anbieten wollte, könnte ich auch $_SERVER['REQUEST_URI'] verwenden. Das hab ich früher auch so gemacht.

Spricht was dagegen $_SERVER['REQUEST_URI'] innerhalb der PHP-Scripts einzusetzen? Denn das erscheint mir als der besserer Weg, als der Umweg über einen GET-Parameter.

Das ist kein Umweg, sondern nur eine andere Möglichkeit, das zu tun. Performance-Technisch ist das transparent, da der Apache hier die Arbeit bereits durch die RewriteRule für dich erledigt. Wichtig ist nur, dass du die RewriteRule so gestaltest, dass die Reques-URI vom Apachen nicht während des Rewritings verloren geht, sondern an dein Skript übergeben wird.

[dago]

Zitat von dr.e.

Das mache ich jedoch nur, damit ich auch Mischformen von Links anbieten kann. Weiter hat das keine Bedeutung, denn wenn ich diese Mischform nicht anbieten wollte, könnte ich auch $_SERVER['REQUEST_URI'] verwenden. Das hab ich früher auch so gemacht.

Verstehe ich nicht ganz. Das kann ich doch genauso mit nur auslesen der $_SERVER['REQUEST_URI'] auch tun, ohne denn Pfand und Query in ein Query-Parameter zu packen.

Das ist kein Umweg, sondern nur eine andere Möglichkeit, das zu tun. Performance-Technisch ist das transparent, da der Apache hier die Arbeit bereits durch die RewriteRule für dich erledigt. Wichtig ist nur, dass du die RewriteRule so gestaltest, dass die Reques-URI vom Apachen nicht während des Rewritings verloren geht, sondern an dein Skript übergeben wird.

Umweg meine ich in dem Sinn, dass man auch ohne dieses Umschreiben an die ganze URL (URL-Werte) vom PHP-Script aus ran kommt. So, dass es eigentlich nicht nötig währe. Damit will ja nicht sagen, dass es schlechter oder unsinnig ist es zu tun.

Aber danke dir. Werde nun mein Request-Objekt auf REQUEST_URI aufbauen.

[CIX88]

Ähhh das Umschreiben der URL ist nur für SEO gedacht, nicht für User. Dem User ist es Wurst wie die URL im Browser steht - Google nicht.

[dr.e.]

Hallo dago,

Verstehe ich nicht ganz. Das kann ich doch genauso mit nur auslesen der $_SERVER['REQUEST_URI'] auch tun, ohne denn Pfand und Query in ein Query-Parameter zu packen.

Tun könnte man das sicher - sagte ich ja auch - nur dann ist das implementieren des Parsers schwieriger.

Aber danke dir. Werde nun mein Request-Objekt auf REQUEST_URI aufbauen.

Fein!

[$traight-$hoota]

Zitat von CIX88

Ähhh das Umschreiben der URL ist nur für SEO gedacht, nicht für User. Dem User ist es Wurst wie die URL im Browser steht - Google nicht.

Auch für den User ist eine URL in der Form /blog/archives/2006/45,eine-tolle-geschichte weitaus besser zu lesen und zu merken als zum Beispiel index.php?module=blog&component=archive&action=vie w_item&item=45. Außerdem kann so auch ein User einfach erkennen, was ihn auf dieser seite erwartet.

[CIX88]

Pffffffffff was habt ihr für Vorstellungen ?
URLs muss man sich nicht merken, dafür gibt es Favoriten

was ihn auf dieser seite erwartet

Dafür gibt es Headlines,Breadcrumbs etc...

Wobei

/param1/value1/param2/value2/param3/value3

nicht gerade dies eine falche Verzeichnisstruktur ist, und NICHT für Sumis geeignet ist.
Aber was erzähl ich überhaupt ...

[dr.e.]

Wobei

nicht gerade dies eine falche Verzeichnisstruktur ist, und NICHT für Sumis geeignet ist.
Aber was erzähl ich überhaupt ...

Das stimme ich deinem letzten Satz zu, das ist nicht wirklich sinnvoll. Eine Struktur der Form

/Seite/Startseite
/Seite/Guestbook
/Seite/Guestbook/page/1
/Seite/Guestbook/page/2
/Seite/Kontakt/view/form
/Seite/Kontakt/view/thanks

ist meines Erachtens nach einfach zu merken und schön für Suchmaschinen als auch sinnvoll und gehorcht dem von dir angemeckerten Layout. Überzeuge mich eines anderen, aber dein letzter Post war Schmarrn.

[CIX88]

Da ich 5 Tage die Woche mich mit SEO befassen muss, habe ich einfach meine Erfahrungen gemacht, und die liegen hin und wieder daneben, als was in Blogs, Büchern oder sonstigen geschrieben steht
2, 3 Ordner sind ok, aber mehr sollten es nicht sein, Stichwort => Pyramide einer Website und Ballastfreie URLs.

gut:
/Seite/Guestbook/page/1

hoch besser:
/Seite/Guestbook,page_1.html