2
votes

Background

DotNetNuke supports the ability to give a URL a custom page name, to make the URL more human friendly, e.g. instead of /Page/itemId/14/Default.aspx, you can have /Page/itemId/14/My-Article.aspx. The API for achieving this is via DotNetNuke.Common.Globals.FriendlyUrl(which just calls DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl).

This FriendlyUrl method has some overloads which take a path and pageName parameter, where you can specify the meaningful querystring parameters via path and the friendly page name via pageName. Following an example from Bruce Chapman, that might look something like this:

FriendlyUrlProvider.Instance().FriendlyUrl(tab, "~/Default.aspx?TabId=" + tab.TabID, "My_Custom_Page_Name.aspx")

Problem

My issue with this approach is that the URL only gets the parameters that I directly specify in that path parameter. Using the standard, non-friendly approach with Globals.NavigateURL, I'll get additional parameters based on the current context and the portal's settings (most notably, language). I'd prefer to not have to reimplement/copy the NavigateURL implementation, but I don't see any other choice. Bruce has an issue in DNN's Gemini issue tracker that would add a pageName parameter to Globals.NavigateURL, but it's been sitting there for quite a while without getting any attention.

Another issue is that I have to hard-code ".aspx" onto the page name, rather than letting the friendly URL provider decide what the extension should be (or whether to go without an extension altogether).

Am I missing something, or is copying the core NavigateURL my best option for getting full support for friendly page names in URLs?

1
In my situation I need to facilitate a few hundred thousand pretty URL's, all lowercase with hyphens separating tokens. I made a few lightweight updates to the DNN UrlRewrite, FriendlyURL, and one utility function. Upon app start, the Source / Destination pairs are inserted into the App State where UrlWrite can convert Source (pretty requested URLs) into ugly (application readable URLs) and FriendlyURL does the reverse (so that Nav Menu providers emit the pretty URLs). My solution does not replace the built-in DNN functionality, only enhances it.Brian Webster
I've tried a few times to interpret your specific needs, but I can't tell if my personal solution would be any help. If it sounds appealing, let me know and I can elaborate a bit. I made it so that it should take about 1 to 2 hours to implement and test on future DNN versions. I don't like having to modify the DNN core. I wish the URL Master would have suited my needs, but it didn't scale well for this app.Brian Webster
I'm wanting the best solution for all environments (for situations where I can't replace the URL rewriter). I'm trying to understand if this functionality really isn't built into DNN in any meaningful way, even though there's an API, or if I'm missing something that will get this to work without taking DNN core out of the picture.bdukes

1 Answers

0
votes

One slight enhancement to the above is to call Globals.ApplicationURL(tabId) to get the "~/Default.aspx?TabID=x" part of the URL. You still have to manually add the language parameter, though...