1

I have found conflicting sources on linking/referencing JavaScript to a SharePoint .HTML Masterpage in SP2013.

  1. Out of the box, SP2013 instructions from Design Manager interface are to

Use this drive to:
•Upload the HTML version of your Master Page •Upload CSS and js files and any other design assets
•Access design files for editing

Yea..... about storing JAVASCRIPT files inside a folder called MASTERPAGE GALLERY o.O - what were they thinking?

And this brings up the question - can I add sub-folders to Masterpage gallery at least to organize my files?

AND why is there still a folder called 'STYLE LIBRARY' located in the Site Root if the correct way to upload JS files is into the 'MASTERPAGE GALLERY' ??

Getting to the different ways of referencing JavaScript. It is very confusing on the correct way to do it. Here are the methods I have found:

  1. Normally the script src tag can be used to link JS files to a .html file. using something like <script type="text/JavaScript" src="custom.js"></script>

  2. The author of Professional SharePoint Development himself suggests to do it this way and gives a great tip on wrapping a CDN in MS/ME tags to prevent SP interference

  3. Adding JS through Module or Delegate Control

  4. Creating a Design Manager design package

My personal opinion is that referencing through the .HTML file has been unreliable. The JavaScript stops working for no apparent reason.

I found an excellent guide comparing the Design Manager/SP2013 way vs. the Solution Package/SP2010 way.

Which method do you use and why?

Mia
  • 163
  • 4
  • 13

3 Answers3

2

Yes Master Page gallery is the recommended location in SharePoint 2013. But one thing that I have notified with that is it always go through an authentication check, which for every SharePoint document it does. This make things slow. (Might not be much visible with the single users, but depending on the Secure Store Service and the number of users access it in production, it can give a 2,3 seconds delay)

Suddenly I figured out a way to do this. I tried with the layouts folder in the 15 hive. Given JS, and CSS files did not include any security information in my code it worked well and was relatively fast as well. This was tested on production with a low bandwidth networked location located like 100km away. But if you put these in 15 hive, site members and owners would not be able to make changes using SharePoint interface. So keep that in mind as well.

Good old style library can be used for having style files that are required for webparts and other non master page components.

Malin De Silva
  • 2,392
  • 1
  • 11
  • 21
  • great points here Malin - especially that 'Style Library' still has a use - just not with Masterpage. I didn't know this. Also a good point about placing js files in hive as being faster to load but then less accessible to edit. – Mia Aug 21 '14 at 18:34
0

There are a lot of things that go into this and there are a lot of options, that is evident by this post.

My personal best practice is reference libraries in the master page, like jQuery. Store these libraries in the layouts folder, if you have access to deploy them to the servers, otherwise I store them with javascript files that utilize the libraries.

Files that utilize the libraries I will also deploy to the layouts folder. If I can't do that, then I use the Style Library. I create a subfolder based on the site, and in here I create several subfolders, js, css, img, fonts.

All of the assets go in these folders as appropriate. Then in page layouts or custom aspx pages, I link to these files as necessary.

The important thing is consistency. Whether I can deploy to the file system or the style library, everything is structured the same.

Community
  • 1
Eric Alexander
  • 43,293
  • 10
  • 53
  • 93
  • Eric - I see your point about consistency.. but using _layouts folder for js files referenced in .html masterpage is not suggested for SP2013, it's suggested to store in 'masterpage gallery' folder - what do you make of this? – Mia Aug 21 '14 at 18:37
  • 1
    I haven't used 2013 enough to formulate an educated opinion yet. I would question why. If you have access to deploy to _layouts, you should IMO, as that means you are following a good SDLC process and porting packaged code from environment to environment. The tradeoff as Malin mentions is editability. But if you are doing _layout deploys, then edits are documented and controlled by SDLC/Change Management. – Eric Alexander Aug 21 '14 at 19:01
0

If your goal is to remain true in using SharePoint 2013 OOTB, as a front-end developer, IMO, you should store your custom Javascript and CSS files in the Style Library. Make a sub folder within that location and store your items there. You could then reference your items from your custom .htm master pages and .htm page layouts.

When you say...

"My personal opinion is that referencing through the .HTML file has been unreliable. The JavaScript stops working for no apparent reason."

...You have not provided any details/examples on what you are trying to accomplish with your JavaScript on your .HTM files. So I challenge you to break down the issue first before you explore other theories...

I wouldn't recommend diving into SharePoint Designer 2013 for your JavaScript development. If you are a front-end developer, then work on the front end with SharePoint's front-end tools. But more importantly break down your code this way people here on the forums can provide potential solutions for you.

JavaScript is a form of art, and there is more than one brush you can use to paint on your canvas.

klewis
  • 1,353
  • 5
  • 29
  • 55
  • thank you blachawk. I expanded on the issue I am having with javascript stops working here: http://sharepoint.stackexchange.com/questions/112883/masterpage-conversion-causing-javascript-errors-masterpage-breaks – Mia Aug 22 '14 at 21:56