Currently I'm using this rule to redirect to profile page, which works fine:
RewriteRule ^profile/([^/]*)/ ./profile.php?do=view&profileid=$1 [L,NC]
The problem is that I need to pass a second parameter, so the url
profile/1/Chris/2 to point to
profile.php?do=view&profileid=$1&tab=2
Is there any simple way to do it?
Thank you
Certainly this is possible:
RewriteEngine on
RewriteRule ^/?profile/(\d+)/[^/]+/(\d+)/?$ /profile.php?do=view&profileid=$1&tab=$2 [END]
RewriteRule ^/?profile/(\d+)/? /profile.php?do=view&profileid=$1 [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
UPDATE: considering your additional comment about how that second parameter is to be treated this probably implements that specific requirement:
RewriteEngine on
RewriteRule ^/?profile/(\d+)/[^/]+/.+ /profile.php?do=view&profileid=$1&tab=2 [END]
RewriteRule ^/?profile/(\d+)/? /profile.php?do=view&profileid=$1 [END]
Related
Im having problems with the following rule
RewriteRule ^submit\?t=([^/]*)$ /index.php?escribir=$1 [L]
I want to redirect from /submit?t=word to index.php?escribir=word but its not working.
What am I doing wrong?
You cannot match a query string using a RewriteRule directive. That is documented. You need to match and capture it using a RewriteCond instead. Reason ist that the rule only matches against the path part of the URL.
RewriteEngine on
RewriteCond %{QUERY_STRING} ^t=(.*)$
RewriteRule ^/?submit/?$ /index.php?escribir=%1 [QSD,END]
The more general approach that allows for other query arguments being specified and preserves those:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)t=([^&]*)(?:&|$)
RewriteRule ^/?submit/?$ /index.php?escribir=%1 [QSA,END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I'm trying to setup a rewrite from /api/user{/id} to api/user.php{/id} but for some reason it doesn't work. I suppose it's an internal rewrite loop but I don't know how to fix it.
RewriteCond %{REQUEST_URI} ^\/?api\/user\/?([a-zA-Z0-9_\-\/]+)?
RewriteRule ^\/?api\/user\/?(.*)?$ api/user.php/$1 [L,QSA]
Folder structure:
api/
api/user.php
When I change the rewrite rule so that it's not user but user2, it works without a problem. However, that's not what I need so it'd be kind if you could help me finding a solution to keep the naming.
This here is working with user2:
RewriteCond %{REQUEST_URI} ^\/?api\/user2\/?([a-zA-Z0-9_\-\/]+)?
RewriteRule ^\/?api\/user2\/?(.*)?$ api/user.php/$1 [L,QSA]
This probably is what you are looking for:
RewriteEngine on
RewriteRule ^/?api/user(?:/([a-zA-Z0-9_/-]*))?$ /api/user.php/$1 [END]
It matches /api/user and /api/user/ without capturing anything. For every longer requested URL the remainder is matched against the character group you specified.
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I'm trying to set a .htaccess directive to transform this :
https://www.example.com/nos-modeles?product-page=3
OR
https://www.example.com/nos-modeles?product-page=2
TO
https://www.example.com/nos-modeles/3
OR
https://www.example.com/nos-modeles/2
I've tried this, but it didn't do the job:
RewriteCond %{QUERY_STRING} ^(.*&|)product-page=\d+(?:&(.*)|)$
RewriteRule (.*) /$1 [R=302,L]
Your question is a bit unclear about what you are actually trying to do, rewriting incoming requests or redirecting existing references to "pretty URLs"...
Here is an approach that does both which actually is a typically combination:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)product-page=(\d+)(?:&|$)
RewriteRule ^/?nos-modeles/?$ /nos-modeles/%1 [R=301]
RewriteRule ^/?nos-modeles/(\d+)/?$ /nos-modeles?product-page=$1 [END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I want a rewrite rule for https://example.com/dev1.0/templates/feedback.php?uid=3 to be used as https://example.com/dev1.0/templates/feedback/uid/3
This probably is what you are looking for:
RewriteEngine on
RewriteRule ^/?dev1\.0/templates/feedback/uid/(\d+)/?$ /dev1.0/templates/feedback.php?uid=$1 [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
If you also want to redirect old references things get a bit more complicated:
RewriteEngine on
RewriteCond %{QUERY_STRING} ^uid=(\d+)$
RewriteRule ^/?dev1\.0/templates/feedback\.php$ /dev1.0/templates/feedback/uid/%1 [R=301]
RewriteRule ^/?dev1\.0/templates/feedback/uid/(\d+)/?$ /dev1.0/templates/feedback.php?uid=$1 [END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I have to redirect an URL with /?1 in the end, like
https://www.example.com/path/to/page/?1
to
https://www.example.com/other/path/to/page/
And I just can't find the solution. Important is to remove the ?1. I don't know why there is this ?1 in the end and what exactly it is used for but I can't change it.
Here is what I tried (and didn't work):
RewriteCond %{REQUEST_URI} path/to/page/\?1 [NC]
RewriteRule ^other/path/to/page/ [NE]
or:
RewriteRule ^/path/to/page/?$ /other/path/to/page/ [R=301,L]
THe reason why your attempt fails is that the "1" is not part of the URL, but of the query string. So this will probably work for you:
RewriteEngine on
RewriteCond %{QUERY_STRING} ^1$
RewriteRule ^/?path/to/page/?$ /path/to/page/ [END,QSD]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).