1

Hi I'm a bit of a newby to Sharepoint!

I have created a masterpage based on nightandday and added some jQuery code that successfully does some simple link hiding/revealing as part of a menu structure and everything works fine for me. However, when a 'read restricted' user logs in, the jQuery doesn't work - in fact, when looking at the page source in the browser, the code that links the jquery.min.js file is not present and the $(document).ready(function() { etc.. code is also absent.

They are both definitely using the same masterpage as the link for my custom css is present in both.

I'd be hugely greatful if anyone has any ideas as to what I need to do to correct this ?

Rab

Improve this question
2
  • It could help to know which method you use to add jQuery to the masterpage. There are so many ways to do it...
    – Christophe
    Commented Sep 24, 2011 at 5:47
  • Hi, I add jQuery using '<SharePoint:ScriptLink name="/_layouts/1033/styles/ZZZ/jquery.min.js" runat="server"/>' underneath the line '<SharePoint:ScriptLink name="init.js" runat="server"/>'. The css file is in the same folder and it is loaded regardless of who is logged in.
    – Rab
    Commented Sep 28, 2011 at 9:06

3 Answers 3

Reset to default
3

I typically include jQuery (and sometimes SPServices) in my actual branding solution. I consider it one of those core components that I typically make available throughout the entire environment by way of the master page.

I'll generally use my branding feature to deploy minified jQuery to the 14 hive, and load it in the head of my master page. If I have jQuery script that will be executed throughout the entire environment or common between multiple master pages, I'll typically break that script out into my own .js file and load that in the master page (after jQuery). This makes the maintenance of such scripts a little cleaner since they're no longer embedded in the master page (and eliminates duplicate script in some scenarios).

Many people will deploy jQuery to the Style Library, and while there's technically nothing wrong with that, I tend to prefer deployment to the 14 hive. This makes version management a little easier, and also ensures that your users only cache jQuery once. If you're storing the source in every site collection's Style Library, your users may be caching the same file multiple times since it has more than one path.

As for your specific question about users not seeing it, I concur with Eric's suggestions. Make sure that your jQuery library is checked in, and available to everyone (if it's not in the 14 hive), and make sure that your master pages are approved; it sounds to me like a simple case of something not being accessible by your users.

You can also verify some of this using an analysis tool like those in Google Chrome, or even Fiddler (though Fiddler may be a bit overkill), to validate that the jQuery source is being called and not throwing a 404, 403, or some other error.

Improve this answer
2
  • Thanks for this advice on js location, I will go back to my current structure and make changes as it makes more sense to do it the way you describe. And yes 'mea culpa' it was an 'unapproved' master page that caused the problem.
    – Rab
    Commented Sep 28, 2011 at 9:35
  • Awesome, glad you've got it resolved.
    – webdes03
    Commented Sep 28, 2011 at 13:33
2

Ensure those users have access to where the jQuery library is located. Also make sure the master page is checked in, published as a major version and approved.

Improve this answer
1
  • Of course! Doh, how stupid am I ? Master page wasn't approved so me and other 'admins' could see it, but muggles (is it PC to say that?) couldn't. Thanks for that. Rab
    – Rab
    Commented Sep 28, 2011 at 9:29
1

A colleague of mine wrote this blog post about integrating jQuery in SharePoint. The post has you add it to the master page by way of a feature/delegate control which allows you to 'turn off' jQuery on certain sites, if necessary.

Once it's been added to the master page, you can reference it anywhere on the page.

Improve this answer
9
  • While this certainly is an option, it's not the way I'd recommend doing it. If you have added jQuery script to a particular page and the feature is deactivated, it will obviously break that script, and particularly with 2010, could cause the OOTB JavaScript to fail to render/execute correctly thus breaking the ribbon and other core functionality.
    – webdes03
    Commented Sep 23, 2011 at 19:48
  • What's to stop someone from going in and removing the reference from the master page? That will break any existing content also. The feature provides a much simpler way of adding the reference rather than opening SPD, editing the page in advanced mode, etc. This also allows it to be enabled at specific site collections/sub sites.
    – Tim Gabrhel
    Commented Sep 23, 2011 at 20:43
  • If you're editing master pages in SharePoint Designer, that's another story. Branding (masterpages, page layouts, and their dependent resources such as style sheets, script libraries and graphics) should be deployed as a compiled WSP from Visual Studio as a best practice.
    – webdes03
    Commented Sep 24, 2011 at 1:09
  • How is your solution different than what I presented then? You're deploying it out to the 14 hive, appending it to the master page and appending it to the master page with a delegate control.
    – Tim Gabrhel
    Commented Sep 24, 2011 at 15:15
  • I never use a delegate control. jQuery is available everywhere, embedded directly in the master. Nobody is going to accidentally deactivate a feature and break functionality by turning off jQuery.
    – webdes03
    Commented Sep 26, 2011 at 18:30

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.