Use jQuery in SharePoint without updating your MasterPage

Frequently I need to use jQuery in SharePoint but don’t always want to have to edit and publish a revised MasterPage to include the necessary script links that will allow me to access the jQuery libraries. This is where the ScriptLink class comes to our rescue. The ScriptLink class allows us to ‘inject’ resources into our pages without having to update the source HTML. What’s even better is we can deploy ScriptLinks via custom actions so we can use the SharePoint feature framework to affect our changes.

Here’s how I go about creating a feature that when deployed and activated will add the jQuery libraries to my site without changing any pages or MasterPages:

First, I create an new Visual Studio 2010 ‘Empty SharePoint Project’ and add to the project a new ‘Layouts’ mapped folder, to this directory I add all the jQuery (and other) resources I want to use in my site:

image

Note: I’m creating my own jQuery folder underneath the existing _layouts/inc’ folder. This is because the ‘inc’ folder is one of the few directories underneath the _layouts folder that is automatically configured for caching and anonymous access. You don’t need to create your folder underneath the existing ‘inc’ directory but you should at least be creating your own directory below the _layouts folder.

Next, I create an elements file that includes all the resources I wish to include in my pages. Each resource is added as a CustomAction with the Location attribute set to ‘ScriptLink’ and the ScriptSrc attribute set to the relative path of the resource:

image

Finally I include the elements file in a feature:

image

Now once this is deployed to my site and activated, the following script links are automatically included in the rendered HTML of the site:

image 

Now I can use jQuery on my site and I’ve had to alter or switch MasterPage – yay! Obviously deactivating the feature then removes these script links from the rendered HTML.

P.S. One other thing you can do to streamline the solution that contains this feature is to switch off the inclusion of the default assembly that Visual Studio will include with the project. As this solution contains no managed code whatsoever the assembly that gets created for us by default by Visual Studio is totally redundant. To suppress the inclusion of the default assembly in the solution (and therefore the ability to delete the class file from the solution as well), update the solution property ‘Include Assembly In Package’ to False:

 image

Enjoy!

Advertisements

9 Responses to Use jQuery in SharePoint without updating your MasterPage

  1. Hi,
    This is pretty neat way of doing this.

    Wonder if this method can be used to reference java scripts from a place like “Style Library” in case of a sandboxed solution where I can not deploy files to _layouts folder. Any thoughts?

    • briancartmel says:

      Hi Hasanga,

      The script files must be deployed somewhere under the layouts virtual directory so this rules out the style library and using this technique in sandbox solutions too.

      😦

  2. beytan says:

    Thanks for the extensive alternative. But, I wonder if it will be really used by a designer without visual studio habits; or can it be helpful to teams; or is this a proper way to be used for single click deployment scenarios?

    • briancartmel says:

      Hi Beytan,

      I find its most useful attribute is repeatability. I can take this solution from one project to the next and re-use it. I tend to then build solution dependancies between this solution and the full trust branding solutions I then create that require jQuery. It will work just fine in single click deployments but not in a sandbox..

  3. Ceej says:

    This is a neat solution. Do you think this is a better way to hook up jQuery rather than using the AdditionalPageHead delegate control? What advantages does it have?

    • briancartmel says:

      Hi Ceej,

      They are both valid solutions and provide the same results:

      • Neither require managed code
      • Using ScripLink relies on the js files being deployed somewhere below the layouts virtual directory
      • Using delegate controls requires creating an extra .ascx file

      Take your pick 😉

  4. Pingback: Metro Style SharePoint Search Results « SharePint Blog… Hic!

  5. Pingback: Track SharePoint Content Database Growth via Central Admin « SharePint Blog… Hic!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: