When the "Remember Me" feature of the DotNetNuke Login is enabled an encrypted authentication cookie is placed on the user's machine. The cookies short one hour lifespan makes it almost useless.  However, the expiration of the cookie can be tweaked by editing a line in the web.config.

One thing I think it's important to do is to protect my clients from spam. Clients like to be able to put their email address on their sites. But, putting an unprotected email address on a site can soon result in a lot of spam as spambots search sites looking for email addresses to add to their lists. There are multiple ways to prevent this...

Sometimes, you need (or want) to know what modules are and are not actually being used on your DotNetNuke site. This can be useful if you want to uninstall unused modules for performance improvements or if you're planning on upgrading your site and you need to know what modules you'll need to test or upgrade. Here's some sql that will help you answer these questions...

eTailer from Emerald Solutions is a fairly new entry in the DNN e-commerce world. While there is a great deal of promise in the product, my brief attempt at using it seems to indicate it's not ready yet...

Purchasing, downloading, and installing it went smoothly. eTailer adds a reasonable 5 modules to your DNN install (much better than the 23+ modules Catalook adds). Initially getting things setup and going seemed quite intuitive.  I created a new page and added the "eTailer Store Front module". It had a nice obvious link that allowed me to Add/Modify Products. And so I was off and running, or so I thought...

We've been doing a lot of DotNetNuke based E-Commerce projects lately. The projects we've done have really spanned a variety of store types (wine, audio files, church stuff, an automated shutoff system, resistors, printing products, and more), client types (wineries, churches, incentive programs, manufactures, master distributors) and feature requirements. So far, for all the DotNetNuke based E-Commerce sites we've built, we've used Catalook.

Catalook has a huge number of features, an immense number of configuration options, and is probably the worst implemented piece of software I've ever used. But it works. At times, though, I think it would be faster if I had just built the E-Commerce pieces of each of the sites from scratch.

Here's a compilation of tips and tricks for getting at more than just <%= SkinPath %> in your DNN skin.

To show the name of the Portal:
<%= PortalSettings.PortalName %>

To get the current portal's home directory (i.e. /portals/0 ) you would use:
<%= PortalSettings.HomeDirectory %>

You may have noticed that when you edit text in DotNetNuke, what you see in the editor window may not look like what you see when you save your changes. This is because the fckEditor applies a different stylesheet in the editor window instead of any of the actual site css files. To change this, all you need to do is edit the web.config file for the site and set the proper value for the StaticCSSFile variable in the FckHtmlEditorProvider section.

So search your web.config for StaticCSSFile. And update it to point to your desired css file (e.g.  StaticCSSFile="~/Portals/0/Skins/MySkin/skin.css"). Save your changes and you should now see the proper styles when you edit content.

I initially tried making changes to the EditorAreaCSS variable in the fckconfig.js file as this is the standard place to make fckeditor changes but that proved to be a dead end. Not sure why the DNN folks implemented this in the web.config instead.

DotNetNuke has a nice way to require unique passwords for all users. You can't simply go into the web.config, search for RequireUniqueEmail="False" and set it to RequireUniqueEmail="True". The problem is if there are already users with duplicate email addresses, bad things happen (It's been awhile since I've tried it and I don't remember specifically what happens but I know it wasn't handled well).

So, you need a way to remove the duplicate email addresses before you make the web.config change. This SQL will take care of it.

This is something I've learned and forgotten at least 4 times. Writing these types of things here helps me remember and seem to help quite a few other people as well. So...

Usually in DotNetNuke, if you want to associate a resource file with your control, you just create a resource file with the same name as the ascx file plus the .resx extension and place it in your App_LocalResources directory. DotNetNuke and/or ASP.NET auto-magically associates the file with your code and it just works.

However, every time that I create a control that dynamically loads other controls, I spend 30 minutes looking at names and file placement and... trying to figure out why the resource file doesn't seem to be loading. Eventually, it comes to me, for dynamically loaded files, you must explicitly set the LocalResource file.

To do this add the following line to your PageLoad function in your dynamically loaded control:

 LocalResourceFile = DotNetNuke.Services.Localization.Localization.GetResourceFile(this, "controlfilename.ascx");

To learn more about DNN Module Localization, check out the DotNetNuke Module Localization Guide.

DotNetNuke makes it easy to determine if the currently logged in user is an administrator (aka admin) or any other role for that matter. All you need to do is call the following: PortalSecurity.IsInRole("Administrators") or PortalSecurity.IsInRole("MyRoleName"). This function should return the boolean value very quickly as everything it needs is already in memory. You can call this from either the code behind or the ascx file (e.g. Visible='<%#PortalSecurity.IsInRole("Administrators")%>').

This can be very useful for determining whether or not to show a control or content meant only for the right groups eyes.