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).