3

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.

Improve this question

2 Answers 2

Reset to default
5

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"

Improve this answer
3
  • Hey, totally forgot about that construct. I'll give it a whirl and check 'answered' if it works.
    – bkwdesign
    Dec 10, 2012 at 17:11
  • Took me a while to understand how Visual Studio interacts with solutions when I try to deploy them to a site collection that is not on the root. Nevertheless, you were indeed correct. The ~SiteCollection token did indeed expand exactly as desired. Thanks! - Marked 'Answered'
    – bkwdesign
    Dec 10, 2012 at 19:59
  • Just wondering: what happens if you just put ScriptSrc="Style Library/mySolution/custom.js" without the "/" in front? Would it look for the file in the curent web's Style Library or would it look for it in the _layouts/Style Library? I read on a blog that by default it always prepends "/_layouts/" to the path. If you already tried this out, maybe, could you tell me please what would be the result ?
    – Norbert
    Dec 10, 2012 at 22:59
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!

Improve this answer
3
  • Thanks for the response. When I formerly worked at a global company of 110,000 users, I would've been aligned w/your mindset expressed above. My current scenario is a company of 80 users in one office with 5 I.T. staff, of which I am the sole SharePoint guy. Initially my custom app was deployed to the main site collection. Refactoring has me thinking it should be split off onto a separate isolation boundary (site collection) just to keep it from interfering with our main intranet when I perform maintenance on the specialized solution.
    – bkwdesign
    Dec 10, 2012 at 17:06
  • The site is sufficiently complex enough that all possible use cases won't be known until after I deploy. They'll call me saying something isn't working and I don't want to have to login to the server's 14 hive to fix a script in the _layouts folder. Yes, it'll be up to me to ensure whatever patches I put into a Style Library/xx.js file get back into our code repository. Not acceptable for some folks, but just fine for our department. :)
    – bkwdesign
    Dec 10, 2012 at 17:10
  • Yes, I see what you mean. And you are right. For this size of the project it doesn't worth complicating you're life with the 14 hive. Everything depends when it comes to Sharepoint. :-)
    – Norbert
    Dec 10, 2012 at 22:37

Your Answer

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

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