Site Collection Pop Quiz: _layouts vs Style Library

Question

First, let's say I have 2 site collections within a single web app at port 80:

1. Main Site Collection: /
2. Nested Site Collection: /sites/special/

So, let's say I have a module in a site-collection scoped feature, the purpose of which is to add a couple of scripts throughout a site collection (this just as easily could be deployed as scriptlink controls in a custom master page for a site collection, my question still applies):

  <CustomAction Id="script1" Location="ScriptLink" ScriptSrc="/Style%20Library/mySolution/custom1.js" />
  <CustomAction Id="script2" Location="ScriptLink" ScriptSrc="/_layouts/mySolution/custom2.js" />

Both of the above work fine as long as the feature is being activated in the main 'root' site collection. However, if I only deployed the feature to the secondary 'special' site collection (new isolation boundary, nested URL path), won't the script1 reference break?

The browser would be looking for custom1.js at the following path:

/Style Library/mySolution/custom1.js

when really the file is at

/sites/special/Style Library/mySolution/custom1.js

The second scriptlink always works, since _layouts is global, and thus the browser always finds /_layouts/mySolution/custom2.js no matter which site collection the feature was deployed into.

Correct? I guess I'm just doing a sanity check.

I am tempted by the easy access to scripts I can edit on an ad-hoc basis in the /Style Library/, but, hate the idea that such a feature (as designed above) would only work in root level site collections.

Answer 1

Try this for the first link as it is intended to address exactly what you are seeing, though certain controls do not expand the value.

<CustomAction Id="script1" Location="ScriptLink" ScriptSrc="~SiteCollection/Style%20Library/mySolution/custom1.js" />

As to whether it should be in _layouts or Style Library is a debate that has raged since the SP2007 beta in 2006 with no clear winner. The general rule is that if the file is something that can be modified by site owners then it should go in "Style Library" and if the file is something that only admins should be able to modify then it goes in _layouts. I am simplifying, of course, as there are at least a dozen differences between the two locations.

This is just another one of the places where the Official SharePoint Answer To Everything applies: "It depends"

Answer 2

Please look at the answers on this question too. It is a complex topic, with no "correct" answer. I think Chris O'Brien summed it up pretty well in his answer.

My personal opinion is, that it depends :) In your case, since you want to use the same .js file in two (or more) site collections, I would definitely put it under "_layouts".

Another question is: do you have development stages? Development-Acceptance-Production? Do you have some kind of a source control? If the answer to either of these is YES, then I would, again, definitely put it under "_layouts". Especially because it's a javascript file. Why? Because javascript also contains "code", it performs some kind of a logic, sometimes it even has business logic (hide something if some fields are filled in, validate data before submitting, etc). If all your .Net code goes through Development->Acceptance before going to production, why would the javascript code be "privileged" by going directly to production? Why shouldn't it go through the same testing phases? Of course it should.

And if you have source control and you use a module to deploy your file to a document library as "GhostableInLibrary", I think it's the beginning of a nightmare if you let people to customize it. Imagine that you deployed your file (js or css) through the module to 10 site collections. On 5 of them Site Administrators have modified the file. This means that your file is now decoupled from the version on the file system. When next you want to deploy some global changes to this file, and want it to be applied on all site collections, it will silently fail on the ones where the file has been customized. You will need first to revert those files to site definition and then your file pushed by the module will be taken into consideration. But you will loose any modification those Site Administrators have made. Or, if you want to keep some of those modifications and put it in your version on source control... You will have to take every customized file, one by one, compare them manually with the one on source control, and merge the changes. No, I think this is better to be avoided.

But you know better your Sharepoint Farm and how it is going to be used. So maybe there are some particularities in your setup that demand to put these files into the Style Library. If so, please tell me, I am curious :)

Cheers!