RSS Feed
abonnieren.
Suche
Wunschzettel
Weblogeinträge
Referenzenmod_rewrite haben eh alle - oder etwa nicht? | 19. September 2005 um 20:18 Uhr / Webdesign
mod_rewrite nutzt einen Parser, der anhand von regulären Ausdrücken die angeforderte URL umschreibt.
Aus
http://example.org/2005/09/mod-rewritewird intern:
http://example.org/index.php?jahr=2005&monat=09&titel=mod-rewrite
Ich nutze das schon seit … immer? Damit sind die URLs schön aufgeräumt und für den Besucher auch gut nachvollziehbar dargestellt. Da mir das so gut gefallen hat, habe ich so etwas auch in 
Jlog eingesetzt.
Nun nutzen schon ein paar Leute Jlog – auch wenn es noch eine Beta Version ist. Ich habe mir die Seiten, die ich über meine Referer gefunden hatte, angeschaut und habe mit großem erstaunen festgestellt, dass keiner von ihnen die Variante der »sauberen« URLs nutzt, also auch kein mod_rewrite nutzt. Ich habe also direkt bei den Betreibern nachgefragt und undgefähr solche Antworten bekommen:
Diese Seite wird von Host Europe gehostet. Mein Webpack M erlaubt keine Änderung der .htaccess. Ich darf nur Error-Pages anlegen. Das htaccess-Feature (so nennt sich dies bei Host Europe) gibt es erst beim WebPack L und das ist doppelt so teuer.
Ne, mod_rewrite scheint nicht erlaubt zu sein. Das sind aber auch ein paar honqs. Die kriegen so einiges nicht gebacken.
Ist das wirklich so außergewöhnlich, dass man mod_rewrite vom Provider aus nutzen kann? Ich dachte eigentlich, dass das mittlerweile zum guten Standard gehört, aber anscheinen habe ich mich geirrt. Deshalb bin ich schon am überlegen wie ich diese ewig lange URL irgendwie abkürzen kann. Leider fällt mir dazu nur eine sinnvolle Alternative, umsteigen auf eine ID–Nummer, anstatt den ganzen Informationen über Datum und Titel der Seite, was aber leider sehr viele Informationen aus den URLs herausnehmen würde.
Oder ist es doch besser so wie es jetzt ist, also mit dem ganzen Rattenschwanz hintendran? Was meint ihr? Vielleicht ist es dem Nutzer auch völlig egal?
Kommentare
Die Kommentare sind für diesen Eintrag geschlossen.
blogerich schrieb am 19.09.2005
Ich würde gerne eine kurze URL haben. Noch habe ich meinem Hoster nicht gefragt, doch wie ich in seinem Forum gelesen habe ist es durchaus möglich sowas frei zu schalten. Werde ihn mal fragen.
rico aus dresden schrieb am 19.09.2005
hey jeena
ich würde bei mod-rewrite bleiben. nur das mit den kürzeln in der url würde ich rausnehmen da eigentlich das datum in der form von domain.de/2005/08/19/eintrags-id eigentlich reicht.
das problem ist eigentlich dass viele provider noch nicht erkannt haben dass es den kunden auf solche einzelheiten wie mod-rewrite auch ankommt und dadurch geld verdienen wollen da man ja ein höheres/anderes/meist teueres paket kaufen muß. oder auch die kunden und anwender haben es noch nicht gelernt ihren providern deswegen mit einer kündigung zu drohen. ich habe meinen provider auch angeschrieben und werde wohl in den nächsten monaten wegen solchen "kleinigkeiten" (es sind noch mehr zusätze welche ich brauche die aber fehlen) meinen anbieter wechseln. für meinetwegen 1/2 euro im monat mehr ist dass vertrehtbar.
wrtlprnft schrieb am 20.09.2005
Eine nette Alternative zu mod_rewrite ist, einfach hinter die PHP- Datei einen / und dann die Parameter zu verwenden, etwa so:
http://example.org/index.php/parameter/fuer/das/script
Das funktioniert wunderbar, man muss halt die Parameter selbst parsen (über $_SERVER['REQUEST_URI']) und akzeptieren, dass irgendwo in der URL .php vorkommt. Das sollte auch überall funktionieren, man ist jedenfalls das ? los.
Jeena Paradies aus Varberg schrieb am 20.09.2005
Alexander, wo du recht hast, hast du recht. Doch den Aufwand das jetzt im Nachhinein zu implementieren scheue ich noch. Einen Nachteil gibt es noch, die Datenredundanz. Es gibt die Daten dann zwei mal, 1. in der Datenbank und 2. in den einzelnen HTML Dateien. Dann noch ein Nachteil, wenn man irgendeine Kleinigkeit am Template ändert, muss man alle einträge neu bauen lassen. Das kann bei langsammeren Servern schon einige Zeit kosten, so dass man bei umfangreichen Weblogs an die Grenzen der Ausführungszeit von PHP kommt. Da hatten einige User von Movable Type schon ihre Schwierigkeiten.
Rico, es geht nicht hier um die Seite, hier habe ich mod_rewrite und es funktioniert auch gut. Das Monatskürzel bleibt aus historischen gründen und um mich aus der Masse herauszuheben drinn ;-). Der Tag interessiert in der URL keinen, deshalb habe ich ihn auch in Jlog weggelassen. Die von dir genannte eintrags-id ist keine, das ist nur ein titel für die URL, dieser darf sich wärend des Jahres auch ruhig wiederholen, wenn man zum Beispiel einmal im Monat seine Statistiken veröffentlicht, dann dürfen die jedes mal example.org/YYYY/MM/statistik heißen, wobei durch die zuordnung des Datums und des gleichzeitigen URL Zusatzes sichergestellt wird, dass diese kombination einmalig ist.
Mich wundert es, dass mod_rewrite als eines der elementären Mittel im URL-Design erst in den teueren Paketen der Provider enthalten ist.
Wrtlprnft, das ist wirklich zu überlegen, wobei man ja das .php vielleicht sogar weglassen kann, wenn man Multiviews verwendet (leider nur beim Apache). Ich muss mich da mal erkundigen, ob bei zusätzlich übergebenen Parametern das ganze immer noch funktioniert.
wahsaga schrieb am 20.09.2005
$_SERVER['PATH_INFO'] sollte bei Aufruf von
http://example.org/index.php/parameter/fuer/das/script
gleich nur
/parameter/fuer/das/script
zurückliefern - und das lässt sich leicht zerlegen, per explode bspw. - natürlich muss man dann noch ein wenig Fehlerbehandlung betreiben.
Erfordert beim Apache2 m.W. die Anweisung
AcceptPathInfo On
in der Konfiguration.
Christoph Hörl schrieb am 20.09.2005
Bis vor einigen Wochen war ich Kunde bei einem kleineren Webhoster hier aus unserer Umgebung zu denen ich einen persönlichen Kontakt aufgebaut hatte. Auf ihrem Server funktionierte mod_rewrite auch nicht. Sie hatten schlechte Erfahrungen gemacht und deshalb die .htaccess-Funktion aus Sicherheitsgründen deutlich eingeschränkt. Ich hätte zwar auf Wunsch meinen Account freischalten lassen könnte, aber dann hätte ich jede Änderung in der .htaccess von einem Mitarbeiter beim Provider eintragen lassen müssen, weil ich nicht Zugriff hatte. Mittlerweile bin ich gewechselt. Die Providerwahl war recht kompliziert, da manche - wie schon erwähnt - nicht ab dem günstigsten Paket mod_rewrite mit anbieten. Für mich war es aber notwendige Voraussetzung.
blogerich schrieb am 20.09.2005
Mein Problem: ich wüsste gar nicht welche Regeln ich in die .htaccess schreiben sollte damit es funktioniert.
So dumm wie ich war habe ich mir mod rewrite einschalten lassen und habe nun chaos.
Nun funktionieren die url in der übersicht nicht mehr. Das hat man nun davon.
Jeena Paradies aus Varberg schrieb am 20.09.2005
die .htaccess ist schon im jlog paket dabei, hast du die mit hochgeladen?
blogerich schrieb am 22.09.2005
Nö, habe ja nur die 0.2.81. Die neueste ist ja die 1.2.81. Wenn ich die .htaccses hochlade kommt diese Fehlermeldung anstelle meiner HP.
Na da bin ich überfordert. Ist schon verflixt mit mir. Erst DAU dann GAU :-) und Tschau
rico aus dresden schrieb am 22.09.2005
sieht so aus als könnte das paket deines providers ein mod_rewrite gar nicht verstehen...
blogerich schrieb am 22.09.2005
Ohne .htaccess funktionieren einige Links mit sauberer url und einige nicht. Ist mir ein Rätzel warum nicht alle gehen?
Kann es sein das ich einige Parameter in der .htaccess ändern muss?
Jeena Paradies aus Varberg schrieb am 23.09.2005
Ohne .htaccess ist es ein Zufall, dass die Links funktionieren. Wenn du mod_rewrite nutzen möchtest, dass ist die verarbeitung der mod_rewrite Regeln in der .htaccess Voraussetzung. Wenn das Einbinden einen 500er Fehler auslöst, dann kann das dein Server eindeutig nicht und du musst dich noch einmal bei deinem Provider melden und ihm sagen das mod_rewrite nicht funktioniert.
Die Rewrite Regeln in der .htaccess sind alle getestet und machen bei anderen auch keine Probleme.
blogerich aus DO/NRW schrieb am 23.09.2005
Ich habe das Options FollowSymlinks aus der .htaccess raus genommen und dadurch werden dann zwar saubere Links wie z.b.http://sirerich.de/2005/09/weiter_in_de angezeigt, doch dann geht es nicht mehr zur index.php zurück weil die url so angezeigt wird http://sirerich.de/2005/09/index.php.
Das 2005/09/ dürfte ja nicht sein sondern es müsste http://sirerich.de/index.php heißen.
Sobald ich wieder in den Kategorien selber bin kann ich auch wieder in die index.php.
Außerdem werden, sobald ich in den sauberen URL's lande die Grafiken nicht mehr alle angezeit so das ich vermute das die URL's irgendwie nicht korrekt sind. Siehe HIER da sind die url sauber, doch die Grafiken nicht alle vorhanden.
Also denke ich das es an der .htaccess liegt und dort etwas geändert weren muss, denn nachdem ich ja das Options FollowSymlinks rausgenommen habe gingen zumindest die sauberen url's.
Jeena Paradies aus Varberg schrieb am 23.09.2005
Du musst in deinem Template alle pfade absolut angeben, dann wird das alles funktionieren.
Chris schrieb am 24.09.2005
Meiner Meinung gehört mod_rewrite zu der Standard-Webspace-Ausstattung. Leider erlauben die meisten Provider - wie beispielsweise Host Europe - in den billigsten Paketen nicht mal eine .htaccess. Auch all-inkl.com hat erst kürzlich die .htacess aus den günstigsten Angeboten rausgeschmissen - man setzt jetzt den IIS als Server ein. :(
Jeena Paradies aus Varberg schrieb am 24.09.2005
Wenn mein Hoster auf ISS wechseln würde, dann würde ich sofort meinen Hoster wechseln. Ganz ehrlich, der Apache hat wesentliche Vorteile gegenüber dem ISS, nicht umsonst ist er auch viel verbreiteter.
Ingo schrieb am 26.09.2005
Das mod_rewrite nicht bei allen Hostern verfügbar ist hängt wohl auch mit seinem Speicherhunger zusammen. Bei vielen Usern auf einem Server, die zur Suchmaschinenoptimierung immer häufiger mod_rewrite nutzen, ist das ein echter Faktor.
Für die Erzeugung von statischen Seiten nach dem Modell von Alexander gibt es eine schöne Möglichkeit, nicht nach einer Templateänderung alles neu aufbauen zu lassen. Du kannst die 404-Seite einfach durch ein Script ersetzen, daß dir dann einmalig dynamisch die entsprechende HTML-Seite aufbaut. Somit muß nicht alles in einem Stück erstellt werden...
Gruß,
Ingo
wrtlprnft aus Winnipeg schrieb am 27.09.2005
Das größte Problem bei .htaccess ist meiner Meinung nach, dass es bei jedem Aufruf neu eingelesen wird. Das dürfte schon etwas Performance kosten.
Alexander aus dem guten alten Mannheim schrieb am 28.09.2005
Hi Jeena,
Ich habe noch eine Idee zur Reduzierung der Serverlast:
In der Datenbank wird doch der Text der Einträge und Kommentare so gespeichert, wie er eingegeben wurde, oder?
Dann könntest du eine weitere Spalte anlegen und dort das gerenderte HTML speichern.
Braucht zwar doppelt so viel Speicherplatz, ist aber viel schneller, weil nicht bei jedem Aufruf die BB-Code-Klasse über sämtliche angezeigte Kommentare und Einträge laufen muss.
Gruß
Alexander
fwolf aus stadt-land-fluss schrieb am 29.09.2005
zu dem thema verweise ich einfach mal auf nen alten eintrag in meinem weblog ;)
cu, w0lf.
Jeena Paradies aus Varberg schrieb am 29.09.2005
Alexander, die Idee ist gar nicht mal schlecht, da veränderungen sowieso immer durch die Software geschehen solle es auch nicht zu einer Inkonsistenz der Daten kommen. Wie viel das schlussendlich bringt müsste man mal messen, denn die meisten Texte sind nicht wirklich lang und verschachtelt, so dass das eventuell gar nicht wirklich ins gewicht fällt.
Robert Wetzlmayr aus Lenzing, Oberösterreich schrieb am 02.10.2005
Textpattern, ein andres Blogsystem, erlaubt die Eingabe der Postings mittels Textile (das ist so wie BBCode oder Markdown eine alternative Textauszeichnungsmöglichkeit), legt aber die fertig nach HTML übersetzten Texte parallel in der Datenbank ab.
Ist ja auch logisch. Besser, der Übersetzungsvorgang wird einmalig nach dem Verfassen des Posts ausfgeführt als bei jedem Aufruf...
Textpattern schneidet bei Benchmarks in Sachen Seitenaufbauzeit zum Beispiel im Vergleich mit WordPress sehr gut ab. Das die Seiten bereits fertig vorliegen, ist sicher einer der Gründe.
Florian aus Staufen, Deutschland schrieb am 05.10.2005
Da auch mein Provider überraschend mod_rewrite gekillt hat, habe ich bei meinem Blog einen anderen Trick benutzt:
Meine 404-Fehler-Seite ist eine PHP-Datei, die den Pfad ausliest, und entsprechend die richtigen Inhalte ausgibt. Zuvor wird der Fehler-404 wieder in ein korrektes 202-OK gewandelt.
Damit habe ich jetzt dieselben schönen URLs wie mit mod_rewrite. Einziger Nachteil: Meine Serverlogs kann ich jetzt wegschmeißen, weil sie praktisch nurnoch aus 404-Fehlern bestehen.
Mit WordPress geht das übrigens recht einfach. Ich musste nur einige wenige Zeilen ändern. Kann sein, dass es auf anderen Servern sogar von alleine klappt.
Martin schrieb am 17.10.2005
4websites.de zeigt eine weitere Möglichkeit, die Endung .php loszuwerden:
So lässt sich über http://example.org/artikel/foo/bar das Skript /artikel aufrufen, ohne dass es die Endung .php haben muss. Auswertung der Parameter erfolgt wie schon oben beschrieben über $_SERVER['REQUEST_URI'] oder noch besser über $_SERVER['PATH_INFO'], in letzterer Variable ist nur das "Anhängsel" (hier: /foo/bar) enthalten.
Robert Hartl aus Passau, D schrieb am 17.11.2005
Eine Link-Übersicht mit verständlichen Infos und Online-Generatoren zu mod_rewrite findet man bei den SEO-Marks von NetProfit.
Ich hatte zu Beginn arge Schwierigkeiten die Regeln zu verstehen, um selbst Fehler verbessern zu können.
Gottseidank liefern die meisten CMS dies nun automatisch.
viagra aus Engladn schrieb am 19.11.2005
Alexander, die Idee ist gar nicht mal schlecht, da veränderungen sowieso immer durch die Software geschehen solle es auch nicht zu einer Inkonsistenz der Daten kommen. Wie viel das schlussendlich bringt müsste man mal messen, denn die meisten Texte sind nicht wirklich lang und verschachtelt, so dass das eventuell gar nicht wirklich ins gewicht fällt.
Anonym schrieb am 28.02.2006
Kürzere URLs wären besser. Allerdings finde ich das Format bei Dir schon ganz gut.
Aber: Wieso verwendest Du nicht die gesamte Überschrift in der URL?
Julius aus Dresden schrieb am 21.05.2007
Hej Jeena,
es gibt auch ohne Mod-Rewrite eine angenehme Lösung, an /relativ) saubere URLs ranzukommen..
Sehr vereinfach, dient aber nur als Beispiel für den Grundstein... dann einfach
<? $menu = explode(",",$var_per_get); ?>und schon hast du eine schöne URL like www.example.com/index.php?news,2007,12,24,weihnachten
zum Beispiel :)
hej då, julius