The DotNetNuke Advanced Login Module offers a New Slide Down Effect as seen on the Demo pages on the dnn module website here. Or see our DotNetNuke forum post here.

Some interesting and easy to use effects that are template driven and display content with the dropdown effect replacing the normal login and registration skin objects on your site.

The configuration of this mode takes only seconds to configure. With these quick Options.

Basic Settings Tab

1. Show Both – Display Mode

2. Slide Down – Mode

We saved Tab and out demo page looks like this in the back end.

Template Tab

1. Load Template

Select Grey – then press the Select Button

Save Tab Changes and we are done.

The template page looks like this:

Giving a great resulting page that looks like this:

We also put up tow examples of the Slide Down DotNetNuke login effect that are done in RED and BLUE.

DotNetNuke Slide Down Demo – Grey

DotNetNuke Slide Down Demo – Blue

DotNetNuke Slide Down Demo – Red

All are using the same skin template, but with different CSS colours defined, and different slide down templates in the Advanced Login Module.

An example of the DotNetNuke user login via way of jQuery popup effect can be seen here.

The example shows two button images defined that when pressed will give the pop-up template effect shown here.

Popup of Login

Popup of Register

The configuration of this mode is really easy to manage.

Basic Settings Tab

1. Mode = Popup

2. Show Profile as Popup

Giving a Basic Settings tab looking like this:

Template Tab

We selected the Template-gray.

Look and Feel

We loaded some .png images for the Login and Register Buttons, and set the profile form width and height.

jQuery Settings

We left as default.

That was it. This will place the module into a Pop-Up mode, allowing dotnetnuke users to register on your website with a jQuery style of popup effect.

Today we have released a new version of DotNetNuke Advanced Login Module that supports the upload of an image file as part of the user registration process. The image file or [Photo] token, takes advantage of the profile item in later releases of DNN that allow a user to attach an image of themselves during registration.

The feature is only available to DotNetNuke 5x releases, and is yet another good reason to update from DotNetNuke 4x.

To Use The Photo Token

Under the Advanced Login Module, select Templates Tab

Then “Registration Form Template” and expand the Tokens Available.

Navigate to the “Profile Field” and click to see the list of available tokens.

The new [Photo] token is available in that list.

When used in code to that looks something like this

<div class="advRegister_box"><br>
<table cellspacing="0" cellpadding="3" border="0">
    <tbody>
    </tbody>
    <tbody>
        <tr>
            <td><span class="advLogin_LabelText">Username</span></td>
            <td>[username|class=advLogin_text|tabindex=3]</td>
        </tr>
        <tr>
            <td style="padding-top: 5px;"><span class="advLogin_LabelText">Email </span></td>
            <td style="padding-top: 5px;">[email|class=advLogin_text|tabindex=4]</td>
        </tr>
        <tr>
            <td style="padding-top: 5px;"><span class="advLogin_LabelText">Password </span></td>
            <td style="padding-top: 5px;">[password|class=advLogin_text|tabindex=5]</td>
        </tr>
        <tr>
            <td width="200px" style="padding-top: 5px;"><span class="advRegister_LabelText">First Name </span></td>
            <td style="padding-top: 5px;">[FirstName|class=advLogin_text|tabindex=6]</td>
        </tr>
        <tr>
            <td style="padding-top: 5px;"><span class="advRegister_LabelText">Last Name </span></td>
            <td style="padding-top: 5px;">[LastName|class=advLogin_text|tabindex=7]</td>
        </tr>
        <tr>
            <td style="padding-top: 5px;"><span class="advRegister_LabelText">Photo </span></td>
            <td style="padding-top: 5px;">[Photo|class=advLogin_text|tabindex=8]</td>
        </tr>
        <tr>
            <td align="right" style="padding-top: 10px;" colspan="2">[register_button|class=advLogin_Button|style=float: right;] [register_login_button|class=advLogin_Button|style=float: right;]</td>
        </tr>
    </tbody>
    <tbody>
    </tbody>
</table>
</div>

You will get a result that looks like this.

That will feed the photo file into the Profile Item “Photo” with DataType “Image”

We had a situation that clearly shows the use of the DotNetNuke Advanced Login Custom Script template, and how it can be used to deliver expected results.

The client wanted to use a custom search function that enabled search, twitter and Facebook into the top area of their skin.

The issue was, that when the this would cause some errors with the way that the search would display on top of the Advanced Login Module slide down effect that was set to run on the site.

The solution to this turned out to be a great example of how the “Custom Script” option from within the module, can be used to deliver a custom experience that takes into account other custom features of the skin or site.

So in this case we needed to move the Search, twitter, and Facebook information into the same layer as the slide down effect. We then changed some CSS styles to make the alignment of the item sit in the correct place on the skin, and not move to the right when the skin was on a wise display.

or

The end result

The custom script ended up looking like this:

jQuery(document).ready(function(){
jQuery(“#open”).click(function(){
jQuery(“div#adv_slidedown_panel”).slideDown(“slow”);
jQuery(“.search_style”).css(‘display’,'none’);
});
// Collapse Panel
jQuery(“#iwebs-close”).click(function(){
jQuery(“div#adv_slidedown_panel”).slideUp(“slow”);
jQuery(“.search_style”).css(‘display’,'block’);
});
// Switch buttons from “Log In | Register” to “Close Panel” on click
jQuery(“#toggle a”).click(function () {
jQuery(“#toggle a”).toggle();
});

jQuery(“#dnn_dnnLOGIN_cmdLogin”).css(“display”,”none”);
jQuery(“#dnn_dnnUSER_cmdRegister”).css(“display”,”none”);

if(jQuery(“.wsc_login”).length>0){
jQuery(“.wsc_login”).css(“visibility”,”hidden”);
}

jQuery(“.search_style”).appendTo(jQuery(“.tab”));
jQuery(“.search_style”).css(‘margin-top’,’10px’);

var w=jQuery(“.search_style”).offset().left- jQuery(“#s_wrap_main”).offset().left-jQuery(“#s_wrap_main”).width()+jQuery(“.search_style”).width();
if(w>0){
jQuery(“.search_style”).css(‘margin-right’,w+’px’);
}

})
function custom_validate_login(){
/*
add any custom login form validation logic here,
return true if pass validation
*/
return true;
}
function custom_validate_registration(){
/*
add any custom registration form validation logic here,
return true if pass validation
*/
return true;
}

The end result being that the skin, search and advanced login module slide down effect works well together.

slidedown-export

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

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.

DotNetNuke Solution

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.

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.

Best Resolution

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:

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.

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.

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

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.

A possible error was introduced with DotNetNuke 05.06.03 that caused certain types of post backs to generate an error:

Invalid postback or callback argument. Event validation is enabled using <pages enableeventvalidation="true" /> in configuration or <%@ page enableeventvalidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Details: http://www.dotnetnuke.com/Resources/Wiki/loc/print/Page/Event-validation.aspx

This error was introduced into the Advanced Login module, when the registration form was set to use the auto filling Country / Region Selector.

We have produced a fix for this in release version: 45.03.22 of our module. Update to this or a later version if you are receiving the above error.

Another Fix

If you are not using our modules and you receive this, you can resolve it by setting EnableEventValidation to false in the web.config.

Note: The above website mentions that this is “not ideal”. That is not really accurate. The change to the web.config for this has little to no effect on anything else at all.

Understanding Activation

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:

1. www.domain.com
2. dev1.domain.com
3. domain.com

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.

Trial

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.

Example

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.

Before You Activate

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.

To Activate Your Module

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.

Wrong License 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.

Correct License E-mail Address

With the correct details, you will receive a message like this:

Managing Licenses

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.

Module Support

We provide several Support services for our modules.

1. Where necessary our modules come with extensive manuals (like our bulkemailer module).
2. Each Module has it’s own pages on our website. Visit the module website by clicking on the correct module from this list: http://www.interactivewebs.com/DotNetNukeModules.aspx

Then use the support menu to find module specific support. This will include KB Articles, Support Forums, Blog Posts.

Advanced Login module for DotNetNuke works with DotNetNuke 4x, 5x and now 6x.

However because DotNetNuke 6x has some popup effect by default with the login button it interferes with the Advanced Login Module popup mode.

Solution

To fix this issue, the solution is relatively easy.

After selecting “Popup" from the Advanced Login Basic Settings Edit the skin object login and register as follows.

Default Settings

Update to:

Login

#dnn_Login,#dnn_LOGIN1_loginLink

Register

#dnn_USER1_registerLink

Save Tab Changes

Update to Templates

Then we need to make a small mod to the templates. After Selecting the Templates tab, click on Custom Script.

And modify the script to:

jQuery(document).ready(function(){
    /*
     add any custom initialization logic here,
    */
       jQuery("#dnn_LOGIN1_loginLink").attr("onclick","");
       jQuery("#dnn_USER1_registerLink").attr("onclick","");

})
function custom_validate_login(){
    /*
    add any custom login form validation logic here,
    return true if pass validation
    */
    return true;
}
function custom_validate_registration(){
    /*
    add any custom registration form validation logic here,
    return true if pass validation
    */
    return true;
}

Note: We added two new lines highlighted in yellow.

Save Tab Changes and you should be done. With the default skin in DNN 6.0.1, now the advanced login popup mode should work fine. Look at the Advanced Login Module for more assistance with configuring the module with different skins.

One of the most asked for features of the DotNetNuke user registration process is to allow users to register without the need for a user name.

Today we have added this feature to the DotNetNuke Advanced Login Module.

User Name Omission

Normally DotNetNuke requires a user name to be entered at registration. The Advanced Login Module will automatically create a DNN user name at registration time, even if the token for User Name is not included in the registration form. This way you can allow users to register with an email address and no user name, while in the background the Advanced Login Module handles the user name for you.

How It Works

If omitted from the registration form, the user name will be taken from the email address.

david@domain.com for example will generate a user name using all data from before the @ symbol.

david@domain.com = david as the user name.

If david is already taken as a user name, then david-01 or david-02 etc. will be used automatically.

This keeps the username familiar to users should it ever be provided to them, yet keeps the registration process as simple as possible.

The module is available as a Free DNN Module trial on our site.