Advanced Mod Rewriting Contenido 4.4.4
Verfasst: Do 6. Jan 2005, 20:27
Advanced Mod Rewrite:
ACHTUNG Warnung vorweg: Momentan nur für Benutzer gedacht die
FORTGESCHRITTENE PHP-Kentnisse haben!!!!
Statt einer URL á la front_content.php?idcat=34&lang=2&idart=64&client=1
will man suchmaschinenfreundliche Links.
Lösungsansatz 1:
mod_rewrite wie hier auch im Forum Lösungen beschrieben wurden:
/1/2/34/64.html oder 1_1_34_64.html
Problem:
Die Varianten gefielen mir nicht sonderbar, da keine
suchmaschinenfreundlichen Keywords in der immer wichtiger
werdenden URL vorhanden sind.
Ziel:
eine schöne URL nach dem Schema /sprache/kategorie/artikel.html
Erweitertes Ziel:
der Nutzer (normal Endanwender, der nix von HTML versteht) soll
mit der Erzeugung dieser URL nix zu tun haben müssen.
... und genau das habe ich umgesetzt.
Demonstration:
Frontend: http://contenido.polycoder.com
Backend: http://contenido.polycoder.com/contenido/index.php
User: demo
Passwort: test
Download des kompletten Bundles: Contenido 4.4.5
Letzte Änderung: 15.07.05
(Achtung es ist NICHT für die 4.5.x angepasst, diese Version findet ihr hier)
Bitte die Textdatei im Ordner SETUP_DOKU lesen!!!!
Vielen Dank an Ronaldo, der das Package auf
die aktuelle stable Version 4.4.5 angepasst hat:
contenido4.4.5_copy_art--mod-rewr_pl2.zip
Zur theoretoschen Arbeitsweise der Mod_Rewrite Funktionen:
Herzstück der ganzen Geschichte ist eine neue Klasse namens
ModRewrite in der Datei class.modrewrite.php im Ordner classes
und einigen neuen Funktionen in der datei functions.modrewrite.php
im includes Ordner. Die Klasse wird hauptsächlich im Backend genutzt,
die Funktionen nur bei der Rückgenerierung der websicheren Namen in
die entsprechenden ID Nummern.
Backend
Wenn eine neue Kategorie erstellt wird, wird automatisch der
Kategoriename als Websicherer Name erzeugt. Dazu wurde in der
Datenbank "cat_lang" ein neues Datenfeld erzeugt namens "websafename"
Beim Erstellen/Modifizieren des Kategorienamens wird wie schon
gesagt ein neuer websicherer Name erstellt, der nur die Zeichen
a-zA-Z0-9.-_~ enthalten darf. Dieser Name wird automatisch
mit allen bereits vorhandenen Kategorienamen innerhalb dieser
Kategorie abgeglichen um evtl. dubletten auszuschließen. Sollte
bereits eine Kategorie mit gleich lautendem Namen vorhanden sein,
so wird der neuen Kategorie am ende automatisch die ID Nummer
angehangen. (z.B. "Kategorie_23").
Bei jedem Modifizieren der Kategorie, sei es durch Umbenennen oder
Verschieben in andere Kategorien wird der websichere Name erneut
überprüft und ggf. geändert.
Das gleiche gilt für Artikel. In der Artikel Tabelle art_lang wurde
ebenfalls ein neues Datenfeld namens "websafename" angelegt. Beim
Artikel wird automatisch der "Titel" des Artikels (unter
Eigenschaften) in einen websicheren Namen umgewandelt und mit evtl.
vorhandenen Artikeln in der gleichen Kategorie abgeglichen.
Das war die Arbeitsweise im Backend. Ihr werdet die URLs im
Backend nie als Mod_Rewrite umgewandelt erleben, da dies nur bei
der Ausgabe des Frontends geschieht. Ihr habt also absichtlich
KEINE Möglichkeit den websicheren Namen individuell Abändern zu
können.
Frontend
Durch die .htaccess Datei werden der front_content.php neue
Variablen übergeben. Eine beispielhafte RewriteRule schaut
folgendermaßen aus:
RewriteRule ^(de|en|fr|sp|deutsch|english|englisch|franzoesisch|francais|spanisch|spain|espanol)/([^/]*)/([^/]*)/([^/]*)/(.*).html$ front_content.php?langname=$1&catnames[]=$2&catnames[]=$3&catnames[]=$4&artname=$5 [L]
Die neuen übergebenen Variablen lauten also (string) $langname,
(array) $catnames sowie (string) $artname.
Am Anfang der front_content werden diese 3 Variablen durch
entsprechende Funktionen ausgewertet, welche dann die korrekten
IDs $idcat, $idart und evtl. $lang zurückliefern.
Danach arbeitet die front_content ganz normal weiter, bis kurz vor
der Ausgabe der eigentlichen Seite. Statt der direkten Ausgabe des
Befehls eval("?>\n".$code."\n<?php\n"); wird der Ausgabe gebuffert
und einer Variable übergeben. Danach wird gecheckt ob Mod Rewrite
überhaupt aktiviert ist (wird mittels eines Schalters in der
config.php gesetzt). Wenn ModRewrite aktiv ist, so durchsucht eine
kleine funktion die gebufferte Ausgabe nach vorkommen von
href="front_content.php(.?)" und ersetzt diese dann in einer
kleinen Funktion zu den "schönen" Modrewrite URLs. Somit ist
gewährleistet, dass auch noch alle Module funktionieren und nicht
umgeschrieben werden müssen und bei einem evtl. Umzug und der
Tatsache, dass ein Server .htaccess nicht mehr unterstützt, die
Artikel mit Ihren Querverlinkungen zu anderen Artikeln nicht im
Nachhinein geändert werden müssen.
geänderte Dateien:
/cms/front_content.php
/contenido/includes/functions.con.php
/contenido/includes/functions.str.php
/contenido/includes/functions.modrewrite.php
/contenido/classes/class.modrewrite.php
/contenido/main.php
Ich hoffe ich hab da nix vergessen. Wenn Ihr das obige Zip File
geladen habt, könnt ihr mit dateiübergreifendem Suchen nach "stese"
alle modifizierten Stellen herausfinden.
Eine Manuelle Installationsanleitung findet Ihr unter:
http://contenido.polycoder.com/doku/man ... lation.txt
Ich bitte darum dass VERSIERTE Anwender das mal Testen und evtl.
Schwachstellen finden (die gibt es immer)
ACHTUNG Warnung vorweg: Momentan nur für Benutzer gedacht die
FORTGESCHRITTENE PHP-Kentnisse haben!!!!
Statt einer URL á la front_content.php?idcat=34&lang=2&idart=64&client=1
will man suchmaschinenfreundliche Links.
Lösungsansatz 1:
mod_rewrite wie hier auch im Forum Lösungen beschrieben wurden:
/1/2/34/64.html oder 1_1_34_64.html
Problem:
Die Varianten gefielen mir nicht sonderbar, da keine
suchmaschinenfreundlichen Keywords in der immer wichtiger
werdenden URL vorhanden sind.
Ziel:
eine schöne URL nach dem Schema /sprache/kategorie/artikel.html
Erweitertes Ziel:
der Nutzer (normal Endanwender, der nix von HTML versteht) soll
mit der Erzeugung dieser URL nix zu tun haben müssen.
... und genau das habe ich umgesetzt.
Demonstration:
Frontend: http://contenido.polycoder.com
Backend: http://contenido.polycoder.com/contenido/index.php
User: demo
Passwort: test
Download des kompletten Bundles: Contenido 4.4.5
Letzte Änderung: 15.07.05
(Achtung es ist NICHT für die 4.5.x angepasst, diese Version findet ihr hier)
Bitte die Textdatei im Ordner SETUP_DOKU lesen!!!!
Vielen Dank an Ronaldo, der das Package auf
die aktuelle stable Version 4.4.5 angepasst hat:
contenido4.4.5_copy_art--mod-rewr_pl2.zip
Zur theoretoschen Arbeitsweise der Mod_Rewrite Funktionen:
Herzstück der ganzen Geschichte ist eine neue Klasse namens
ModRewrite in der Datei class.modrewrite.php im Ordner classes
und einigen neuen Funktionen in der datei functions.modrewrite.php
im includes Ordner. Die Klasse wird hauptsächlich im Backend genutzt,
die Funktionen nur bei der Rückgenerierung der websicheren Namen in
die entsprechenden ID Nummern.
Backend
Wenn eine neue Kategorie erstellt wird, wird automatisch der
Kategoriename als Websicherer Name erzeugt. Dazu wurde in der
Datenbank "cat_lang" ein neues Datenfeld erzeugt namens "websafename"
Beim Erstellen/Modifizieren des Kategorienamens wird wie schon
gesagt ein neuer websicherer Name erstellt, der nur die Zeichen
a-zA-Z0-9.-_~ enthalten darf. Dieser Name wird automatisch
mit allen bereits vorhandenen Kategorienamen innerhalb dieser
Kategorie abgeglichen um evtl. dubletten auszuschließen. Sollte
bereits eine Kategorie mit gleich lautendem Namen vorhanden sein,
so wird der neuen Kategorie am ende automatisch die ID Nummer
angehangen. (z.B. "Kategorie_23").
Bei jedem Modifizieren der Kategorie, sei es durch Umbenennen oder
Verschieben in andere Kategorien wird der websichere Name erneut
überprüft und ggf. geändert.
Das gleiche gilt für Artikel. In der Artikel Tabelle art_lang wurde
ebenfalls ein neues Datenfeld namens "websafename" angelegt. Beim
Artikel wird automatisch der "Titel" des Artikels (unter
Eigenschaften) in einen websicheren Namen umgewandelt und mit evtl.
vorhandenen Artikeln in der gleichen Kategorie abgeglichen.
Das war die Arbeitsweise im Backend. Ihr werdet die URLs im
Backend nie als Mod_Rewrite umgewandelt erleben, da dies nur bei
der Ausgabe des Frontends geschieht. Ihr habt also absichtlich
KEINE Möglichkeit den websicheren Namen individuell Abändern zu
können.
Frontend
Durch die .htaccess Datei werden der front_content.php neue
Variablen übergeben. Eine beispielhafte RewriteRule schaut
folgendermaßen aus:
RewriteRule ^(de|en|fr|sp|deutsch|english|englisch|franzoesisch|francais|spanisch|spain|espanol)/([^/]*)/([^/]*)/([^/]*)/(.*).html$ front_content.php?langname=$1&catnames[]=$2&catnames[]=$3&catnames[]=$4&artname=$5 [L]
Die neuen übergebenen Variablen lauten also (string) $langname,
(array) $catnames sowie (string) $artname.
Am Anfang der front_content werden diese 3 Variablen durch
entsprechende Funktionen ausgewertet, welche dann die korrekten
IDs $idcat, $idart und evtl. $lang zurückliefern.
Danach arbeitet die front_content ganz normal weiter, bis kurz vor
der Ausgabe der eigentlichen Seite. Statt der direkten Ausgabe des
Befehls eval("?>\n".$code."\n<?php\n"); wird der Ausgabe gebuffert
und einer Variable übergeben. Danach wird gecheckt ob Mod Rewrite
überhaupt aktiviert ist (wird mittels eines Schalters in der
config.php gesetzt). Wenn ModRewrite aktiv ist, so durchsucht eine
kleine funktion die gebufferte Ausgabe nach vorkommen von
href="front_content.php(.?)" und ersetzt diese dann in einer
kleinen Funktion zu den "schönen" Modrewrite URLs. Somit ist
gewährleistet, dass auch noch alle Module funktionieren und nicht
umgeschrieben werden müssen und bei einem evtl. Umzug und der
Tatsache, dass ein Server .htaccess nicht mehr unterstützt, die
Artikel mit Ihren Querverlinkungen zu anderen Artikeln nicht im
Nachhinein geändert werden müssen.
geänderte Dateien:
/cms/front_content.php
/contenido/includes/functions.con.php
/contenido/includes/functions.str.php
/contenido/includes/functions.modrewrite.php
/contenido/classes/class.modrewrite.php
/contenido/main.php
Ich hoffe ich hab da nix vergessen. Wenn Ihr das obige Zip File
geladen habt, könnt ihr mit dateiübergreifendem Suchen nach "stese"
alle modifizierten Stellen herausfinden.
Eine Manuelle Installationsanleitung findet Ihr unter:
http://contenido.polycoder.com/doku/man ... lation.txt
Ich bitte darum dass VERSIERTE Anwender das mal Testen und evtl.
Schwachstellen finden (die gibt es immer)