removal of site_name from production URL

Hi All,

I was going through LS manual, and was explaining about site_name in production URL is mandatory. But out of curiosity, I would like to understand if there is a way to actually bypass (i.e. not displaying site_name such as "en-US" or "en-AU") site_name in production URL.

To summarize:

Production URL: http://www.someURL.com/en-US/home.page

Required URL: http://www.someURL.com/home.page

It would be great if anyone can provide their valuable direction to achieve this.

Below are the environmental details:

TS: 7.2.1
LS: 7.2.1 with .NET integration
OS: Windows

Regards,
Ace

Find more posts tagged with

Comments

rohit34582

Why not have URL rewrites in a Web-Server?

acezone

Why not have URL rewrites in a Web-Server?

Rohit,

Thanks for your suggestion, but I was thinking of taking an approach where this functionality can get handled on site level. But I am not sure if client is ready to make the redirection as site is currently live and any mishap can hamper their brand image.

Any one else with their thoughts

Regards,
Ace

Rick Poulin

But I am not sure if client is ready to make the redirection as site is currently live and any mishap can hamper their brand image.

That's not a valid argument for rejecting a solution. The suggestion is a solution to your URL problem, not your client freak out problem -- which you're going to have regardless.

Handling this rewrite is the best practices way of solving this problem. You might be able to do something on the app container, depending on which one you're using, but that's still going to involve downtime and is probably even more error-prone. Option 3 is to modify LiveSite's JSP controlling the root page (the site selection dropdown) to redirect to your US homepage, but that doesn't sound supported in the least.

I'm curious what your plan is when you want to control this "at the site level". Only one locale can be at the root of the site, so what exactly did you want to control at the site level of the other sites?

acezone

That's not a valid argument for rejecting a solution. The suggestion is a solution to your URL problem, not your client freak out problem -- which you're going to have regardless.

Handling this rewrite is the best practices way of solving this problem. You might be able to do something on the app container, depending on which one you're using, but that's still going to involve downtime and is probably even more error-prone. Option 3 is to modify LiveSite's JSP controlling the root page (the site selection dropdown) to redirect to your US homepage, but that doesn't sound supported in the least.

I'm curious what your plan is when you want to control this "at the site level". Only one locale can be at the root of the site, so what exactly did you want to control at the site level of the other sites?

Poulin,

It is not that I am rejecting the solution provided by Rohit neither I am saying that it is not an appropriate solution but I was just looking forward for another approach if the experts are here to favour on same approach I think there is noway one can put steps over the suggestions provided out here in this forum.

Well, I am going to get back with client on the same and will further discuss on the matter and also need to check how comfortable clients be with this approach.

I once again would like to thank all for providing their valuable suggestions and comments.

Regards,
Ace

santosh013

Poulin,

It is not that I am rejecting the solution provided by Rohit neither I am saying that it is not an appropriate solution but I was just looking forward for another approach if the experts are here to favour on same approach I think there is noway one can put steps over the suggestions provided out here in this forum.

Well, I am going to get back with client on the same and will further discuss on the matter and also need to check how comfortable clients be with this approach.

I once again would like to thank all for providing their valuable suggestions and comments.

Regards,
Ace

Hi Ace,
I can understand your willingness to find the best solution for your case.
And I confirm from my case study/work that Rick has given you the best possible solution.
If you want some sample code to have a look into it then I can forward some codes as well as the site name for your reference.

Thanks.

acezone

Hi Ace,
I can understand your willingness to find the best solution for your case.
And I confirm from my case study/work that Rick has given you the best possible solution.
If you want some sample code to have a look into it then I can forward some codes as well as the site name for your reference.

Thanks.

Santhosh,

I agree with you. And also communicated to my clients but waiting for thier feedback on the same. Further, I would definitely like to have a look at the sample code so if you may please provide the same that would be appreciated.

Regards.
Ace

santosh013

Santhosh,

I agree with you. And also communicated to my clients but waiting for thier feedback on the same. Further, I would definitely like to have a look at the sample code so if you may please provide the same that would be appreciated.

Regards.
Ace

Hi Ace,
I sent the sample code as well as how I implemented it.
Check your inbox.

Thanks.

acezone

Hi Ace,
I sent the sample code as well as how I implemented it.
Check your inbox.

Thanks.

Replied you back. Please check

santosh013

Replied you back. Please check

Thanks Ace...

ccprofessional

What is this secret code you guys are talking about?

Regardless, it is indeed a pain that LiveSite does not have a clean solution to fix production URLs in a clean way other than with rewrites.

santosh013

What is this secret code you guys are talking about?

Regardless, it is indeed a pain that LiveSite does not have a clean solution to fix production URLs in a clean way other than with rewrites.

Hi ccprofessional,
It is nothing secret but some of my code base and there implementations which I discussed personally.
It is just a sample URL Rewrite.

Thanks.

RonaldV

Sorry,

either me or you don't quite understand the problem here:

url-management is a two-way problem:
1. output a link to a page/image/download/js/css in the proper rewritten form
2. rewrite a incoming url-request to a format that livesite understands.

Problem 2 can be solved using apache mod_rewrite or it's iis equivalent.

Problem 1 is something that the cms/html-generator (e.g livesite) should handle. Sofar I have seen nothing in livesite that properly targets this problem. Or did I miss something?

santosh013

Hi,
Here Ace is having problem in removing en-US in his URL http://www.someURL.com/en-US/home.page.

I suggested Apache URL Rewriting to remove the same.
We can write rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism for him/his cause.

Thanks.

ccprofessional

The problem is more than simply rewriting URLs with the site-name removed (en-US in your case). When you use SitePublisher's tokens in a link to another .page file it prepends the sitename at run-time.

For example your rendered .Page could have a link such as:


 link to another .page file

which really doesn't exist and requires another instance of rewrite.

So, for example /some-other.page and /site-name/some-other.page will both point to the same page - leading to SEO duplicate page penalty (there are other reasons why this is bad).

Get it?

Ranveer

Hi,

Actually I faced duplicate URL issue in my project "www.jagranjosh.com" which is live since Nov 2010. In starting days Search engine crawl duplicate links. I resolved it by by ROBOT. Since then my SEO team never complained about the duplicate links. But you have to be very careful as a minor mistake can allow search engine to crawl the other links.

regards
Ranveer Kumar
Senior Software Developer
New Delhi, India
ranveer.solr@gmail.com
+91-9810558562
-----------------------------------
http://www.jagranjosh.com
http://www.jagranpost.com

The problem is more than simply rewriting URLs with the site-name removed (en-US in your case). When you use SitePublisher's tokens in a link to another .page file it prepends the sitename at run-time.

For example your rendered .Page could have a link such as:
 link to another .page file  
which really doesn't exist and requires another instance of rewrite.

So, for example /some-other.page and /site-name/some-other.page will both point to the same page - leading to SEO duplicate page penalty (there are other reasons why this is bad).

Get it?

acezone

Hi,

Actually I faced duplicate URL issue in my project "www.jagranjosh.com" which is live since Nov 2010. In starting days Search engine crawl duplicate links. I resolved it by by ROBOT. Since then my SEO team never complained about the duplicate links. But you have to be very careful as a minor mistake can allow search engine to crawl the other links.

regards
Ranveer Kumar
Senior Software Developer
New Delhi, India
ranveer.solr@gmail.com
+91-9810558562
-----------------------------------
http://www.jagranjosh.com
http://www.jagranpost.com

Out of curiosity, I would like to understand if the url rewrite will work on preview time or within TeamSite environment? if yes, then it would be great if you may kindly provide your inputs on the same.

tec_iwov

you won't get it in the preview environment.

acezone

you won't get it in the preview environment.

Thanks for pointing this out. Hence, I am now closing this thread.

Regards,
Ace