I'm so tired of people discounting HTML Tables. I'm a huge fan of CSS, I'm fully aware that it is possible to do columns using CSS, but in order to do so, you have to use a variety of hacks, and those hacks change based on a variety of circumstances.

With DNN, because we have skinning, we already have the needed separation between content and presentation. Tables are the best way to handle columns. They are rendered consistently across browsers, are clean, and easy to read and use, and provide capabilities that are very hard to get without Javascript hacks in CSS.

I've spent countless hours trying to work around problems with my CSS based columns due to one need or another. I've researched many approaches to the best way of handling them. None of the solutions I've seen have proven to be nearly as clean and easy as just using tables.

If you continue to feel compelled to build tableless designs, go for it, perhaps you'll have better luck than I, but when you have a complex need and you can't find a solution that works consistently in all browsers, I give you permission to just go ahead and use a Table.   

There are hundreds of different functions and variables available through DotNetNuke, ASP.NET, and HTTP which can give you a variety of variations on your sites URL. I often find myself needing one variation or another as I'm building one application or another. The problem is, I have yet to find a clean and consistent way to get at the site's root or fully qualified URL regardless of whether the site is in a virtual directory (i.e. http://www.efficionconsulting.com or, for sites with virtual directories http://www.efficionconsulting.com/dotnetnuke). For DotNetNuke, I'm now using the following...

    Read More...

When the "Remember Me" feature of the DotNetNuke Login is enabled an encrypted authentication cookie is placed on the user's machine. By default, the web.config has a setting which causes to cookie to expire after one hour, which makes it almost useless.  However, the expiration of the cookie can be tweaked by editing a line in the web.config.   Read More...

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, often referred to as "harvesting". There are multiple ways to prevent this...   Read More...

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.   Read More...

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 %>   Read More...

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.   Read More...

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.