While upgrading Magento to 1.9.3.4 it overwrote the .htaccess file and now I am left with 2000+ broken links that I had manually created.
Since the old product URLs had a random number at the end and now they don't have so I am looking for a way to redirect them.
Old URLs Structure:
http://example.com/category-1/subcategory/product-name-1421.html
http://example.com/category-2/subcategory/product-name-5421.html
http://example.com/category-3/subcategory/product-name-5891.html
New URLs Structure:
http://example.com/category-1/subcategory/product-name.html
http://example.com/category-2/subcategory/product-name.html
http://example.com/category-3/subcategory/product-name.html
I know I can use RegExp something like RewriteRule ^category/subcategories/(.+?)(-[0-9]+)?$ category/subcategories/$1 [L,R=301] but I couldn't get it working.
I'd say this probably is what you are looking for:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?category/subcategory/(.+?)-\d+\.html$ /category/subcategory/$1.html [R=301]
For this you obviously need the rewriting module activated in your http server. And in case you want to use a dynamic configuration file (see below...) you need to enable that too (see the AllowOverride directive).
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
Related
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 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).
i tried different code in order to convert url to friendly url, but its doesnt seems working. here is my code the recent in tried.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
i would like to use instead of id to friendly text which could be the title of the page.
my current link is as follows
http://example.com/website/425199399/
i am exception the link something like this
http://example.com/website/the-working-class-family-425199399
Thanks for your help.
The code snippet you posted does not even attempt to implement a rewrite s you sketched it...
Here is a version that should point you into the right direction, but you certainly will have to adopt it to our needs and specific situation. So you won't get around reading into the documentation of the tools you use. You will find that the documentation of the apache modules (her the rewriting module) are of excellent quality and offer really good examples...
RewriteEngine on
RewriteRule ^/?website/.+-(\d+)$ /website/$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).
This code is not responding:
RewriteEngine On
RewriteRule ^/index.asp?lang=he&cid=270$ /?aid=2260 [R=301,L]
The query string ("http get arguments") is not part of the URL when the rule pattern is compared against it. You need to use a separate condition to match it:
RewriteEngine On
RewriteCond %{QueryString} ^lang=he&cid=270$
RewriteRule ^/?index\.asp$ /?aid=2260 [R=301,L]
Also note the additional ? near the start of the rules matching pattern. The URL is compared as relative (so without leading slash) in dynamic configuration files. The additional ? makes that leading slash optional, so the rule now will work in dynamic configuration files (".htaccess" style files) and likewise in the real http servers host configuration.
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
this code made my redirect:
RewriteCond %{QUERY_STRING} ^lang=he&cid=270($|&)
RewriteRule ^/?index.asp$ /?aid=2260 [R=301,L]
I am using following htaccess rewrite for clean URL:
RewriteRule ^([^/]+)/?$ category.php?cat=$1 [L,QSA]
RewriteRule ^([^/]+)/([^/]+)/?$ subcategory.php?cat=$1&subcat=$2 [L,QSA]
RewriteRule ^([^/]+)/([^/]+)/([^/]+)/?$ item.php?cat=$1&subcat=$2&item=$3 [L,QSA]
And I get clean URL like:- domain.com/SHOE/MEN/ITEM-NAME
Now I want change URL to be:- 1. domain.com/BOOTS/MEN/ITEM-NAME
and similar changes at parent level like: 2. domain.com/BOOTS/MEN and 3. domain.com/BOOTS
I tried with one additional line
RewriteRule ^SHOE/.*$ /BOOTS/$1 [L,R]
But still not working. Sorry If I made it complex. Thank you for help in advance.
Your question is not really clear, but I assume you want to redirect incoming browser requests to URLs using BOOTS instead of SHOE, whilst keeping the rest of the requested URL as it is...
For that try something like that:
RewriteEngine on
RewriteRule ^/?SHOE(.*)$ /BOOTS$1 [R=301,END]
That rule should be placed at the beginning of a possible series of rewrite rules. If you are using an old apache http server you might have to use the L flag instead of END. That also means you might have to take additional measures to prevent an endless rewriting loop.
And a general hint: you should always prefer to place such rules inside the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).