bd ripper
HTacces rewrite
Ik wil de url die ik krijg aanpassen. Dit kan dmv htacces. Ik heb de volgende link die ik wil aanpassen:
www.voorbeeld.nl/topics.php?id=10&titel=over%20htacces%20leren
Nu wil ik die veranderen in iets als:
www.voorbeeld.nl/topics.php/id/10/titel/over-htacces-leren
ik heb deze code:
# Displaying PHP errors
php_flag display_errors on
php_value error_reporting 6143
RewriteEngine On
RewriteBase /
ErrorDocument 404 /errorpages/404.php
RewriteRule ^id/([^\./]+)\.html /id/$1.html [L]
Dit werkt helaas niet. Wat doe ik hier verkeerd aan?
Overigens zou ik die hele extensie gewoon weghalen uit je url. Heeft geen enkele meerwaarde en is dus eigenlijk ook url vervuiling.
maar dit is hoe ik het altijd doe:
Code (php)
1
2
3
4
5
2
3
4
5
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ index.php?route=$1 [QSA]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ index.php?route=$1 [QSA]
De eerste conditie zegt dat als de request voor een bestaande file is dan moet die aangeroepen worden. Bestaat de file niet, dan gaat de tweede in werking en die schrijft in feite de hele url om naar een parameter (route) in de url. vervolgens kan ik in php die gaan ontleden en bepalen wat er moet gaan gebeuren.
Als ik dus deze url aanroep:
http://www.domein.nl/pagina/actie/bla/bla/bla
dan wordt dat:
www.domein.nl/index.php?route=pagina/actie/bla/bla/bla
Bovenstaande van Erwin werkt perfect bij mij behalve als ik www.domein.nl intyp.
Deze lijkt nu niet meer naar index.php te gaan maar komt nu met (vanuit mijn script)een 404 pagina.
Kan de pagina dus niet vinden. Hoe kan ik dit voorkomen?
Onder de inhoud van mijn index.php
Code (php)
Gewijzigd op 05/09/2013 20:38:34 door N K
1) Waar staat je .htaccess (zou de root moeten zijn)
2) Waar staat je index.php (zou ook de root moeten zijn)
3) Check of je een RewriteBase nodig hebt. Op shared hosts is dat vaak nodig en dan krijg je waarschijnlijk dit:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ index.php?route=$1 [QSA]
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ index.php?route=$1 [QSA]
Gewijzigd op 05/09/2013 22:06:45 door Erwin H
mijn index.php staat een paar berichten terug. Of wil je iets anders zien?
De .htaccess staat in mijn root samen met index.php
htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ index.php?p=$1 [QSA]
Gewijzigd op 05/09/2013 22:17:13 door N K
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^(.*)$ events.php?event=$1 [QSA]
Als ik die rewritebase erin zet doet mn site het niet meer
ok, dan is het probleem (denk ik) duidelijk. Je moet namelijk wel goed begrijpen hoe die rewrite rule werkt. Elk request zal verwijzen naar dezelfde index file, met een get parameter. Als je dus naar www.domein.nl gaat, dan wordt dat herschreven naar www.domein.nl/index.php?p= je parameter p blijft dus leeg (er is verder geen route). In je index file vang je dat echter niet af. Je checkt op het niet bestaan van de parameter of anders op file_exists('pages/' . $page . '.php') (wat in dit geval 'pages/.php' wordt). Beide zijn niet correct en dus krijg je die 404 pagina.
Je zal dus nog de optie voor een lege parameter moeten opnemen.
@Donny
Wat gaat er bij jou dan mis? Je zegt dat er pagina's niet kunnen worden gevonden, maar dat is een beetje te weinig info voor mij om te kunnen zien wat er dan misgaat. De rewitebase heb je dus blijkbaar niet nodig.
Wat overigens nog een goede optie om je rewrite te testen, is om gewoon in je index file even de $_GET array te printen naar het scherm. Dan zie je precies welke rewrite goed gaat en welke niet. Als er dan een pagina niet gevonden kan worden, maar die GET array zie je wel, dan weet je dat het misgaat in je php stuk.
Thanks, ik dacht al zoiets maar je hebt me helemaal in de goede richting geholpen.
Heb nu dit wat werkt:
Zoals ik hierboven al zeg, je moet goed begrijpen hoe het werkt. Elk request dat er nu gedaan wordt gaat naar dezelfde index file, met het volledige pad in de opgegeven GET parameter. Je zal dus in php dat pad moeten gaan 'lezen' om te zien wat je moet doen. Het grote voordeel is dat je elke route nu dynamisch kan bouwen.
Gewijzigd op 05/09/2013 22:31:56 door Erwin H
Ik wil graag een GET parameter erbij hebben. Heb aardig wat gelezen maar kom er niet uit i.c.m. onderstaand voorbeeld.
Ik heb nu dit:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]
RewriteRule ^reset_password/(.*)$ index.php?p=reset_password&token=$1
RewriteRule ^(.*)$ index.php?p=$1 [QSA]
Op zich werkt dit wel maar al mijn paden binnen reset_password.php kloppen nu niet meer.
Bijv. bij een css bestand in deze pagina ziet het pad er nu uit als
http://localhost/site/reset_password/css/style.css
Terwijl het moet zijn
http://localhost/site/css/style.css
Kan iemand mij de juiste richting op helpen?
Gewijzigd op 09/09/2013 23:29:52 door N K
Vanuit index.php haalt mijn script de pagina op die in mijn GET['p'] staat.
Al deze pagina's bevatten relatieve paden bijv. css/style.css.
Vanuit mijn email wil ik naar site/reset_password/25f2vrggg43g34 (waarbij dat laatste de value van de token is) kunnen. Kan het zijn dat mijn script op index.php niet goed werkt in combinatie met de .htaccess?
Als het fout gaat door de relatieve paden, dan moet je of die relatieve paden loslaten, of een base pad opnemen in je html document.
Code (php)
1
<base href="http://www.domein.nl/">
De relatieve paden worden dan gebouwd vanaf dat pad en niet vanaf de url.
Ik vind het irritant dat ik niet snap waarom dit verkeerd gaat..;-)
Wat is het verschil tussen deze twee links?
http://localhost/site/reset_password/7c28f11d77f2f89e
http://localhost/site/login
Beide pagina's (reset_password en login) staan in dezelfde map (pages) en hebben dezelfde paden gedefinieerd.
Bij de eerste is er alleen een GET parameter toegevoegd.(token)
Toch probeert hij (bijv. een CSS bestand) bij de eerste vanuit een reset_password map te benaderen wat fout gaat.
Bij de tweede is dit gewoon zoals het hoort vanuit de root.
In beide scripts staat <link rel="stylesheet" href="css/style.css" />
Ik ben echt benieuwd waar ik dan de mist in ga..
(P.S.
is mijn htaccess regel wel goed? :
RewriteRule ^reset_password/(.*)$ index.php?p=reset_password&token=$1
Deze heb ik zelf in elkaar geknutseld maar ik mis hier nog de nodige kennis in..)
Met jouw voorbeelden (let ook op de eerste twee!):
relatieve pad: css/style.css
url: http://localhost/site/login -> http://localhost/site/css/style.css
url: http://localhost/site/login/ -> http://localhost/site/login/css/style.css
url: http://localhost/site/reset_password/7c28f11d77f2f89e -> http://localhost/site/reset_password/css/style.css
Voor de browser klopt dit, maar door het rewriten van je urls klopt het voor jouw server niet meer. Daar is de root altijd http://localhost/site/
Vandaar dat je de browser even moet helpen om de root correct te krijgen en dat doe je met die <base>.
N K op 10/09/2013 18:49:51:
Beide pagina's (reset_password en login) staan in dezelfde map (pages) en hebben dezelfde paden gedefinieerd.
Bij de eerste is er alleen een GET parameter toegevoegd.(token)
Bij de eerste is er alleen een GET parameter toegevoegd.(token)
Dat is niet waar. Je het er geen GET parameter aan toegevoegd, je hebt er een map aan toegevoegd. En dat is nu net het probleem. Een GET parameter komt na het vraagteken en daar zou de browser ook niet over vallen. Die extra 'map' wordt pas na het rewritten weer een GET parameter, maar dat weet de browser dus niet.
Toevoeging op 10/09/2013 19:49:36:
N K op 10/09/2013 18:49:51:
(P.S.
is mijn htaccess regel wel goed? :
RewriteRule ^reset_password/(.*)$ index.php?p=reset_password&token=$1
Deze heb ik zelf in elkaar geknutseld maar ik mis hier nog de nodige kennis in..)
is mijn htaccess regel wel goed? :
RewriteRule ^reset_password/(.*)$ index.php?p=reset_password&token=$1
Deze heb ik zelf in elkaar geknutseld maar ik mis hier nog de nodige kennis in..)
Als het werkt, werkt het, maar ik zou het niet doen. Ik zou gewoon bij de algemene blijven die ik boven heb gegeven en in je php script die route gaan interpreteren. Hoe meer uitzonderingen je al in de htaccess maakt, hoe inflexibeler (en lastiger te onderhouden) het wordt.