Learn More





DNN Community Blog

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.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
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 (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (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)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?