Follow Us
Printable Version Printable Version Recommend Recommend Email to a friend Email to a friend

A Detailed Explanation of the Anatomy and Components of a DotNetNuke Website URL

An in-depth explanation of the components of a DotNetNuke (DNN) URL and what purpose they serve. The example is a relatively complicated URL for a video located on the website.
People don’t like to think about or talk about URLs. Unless someone know how their website works in detail, there is a chance for URL confusion. Even technically-minded people gloss over when talking about the details around what is happening with the fundamental pieces of a URL.

Because this seems so common, I thought I would devote some time to discussing each piece of the URL and what the significance is.  The example used is a DotNetNuke (DNN) URL.  I will start with the very basic and expand from there.  

This will blog post will not cover URL management (including friendly URLs, canonical URLs, broken links, etc .).  It will, however, provide the background for any further discussions about URL management which may be discussed in other posts.

This post is written to minimize jargon as much as possible.  To do this, some generalities have to be used, where necessary.  In other words, the strict definition of some items may be overlooked in the interest of clarity*.

What is a URL?

A URL is an address for the internet. The full URL is the location to find a specific piece of information on the website. Before there were Content Management Systems (CMS), this meant that every URL pointed to an individual file on website’s server (typically, with a “.html” extension on the end of it).

With the evolution of CMS platforms, such as DotNetNuke (DNN), the URL is still a unique address.  But, the URL may no longer represent an actual “physical” file on the server – the URL may describe a unique set of data to get from the database.  Basically, the URL has enough information to tell the CMS what data to display from the database.  This is an important point to understand, since the examples will point out the types of data that the URL can hold, rather than talking about the files involved.

A sample URL from the PackFlash website is below.  This points to a specific video on the site:

Since this URL is relatively complex already, I will dissect this URL for the rest of the blog post.


For the sake of simplicity, we are only going to be focusing web pages and will not be digging into the details of what protocols and extensions do. This means that the HTTP protocol (HyperText Transfer Protocol) is the only one that will be referenced. If you have a site with a secure connection, you may substitute https:// for the http://. The technical underpinning of this is beyond this post, but the text “http://” is required in a browser address bar for it to be understood (modern browsers are doing a good job of hiding that they are needed, but behind the scenes, they are still there).

The first characters in the URL reference the protocol as shown below:


The extension of the url historically implied the technology used to create the site. In DotNetNuke, the extension “.aspx” is used which has to do with Microsoft’s most recent .NET application framework, but other common extensions include “.html”, “.asp”, “.php”, and “.cfm”. This has changed over time, where if you see an extension for “.aspx” or “.php” it may be an indication of the technology used, but it does not ensure it. This is because it is possible to have no extension at all, mask the extension, or provide a vanity extension. We could, in fact, have an extension called .chris if we wanted.

In our example, the extension is buried within the URL below representing a .NET application:


The domain name is at the beginning, like ours, which is This is also what is known as a TLD (Top Level Domain):

Note that in this case it is shown with the “www.”. This could be left out and just represented as, like below:

For this to work correctly, the DNS has to be set up correctly. There should also be a re-direct telling the search engines that these 2 URLs represent the same exact information as well.


Subdomains borrow and descend from the top level domain. They are managed by the same organization that manages the top level domain. Examples of subdomains of include the following: (demo site for the PackFlash Constellation Suite) (demo site for the PackFlash Mega Menu Admin Module)

Directory Path (Folder Path)

The directory path (or traditionally folder path) was the physical path of the server system to get to the file. In a CMS, the directory path could represent the name of anything in the system at the time. For instance, with DNN, the most common directory path is the page name (not page title). Depending on the system used, the other most common use for the directory path is a category set up in a tree structure. Below is our example URL with the directory paths highlighted. In this case, these paths do represent the pages on the site where the Video is being displayed on the page “Video Demo 1 All Features” which is a child page of “Video” which is a child page of “DotNetNuke Modules”. DNN removes all spaces for us.

Query String (Parameters)

Query strings represent dynamic data (or variable) that is read by the system to display specific information. These are represented by the query field (or sometimes called query key) and value pairs. There are multiple ways to use and represent a query string in a URL. Our example shows 2 different examples.

Example 1 :  The first example represents the actual DNN page (or tabid) of the system.  This is written by a “/queryfield/queryvalue/” syntax.  In our example below, DNN knows how to understand what a tabid is and how to find the page that matches that tabid of 199.  As long as this text is in the URL, DNN knows what page is being requested even if the rest of the information is incorrect:

To test this out yourself, replace any portion of the text “/DotNetNukeModules/Video/VideoDemo1AllFeatures” with whatever nonsense text you want and put it into the browser.  I replaced it with “garbage-text” and it still finds the correct page and video.

Example 2:  The second example of query strings in the example URL represents which video to display (lvid) and which video player to show the video in (mvid).  This is done because multiple video players can be on the same DNN page. 

Because these query strings appear at the end of the URL, it is required to have a special character to provide a separator to tell the system that the parameter is coming.  This is where the “?” comes in.  It tells the system to expect more information to process.

In this example, the syntax uses a “queryfield=queryvalue” structure.  So, the URL is telling the system to find video id 3 and display it in video player id 1002 within the DNN page that we already found.  Depending on the system, the order may not be important as long as all of the query strings are represented:

Since there is more than one query string parameter at the end, we need an ampersand “&” between them. If there were 20 query string parameters, each pair would need an “&” separating them.


An anchor typically represents a position on a page. This is set up as a link on the page so that if someone scrolls up or down the page and clicks the link, then the user is taken to the location specified by the anchor. In our example, the anchor “pfvideo_player_1002” is located at the top of the video player. Visiting the page with the example URL scrolls the page down to the top of the video player. Clicking any of the videos on the page takes the user to the anchor as well. Anchor is always represented by a “#” plus the name of the anchor that is requested.

In recent years, the anchor has been expanded to be used for many other purposes other than a position on a page. Other uses for the anchor syntax could include but are not limited to the names of tabs of an AJAX tab (the system would know which tab would be displayed) or an AJAX request parameter.

*NOTE: An example of this generality is that I am not distinguishing between a URL, URI, or even URN. For this discussion, they are synonyms or the distinction is not important for the basic understanding because this topic is focused on web pages (technically, a URL is a type of URI). The distinction and differences may be more important for other discussions, however.

Please provide comments on this subject in the comments section below.

Comments (0)

PackFlash| Superior DotNetNuke Solutions| 415 N. Lasalle Street, Suite 205, Chicago, IL 60654|
Home | DotNetNuke Modules | Skins & Design | Website Services | Demos | About Us | Contact Us | Blog
Copyright 2021 by PackFlash