Recently there was an update to jQuery that caused some problems with DotNetNuke. The problems include:
Strange or missing popup effects in custom jQuery modules
Admin menu hiding the menu items on Standard DNN Dark Knight Skin
Modules using jQuery failing to function as desired
The problem is associated with some bugs in the jQuery released and hosted googleapis. The bugs are not related to DotNetNuke directly but the jQuery used in many instances of jQuery.
The solution is an easy one. You just need to login to your DotNetNuke website with a Host Account, and modify the jQuery settings under the HOST / ADVANCED SETTINGS to a more recent and bug free version of jQuery UI.
DotNetNuke can use jQuery to enable popup style and image rotator effects. These are great and a big improvements on technologies like flash. However it is not hard to find two separately coded jQuery modules that can cause conflicts when used on the same page as each other.
The reason in most cases is that modules can be hard coded to use their own version of jQuery. (Think of jQuery as a plugin that is required for the code to load onto the web page).
The library that powers jQuery is often updated to include new features. Earlier version of DotNetNuke did not have any ability to load jQuery or reference it as “part” of the core of DNN.
So for any module written for early DNN versions, the library plugin for jQuery needed to be included or referenced to an online source like the free Google jQuery reference.
If two module are on the same page and calling different versions of jQuery into play, it is likely that one of the modules will conflict and fail to work correctly. Often it will be the more advanced or later built module that fails.
The solution to this is to built a common core library into the core of DotNetNuke, and allow modules and other code to reference this single source when calling on the jQuery library for any reason.
DotNetNuke have included jQuery as an option in the host settings, to allow it to be loaded from there.
They run a release version of the jQuery library that is presumably updated with releases of DotNetNuke. The last version of DotNetNuke 5x shows this.
Modules can either call this library, or use their own library.
How Modules Use DNN version of jQuery or their Own version
Well developed code or modules will usually have a setting that allows you to reference the HOST DNN version of jQuery, or call into play the version that shipped with the module.
If the “Load jQuery” is ticked, the module will use the jQuery library that is shipped with the module.
If the option is not ticked, the module will use the DotNetNuke included version of jQuery.
When conflicts occur, the best way to resolve it is to ensure that both modules are referencing the exact same jQuery library version. The easy way to do this is to ensure that both modules are NOT using their own version, or in our case “Load JQuery” is NOT CHECKED.
And, ensure that any other modules are also not referencing their own version of jQuery but are looking to the hosted jQuery. (Talk to the module developer on how to do this.)
Other Possible Problems
1. One of the modules may require a feature that is more advanced than the the hosted jQuery version. In this case, a later jQuery library will need to be referenced. To allow this to be done, DotNetNuke have allowed you to reference a URL for another version of jQuery.
For example, in our Mushroom Image module for DotNetNuke, the rotator effect requires a later version of jQuery than the last version of DotNetNuke 5x references. 1.4.4. To set a later version, you simply find an online resource like this Google hosted jQuery library:
And enter that URL into your HOST jQuery settings.
2. Another issue is that there may be a conflict in the jQuery script used to call the module actions. We have included the ability to customize the script used to reduce conflict.
Naturally this is an option for advanced users, and not all modules have this feature.
What is the Take Home Message?
When a conflict occurs, there is usually no “developer” at fault, but rather an incompatibility between the ways that the jQuery is being called. Don’t assume that the last module installed is to blame.
In most cases the conflicts can be resolved using the steps outlined above. This assumes that the modules installed have similar flexibility as we do in our modules.
We have been working to improve the UI of our dnn modules in recent times. This has included extensive updates to the backend administrator management. We have struggled for a long time to find a solution that actually works well for us and well for our clients.
The problem has always been the fragmentation of web technologies and browsers. Browser brands, versions, libraries, server technologies, uptake of new technologies like Silverlight etc has all been issues for us.
It’s one thing for us to develop a great solution, only to find that others struggle to have it implemented correctly. Silverlight is a classic example of this. Versions of SL and operating systems like mac vs pc really make a difference.
What we came up with
JQuery was the solution. Now that DotNetNuke had the core library built into the CMS, we are able to use it and find that most people have little or no trouble with it. We even managed to upgrade or template management system to use the new JQuery based UI. This makes the loading of the template management pages very fast.