I am trying to achieve the following redirect but for the life of me cannot figure it out:
domain.com/[anythingatall]
Redirects to:
domain.com/page.php?path=anythingatalldata
So essentially take [anythingatall] and auto redirect it to the second URL and put it where it says anythingatalldata.
Any suggestions? Currently I've got it semi working but it's adding the redirected code, specifically page.php to the anythingatalldata field instead of what I enter at /[anythingatall].
This probably is what you are looking for:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)path=(.*)(?:&|$)
RewriteRule ^/?page\.php$ /%1 [R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^/?(.*)/?$ /page.php?path=$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 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).
Related
I have .htaccess file for seo friendly url. My standard url is;
index.php?p=user
And I can access this url by typing;
www.mydomain.com/user
Everything is fine until here. What I also want to do is to crate a seo url for the following url;
index.php?p=user&username=john
and the seo url should be as follows;
www.mydoamin.com/user/john
I have tried the following and it keeps throwing 404 error.
RewriteRule ^user/([^/]*)$ /index.php?p=user&username=$1 [L]
Can anybody tell me what is wrong here?
Here is the current .htaccess code
RewriteEngine On
RewriteRule ^(.+)$ index.php?p=$1 [L,QSA]
RewriteRule ^user/([^/]*)$ /index.php?p=user&username=$1 [L]
Considering the current configuration you added to the question the issue might be that you need to reverse the order of those directives:
RewriteEngine On
RewriteRule ^user/([^/]*)$ /index.php?p=user&username=$1 [L]
RewriteRule ^(.+)$ index.php?p=$1 [L,QSA]
The reason is that the directives get processed from top to bottom. That means that you need to implement more specific rules, so exceptions earlier, so further up in the file. Because the pattern ^(.+)$ will match all requests.
There are some additional modifications I would suggest. But you will have to test that, since I have only a very limited insight into your setup:
RewriteEngine On
RewriteRule ^/?user/([^/]+)/?$ /index.php?p=user&username=$1 [END]
RewriteRule ^/?([^/]+)/?$ /index.php?p=$1 [END,QSA]
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 am using OpenCart for my e-commerce software and I have the following requirement I want to have for my store. Certain URLs I wish to apply my own rules before the normal OpenCart rules.
I tried a few tutorials online and the best I have come without causing a 500 is the following - I am placing the URL rules before the Opencart generic one. But it returns 404 in the browser - at least it is not a 500.
RewriteEngine On
RewriteBase /
# MY RULES
RewriteRule ^/bag$ /index.php?route=checkout/cart
# START OPENCART
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
I tried adding the [L] after the custom URL but it still won't display /bag
I should be able to do
/bag which should loading /index.php?route=checkout/cart
And I should be able to follow the rules below which are the normal OpenCart rules. /bag is giving me 404 however.
The documentation of the rewriting module explicitly states that RewriteRules operate on relative paths, when implemented in dynamic configuration files (".htaccess") as oposed to absolute path when implemented in the real http server's host configuration. That means that you need to change your rules matching pattern. Such rule can actually be implemented in a generic patter that will work in both situation which makes the implementation reusable.
Also you need to terminate the rewriting process when that rule gets applied. Otherwise the following rules will again rewrite the result of your own rule which is not what you want.
RewriteRule ^/?bag$ /index.php?route=checkout/cart [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 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 this:
website/test.php?id=1
How to get this?
website/test/1
I use this to remove .php extension. I tried a few rules to get the needed result but I couldn't.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_FILENAME}.php [QSA,L]
This should point you into the right direction:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_FILENAME}.php [END]
RewriteCond %{REQUEST_URI} ^/([^/]+)/(\d+)/?$
RewriteCond %1.php -f
RewriteRule ^ /%1.php?id=%2 [END]
It checks the path component of the requested URL, looks whether a corresponding php script exists similar to you already existing rewrite rule and if so performs the actual internal rewriting.
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 to change my website url display from bdnow.net/sites/businessName/index.php?page=pageName to bdnow.net/sites/businessName/pageName
if i write
RewriteEngine On
1 RewriteCond %{REQUEST_FILENAME} !-f
2 RewriteCond %{REQUEST_FILENAME} !-d
3 RewriteRule ^/(.*)$ /index.php?name=$1 [L]
it will go back to bdnow.net/index.php not index.php of businessName directory
Please help
If this does not work then you have some additional rewriting rules in place which you did not mention. This sometimes is the case within the application logic creating absolute references.
If you need to start debugging then take a look at "rewrite logging". It is documented, obviously, and allows to get a closer look at what is actually going on inside the rewriting engine on a step by step manner.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?(.*)/?$ /sites/businessName/index.php?name=$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 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'm struggling to redirect using the .htaccess.
Specifically I want to redirect based on a parameter. So for example:
mywebsite.com/2345 would redirect to otherwebsite.com/query?=2345
Is this possible using .htaccess? How would I be able to do it? I've never done anything with htaccess before..
Thank you!
Sure this is possible:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^/?(\d+)/?$ /query?=$1 [END,QSA]
This rule works likewise in the http server's host configuration or in a dynamic configuration file (".htaccess" style file). For this to work the http server's rewriting module has to be enabled, obviously. And if you decide to use a dynamic configuration script that also will have to be supported and enabled.
In case you receive an "internal server error" (http status 500) using above rule then chances are that you operate a very old version of the apache http server. In that case replace the END flag with the L flag, should work too in this case, though it depends on other rewriting rules you have. In any case you will find a definite hint on the unknown END flag in the http servers error log file.
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).