Closed AKrasheninnikov closed 9 years ago
I overlooked it, sorry. Then I can only suggest using window.location.origin as a simplification of
4185 // The SharePoint variables only give us a relative path. to match the result from WebUrlFromPageUrl, we need to add the protocol, host, and (if present) port. 4186 var siteRoot = location.protocol + "//" + location.host + (location.port !== "" ? location.port : "");
Hi Alexey... Good to see you contributing. :+1:
The use of window.location.origin
unfortunately is not yet well supported by browsers, so it would not work well at this time. For now, I still see Marc's approach as the best solution.
Hi Paul. I don't think that page has accurate up to date information. Latest IE, Opera 15+, FF and Chrome all support the property. Just verified. http://www.w3schools.com/jsref/prop_loc_origin.asp also states that it's not supported in IE, but it's also outdated. See http://msdn.microsoft.com/en-us/library/ie/dn760719(v=vs.85).aspx and give it a try. You can always screen it for older browsers.
URLUtils.origin is not exactly the same as window.location.origin, is it?
I'm pretty sure it is... the MDN docs reference that the Document/Window.location object return a Location interface - here: https://developer.mozilla.org/en-US/docs/Web/API/Location - which they refer to a URLUtils...
Also, I took at look at http://www.w3schools.com/jsref/prop_loc_origin.asp and It states its not supported by IE, although I just tried it in IE11 and it works... so we're talking older browsers versions...
Paul T
On Sat, Dec 6, 2014 at 4:09 PM, AKrasheninnikov notifications@github.com wrote:
URLUtils.origin is not exactly the same as window.location.origin, is it?
— Reply to this email directly or view it on GitHub https://github.com/sympmarc/SPServices/pull/4#issuecomment-65914021.
Right. Older browsers still need this concatenation, but only if location.origin is undefined.
F12 says IE 10 doesn't support it, but IE 11 does.
For stuff like this I try to stay compliant with IE8. There are still a lot of people using it with SharePoint. Besides, having a test to see if origin exists probably negates the benefit of using it here.
M.
Thanks for the idea here. I actually have a function that I call right at the top of SPServices called SPServicesContext that contains similar logic. By the time we get to SPGetCurrentSite, the currentContext ought to be set. Are you seeing that isn't the case?