I have two URLs.
This one works: equipo.php?equipo=sk+gaming&page=2&ipp=24
This one does not: equipo/sk+gaming.html?page=2&ipp=24
equipo/sk+gaming.html does the same thing as equipo.php?equipo=sk+gaming, as it should.
My problem is that when using equipo/sk+gaming.html?page=2&ipp=24, the page parameter isn't there.
Why am I not getting the page parameter and how can I fix it?
If you're using Apache's mod_rewrite, the RewriteRule probably doesn't have the QSA flag.
Related
Hi and sorry for bothering you, i try to look around but i couldn't find a solution, and i really can't figure out how and if it's possible to do something like that with rewriterule.
This is the portion of htaccess file interested in my problem:
RewriteRule ^pagename/([^/]+)-([^/]+) mypage.php?name=$1&id=$2 [NC,L]
example.com/mypage/dogarticle-800ad43
so my variable in php will be like
$_GET["name"]=dogarticle and $_GET["name"]=800ad43
so far so good, but if an article contain a slash i can't get the right variable anymore, example
example.com/mypage/animals/dogandcat-800ad44
where animals/dogandcat should be name i receive the following get vars:
$_GET["name"]=animals $_GET["name"]=dogandcat
Here the question what should i do to receive the following get var:
$_GET["name"]=animals/dogandcat $_GET["name"]=800ad44>
Cant really figure out the solution, probably not the best of my days.
Thanks
edit:
in the name there can be a lot of slash example:
example.com/mypage/animals/dogandcat/squirrel/someotheranimal-800ad44
You can use:
RewriteRule ^pagename/(.+)-([^/]+)$ mypage.php?name=$1&id=$2 [NC,L]
We're trying to migrate our forum to another platform and we have encountered links which have queries in them, such as
http://forum.test/threads/119312-Warnight-CS-GO?p=2306618&viewfull=1#post2306618
which has to point to http://forum.test/threads/warnight-cs-go.119312/#post-2306618
So the logical structure of the original link is :
http://{forum_base_url}/threads/{thread-id}-{thread-permalink}?p={post-id}&viewfull={post-number-in-thread}#post{post-id}
While the new one is:
http://{forum_base_url}/threads/{thread-permalink}.{thread-id}/#post-{post-id}
So for the rewrite to work we need to "pull" three things out of the original link: the thread-id, the permalink, and the post-id. The first two aren't an issue, it's the third one which doesn't want to cooperate.
After scouring the Internet for possible solutions, we came up with:
RewriteCond %{QUERY_STRING} ^p=(\d+)&viewfull=(\d+)#post(\d+)$
RewriteRule ^threads/([0-9]+)-(.*)$ /threads/$2\.$1/#post-%1? [R=301,NC,L]
But unfortunately, the rewrite doesn't work.
What throws us off regarding the rewrite is that there are multiple variables in the query and no .php file specified in the link itself, so we can't just use the solution offered here: https://stackoverflow.com/a/2252242/1288397
Any tips on how to overcome this particular hurdle?
The #post- part of the URL is never sent to the server, it remains entirely on the browser's end, so there's no way to match against it. Luckily, the post ID is already in the query string so you can ignore it:
RewriteCond %{QUERY_STRING} ^p=(\d+)&viewfull=(\d+)$
RewriteRule ^threads/([0-9]+)-(.*)$ /threads/$2\.$1/#post-%1? [R=301,NC,L]
The other thing is that the thread-permalink is lowercase in your second URL. Not sure if that matters or not, but in order to change text to lowercase, you need to use a Rewrite Map, and the tolower internal function. You can only declare maps in the server vhost/config, so if you don't have access to those config files, you're not going to be able to use maps.
Thanks for clearing up the #post- aspect.
I tried your modification, but the links initially became:
http://forum.test/threads/warnight-cs-go.119312/%23post-2306618#post2306618
In order to work, the rewrite needs to be
RewriteCond %{QUERY_STRING} ^p=(\d+)&viewfull=(\d+)$
RewriteRule ^threads/([0-9]+)-(.*)$ /threads/$2\.$1/#post-%1? [R=301,NC,NE,L]
Notice the additional NE (noscape) flag at the end
That's because, by default, special characters, such as & and ?, will be converted to their hexcode equivalent. Using the [NE] flag prevents that from happening, as seen here: http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_ne
I'm currently trying to add a second get variable to an existing htaccess rule. I have little experience with the htaccess but using what expressions I know, I think it's missing one element to ensure the second variable is outputted correctly.
The domain (as the user sees it);
http://domain.com/london-area-info/?src=go
The rule i'm trying to apply;
RewriteRule ^(.*)-area-info/(.*)$ regioncc.php?region=$1&src=$2
The resulting output URL;
http://domain.com/regioncc.php?region=london&src=
I appreciate I'm probably overlooking something but looking around I haven't found an explanation has to how to make sure the ?src=go is shown after the rewrite rule rather than in another directory like /xxx-area-info/src/ for example.
EDIT
I have also tried the following rule but wasn't sure if I was escaping correctly
RewriteRule ^(.*)-area-info/(\?src=?.*)?$ regioncc.php?region=$1&src=$2
I believe this is what you want:
RewriteRule ^(.*)-area-info regioncc.php?region=$1&%{QUERY_STRING}
I'm writing a simple URL routing code based on using mod_rewrite to pass the URI as a GET parameter, like Drupal does. So I have the rule:
RewriteRule ^(.*)$ index.php?q=$1 [QSA,L]
And the URL http://www.example.com/test/1 would give me "/test/1/" passed as value $_GET['q'], instead of the usual index.php/test/1 and having to extract that from $_SERVER['REQUEST_URI'].
The thing is, the mod_rewrite QSA flag allows me to still use query strings normally, which I find very useful for parameters like filters and pagination, like "/products/category/?pg=1".
Will this work the same on Nginx and Lighttpd servers? I'd like my code to be portable.
Thanks.
No, in either case you'll have to translate your rules into each server's specific syntax. Some links to get you started:
http://forums.digitalpoint.com/showthread.php?t=187965
http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModRewrite
https://serverfault.com/questions/24243/nginx-support-for-htaccess-rewrite-rules-differences-from-apache
I have a really strange problem
ok the problem is thus
let say I have this url
http://www.example.com/?file=WFS010C.part3.rar&url=http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar
If I do base64_encode($_GET['url'])
the results is this
aHR0cDovL3d3dy5maWxlc2VydmUuY29tL2ZpbGUvdkVwQnlwMy9XRlMwMTBDLnBhcnQzLnJhcg==
after applying this rewrite condition
RewriteEngine On
RewriteBase /
RewriteRule ^file-(.*)-(.*)\.html$ index.php?file=$1&url=$2
The url is like this
http://www.example.com/file-WFS010C.part3.rar-http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar.html
now if I do base64_encode($_GET['url'])
the results is this
aHR0cDovd3d3LmZpbGVzZXJ2ZS5jb20vZmlsZS92RXBCeXAzL1dGUzAxMEMucGFydDMucmFy
**Note that the value of $_GET['url'] is exactly the same in both cases if printed without encoding!!!!
how come same string giving different results just after using rewrite ?**
Does anyone know whats the problem
You can use base64_decode to see whether they are same.
In fact:
The first one is
http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar
And the second one is
http:/www.fileserve.com/file/vEpByp3/WFS010C.part3.rar
You can see, they are not same.
You are rewriting your URl so the part after the second - is stored in url parameter. So in second case you receive url = http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar.html. Just like you had before.
What you are encoding is marked with bold:
With first url
http://www.example.com/?file=WFS010C.part3.rar&url=http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar
With second URL you are rewriting it to
http://www.example.com/index.php?file=WFS010C.part3.rar&url=http://www.fileserve.com/file/vEpByp3/WFS010C.part3.rar
UPDATE your second base64_encoded URL is decoding to http:/www.fileserve.com/file/vEpByp3/WFS010C.part3.rar. Note single / after http. Are you sure you have no typos in second URL?
First you need to urlencode the 'url' parameter. I'm guessing the parameter does not get correctly parsed because of invalid characters like '/' in it.