DNN Blog 6.1 - Proposed Enhancement 1


I want to propose one enhancement to an issue in the DNN Blog Module that has been a pet peeve of mine since I started using the blog module. As a matter of fact, my very first work item I ever posted on CodePlex back on February 2014 was describing this issue: Templates View Link Enhancement Request

What I propose is to:

  1. Eliminate the need for “URL to target page” property in Template Settings (see image below)
  2. Construct and display links from all the templates in the same manner and with the same standards
  3. Modify the existing templates to use the new architecture

Eliminate the “URL to Target Page” property

3 out of the 13 templates included in the DNN Blog module contain the “URL to target page” property in the Template Settings:

  1. commentList
  2. latestPosts
  3. and timelineJS

What this means is that these three templates are the only ones that you can “move around” - so to speak - and place them into pages other than your main blog page. The rest of the templates, however, must live within the main blog page in order for the links to work correctly. This is a big limitation to website administrators, web designers, and blog owners who want to have the flexibility to “move” modules around to match their specific website needs.

So how can we eliminate this limitation and allow all templates to be “movable”?

The concept is simple:

  1. We know that DNN uses the TabID behind the scenes in the contruction of friendly URLs and to redirect to the page being requested
  2. We also know the Parent Blog Module when we select it from the Blog Settings page, as shown below. Thus, we can easily obtain all the properties for the parent blog including the TabID, which I will call the ParentTabID from now on

  1. We know that in the existing functionality the Blog module is using the “URL to target page” from the Template Settings to construct the link

  1. So if we discard the “URL to target page” from Templates Setting, and instead we use the ParentTabID from the Parent Blog Module in the construction of the link, then voilà, we have automatically created a link that will always point to the correct page regardless of where it lives
  2. The best part of all is that if we apply this technique to all the templates included in the Blog module, then all the templates become “movable” (can live on any page you want)
  3. And if this isn’t sweet enough, both modules (the main blog module and the latestPosts module in our example) will have matching URLs. More on this on the next section.

Look at the Proposed Code Changes on GitHub

As I mentioned before, the concept is very simple in nature, but the code changes to achive this goal were far from simple. If you want to take a closer took at the code changes go to my GitHub fork and look at the commits posted on Oct 9 and Oct 12:


Construct and display links from all the templates in the same manner and with the same standards

When you start using the DNN Blog module you notice right away how each module constructs and displays links somewhat differently from each other. To illustrate what I mean, let’s compare the links from the _default template to the links from the latestPosts template.

The links produced by the _default template are constructed in the following manner:

    http://www.yoursite.com/Blog/Post/1014/The-Title-Goes-Here (sample link 1)

And the links produced by the latestPosts template are as follows:

    http://www.yoursite.com/Blog.aspx?post=1014 (sample link 2)

Both links behave the same and produce the same result: open a blog post (postid 1014) titled “The Title Goes Here” on a page called Blog. HOWEVER, the way the links are constructed are not uniform and it greatly affects SEO efforts.

Wouldn’t it be nice to have both templates generate the same link as sample link 1?

I think so too! And with the introduction of the ParentTabID concept, this issue is completely eliminated. The construction of the links from all the templates will be the same.

Modify the existing templates to use the new architecture

To take advantage of the architectural changes explained above, it is necessary to introduce a new parameter to all the templates: “parenturl” Let’s take the latestPosts template, for example.

The Post.html from the latestPosts module looks like this

The Post.html template will look like this with this new change

Will this affect your existing templates, tokens, and functionality?

Absolutelly not. These proposed changes are additions to the existing template engine and functionality and will be fully backwards compatible. You won’t have to modify your existing templates unless you want to take advantage of the new improvements.

So what benefits do we obtain from this change?

  1. Standarization - All the templates will support this new architecture, not just a few
  2. Movability - You will be able to move templates/modules around to any page you want
  3. Uniformity - Links will be constructed and displayed with the same format
  4. Usability - You won’t ever have to mess with the “URL to target page” again in the Templates Settings
  5. Reachability - New users may find the DNN Blog Module a better candidate for their blogging needs with less cumbersome configuration


The enhancements proposed in this post have been submitted to Peter Donker for his consideration and approval. It is not a guarantee that these changes will make it to the DNN Blog Module.

Happy DNNing! and Blogging!


Luis Cabrera is a family man and a dedicated dad. He lives in Florida, where he works as an Applications Architect for one of the most recognizable brands in the US. In his spare time, Luis likes to develop apps using ionic and Firebase. Aside from technology and family, he enjoys the outdoors and working on his horse farm.

Older posts...

Written by

Get in touch!

Notice any mistakes?
Leave me a message