Editor’s note: Please ensure that you create a backup of your files before attempting to make any core module changes. Also make sure that you test any code changes on a test DotNetNuke installation before applying any changes to a live website.
The standard and recommended method by the DotNetNuke core team for editing modules is to recompile and make changes to the.dll files. The method in this article demonstrates how to edit modules using the .ascx files which beginners may find more suitable. If you are interested in module development, we have provided some links to tutorials here.
By Oleg Zhukov
February 2007
Updated June 2008
This article explains how to make changes to DotNetNuke modules varying their look-and-feel, as well as adding some fundamental behaviour. Explanation is done by example of the Blog module.
Introduction
DotNetNuke is shipped with a number of feature-rich modules suitable for various tasks. However, a necessity to modify a module’s behaviour may arise. This article covers how to easily modify DNN modules and extend their behaviour.
As a case in point, we will modify the Blog module, making it better step by step. But firstly, let us clarify the basics of a DotNetNuke module’s structure.
DotNetNuke module structure
In DNN 4.x a module is usually comprised of front-end controls (in *.ascx files) and module’s logic (*.dll assemblies). A module’s front-end is located under DesktopModules\\ folder. Module’s assemblies can be found in the Bin\ folder.
When modifying module’s *.dll files, it is a complicated task due to the need of an entire recompilation. So we will insert all additional behaviour into *.ascx files and will deal with them through the rest of the article.
Step 1: removing needless parts
Some information displayed in a module may be redundant and would be better hidden. For example, the calendar in a blog archive view is needless if posts aren’t made often. We will now demonstrate how to remove the calendar from the Blog archive.
Take a look at the contents of Archive.ascx file (under DesktopModules\Blog folder). It describes how the archive view looks. Several lines in the beginning of the file contain definitions for unwanted items:
However we cannot simply remove label and calendar controls since they are referred to in the underlying dll’s. Instead we should attribute them as invisible:
This will make a module contain only what is desired and nothing more.
Step 2: rearranging existing controls
Let's now look at the search box in the Blog module. In this example we will hide the combo box at the top and we will arrange the radio buttons vertically.
Here we need to modify the Search.ascx file. The former task is done as in Step 1. The latter one is no harder - we just set repeatdirection="Vertical" on control.
Note that changes to the visual style of a module (e.g. fonts, colors, etc.) are made through the module.css style sheet.
Step 3: adding logic to a module
So far we have dealt only with visual modifications to modules. But what if it’s necessary to add some new functionality to a module? It can be fulfilled the same way - via modifying the module’s front-end *.ascx files.
For example, let's make the blog archive show the number of posts for each month.
In order to get the number of posts made in a particular month a SQL query should be executed. Since inline querying is forbidden in DotNetNuke we need to create an appropriate stored procedure which will return the desired number.
A stored procedure can be created by means of the DotNetNuke SQL tool. Open it by logging in as the Host user and going to the Host > SQL menu item. Then paste there the stored procedure creation query, select “Run as Script” and click “Execute”.
(The stored procedure code can be downloaded with the source code at the bottom of this page.)
Now that we have created the stored procedure, we need to find a method to execute it. In order to execute it, we need to provide connection settings and procedure parameters. Connection settings can be retrieved by static methods of the corresponding DataProvider subclass. Other parameters depend on the specific case, for example portal ID can be obtained via the “PortalId” property of a module’s front-end control.
Anyway, we will need to embed server scripts with additional logic into *.ascx controls. Here is how it would look for our example:
For Blog module versions below 03.04.00
<%@ Import Namespace="DotNetNuke.Modules.Blog.Data" %>
<%@ Import Namespace="DotNetNuke.Modules.Blog.Business" %>
<%@ Import Namespace="Microsoft.ApplicationBlocks.Data" %>
…
…
(<%#GetEntryCount(CType(Eval("AddedDate"), DateTime))%>)
For Blog module version 03.04.00
<%@ Import Namespace="Microsoft.ApplicationBlocks.Data" %>
…
…
(<%#GetEntryCount(CType(Eval("AddedDate"), DateTime))%>)
The stored procedure used is "Blog_GetEntriesCountForMonth" and it is called with SqlHelper.ExecuteReader static method. Here we use standard ASP.NET notation <%#expression%> to embed calculated values into the markup.
Conclusion
DotNetNuke is an open-source framework and this makes it possible to modify the behaviour of all of its parts, including native modules. Through the article we have addressed questions of making changes to modules by modifying their *.ascx front-end files. Such changes do not require recompilation of underlying dll’s though they may contradict the standard DotNetNuke programming model. If a minor change to a module needs to be made, then modifying the module’s *.ascx files is the easiest way to do it.
Download
The example improvements to the Blog module can be found in the downloads section of my website. Or just click here for fast access.
Oleg Zhukov, born and living in Russia is a software development consultant in a company which provides business solutions.
http://www.olegzhukov.com