Friendly URLs

Friendly URLs is a multi-faceted enhancement which essentially boils down to providing a mechanism for mapping virtual resource names to physical resource names at runtime.

A number of generic solutions exist for friendly URL processing; however, the real focus must be on identifying the specific use cases where friendly URLs are required in DotNetNuke.

1. Most search engines ignore URL parameters. Since DotNetNuke relies on URL parameters to navigate to portal tabs, the current application is not search engine friendly. In order to effectively index your site we need a parameter-less mechanism for constructing URLs that search engines will process.

2. DotNetNuke has a concept of "child" portals which are essentially subportals beneath a domain ( ie. www.domain.com/child ). The current application requires that physical child folders be created on th web server ( requiring Modify security rights to the root folder ). In addition, once the user browses to the child portal, the identity of the child portal is lost ( ie. www.domain.com/child becomes www.domain.com ) which prevents search engine indexing and URL recognition for the child.

3. The feature should not affect the processing of Requests for other applications installed in the shared hosting environment.

1. A portal administrator will be able to submit a friendly URL identifying a specific tab to a major search engine ( ie. Google ). A user will be able to search for the tab and select the URL link which will redirect them to the specific tab in the DotNetNuke portal.

2. A user will be able to enter the child portal URL ( ie. www.domain.com/child ) and the application will load the portal but retain the child portal identity in the browser address. The portal administrator will be able to submit a child portal URL to a major search engine which will behave the same as #1.

3. Other applications in the same shared hosted account are not affected.

Any additional processing of each Request will affect the performance of the application. As a result the implementation must balance the friendly structure of URLs with the corresponding performance impact. ASP.NET HTTPContext.Current.RewritePath() will be used for modifying URLs.

1. The URL format for search engines should not include parameters. In addition, names are much more important than IDs when it comes to indexing. Unless the Request is for .aspx then it is ignored. Note that the tabid also identifies the portalid.

Proposal #1:

http://www.domain.com/ tabname/default.aspx -> http://www.domain.com/ default.aspx?tabid=tabID

Pro: user and search engine friendly structure
Con: This would require a database lookup to translate the tabname to a tabID - which will affect performance. In addition, since tabnames are not unique, there could be multiple tabs inthe same portal which have the same tabname - resulting in a navigation scheme which is not 100% reliable. The hierarchical nature of tabs are not reflected either.

Proposal #2:

http://www.domain.com/ tabname/tabid.aspx -> http://www.domain.com/ default.aspx?tabid=tabID

Pro: The tabID could be reliably extracted from the URL filename which eliminates the need for DB translation of the tabname to tabID. The tabname is still reflected for search engine indexing benefits. The entire hierarchical path to the tab could be represented ( ie. parenttabname/childtabname/tabid.aspx )
Con: not so user friendly

2. The URL for child portals must be mapped to a valid PortalAlias ( this is only necessary on the first Request as subsequent Requests have the tabid value - which identifies the portal ). Physical folders matching the child portal name do not need to be created.

http://www.domain.com/ childportal/default.aspx -> http://www.domain.com/ default.aspx?portalid=portalid

This still requires a database lookup to translate the child portal name to a PortalID ( but this can not be avoided ).

3. Create a simple RegEx engine which allows URLs to be mapped to other applications outside of DotNetNuke. Create the UrlRewriter as a HTTPModule so that it can custom versions can be created and plugged in.

Note: For #1, #2 above - a global function needs to be created which builds URLs in the exact virtual syntax. This function would be used whereever DotNetNuke specifies a URL for an application ASPX.

Complex example:

http://subdomain.domain.reg/ childportal1/childportal2/childportal3/ tabparent1/tabparent2/tabname/tabID.aspx -> http://subdomain.domain.reg/ default.aspx?tabid=tabID

- the tabID identifies the portal and the tab

or

http://subdomain.domain.reg/ childportal1/childportal2/childportal3/ default.aspx -> http://subdomain.domain.reg/ default.aspx?portalid=portalid

- the "subdomain.domain.reg/ childportal1/childportal2/childportal3" maps to a PortalAlias value in the Portals table

One of the issues related to the processing of child portals is how to deal with the limitations of IIS. By default only ASP.NET specific requests are routed to DotNetNuke and since we can not rely on custom IIS configuration in a shared hosted environment, we need to find solutions which are self-contained. Case in point is the processing of child portal addresses:

http://subdomain.domain.reg/ childportal1 - this refers to a folder which means this request will never be routed to DNN ( even if the default document is set to "default.aspx" ) unless the physical resource exists on the file system ( which we are trying to move away from ). As a result, a child portal would be required to use the syntax http://subdomain.domain.reg/childportal1/default.aspx for their web address - definitely not as elegant.

A solution to deal with this problem involves trapping the IIS 404 error and redirecting to a DNN page for processing - however this solution requires custom changes to IIS which means we can not rely on it as a core servive. However, it would be useful to include this solution with some documentation anyways for those who do have control over IIS.

Jeremy White