We experienced a problem with the store checkout only listing a creadit card expiry date up to 2015
Thus the drop down selector in the Credit Card field for expiry date would not allow years fat enough into the future that the customer could select the correct expiry date.
The solution we found was this:
Navigating to the “Your Cart” module. You can do this by login in as an admin (not host) and buying a product. When it takes you to the cart module… Select Edit Skin from the module menu. Grab the code there, and paste into notepad etc. And look to the code that looks like this. ListItem Value=”09″ Selected=”True”>2009 ListItem Value=”15″>2015 ListItem Value=”16″>2016 ListItem Value=”17″>2017 ListItem Value=”18″>2018 ListItem Value=“19″>2019 ListItem Value=“20″>2020 Make it look like this exactly for the update at this time.
If you are trying to upgrade your DotNetNuke site and found that you are presented with the Welcome to the DotNetNuke Upgrade Page, but can’t login with your Host (SuperUser) account.
DotNetNuke Upgrade – Version 06.02.07
Current Version – 06.02.05
Welcome to the DotNetNuke Upgrade Page.
The first step is to choose the language you wish to use for the Upgrade.
You are about to upgrade your website to a more recent version of the DotNetNuke application. Applying upgrades on a consistent basis is the best way to ensure that you are protecting the integrity of your investment and the security of your users and assets. Before proceeding with the automated upgrade process please ensure that:
you have made plans to first attempt this process in a staging environment
you have documented your current installation characteristics including doing research on the compatibility of any third party modules which you may be using
you have created the necessary backups of your environment so that you will be able to restore your website in the event of an unexpected upgrade failure.
Solution
Just simply close your browsers, or better yet, grab a browser that you have not accessed for some time. Then try hitting your URL and loggin in with the new browser session. While I did not bother to work out what the cache issue was, I did find it was cache related to an open browser session that was trying to authenticate to a previous session.
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:
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
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.
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.
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.
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.
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”
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.
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:
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: 0x80131040)
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!
With the Advanced Login Module, users of your website can login with an email address or otherProfile information instead of having to remember a user name.
Additionally you can allow verification of identity with profile data other than a password. First Name for example.
Restrict and allow access based in IP address, and then redirect based to a DotNetNuke page based on IP address of the user.
How to Configure DotNetNuke Websites to use DotNetNuke Advanced Login Module
We have updated our popular advanced login module for DNN. The updates can be viewed from the