InteractiveWebs Blog

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.

DotNetNuke 05.06.03 Pain

If you look at the project downloads for dotnetnuke, you will notice that the forums module has the latest version as: 05.00.01

And if you click the link from within this page: http://www.dotnetnuke.com/Resources/Downloads/Projects-Downloads.aspx

05.00.01 is exactly what you get.

All sounds neat and tidy… right?

Not really, because if you install the latest version of DotNetNuke 05.06.03 (an important security release) you will kill your forums. Dead as dead.

And if you check around for an update of the forum module, you will not find one either in your Module Definitions, or in the DotNetNuke website. But keep looking to codeplex and you find this:

05.00.02 and what is strange, it is released before the DNN 05.06.03 update, like significantly before it… like 1 month.

This Forum Update is NEEDED if you want the forum module to work on DNN 05.06.03

http://dnnforum.codeplex.com/releases/view/67840

Release Notes

The same module as 5.0.1, except compiled against DotNetNuke 5.6.3 (and therefore is a minimum requirement) and the same version of Telerik (2011 SP2) included with it.
NOTE: This was compiled against, and for, 5.6.3 and is included with that release (Not released yet, as of June 12th (try 5 July).

All so confusing!

It waisted a lot of our time trying to work out what is going on. All we know is that DNN 05.06.03 broke a bunch of stuff, including the Forum Module. There is a fix but it is hidden on codeplex and is incorrectly referenced.

Very Unprofessional DNN Corp!

What you need to know

If you update to DNN 05.06.03 – your forums will die.

To fix it, download the hidden forum update 05.00.02 here: http://dnnforum.codeplex.com/releases/view/67840

We found an issue with what is the current release version of DotNetNuke Blog module 04.01.00 or 04.01.01.

First up, we don’t know what the version number should actually be, as the compiled version on the download is 04.01.00 but the source code is referenced as 04.01.01.

We presume there is some difference, but who knows what it is.

Anyway The Problem

The problem is that any forms on a page that run the blog module, will not allow form data to be validated. By validated, we are talking about ensuring a number is entered in a number field and text in a name filed etc.

The cause is the blog module is using an old ASP.Net 1.0 validation function. While it should be using ASP.NET 2.0 with the updated validation behaviours as found here:

http://msdn.microsoft.com/en-us/library/0ke7bxeh.aspx

With this mistake, if you use Page.Validate on ASP.NET 2.0, page validation groups are ignored and the controls are validated.

Why the BLOG module is even coded this way is quite questionable in any case. However without DNN being a true open source system, we have no ability to fix this were needed in the source.

Our solution

We fixed the problem and recompiled a version that people can download an use for free.

Blog_04.01.01_Install A

You can install this on top of any DNN blog module 04.01.00 and we would expect that future releases of the blog module will not be affected by this version we compiled. However they may well revert back to their junk code in the future releases.

Today we released an update to the Automatic Backlink Module for DotNetNuke.

Details of the update are available here: http://www.interactivewebs.com/automaticlinkbuilder/Support/VersionHistory.aspx

But include improvements on the way site monitoring is handled and the way the module works with the known GZIP issues.

An example of the module can be seen here: http://www.interactivewebs.com/Admin/DotNetNukeWebsites.aspx?&action=add

where you can add your site for back linking.

How to Configure DotNetNuke Websites to use DotNetNuke Advanced Login Module

DotNetNuke had the ability to configure a custom page to be used as the login page on your website. This page does not need to appear in your menu structure and the login process can effectively be made to use the Advanced Module in a seamless way to the default DNN login process.

Setup a Page for Login

1. Create a New Page in your DNN Website using the normal Add Page Method:

2. On that new page, uncheck the menu item for Show in Menu, and make the page viewable by all users or unauthenticated users:

This ensures that people who are not logged into your website have the permissions to view the login page.

3. Add the DNN Advanced Login Module to the web page, and format the page as desired. Remember too that you can have content that is visible in different states. i.e. Users that are not logged in can see modules and content set to “unauthenticated” but cannot see content for Authenticated users until they have logged in. We use this to our advantage on our DotNetNuke Module Download Page, by providing instructions to people about login before they are logged in, but after they are authenticated and logged in those instructions are no longer displayed.

4. Configure the module into the mode you wish to use for login. Options like logging in with email address in place of user name etc. This is an example we use for the login settings to our site:

5. To set the page you have just created as the default site login page, go to the Admin / Site Settings / Advanced Settings / Page Management, and select the page you have just created as the login page for the site, and set the Home Page as the page you wish to display by default after users have logged into your site:

The end result is that when someone clicks on the “Login” menu option in your DNN skin they will be directed to the login page of your website. Once authenticated the user will be directed to the Home Page, unless they were looking for a members only URL when they hit your website. In that case the login process will deliver the user to the original place they were attempting to reach.

Today we updated out profile at Codeplex http://www.codeplex.com/site/users/view/InteractiveWebs

mostly so that we could slam a review up for the latest dotnetnuke 5.6.2 release. The review points out that the release is not one of the worst releases of dotnetnuke, but it is buggy and caused us some problems. We are quite disappointed that this is the last 5x release, and hold little hope about the initial releases of DotNetNuke 6x.

Shame for all the hype and spin that dnn corporation have been putting on themselves that they are so happy to release such junk.

Getting your site ready for Mushroom Image

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

Background

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.

Adding the module to a page

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:

Today it was drawn to my attention that the DotNetNuke Corporation has a User Experience Team. Good on DNN Corp for caring about UI, and so they should.

What cracks me up about it is this.

Go to the webpage and seek more information on the UI team members. First from the list is Joe Brinkman. (Not picking on you Joe, but your smile is first on the list).

Notice the *******, Ohio ********* (Funny hay)

Where is my User Experience I would like to know? How can a UI team allow the details page of their team profile pictures look like that… I’m still laughing about it as I write it now.

Are you serious???

This is like one of those Microsoft jokes they play on me as a system admin. They give me an error log, with a meaningless code in an event view… then for a joke they give me a link to a support site that has NO SUPPORT.

They even call the link a help and support link. Yet every link has exactly NO help.

Now I am sure that there is a big counter on the wall in Microsoft land, with a big number ticking over for every time a users clicks a help link and gest NO HELP! They are sitting there watching and laughing so hard that they did not see apple dominating their market for the last 5 years.

I wonder if the DNN UI team has something similar… something that at least gives them a laugh each time a user clicks for more information about the team, and finds not only… absolutely NO INFORMATION, but NO INFORMATION DELIVERED WITH THE WORST UI POSSIBLE!

Could not load file or assembly ‘AjaxControlToolkit, Version=3.0.30930.28736, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0×80131040)

We were playing today with a trial module from another developer. Received the above error. After much mucking around, we found that the very specific version of the

• AjaxControlToolkit.dll

file that came with the module, was not installed during the normal module setup.

We extracted the file into the \bin\ directory on the site, and joy to the world.

Strange that a specific version is required and that the 3.5 or 4.0 version does not work. This is how they referenced a specific version. Not a good way to program.

There are load of features and functions about DotNetNuke that tick us off. Some big, some small and some that are baseless. It never ceases to astound me why they do some features and functions so poorly.

Today I had to write about a pet hate…

Why when we go to the module definition page, do we see a list of “Upgrades?” with the painfully ugly Microsoft style highlighted version number.

Really. Whoever built that system.. was that look the best you could come up with. It is painful enough that the stupid system does not allow third party developers to reference an RSS feed for their own updates. (Would have thought that was a no brainer). But why Microsoft Word frigging green highlight!

How about something a little classier in the default look. Is this 1998? Think not!

And for anyone reading this who thinks… “well you did not develop it.” That’s only because is is not an open source platform. One of the biggest problems with DotNetNuke is that it is not open source. They claim yes… but just because you call something by a name, does not make it accurate!

There… I said it!

Now back to work.