This project is read-only.

Project Description

FUP is a DotNetNuke module and friendly url provider.
It runs extensible and goal oriented rewriting strategies without the need for reversible transformations.

What's a friendly url provider?

Friendly url rewriting is the process of turning original urls with numerical query string parameters, usually primary keys for database entities, which core components and third party extensions rely on to process and display the appropriate information, into human readable labels, e.g. the names for those DB entities, often inserted into the url path rather than in the query string.

This gives the illusion that the site is made of directories of html documents, making those urls easier to manipulate for end-users, and yielding better SEO rankings.

Accordingly, url rewriting is involved when building the web page, DNN integrators making use of the corresponding DNN API each time they need to display a URL somewhere in their module, and at the beginning of each Http Request cycle, when the incoming Friendly Url needs to be reversed into its original counter-part, before DNN and further components can process the request as expected.

DNN offers an extension point in the form of a provider to perform the actual friendly url generation when the API is called, and the reversing can be customized with a dedicated HttpModule registered on the begin request event.

What's the usual way to do it?

The conventional approach to this uses a reversible pipeline, Friendly Urls being built incrementally with a series of transformations over the original url, which in turns is recovered applying the invert process at the start of each request processing.
This involves several constraints:
  • First, you have to make sure that the process is indeed reversible. This is particularly tricky considering that often, friendly labels injected into the url have some kind of irreversible characters normalization applied (removing invalid or accented chars, applying lower case etc.), and there is no universal rule to split an arbitrary url path into the distinct components to be reversed. As a consequence, although this tedious work was accomplished natively to turn a page number (tabid) into the corresponding path, other entity names are usually appended into the friendly url right next to their numerical counter-part to ease with their recovery, ignoring completely the label during that phase.
  • Then there is not so much flexibility into it. Any transformation within the pipeline must have a precise inverse counterpart, and absolutely not interfere with what’s happening next, so there is not so much you can do, without having to provide a lot of information for the system not to break. Accordingly, when custom extension providers are permitted, it is up to the developer to provide the means and UIs for customization and to make sure everything done can be undone.
  • Finally it is prone to performance loss. With each additional transformation supported, the whole pipeline gets heavier, which is pretty critical considering it is called many times during page build up and at the start of each request.

How is this one different?

Friendlier Url Provider has been proposing an alternate method to achieve the same goal. The original url is only considered for the parameters it contains, and you get to define the precise pattern you want to write making use of those parameters, a bit akin to Url routing in MVC and web API, yet without any reversible transformation involved. The resulting friendly url is then stored in DB, so that on the way back, that mapping is used to recover the original url. The advantages are numerous:
  • Without a need for reversibility, you can completely get rid of the remaining numerical parameters and concentrate only on the labels you want to display.
  • There is significantly more variations to the urls you can produce, you can change the order of things and the string processing involved without the extension developer having to actually take responsibility for those choices.
  • The mechanisms involved are shared for all extensions and the sub-provider developer only has to concentrate on producing a list of labels available with the corresponding parameters involved. A module provider can take 100 lines of code, where it would need traditionally several thousands.
  • There is much less of a performance penalty, only the targeted labels are computed and the original url is instantly reversed on the way back.

Rewriting strategies

Within the configuration, you can define default, page and module based strategies.
Each strategy includes a set of dedicated settings, including the rewriting rule, the caching behavior, the alias to use etc.

Advanced strategy features include:
  • 301 redirects: As you update your site and change the labels used in your friendly urls, obsolete mappings are kept and can be automatically redirected to their newer counter parts without a need to individually keep track of those changes, which can be a huge time saver.
  • sub strategies are made possible from custom conditions as dynamically compiled expressions to be evaluated. Since most of the environment context is available within those expressions, you can discriminate against pretty much any condition you can think of.
  • Html Filter is an additional engine to the original DNN url rewriting API. It goes through the Http Response Html tags to process Urls, including those not originally processed such as static urls included in articles or Html modules, or non pages urls, such as DNN file system "linkclick" urls, or Ventrian Newsarticle thumbnails Urls, where thumbnail dimensions are injected into the original file name.
  • Urls can be cached with a custom timeout, but additionally Output Caching strategies can be associated with the corresponding pages, and precisely controlled with many custom settings.

Rules and groups

Rewriting rule don't intend to describe the way you transform the input urls. Instead, you define the pattern the target rewritten url should have. Those patterns are made of so called url groups of distinct types. Some groups represent parts of the orginal url, whereas some others are computed from general or module specific providers.
An optimized dictionary of all computed mappings is stored in DB and serves reversing the friendly url on incoming requests.

Included Providers

Most module include their own entities, the ids of which are often used in corresponding urls. Those entities usually have friendly names or labels to be used instead. Each module provider introduces a series of fields available and the query string ids they are based on. The engine automatically checks whether those input parameters are included in the original url.

Module specific providers are usually very short and easy to develop and they do not require an associated user interface for extended customization, directly available from the main UI.

Here's a list of providers included in the default install:
  • DNN Blog
  • DNN Forum
  • DNN Wiki
  • Catalook Store
  • ZLDNN DnnArticle
  • ZLDNN Multimedia Gallery
  • Ventrian Newsarticle + Newarticle Thumbnails (Html filter)
  • Ventrian Property Agent
  • Datasprings OptinEmail
  • Engage Publish
  • Aricie Module Workflows
  • Aricie Lucene Search

Variable patterns

One of the most advanced features is the possibility to define rewriting rules with variable patterns using regular expressions. A dedicated Radix Tree structure was introduced in order to enable scaling and fast pattern matching.

Last edited Jun 22, 2016 at 2:37 PM by Aricie, version 16