New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DNN Outside HttpContext limitations

All DNN requests run within what’s known in an HttpContext, i.e. a context of an http web request. I say all, but this is not entirely true. Nearly all DNN requests run through HttpContext. There are a number of circumstances under which your code will not run within an HttpContext. This can be because the code runs as a result of a scheduled service or because you’ve decided to spark off a new thread. If you do have code that runs outside HttpContext, there is an evil ‘bug monster’ lurking in the core. This is the PortalSettings object. More specifically, the GetCurrentPortalSettings static method on this PortalController that returns this object.  Allow me to explain.

What is the PortalSettings object? It is a collection of parameters that define in which DNN portal context the user is. So this includes most of the parameters set by the Administrator under the Site Settings, but also some context parameters such as the HttpAlias (remember that a single portal can respond to/have multiple aliases). The portal settings are made in the Url rewriter module. The latter is a piece of code that runs on every regular Http page request to DNN. It analyzes the url and distills the correct portal from this. The portal parameters are loaded and the extra contextual variables are added to this. The whole object is then stored in the variables that all subsequent code that runs in that thread can draw from. The GetCurrentPortalSettings method draws this object from the place it is stored.

So what is the PortalSettings used for? Well, in short it is used all over the place. It is the default method to find out what the current portal is, amongst others. If you search in the DNN source code for usages of GetCurrentPortalSettings you’ll get a very, very long list of calls.

So what’s the issue? The issue is that outside the HttpContext the PortalSettings object is not available. “A”, I hear you say, “that makes sense as we have no HttpAlias”. Well, yes and no. Sometimes we need to access portal settings from our code that is running outside the HttpContext. It is quite thinkable that I have a PortalID and I’d like to have my Portal’s Settings. Hmm, but we have the PortalInfo object, no? The PortalInfo is a lot like the PortalSettings. It is the container for the settings under Site Settings, so it only misses the contextual info like the HttpAlias. Correct. We could use this object to access our settings. But unfortunately a lot of DNN methods rely on the PortalSettings object. So many (and I mean a lot) of calls to the framework will start to throw exceptions. The aforementioned usages list underlines what the extent is of this ‘problem’.

To add to the predicament, later (I believe post 04.06.xx) versions of the Url Rewriter no longer set the PortalSettings object if the call is not to a DNN or other aspx page. I was once faced with a lot of rewriting as I was using an .axd extension to handle some calls to my code.

An illustration

I have a scheduled task that checks in the database for notifications to be sent. For these notifications I use token replace and a url to the site. The url needs an HttpAlias so this immediately brings home the problem. But DNN’s token replace (used to personalize text blocks) heavily relies on the PortalSettings object. This object is unavailable as it is a scheduled task.


The solution to this problem is not easy. My first thought was:

1.       Introduce a site setting where the preferred HttpAlias is set. Admins set this and are aware that for instance emails sent outside HttpContext will link back to this address in my example.

2.       GetCurrentPortalSettings gets a sister where you specify a PortalID. If the PortalSettings have already been constructed and the IDs match, then use those. If not, than reconstruct.

3.       Start carrying the PortalID throughout the code that relies deep down on the PortalSettings object

Point 3 above is probably the most problematic of the changes. It will change the signature of many methods.

Another approach would be to ‘kick’ DNN to set the PortalSettings in the current thread. You could have a method SetCurrentPortalSettings which takes a portal ID and sets the object that all subsequent calls can use through GetCurrentPortalSettings.


In my opinion the reliance on PortalSettings within the DNN framework is such that we need a proper way to have them outside an HttpContext.


Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out