Rewrite dynamic Magento URL - nginx

I have a Magento v1.4.1.1 installation on Nginx web server. I'm trying to rewrite the following dynamic URL:
#5028 is the dynamic id passed in the URL
$baseUrl/design/index/index/design_id/5028
To:
$baseUrl/my/design/5028
I have used the Magento's "URL Rewrite Management" to rewrite static URLs, without a problem. But it seems I cannot use dynamic parameters.
I've also tried to do the following on Nginx configuration inside my server{} location
rewrite ^/my/designs/([0-9]+)$ /design/index/index/design_id/$1 last;
But it's not getting catch, I keep getting 404 errors if I try to access http://mysite.com/my/design/5028
Another rule right next to this one works perfectly
rewrite ^(/fb)/design/([0-9]+)$ $1/landing_no_contest.php?design_id=$2? last;
Thanks for any help.

Yes, Magento's "URL Rewrite Managment" does not support dynamic links, afaik.
You could programmatically add static rewrites per design_id to it, though:
$iStoreId = 1;
$sOptions = 'RP'; // 'RP' for a 301, or 'R' for a 302
$aDesignId = array(5026, 5027, 5028);
foreach ($aDesignId as $iDesignId) {
Mage::getModel('core/url_rewrite')
->setStoreId($iStoreId)
->setCategoryId(null)
->setProductId(null)
->setIdPath(str_replace('0.', '', str_replace(' ', '_', microtime())))
->setRequestPath('design/index/index/design_id/' . $iDesignId)
->setTargetPath('my/design/' . $iDesignId)
->setIsSystem(0)
->setOptions($sOptions)
->save();
}

Related

Nginx redirect path to a new structure not working with "#"

I'm trying to create the following rewrite in nginx:
https://my-domain/app/kibana#/discover?<some-get-params>
to
https://new-domain/app/discover#/?<some-get-params>
I'm struggling I think because of the "#" character.
I am able to redirect to the destination, but always without the params.
My last attempt was as follows:
location / {
rewrite ^/app/kibana#/discover(.*)$ https://my-new-domain.com/app/discover#/$1 redirect;
}
What happens with this one is a 404.
If instead I do something like:
location / {
rewrite ^/app/kibana(.*)$ https://my-new-domain.com/app/discover#/$args redirect;
}
I get redirected to the right destination but without any args: https://my-new-domain.com/app/discover#/
Same thing if instead of $args I use $1 instead

NGINX user-friendly url without changing path in browser

Is it possible to rewrite or redirect an url to a user friendly url without changing the requested url in the browser ?
I want user to access the page :
example.com/dashboard/c7BIDZMJ96zh8jKgmTEcAugA22RDhGkH
Through url :
example.com/dashboard/nicedashboardname
I am using Nginx rewrite
location = /dashboard/nicedashboardname {
rewrite ^/dashboard/nicedashboardname?$ /dashboard/c7BIDZMJ96zh8jKgmTEcAugA22RDhGkH break;
}
I need this because the Id of the non-user-friendly page can change over time.
Thank you
No need to use rewrite here… You can use return:
location = /dashboard/nicedashboardname {
return 301 /dashboard/c7BIDZMJ96zh8jKgmTEcAugA22RDhGkH;
}

Read query parameter from url to do a nginx redirect

I have two source URL format and want to redirect both url based on
color variant to the destination link with the parameter appended.
Scenario1: www.example.com/pages?abc=123&color=white which should redirect to www.example.com/variant1?abc=123&color=white
Scenario2: www.example.com/pages?abc=456&color=red which should redirect to www.example.com/variant2?abc=456&color=red
I have tried with below , it works for one but not for both as its specific. Not able find the solution for both cases, as else doesnt work
location = /pages {
if ($args ~* "&color=white”) {
rewrite ^.*$ /variant1 redirect;
} }
While it is possible to do this in Nginx, it'll defeat some of the advantages that Nginx provides. If you can, it's better to do it within your application code or Lua.
If you choose to go forward with if statements, you'll want to match against individual $arg_* variables rather than $args. In particular, you'll want to use $arg_color, which will contains the color querystring value.
location = /pages {
if ($arg_color = "white") { return 301 /variant1$is_args$args; }
if ($arg_color = "red") { return 301 /variant2$is_args$args; }
# If we get to this point, there was no match. You have to keep
# this very simple and can only use directives documented as being
# compatible with `if`, or you'll get all sorts of crazy bugs and
# crashes.
return 404.
}

Nginx rewtire question mark

I use Windows 7 for developing web sites. Now I have a problem on rewrite an url. Try to change a question mark to an underscore, but nothings seems to work.
location /site/ {
rewrite "^skript.php([?]{1})(.*)$" skript.php_$2;
}
Url should be "skript.php_$args.
Solution needed.
The ? is the delimiter for the query string. The rewrite and location directives use a normalised URI which already has the query string removed and placed into $args.
There are a number of ways to append _$args to the URI, depending on what you are trying to achieve. For example:
location = /foo.php {
rewrite ^ $uri_$args?;
}
Or:
location = /foo.php {
return 301 $uri_$args;
}
Or:
rewrite ^/foo.php$ $uri_$args?;
See this and this for details.

nginx rewrite file name on secure connection

How can I rewrite the file name on https in nginx configuration?
for example I have
/public/abc.html
/public/abc-s.html
but I want user who access https://mydomain/abc.html load abc-s.html, while http://mydomain/abc-s.html load abc.html.
thx
This can be done by a series of regular expressions; example:
set $hasdashs u; # if we don't match .html we don't want to do a rewrite
if ($uri ~* "^(.*)\.html$") { # are we looking at a .html page? If so, get the base name
set $hasdashs n;
set $shorturi "$1";
}
if ($uri ~ "^(.*)-s\.html$") { # are we looking at a secure page? Get the base name without -s
set $hasdashs y;
set $shorturi "$1";
}
set $schemecheck "$scheme$hasdashs";
if ($schemecheck = "httpy") { #we're using http and looking at a secure page
rewrite . "${shorturi}.html" redirect;
}
if ($schemecheck = "httpsn") { #we're using https and looking at an insecure page
rewrite . "${shorturi}-s.html" redirect;
}
Note that this has to be in the server block and not the location block of the configuration. Tested on NGINX 1.2.1.

Resources