This project has moved and is read-only. For the latest updates, please go here.

SPGetCurrentSite() fails when page URL has hash anchor (ex.:page.aspx#hashToken=value)

Oct 5, 2012 at 3:28 PM

Hi Marc...

Came across an issue with SPGetCurrentSite() utility... Looks like it is not setup to strip out any url hash information, which in some cases (mine in this case) generates invalid XML and thus the call to the server fails... Here is an example that recreates the issue:

Add the following to the end of a SP page: yoursite/page.aspx#focus=myelement&show=tab1

The problem in SPGetCurrentSite() is that it currently strips out the search params (anything after the ?), but is not accounting for an URL that has only Hash information (example above).

The code that I think needs to be modified is at line 1273:


var msg = SOAPEnvelope.header +
        "<WebUrlFromPageUrl xmlns='" + SCHEMASharePoint + "/soap/' ><pageUrl>" +
	((location.href.indexOf("?") > 0) ? location.href.substr(0, location.href.indexOf("?")) : location.href) +
	"</pageUrl></WebUrlFromPageUrl>" +


In my projects I have used something like the following to ensure I get a "pure" page url:

var pageUrl = location.href;
if ( > 0) {
    pageUrl = location.href.substr(0, location.href.indexOf(;
} else if (location.hash.length > 0) {
    pageUrl = location.href.substr(0, location.href.indexOf(location.hash));


In this most recent customization I did, I'm using the URL hash to store information (with format of key=value&key2=value2) that reflects the current state of the page, so that users can use the URL to send to others in the company, thus enabling those other users to see exactly what user 1 was seeing/referencing.



Oct 8, 2012 at 2:52 AM


Seems like a legitimate bug. However, SharePoint doesn't create URLs like your example, so I never caught it. As usual, you're using Web development tricks that aren't often seen in SharePointland. That said, what's the benefit to you of using the hash rather than a question mark?


Oct 8, 2012 at 3:19 AM
Thanks for looking at this.
The main benefit is that I can generate a page self-referencing URL as the user clicks around without refreshing the page. Those URLs can be bookmarked and when reloaded custom code on the page reads the information in the hash and processes it.

In this particular project, I have a custom webpart page that Acts as a dashboard where I show/hide different data based on user set options. As the user defines the view they are interested in, I store the options in the url hash, case the user: 1) wants to bookmark it, or 2) they want to email the link to someone.

The Hash portion of a URL can be set via JavaScript without triggering a post back. This is not possible with the search parameters portion of a URL.

I have been using the Hash portion of a URL allot more to store page data.


Sent from mobile device.
Oct 8, 2012 at 3:39 AM

See, your ingenuity is getting you in trouble again. ;+) That's consistent with what I see a lot of the infinite page (Facebook, and  lot of the young upstarts) sites doing these days. SharePoint doesn't do it even in 2013, I don't think, even with it's smart sub-page caching.

Hoever, it's certainly possible that there might be a plain old anchor in the page, even in good old SharePoint, like yoursite/page.aspx#bookmark1. I'll add it to the list for a fix.


Oct 8, 2012 at 3:40 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 8, 2012 at 2:38 PM
Thanks Marc.

Paul T