Feb9Written by:Will
2/9/2009
I was looking through some of the Client API and Widget code tonight, and ended up finding a setting that you might find interesting.
There may be times or installations where you might want to prevent or disable the use of the new Widget feature in DotNetNuke 5. Why would you want to do that? I don't know, but you do. :)
Perhaps you don't want to allow the client-side overhead, or maybe you don't want content editors to put skin widgets into the Text/HTML Modules. In any case, you have the ability as the Portal Admin to enable and disable skin widgets per portal.
Go to your Admin Menu, and select the Site Settings page. In the Basic Settings > Appearance section, there is a simple checkbox that will be used to enable or disable the skin widgets in DotNetNuke.
Simply check or uncheck the checkbox as appropriate to enable/disable the skin widgets for the portal.
So how does it work? By default, that checkbox is checked. When it is checked, the DNN core adds the following script into the HTML markup:
~/Resources/Shared/scripts/initWidgets.js
If the checkbox is unchecked, that file is NOT added. However, one thing confuses me. There is another file there called init.js. In just looking at the code alone, it would seem that this file should be added to the markup in the place of initWidgets.js, but that is simply not happening. In turn, the DotNetNukeAjaxShared.js file is not loaded either. Hopefully, I am dead wrong. :)
Technorati Tags: DNN, DotNetNuke, DNN Blog, Widgets, 5.00.00
Copyright ©2009 Will Strohl
6 comment(s) so far...
Hey Will,
I have been searching for Tutorials and information regarding DNN widgets.
First of all thanks very much for your contributions.
I was wondering though if you would mind sharing any links know of that may provide additional information regarding DNN widgets. I am finding surprisingly little info.
Thanks
By Phil Speth on
11/17/2009 |
There are indeed few resources about the widgets. What do you want to know? I will blog about it.
By Will on
11/17/2009 |
Hi Will,
Thanks for this short article.
After compression (JS, CSS) of my site I get continuity of execution of some functions in initWidgets.js which kills my bloody Firefox :)
Did you have similar experience guys?
Kind Regards,
Jonas
By Jonas on
3/8/2010 |
@Jonas Are you using PageBlaster to compress the JS and CSS? If so, I've had different results on different sites. I generally do not compress JS with PageBlaster on any of my sites to prevent postback and other JS issues.
By Will on
3/8/2010 |
Hey Will,
It would be good if this could be done at Page Level don't you think? I have some pages that use Jquery and some pages that don't - then I could reduce the client overhead on those pages that don't use it...
I might raise that as a core feature request - what do you think?
cheers
Rodney
By Rodney on
6/9/2010 |
I think you're right. After all, we already have this indirectly exposed at the module level. It definitely would be nice to have that kind of granular control over page overhead - but I am not sure how fast an update like this will make it into a build. I'd support the idea though. :)
By Will on
6/9/2010 |