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).
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 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 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).
My server has following directory in the web directory
/mydomain/site/
/mydomain/site/project1/
/mydomain/site/project2/
I want to point domain http://mydoman.com to site directory /mydomain/site/ and access project directories using http://mydoman.com/project1/ and http://mydoman.com/project2/
I tried following code. When I type http://mydoman.com/project1/ in the browser, it is working fine but the problem is when i type http://mydoman.com/project1 (without "/" in the end of url) the url changes to http://mydoman.com/mydomain/site/project1/
RewriteEngine On
RewriteCond %{HTTP_HOST} mydomain.com$ [NC]
RewriteCond %{REQUEST_URI} !^/mydomain/site/.*$
RewriteRule ^(.*)$ /mydomain/site/$1 [L]
what I need is when I type http://mydoman.com/project1 url should not change to http://mydoman.com/mydomain/site/project1/
also
this url should not work http://mydoman.com/mydomain/site/project1/
Not sure why you don't want to use separate host names for separate projects. That would save a lot of hassle. Like https://example.com/... and https://project1.example.com/....
But anyway, this probablyis what you are looking for:
RewriteEngine on
RewriteRule ^/?mydomain/site/(.*)$ /$1 [R=301,QSA]
RewriteRule ^/?site/(.*)$ /$1 [R=301,QSA]
RewriteRule ^/?(.*)$ /mydomain/site/$1 [END]
You also need to take care that your application logic uses clean, relatvie references and not absolute paths like /site/... or /mydomain/site/... or even full URLs like https://example.com/mydomain/site/.... But that has nothing to do with rewriting. You need to solve that directly in your application logic.
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).
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).