read more..
DotNetNuke 5 refers to modules as extensions. There are two types of module extensions:
We will look at third party installs only here.
Adding third Party Modules
There is a great video here that explains it:
Once you have installed the Mushroom Image module, you will need to ensure your site is ready to host jQuery. DotNetNuke makes this easy, but there is one small change we recommend first.
1. Login as Host
2. Go to HOST SETTINGS and locate the jQuery settings:
3. Tick the option for “Use Hosted jQuery Version”
4. In the Hosted jQuery URL, type: http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
DotNetNuke currently runs with jQuery version installed. That is to say that DNN have included some jQuery files that will sit on your web server and ensure that jQuery works on your site. The only problem is that at the time of writing this, the included jQuery version is not up to date enough to take advantage of some of the recent features of jQuery that Mushroom Image takes advantage of.
The Rotate Effect http://www.interactivewebs.com/mushroom-image/Demo/RotateEffect.aspx
uses a later version of jQuery than the one currently included in DNN that is 1.4.2.
Using the hosted jQuery option takes advantage of some open source Google hosted jQuery that is a later version than the 1.4.2. For our module, you currently need 1.4.3 or later.
As with any DotNetNuke module, you need to add the module to the page before you can configure it.
Login to your DotNetNuke website as either a host or admin, and proceed to the module menu at the top of your website page.
Select “iwebs – MushroomImage” from the module list and “Add Module To Page”
Then look for the module in it’s configured state.
From the dropdown menu, select the Configure Module option:
To reveal this:
This is the source that the module will connect to to pull images from. You can use Flickr, RSS, or Local Folder.
Flickr – Will pull images directly from a Flickr Image Set e.g. http://www.flickr.com/photos/45764413@N00/sets/
RSS – Will pull the first image from each unique post in an RSS source. e.g. http://www.interactivewebs.com/blog/index.php/category/dnn-module/feed/
Local Folder – Will use images with a selected folder to display as images. This folder must be part of your DotNetNuke website.
Google Picasa – Will pull images from a Google Picasa source, using the images in the module.
You can define the image types to be used in the module. For example if you pointed the Image source at a local folder that had a mixture of image types in it, then the Filter can be used to only use one type “.jpg” for example.
Defines the number of images that will be used from a feed source. So for example if your RSS source includes a large number of items, you can limit it to show only the last x number.
Defines the Pixel Size of the thumb nails to be used. It should be noted that not all templates will use the thumbnail size. For example the “Light Box Effect” does use the thumbnail size, while the “Shutter Effect” does not.
Thumbnails used
No Thumbnails used
In most cases, the thumbnail feature is only for templates that employ a popup effect.
This is the size that the image will be displayed on the page. We have intentionally left this variable to allow you to adjust to fit the images you use. If you use the HTML5 Template for example, then the amount of white space around the displayed image is dependent on how closely the defined image size matched your original images.
To improve page load time, we wanted to ensure that the web server with your dotnetnuke site on it does not need to run off to your image source each time the page is hit and reload the images. If you imagine a slow RSS as the source, then this could cause the page load time to be considerable.
To fix this we allow the module to cache images locally on the server, there by improving page load time.
In this setting you can define the length of time before the web server will run off and update the feed. The time you define here should be reliant to the type of images you want to feed. If you feed op to the minute news images, and you set this to cache for a week, then visitors to your site will see images that are out of date.
On the other hand, if you expect the feed source not to change, then set a high value here to reduce server load time.
If you reboot the server or restart IIS, then the module will run off and update the source the first time the module is loaded.
This is where you pick how your images will be shown on the page. The display templates define the end user look and feel.
There are several buttons that appear under the Display Templates Tab.
Used to select a predefined or saved template. If you want a look like the Light Box effect, then you can click on the Light Box template from the available templates:
Then select the “Select” button.
This will cause the HTML and CSS for this template to be loaded into the “Display Template”
You can reveal the code for this by clicking the Source View from the HTML Editor.
You can edit or improve the source code to match the colours you use on your site.
When you are done editing, you select the Save Tab Changes, or Save & Return to save the template and return to the page.
If you play around and don’t wish to save, the Cancel & Return can be used to exit without saving your selection or changes.
Allows a template to be packaged and saved as a .zip file. This file can the be used and imported on other sites using the Mushroom Image module.
This is perfect if you want to modify then export a template that you have customized for your own use.
The package includes a Thumbnail.png file that can be modified to reflect the look of your customized template. A Screen capture for example. Use the same dimensions as the example png file.
Naturally you can save a local copy of your favourite templates for used on sites that you create.
Used to import templates that you have exported elsewhere. Selecting the Import, then locating your .zip package that you previously exported. Then uploading into the site for use.
Once imported, your template will become available across all portals on the site.
If you modify a template and wish to save directly to the site for use as a custom template, then you can click the Save Template button.
We have included some icons to allow you to associate an eye catching icon with your custom version, or you can upload a screen capture to associated with the saved template.
To assist you in “Undoing a Mistake” we have enabled versions of the templates. This way you can play with a template, and if you make a change that is for the worse, you can easily revert to an earlier version.
Great Hey!
These templates are used for the loading effect in the website while the module loads content. This is only used while the module pulls down source content, and if the source is cached, you will not see the loading template effect.
If you examine the source view of the loading template, you will notice that the effect references a .gif file. This file is a motion .gif and can be swapped out for any loading .gif image you like.
Google Picasa has the ability to enter a description for an image. That description text is usually an explanation of what the image is about.
We have the ability to access this description text of images using the token: ${item.description} within the template.
To make this easy, we have added a second template to the templates within this module, using the same name but with “Desc” in the name.
Where The – Dec versions of the templates like the Light box-Desc will display the description text.
The templates remain editable as usual, to those of you who are skilled with HTML, CSS etc. We just thought it would be best to include these templates to simplify the process.
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.
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.
On our modules, we use a tab setting that looks like this:
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.)
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:
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
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.
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.
If you see this error
Could Not Load file or assembly NVelocity, Version=1.1.1.0, Culture-nutral, PublicKeyToken=null (Exception from HRESULT: 0×80131040)
While using one of our DotNetNuke Modules. The solution is a simple one.
Update all of the InteractiveWebs DotNetNuke Modules to the latest builds by downloading the latest release from here: http://www.interactivewebs.com/DotNetNukeModules/ModuleDownloads.aspx
The problem stems from a change to some of the code library of some modules that share code with other modules. Updating all modules to the latest build will resolve this issue in all our modules.
InteractiveWebs DotNetNuke Modules require a license to be activates on each sub domain from which the module is accessed.
The license is per sub domain, and NOT for each instance of DotNetNuke.
A sub domain example is:
In the case of domain.com and www.domain.com, these are considered as one single license. EVERY other sub domain needs it’s own license.
If you activate a module on dev.domain.com then browse to the same module using another sub domain (like dev2.domain.com) the module will not be activate with the new sub domain in the browser URL.
Each module will automatically enter into a 100% functional TRIAL mode the first time you access the module with any particular sub domain.
The trial period is automatically set from the date you first visit the module with any particular sub domain.
If you access dev1.domain.com the module will start it’s trial period from today, and may expire if you don’t activate.
If you then use another sub domain like dev2.domain.com the module will start a new trial and you will continue to be able to access the module on that dev2.domain.com sub domain.
Note: All the settings and modifications you make to any module in trial WILL be preserved and waiting for you once you activate the module license. So if your trial expires on your development sub domain, you can simply activate the module in it’s final www.domain.com location when you are ready to go live.
We recommend that if you need to configure and test (development site) before going live, that you do that on a development sub domain (like dev.domain.com), IN TRIAL MODE.
From that dev.domain.com, Setup the module, test and be sure things are working. Don’t be concerned if you get things just right, and the trial time expires. Because as soon as you access the module page on a new sub domain, it will go back into trial, and be available fro activation.
All your module settings and customizations will carry over to the new sub domain when you access it. So in this example, if you are ready to go live with www.domain.com you can access the module page with that sub domain, and extend the trial, or activate the module.
For this reason we always suggest that you only activate your module on www.domain.com as your final public URL of your website.
Select the Licensing Dropdown Menu Item from the module Menu:
The module will tell you about the Module Name, Version Installed, sub domain you are on, and trial days remaining.
If you have not purchased a License yet, you can click the Buy Now icon and purchase a license from our site.
Note: Check that the sub domain shown in the module is the final correct sub domain you wish your license to be active on:
Click: Request License Activation
Fill in the details requested, including the store you purchase from and the email address that you used with your purchase.
Note: The email address must be the one you have on file. With SnowCovered, it is apparently possible to have more than one address on file. The address we need is the one that is in the purchase order confirmation data sent during purchase. This is the accounts primary e-mail address.
If we are unable to match the email address against a valid license activation, we return the error:
We suggest that you verify the email address used for purchase and try again with the correct address. You can also monitor your License Management on our site by logging in with the email address that you try to activate with.
With the correct details, you will receive a message like this:
You can monitor your licenses and activations by visiting our License Management page here.
Ensuring that you login to our site using the e-mail address that the license was purchased with.
We provide several Support services for our modules.
Then use the support menu to find module specific support. This will include KB Articles, Support Forums, Blog Posts.
With our DotNetNuke Image Module, the module comes with several templates. It is possible to modify any of the templates and create images and looks to suite your needs.
The original lightheads template that we use the following html for the thumbnail:
<div class="iwebs-pic " style="background: url(‘$item.image’) no-repeat scroll 50% 50% transparent;">
That means the raw image will be used as background image for the thumbnail rectangle. Since the background image will not be cropped or resized, you can only see part of the whole pic.
I You can change the template <div class="iwebs-pic " style="background: url(‘$item.imageresize‘) no-repeat scroll 50% 50% transparent;">
However, in order to keep the proportion, there will be some blank area for each thumbnail.
If you do not care about distortion of the thumbnail and want to fill the blank area any way he can use <div class="iwebs-pic " style="background: url(‘$item.thumbnail’) no-repeat scroll 50% 50% transparent;">
http://www.interactivewebs.com/mushroom-image/Demo/LightBoxEffect.aspx
Other DNN Modules