SharePoint 2013 - JavaScript & jQuery big booboo to watch out for.

Posted on 5/3/2013 @ 4:22 AM in #SharePoint by | Feedback | 9311 views

So everyone likes jQuery right? Even Microsoft likes it, even the SharePoint team likes it.
Unfortunately, 99.999% of the code you see out there using jQuery makes a big huge mistake. And that is, to load the $ variable in the global namespace.

This can cause issues especially as newer versions of jQuery are released. Many of these changes are breaking changes. Why is this a problem, because lets say in a SharePoint project, your designers used jQuery 1.9, and your app uses jQuery 2.0, you are at risk in all of the following breaking changes… (I’ll see you at the end) ..

Ajax

Attributes

Build

Core

Css

Deferred

Effects

Event

Manipulation

Selector

Support

Traversing

Now, the jQuery foundation guys, they do a pretty good job at documenting these changes, telling you workarounds, and even informing you way ahead of time. Hell, they even create a jQuery migrate plugin for you. So quit complaining.

Where this becomes an issue however, is when previously written code, now frozen, heavily in use – uses the bad practice of generating and using a global $ variable. Let me tell you why this causes an issue.. and this is just one isolated example.

In SharePoint 2013, there is a file called AssetPickers.js. It resides in 15\template\layouts. But a backwards compatible version also lives in 14\Template\Layouts\1033. This file in SharePoint 2010 had no issues, it wasn’t doing anything with the $ variable. But in SharePoint 2013, it overrides the global $ variable as below,

var a=document.createElement("div");a.innerHTML=c;b.appendChild(a)}function $(){a:;

Oh WTF! So what does this mean? This means, if you’re using jQuery in your page, it will break everything that uses AssetPickers.js.

So what uses AssetPickers.js? Apparently a tonne of publishing features. Basic stuff like Insert Picture from SharePoint in the ribbon will break. The following JavaScript files use AssetPickers.js,

  1. SP.UI.Pub.Ribbon.js
  2. SP.UI.RTE.PUBLISHING.js

So what is the workaround? You might think, I’ll just run my sites in 14 compatibility mode. Unfortunately, what I found is that, even if you run your site in 14 compatibility mode, you’re still loading the 15 hive’s AssetPickers.js.

End result: If you’re using jQuery in a publishing site, and you upgrade to 2013 – some basic stuff in publishing ribbon is going to break, even if you stay in 14 compatibility mode.

Now what is shocking however, is that all the App project templates use .debug versions of SharePoint JavaScript files, and override the global $ variable. Hmm… see!! This is why I don’t like the OOTB project templates. (This is all in my book BTW, planet of the apps)

So what is the solution?

a) Never override the global $ variable, use code as shown below,

   1:  var $j = jQuery.noConflict();
   2:  $j('yourselector') ..

Not my preferred approach since you have to edit/fix your code all over the place! So, my preferred approach is,

b) Use that $j variable in it’s own scope and refer to it using the usual $ variable.

   1:  var $j = jQuery.noConflict(true);
   2:  (function ($) {
   3:      // put your code here
   4:  }($j));

So are you using jQuery in a publishing site today? Is the $ variable in the global namespace? Are you looking forward to upgrading it? I wouldn’t be! :-) .. I’d recommend applying the fix I mentioned above ASAP!

Enjoy!

Sound off but keep it civil:

Older comments..