Long ago when we started shipping jQuery resources with DotNetNuke we began offering a Host Setting which allowed you to use a HOSTED version of the jQuery resources. There are a number of benefits for using the hosted jQuery resources, of which I will mention some below, but there are also some potential disadvantages or risks to this as well.
First a quick summary of what the setting allows you to do. With DNN (specifically with DNN 6.*+) we ship both jQuery resources and the jquery.ui resources. These are javascript files that exist on the web server that hosts your DotNetNuke website. Using the HOSTED setting allows you to basically have those files distributed from a CDN (content delivery network).
Advantages to the Hosted resources
- Less bandwidth for your web server – by having the files on a CDN, (the default option is Google’s CDN) visitors to your website don’t have to download the files from your webserver, saving you bandwidth for each user.
- Potential that they are already downloaded – if a visitor to your website has accessed any other website that points to the same CDN for jQuery files they may not need to download the files again, improving the overall experience visiting your website for the first time.
- Faster download experience – because of the way browsers handle “requests” for websites, they typically can only download 5 resources from a domain at a time, if you have resources spread out on other domains, they can simultaneously download more resources at once.
- Latest resources available – Due to the way Google handles the CDN for jQuery, it is possible to load the “latest” version of the jQuery resources, without having to make changes to your website or settings, though this can also be a disadvantage.
Disadvantages to the Hosted resources
- Files change – one of the advantages, is also a disadvantage, and recently became so. If Google updates the jquery files, as they recently did with version 1.8.0, this may cause issues with a website. We’ll talk more about that later.
- Files get removed – by referencing resources on another web server, you always run the risk that those files get removed without any notice to you.
The current problem
It appears that sometime last week Google updated the latest jQuery release, moving to v1.8.0, having previously been on I believe version 1.7.2. This normally wouldn’t be a problem, but unfortunately something in the 1.8.0 release conflicts with something that DotNetNuke depends on, and people have started reporting issues with DNN installations when using the hosted version of jQuery. I personally found that my Control Panel now overlapped the top of my pages on my DNN 6.2.2 sites, where previously this overlap didn’t occur. I believe other users have seen more noticeable problems.
Fixing the problem, Protecting yourself
There are two ways to go about fixing this problem, you can choose which option you want to use.
- Turn off the hosted jQuery setting in HOST SETTINGS. This will let DNN default back to the version of jQuery that hips with that platform, I believe that would currently be v1.7.2. This will make sure that your DNN site always uses the latest shipped w/ DNN version of jQuery.
- Don’t use the generic version URL for hosted jQuery. The default url that ships with DNN for the hosted setting is http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js notice that the version there is simple 1, this basically loads up the latest release of jQuery for version 1, which as of last week (or sometime recently) is V1.8.0. You can get around this by changing the URL to be http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js which would specifically point to 1.7.2 which ships with DNN 6.2.2 (the latest DNN release). The downfall to this approach is that if the jQuery version gets updated in a future DNN release you may need to make changes to your hosted settings to see the newer version with bug fixes or other features.
The safest option would be to simply not use the hosted jQuery version, but you can definitely weigh out the costs/benefits yourselves and make your own decision.
Update: Thanks to @Hattan for the suggestion of this blog post which provides an alternative way to load the local version of jQuery if the CDN version fails to load. This won't prevent problems from changes, but would help if a CDN is unavailable.