Skip to main content
added 402 characters in body
Source Link
Elena P
  • 631
  • 4
  • 15

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|           | 8082
http |           | 8081
https|           | 44301
https|           | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

Update: per @RichardSeal's advice I also tried to get this link via Sitecore.Links.LinkManager:

var options = LinkManager.GetDefaultUrlOptions();
options.AlwaysIncludeServerUrl = true;
var url = Sitecore.Links.LinkManager.GetItemUrl(item);

In this case I obtain a relative url, not a full url, i.e: /en/sitecore/shell/foo/home/lookbook/sales/list

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|           | 8082
http |           | 8081
https|           | 44301
https|           | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|           | 8082
http |           | 8081
https|           | 44301
https|           | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

Update: per @RichardSeal's advice I also tried to get this link via Sitecore.Links.LinkManager:

var options = LinkManager.GetDefaultUrlOptions();
options.AlwaysIncludeServerUrl = true;
var url = Sitecore.Links.LinkManager.GetItemUrl(item);

In this case I obtain a relative url, not a full url, i.e: /en/sitecore/shell/foo/home/lookbook/sales/list

edited body
Source Link
Elena P
  • 631
  • 4
  • 15

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|    foo       | 8082
http |    foo       | 8081
https|    foo       | 44301
https|    foo       | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|    foo    | 8082
http |    foo    | 8081
https|    foo    | 44301
https|    foo    | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|           | 8082
http |           | 8081
https|           | 44301
https|           | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

added 1 character in body
Source Link
Elena P
  • 631
  • 4
  • 15

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|    foo    | 8082
http|http |    foo    | 8081
https|    foo    | 44301
https|    foo    | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|    foo    | 8082
http|    foo    | 8081
https|    foo    | 44301
https|    foo    | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

I have a situation where I need to obtain a link to the item at my site to use it in an e-mail notification. I currently do it like this: var baseUrl = new Uri(Sitecore.Globals.ServerUrl);.
This method works for my local site instance, which has the following bindings:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443

I go to https://foo/, trigger my e-mail notification and the link I get in the e-mail is "https://foo/", so all is well. When debugging, Sitecore.Globals.ServerUrl contains "https://foo:443".

However, our shared sandbox site is configured to be used as https://foo.bar:44305. The bindings there are as follows:

Type | Host name | port
http |    foo    | 80 
https|    foo    | 443
https|    foo    | 8082
http |    foo    | 8081
https|    foo    | 44301
https|    foo    | 44305

and while I use https://foo.bar:44305 to trigger e-mail to be sent, I receive "https://foo.bar:8081" in my e-mails.

If I add an extra binding

<... >
https|    foo    | 40443
to my local instance, I start getting "https://foo:40443" in the e-mails while triggering them from plain https://foo.

The alternative we tried is hard-coding the link to be used in Web.config. which obviously works, but the link is not resolved dynamically, so we have to always keep this in mind to change it before deploying to production, etc.

Is there actually a way to do this properly without hard-coding or messing up the bindings? I'm also very curious why Sitecore.Globals.ServerUrl contains a seemingly random binding port.

Source Link
Elena P
  • 631
  • 4
  • 15
Loading