I am working in SharePoint 2010, and using jquery to modify some display and edit forms throughout a site. To do so, I'm including a reference to the jquery library in the site's v4.master page so I can use it across multiple forms and lists. My reference looks like this:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"  type="text/javascript"></script> 

This works great for a while, but twice now this setup has suddenly stopped working. On the webpage for the end user, suddenly the scripts are not working. The console errors reveal that now "jquery is undefined".

When I "View Source" I find that my reference to jquery in the v4.master page has been altered before it made it to the client, and now looks like this:

<script src="/ajax/libs/jquery/1.10.2/jquery.min.js"  type="text/javascript"></script>

...as you see, SharePoint has stripped out the domain name "//ajax.googleapis.com" referenced here, seemingly out of the blue. Nothing was changed with the v4.master since I initially put it in, so SharePoint suddenly began outputting it differently.

The solution for me was simply to open v4.master - make NO changes (because the original URL was still fully there) - and simply save it again. Then everything was back. Almost as if I was refreshing or replacing some cached version somewhere. But why would that cached version have stripped out the domain?

I'd obviously prefer not to have to open/save this thing every month...does anyone know why SharePoint would do this at an arbitrary time, with no changes to provoke a break? Is there really a cached copy being made here? And if so, why would it cache a different copy than its been using for a month?

  • One note - a coworker of mine reminded me that I should be doing a "Check Out" - change file - "Check In" as I update this, so I will try to do that going forward. Would that make a difference in this issue? Not sure. If it was using the copy I last checked in, it should still be working, so I'm thinking this is a separate issue. But point taken that I should be doing it "properly" when changing.
    – Chad
    May 7, 2014 at 19:19

1 Answer 1


I have had situations where // would not automatically resolve. So adding the protocol 'http' or 'https' should solve your issue. I would also recommend to provide a local fallback url (layouts directory or SiteAssets) in case it fails to load from the cdn.

    <script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.2.min.js"></script>
    <script type="text/javascript">
        // Fallback  
        (window.jQuery || document.write('<script src="/_layouts/Assets/JS/jquery-1.10.2.min.js"><\/script>'));
  • Thanks Aveenav. The reason I'm using "//" is that this SharePoint site is accessible internally and externally, so it may sometimes be accessed via https and other times via http, and I wanted to flex between them if I could. My understanding is that "//" would flex with whatever is currently used for http/https. I agree that a local copy may be a way to go. That is my "Plan B" if I don't get find why this is happening. In that case, though, if I go to the trouble of a local copy and reference, I don't see a reason/benefit to still call the CDN...I'd just stay local probably.
    – Chad
    May 7, 2014 at 19:17
  • One further comment on the "//" item. I could probably just do "https" at all times and be fine, to be sure. This issue hasn't been that the reference is there and not resolving. The issue has been SharePoint actually changing/chopping the domain of the reference before it gets to the client...regardless of http/https. That's the root I'm trying to track down here.
    – Chad
    May 7, 2014 at 19:31
  • I have had similar issue with host/domain chopping off, https:// fixed it.
    – Aveenav
    May 7, 2014 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.