I want to create footer links inside my master page, and I was wondering what's the best approach to achieve this, do I create a SharePoint List to store my lists and embed it as a list and change its look using JSLink?

What are the pros and cons about this approach? Or do I use server side code and use caching to create this section? Any recommendations?


I would go for a User control with server side code. The UC can read from a list you (or the user control itself) creates and then create HTML from that result. You can then style the HTML with CSS if needed

I would use HttpCache or similar to cache the final HTML for as long time as you think is viable for your use case (note that an IISRESET will clear the cache) to get great performance and low stress on the server.

The user control can then be added to the master page directly or through a delegate control depending on wether or not you have a custom master page.

| improve this answer | |
  • Is there a way to cache results using client side if I want to go with JS? – Brittany Rutherford Jan 5 '15 at 20:15
  • Caching client side will only be cached per user / browser so it will not be as effective. If you still want to pursue that road you should take a look at local storage in the browser smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it – Robert Lindgren Jan 5 '15 at 20:19
  • 1
    @John-M, it would be good if you can add some of those half-dozen ways as an answer for general benefit of the SP community. – Nadeem Yousuf-AIS Jan 6 '15 at 5:50
  • 1
    I'm unsure which part of any of the other solutions you suggest would be 'un-cached?' Either they are a static resource file (which is cached client and server side), integrated as part of the page result (cached normally), or a the result of a query which is cached in SharePoint's object cache. You could make the argument about extra HTTP requests for service calls or concurrent request limitations, but those aren't really caching issues -- I'll post some of the other techniques when I have some time today/tomorrow – John-M Jan 6 '15 at 13:53
  • 1
    @BrittanyRutherford I mean ASP.NET (which SharePoint is built on) automatically handles a lot of caching details for you at the application level, which includes caching the results of page outputs. SharePoint also has a couple caching tricks of its own for things like list contents, query results, and even binary information (such as files) if you have enabled BLOB caching. I'll add some more info and a reference on this in my answer. – John-M Jan 7 '15 at 21:37

As I suggested in a comment to another answer, there are numerous ways to accomplish this that don't involve deploying server-side code into SharePoint. Here are a few that I could think of, I may have left some out; each have some advantages and possible challenges.

TL;DR: Use the JavaScript injection pattern (especially with SharePoint Online - -- this is the current Microsoft Patterns and Practices team recommendation) unless you need to do heavy re-branding in addition to adding footer information -- in which case I recommend customizing an existing SharePoint master page or creating your own. Just remember the custom master page route involves some expense in up-front and future effort on your part.

Edit: Chris O'Brien recently published a timely and more thorough blog post about customization issues in general (since they have been evolving over the past couple of years) over on his blog that does a fantastic job of explaining some of these choices while discussing the decisions the SharePoint team have been making as well as those that developers and designers should be making: http://www.sharepointnutsandbolts.com/2015/01/custom-master-pages-and-web-templates-in-office-365--thoughts.html

Now for the details of some various approaches:

1. JavaScript Injection

How it works: Create JavaScript that injects your footer markup and any other supporting styles onto a page. Use an App or solution to deploy the JS asset programmatically to the host web using CSOM/JSOM, then add the script to the site's custom actions so that it runs on each page load. See a rundown on this technique from Andrew Connell here: http://channel9.msdn.com/Blogs/Office-365-Dev/JavaScript-injection-in-SharePoint-Online-Office-365-Developer-Patterns-and-Practices


  • Leaves master pages unmodified, which allows updates from CUs (on premise) or update releases (SharePoint Online) to be applied to your site as soon as they're published by Microsoft
  • Possible to implement as a SharePoint Hosted or Provider Hosted App
  • Possible to alter built-in UI elements like the ribbon or Status notifications
  • Single JS source file
  • This technique is the current Office Dev Patterns and Practices (PnP) recommended guidance for branding and page customization


  • Relies on page markup that you may not have direct control over

  • More complex to setup and update than other solutions

  • Updating content inserted this way requires an update to the source script (some dev/designer intervention needed) Possible to implement a service call to pull the information from a list or file source in a library; this introduces another HTTP Request into the process (disadvantage) but would allow for simplified editing by end/power users (advantage) and allow the page to render and become usable before all the content was retrieved from the server since standard JS data retrieval methods do not block the UI thread (advantage)

2. Modified SharePoint Master Page / Page Layouts

How it works: Use seattle.master or oslo.master master pages as a starting point and make modifications to copies of them to suite your specific branding/content needs (you should not modify these master pages directly). Upload your version of the master page to your site collections. Reference this page as the master that should be used in your site settings. For more information, I suggest: "Master pages, the Master Page Gallery, and page layouts in SharePoint 2013" on MSDN; SharePoint 2013 Branding and User Interface Design by Randy Drisgill, John Ross and Paul Stubbs; and Pro SharePoint 2013 Branding and Responsive Web Development By Eric Overfield , Rita Zhang , Oscar Medina , Kanwal Khipple


  • Relatively simple to implement
  • Greater degree of control over markup, content, and styling


  • Breaks inheritance from the built-in master pages; updated functionality added by Microsoft will not automatically be applied to your sites when SharePoint is updated
  • Requires uploading to and configuring each site collection individually (or requires you to implement a solution that does this in some automated way, perhaps with PowerShell and/or CSOM)
  • Content update requires updating EACH version of the master page you are using throughout your deployment (also possible to implement a JS solution in conjunction with the master page that pulls the data from a list somewhere, this provides the same advantages and disadvantages as noted for JavaScript Injection updating). Possible to solve this issue by using cross site publishing features new to SharePoint 2013, but requires you to set this up. Also possible to mitigate this problem by deploying a farm solution and placing the master page in the server file system, but this introduces many other problems...

3. Custom Master Page / Page Layouts

How it works: There are some options in how to approach this, but typically you would start by making a regular HTML page that looks like you want, then convert your HTML file into a SharePoint Master page then proceed as in the edited master page description. See all of the resources listed for customizing the built-in master pages for way more information from people who know a lot more about this than I do!


  • Greatest control over structure, style, and content

Disadvantages: Same as disadvantages for "Modified SharePoint Master Page / Page Layouts" but with added complexity of building the entire design yourself.

4. Content Editor WebPart with External Source

How it works: Create a text or HTML file that includes all of the markup you want to place in your footer area. Add a Content Editor Web Part to each page where you want the footer to appear and reference your text or HTML file as the content source. You'll need to include appropriate styles with the content (in a <style> tag, for example) or somewhere in your own CSS style sheets.


  • Simplest solution to implement for small number of site pages or single portal pages
  • Single source file to update if changes are needed
  • Possible to combine with JavaScript to dynamically pull values from other SharePoint lists (although this has consequences, see disadvantages section under JavaScript injection)


  • Pretty awful for large-scale deployment. Content editor needs to be added to each page with its source set to the referenced file; possible to mitigate this using CSOM/PowerShell solution but you would need to set this up.

5. Content Editor / Script Editor WebPart with inline Source

How it works: Insert a Content or Script Editor WebPart on each page you need your footer information to display. Instead of defining an external source (as in the previous example) define the markup/script contents directly in the web part source via the web part editor dialog.


  • Simple to implement


  • Terrible for large-scale deployment: each content/script editor needs to be modified individually -- possible to automate this using CSOM/PowerShell but you would need to implement this.

6. Themes / Composed Looks

How it works: Allows you to specify a custom master page and color scheme that an end user can apply to their site and customize under "Site Settings" > "Change the look" (see this Office how-to article for more information). Setup is a bit laborious, so I will just provide a link to the relevant MSDN documentation on the subject.


  • Provides a high degree of control because you are defining your own master page (see advantages for customized master pages)
  • Allows end user site admins to configure and preview the changes to their site, as well as combine different color scheme (theme) combinations with different master pages

Disadvantages: There are a number of disadvantages that are well-covered by Heather Solomon at http://blog.sharepointexperience.com/2013/05/when-to-use-a-sharepoint-2013-composed-look/ as well as better instructions than I have given for how to set this all up. To summarize: the changes they make are difficult to manage in large environments, users are allowed to specify their own background images and color schemes (problem for many designers out there), the solutions are difficult to debug, and you need to re-create your master page design to generate the .preview files but there are enough differences in the formatting and component use to make this a chore (you need to almost repeat yourself... but not almost enough to copy and paste...).

A note on caching and performance: SharePoint is an ASP.NET application under the covers, and ASP.NET in general and SharePoint specifically have a number of tricks for caching the results of most outputs, to include: page outputs, list contents, query results, and large amounts of binary information (such as videos and other file types -- note binary large object (or BLOB) caching is not enabled by default, it must be turned on by the farm admistrator). You can find a MUCH more thorough explanation of the caching options within SharePoint over at Microsoft's Technet site; here is a particularly good article on the subject. These settings cannot be as fine tuned as something like a farm solution using the server-side object model, but they do offer a mature, well-tuned solution that applies to your entire farm and will suffice for the vast majority of content your SharePoint installation delivers.

The reason I mention any of this is to clarify that SharePoint already has many mechanisms for improving performance through caching; it's not really required that you implement a farm solution to have a performant solution when it comes to customization.

I would also add that performance and the perception of performance are two different things. A web page that waits for a bunch of webparts to render on the server will typically be percieved as having much worse performance than a page that makes a bunch of AJAX calls to load the content without blocking the UI, even though the page using AJAX may actually have taken a longer time to complete its work.

Something important to remember for any solution involving JavaScript; you need to remember to make sure your script can handle Minimal Download Strategy (MDS) environments -- this adds a bit to the complexity of the solution, but does greatly enhance the overall experience for 2013 and SP Online sites.

I'm certain I've left out many of the problems and possible mitigating techniques to use for each approach, feel free to add to those that you notice.

| improve this answer | |
  • What if I use content editor web part embedded in the master page linked to html file? – Brittany Rutherford Jan 7 '15 at 20:28
  • That would work - it would allow you to make sure all of your pages had a reference to the information but allow someone to change it easily in the source file. That's another thing worth noting, many of the techniques can be combined to create different hybrids of the answers I listed above. – John-M Jan 7 '15 at 21:20

Since you are using SharePoint 2013, you can either use JSOM or REST API to read the data.

This is happening on the client side, and it will be easier to add it to respective DOM elements (or create new elements).

JSLink is a good option, but implementation will take more time. I prefer REST as it's much easier to implement and performs better.

| improve this answer | |
  • But won't it make unnecessary calls to get the items in the footer, they won't be changed that much, maybe never, so why making the call each time the page is refreshed? – Brittany Rutherford Jan 5 '15 at 18:23
  • Even if you use JSLink the same thing will happen. I don't think there will any performance impact. I have used this approach on multiple projects and no issues so far. – Amal Hashim Jan 5 '15 at 18:25
  • Yep, but I mean won't using server side code to be able to use caching be better? – Brittany Rutherford Jan 5 '15 at 18:30
  • 1
    @BrittanyRutherford Yes using ServerSide you can read only once and then use HTTPCache going forward. But this require serverside coding and as you know Microsoft is discouraging those. Also styling the footer using server side controls will be tricky. – Amal Hashim Jan 5 '15 at 18:32
  • 1
    On premise there should be no problem using server side code for this scenario (sure if you want to push it, write a provider hosted app with a custom action injecting the resulting HTML, it would allow you to cache but will be a heavier and more complex solution). I also se no reason why it would be harder to style it if we are using serverside controls instead of REST? The resulting output could very well be exactly the same – Robert Lindgren Jan 5 '15 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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