CHUVASH.eu

CHunky Universe of Vigouros Astonishing SHarepoint :)

$ in cmssitemanager.js conflicts with $ in jQuery

In SharePoint 2010 if CMSSiteManager.js library is loaded besides jQuery, then much of stuff stops working. The reason is that the dollar sign ($) is used in cmssitemanager.js as well which conflicts with jQuery. Mostly it appears on pages where you load jQuery and have an image library with thumbnails. To avoid this, just replace all $ with jQuery in your custom scripts. A more crazy situation is when avoiding $ isn’t enough. It is when you load jQuery to page head automatically on all pages. The Asset picker (AssetPortalBrowser.aspx) invokes $ itself and gets with jQuery in conflict without you write a single line of custom javascript code. You usually get the following error:

Uncaught TypeError: Cannot set property 'display' of undefined


Or in IE:

Unable to set value of the property 'display': object is null or undefined

The solution

I found a good solution in Brad Curtis’ blog. Run in your script:

jQuery.noConflict()

Brad Curtis creates an additional script file. But it is okay to have this line in your javascript file, so long you load this every time jQuery is loaded. So put this before your javascript code:

// this puts jquery into no conflict mode 
//which will remedy conflicts caused by jQuery when used
// with certan publishing features
jQuery.noConflict();
Important

If you use jQuery.noConflict, the dollar sign ($) is not available anymore! So replace all $ with jQuery. (Unless it is inside modules… another time about that…)

Update 2013-12-06

Thanks to Steve’s comment. Please consider to use closures where you pass jQuery as a parameter

(function($) {
  //do your jQuery stuff
  $(".selector").show();
}
)(jQuery);

Please, keep in mind, the $ in cmssitemanager.js has nothing to do with jQuery, unfortunately it uses the same variable name. The issue applies for SharePoint 2013, too.

About these ads

6 responses to “$ in cmssitemanager.js conflicts with $ in jQuery

  1. Steve B 2013-10-25 at 10:47

    I don’t like to use the noConflict method. This leads to confusion and is unobvious to use.

    I would suggest create a closure function that have a local $ parameter :

    this code:

    $(function(){
    $(“.someclass”).hide();
    });

    would become :

    (function($){
    $(function(){
    $(“.someclass”).hide();
    });
    })(jQuery);

    This case, there’s no conflict, because the local $ parameter is fed by the actual jQuery object.

    HTH
    steve

    • Anatoly Mironov 2013-10-29 at 07:50

      Thanks Steve! That’s correct. Today I would use a closure function for this. When I wrote this blog post for 1,5 years ago, I was quite new to javascript. Appreciate the heads up.

  2. Matthew E Cornish 2013-12-05 at 10:43

    Hi there! The issue you’re describing a fix for is causing no end of grief on our internal SharePoint site. With the solution you found from Brad Curtis — when I see the asset picker having these issues — I don’t see any other scripts using jQuery. Only cmssitemanager.js is making use of $(… stuff. Do I then need to find the cmssitemanager.js file and apply the fix within that? Many thanks!

    • Anatoly Mironov 2013-12-05 at 14:21

      Hi, you should never alter the built-in javascript files in SharePoint. What you should do is to use closures in your code, like Steve (above) says.

      • Matthew E Cornish 2013-12-05 at 14:27

        That’s cool, thanks. The closures method is a lot tidier too :) So what might you suggest I do when getting this error but do not have additional / custom jQuery code running on the page? Or must there be something I can’t see lurking in there? Would appreciate any thoughts :)

    • Steve B 2013-12-06 at 14:43

      @Matthew E Cornish: I think you misunderstood the issue. in the Sharepoint javascript file, the use of $ is not jquery, but a specific SharePoint object. And this is the root cause of the issue, because when a custom code want to use the $ alias of jQuery, it’s not jQuery, but the custom SP object. Either @Anatoly’s or mine solution will actually ensure that calls to $ will be on the jQuery object, and not the SP one.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Discovering SharePoint

And having fun doing it

Bram de Jager's SharePoint blog

My view and thoughts on SharePoint.

My programming life

and everything in between

SharePoint Development Lab by @avishnyakov

It is a good place to share some SharePoint stories and development practices.

SharePoint Dragons

Nikander & Margriet on SharePoint

The Zuul Cat Idea Brewery

Where ideas on software development and entrepreneurship brew.

Paul J. Swider

Inspire! Teach! Awe!

Mai Omar Desouki - Avid SharePointer

Egyptian & Vodafoner - Senior SharePoint Consultant

Alexander Ahrens

MCPD | SharePoint | Web Development | JavaScript | .NET

Cameron Dwyer | SharePoint, Outlook, OnePlaceMail

OnePlaceMail, SharePoint, Outlook & Life's Other Little Wonders

.:paul.tavares:.

Me and My doings!

Share SharePoint Points

By Mohit Vashishtha

Jimmy Janlén "Den Scrummande Konsulten"

Erfarenheter, synpunkter och raljerande om Scrum från Jimmy Janlén

SPJoel

SharePoint for everyone

SharePointRyan.com

Ryan Dennis is a SharePoint Solutions Architect with a passion for SharePoint and PowerShell

SharePoint 2020

The Vision for a Future of Clarity

Aharoni in Unicode, ya mama

Treacle tarts for great justice

Follow

Get every new post delivered to your Inbox.

Join 232 other followers

%d bloggers like this: