5 Things SharePoint Client Side Developers Should Stop Doing Immediately (2/5)

Posted by: Mark Rackley on February 14, 2017

…in order to prepare for Modern sites, pages, and the SharePoint mobile application.

Yesterday we talked about how Client Side Developers need to stop editing their pages in SharePoint Designer. I even had some people giving me grief on Facebook because to them it was common sense not to edit pages in SharePoint Designer. That’s the thing though, to some people these things might seem like common sense. However, I deal with people every day struggling to develop in SharePoint who ARE doing these things. They just don’t know any better, or they don’t know what they should do instead. Good thing there are helpful folks out there writing blogs and not just assuming that everyone knows better… ;)

Okay, where was I… Oh yeah… Day 2.  Today we are going to move on to the next thing Client Side Developers need to stop doing immediately in order to prepare for Modern sites, pages, and the SharePoint mobile application.

Adding script references to Master Pages

There is still no branding story for the new Site Pages and Modern Sites. You know what that means? No master pages. So, if you have been relying on editing a Master Page to get your scripts referenced or executing on a site, you’ll need to plan for a different approach. Another reason I don’t like adding script references to Master Pages is… well… because you are editing a Master Page, and any time you need to change a script or script reference that is stored in a Master Page you have to update that Master Page, publish that Master Page, and if you forget to publish that Master Page things don’t work, and you don’t know they aren’t working because everything is working great for you. It’s just not the best practice.

Instead you should…

Sandbox Solutions are not dead. I still have this argument with people from time to time (I seem to like to argue) who say you can no longer use Sandbox Solutions in SharePoint Online. That’s not true. No Code Sandbox Solutions are still supported. Chris O’Brien has a great blog post on the subject. So, what’s my point? Well, one of the things you can create as a no code Sandbox Solution is a Custom Action. Using a Custom Action you can use ScriptLinks to reference scripts in your entire Site or Site Collection. This means you don’t have to put those script references in your Master Pages.

The basic process for creating a Custom Action as a Sandbox Solution is really simple.

  1. Create a Sandbox Solution in Visual Studio
  2. Add an Empty Element
  3. Paste this XML into the Empty Element (which references jquery.min.js in your Site Collection’s Site Assets Library).

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<CustomAction

ScriptSrc="~sitecollection/SiteAssets/jquery.min.js"

Location="ScriptLink"

Sequence="100"

</CustomAction>

</Elements>

  1. Build and deploy it (don’t forget to remove the dll as explain in Chris O’Brien’s post).

Oh, and don’t forget to upload a jquery.min.js file to your Site Assets Library of your Site Collection. You can get more complex with your solution by having it also deploy your scripts to the Site Assets library, but I wanted to keep it extremely simple for this example.

You don’t even have to use a Sandbox Solution to deploy a Custom Action. There are several options actually. Check out these posts from Waldek Mastykarz and John Liu for other methods.

The big question, will Custom Actions still work on the new modern sites? Well, the functionality has obvioulsy not been rolled out to tenants as of the writing of this blog. Keep an eye out though as more and more features are rolled out. Regardless, removing script references from your master pages well help you get ready for what's coming next.

So there you have it. Stop referencing your scripts in your Master Pages. Even if you have no plans to move to the Modern Sites, there are more manageable ways of referencing those scripts. Check ‘em out!

Tomorrow we’ll talk about a painful subject (for me) and why you should stop modifying SharePoint’s default forms by injecting script.

Topics: O365, SharePoint, JavaScript

    Recent Posts

    Categories