<rss version="2.0" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"><channel><title>AppTheory</title><link>http://www.apptheory.com</link><description>RSS feeds for AppTheory</description><ttl>60</ttl><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/544/DotNetNuke-And-The-Elusive-lsquoCannot-redirect-after-HTTP-headers-have-been-sentrsquo.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=544</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=544&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke And The Elusive &amp;lsquo;Cannot redirect after HTTP headers have been sent.&amp;rsquo;</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/544/DotNetNuke-And-The-Elusive-lsquoCannot-redirect-after-HTTP-headers-have-been-sentrsquo.aspx</link><description>Today I went to log into a clients staging site and received the following error ‘Cannot redirect after HTTP headers have been sent.’ from the YSOD (Yellow Screen Of Death). </description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 06 Dec 2009 20:43:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:544</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/540/Home-From-OpenForce.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=540</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=540&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Home From OpenForce</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/540/Home-From-OpenForce.aspx</link><description>As most of you who read this know, AppTheory had a booth at OpenForce ‘09 last week in Las Vegas where we handed out flyers and discussed DotNetNuke with anyone who stopped by and wanted to chat. Surprisingly, there were many people who had tons of questions.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 20 Nov 2009 20:40:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:540</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/535/AppTheory-wins-the-DotNetNuke-Best-Ecommerce-Site.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=535</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=535&amp;PortalID=2&amp;TabID=411</trackback:ping><title>AppTheory wins the DotNetNuke Best Ecommerce Site</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/535/AppTheory-wins-the-DotNetNuke-Best-Ecommerce-Site.aspx</link><description>AppTheory won the DotNetNuke Open Force 2009 Community Choice Award for Best Ecommerce Site!</description><dc:creator>bryan andrews</dc:creator><pubDate>Wed, 18 Nov 2009 16:35:16 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:535</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/534/Extracting-DotNetNuke-User-Information-With-SQL.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=534</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=534&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Extracting DotNetNuke User Information With SQL</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/534/Extracting-DotNetNuke-User-Information-With-SQL.aspx</link><description>It is not uncommon to have a client request a list of site users in a particular role. You can obviously get this information from the DotNetNuke user interface but its very easy to get this directly from the tables in SQL Management Studio and then export to a CSV or Excel file for easy distribution. Below is an example of finding all users for a particular portal.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 08 Nov 2009 22:29:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:534</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/528/DotNetNuke-lsquoIs-Web-Farmrsquo-Changes.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=528</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=528&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke &amp;lsquo;Is Web Farm&amp;rsquo; Changes</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/528/DotNetNuke-lsquoIs-Web-Farmrsquo-Changes.aspx</link><description>I was on one of our client sites this week and under Host Settings I noticed something odd. I saw that the “Is Web Farm” setting was set to true, the reason this is odd is because I know this particular install is NOT on a web farm as the setting says (shown in the screen shot below). So my next logical step was to jump over to the web.config for the install and turn this off.      Well, as I opened up the web.config and located the “EnableWebFarmSupport” in the appSettings section it was already set to false. At this point, I was puzzled so I decided to reach out to Charles Nurse as I knew DNN Corp. had created a new caching provider offered with DotNetNuke Professional Edition. While this install was using CE, I suspected that the new provider for PE could have required changes in the core itself. Here is what he had to say:  “In 5.1 we modified the “IsWebFarm” detection to detect if there are more than one server in the WebServers table.” Well, it just so happens this particular client we recently upgraded them to 5.1.x from a 4.9.x install which explains why I haven’t noticed this before (as for why we have more than one server in the WebServers table, that is for another blog). Continuing my conversation with Charles, he also informed me of some more details and changes to come. I think it is best to highlight those with a quick bullet list.     In 5.2 this is modified again.    In 5.1.x (All versions, all editions), the setting in the web.config means nothing.    The File Based Caching Provider (shipped with CE and PE) will be switched to, again, rely on the setting in the web.config.    The Web Request Provider (the one with PE only) will continue to rely on the WebServers table (ie. auto detection).    Thanks to Charles Nurse who saved me some discovery time!</description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 02 Nov 2009 04:56:33 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:528</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/522/DotNetNuke-SSL-Wild-Card-Certificates.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=522</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=522&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke, SSL, Wild Card Certificates</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/522/DotNetNuke-SSL-Wild-Card-Certificates.aspx</link><description>In a previous blog I discussed how DotNetNuke can enforce SSL at the page level. Well, going a bit further into the SSL world within DotNetNuke uncovered a few more notes worth keeping in mind. First, you can utilize wild cart certificates using the built in DotNetNuke SSL implementation. To do this, go to Admin –&amp;gt; Set Settings (as host) and locate the SSL section and expand it. What you will see is similar to the screen shot below. You then need to set the SSL URL (the domain the certificate, standard or wildcard, is attached to).      Setting the SSL URL will route all SSL requests to that domain (in the example, www.dnnforums.com). Setting the Standard URL will route all non-SSL requests to the domain (in the example, www.dnnforums.net). Now, the good news here is that with this setup, all my http requests get routed to my .net domain and all https requests get routed to my .com domain. After testing, I have verified it works fine and properly routes domains based on http and https. However, there is one slight issue here. It appears that when doing this the core took only the anonymous use case in here. What that means, if your domains are different you are going to be prompted for a login after a switch depending on which domain you are on (of course, this only matters if the domains are different like our example here). Hopefully, the core can be altered to add a cookie for this domain as well during the login process. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 26 Oct 2009 14:49:08 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:522</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=520</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=520&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke, Telerik &amp;amp; Ajax</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspx</link><description>If you have worked with Telerik you are probably familiar with the “RadAjax” component which is a part of the ASP.NET Controls suite from them. Generally, you throw a RadAjaxManager on your page/control and you are pretty much set to have full Ajax functionality in your application. From here you can include/exclude controls and add a loading panel that can be shared by all panels on the page. Finally, you code your application pretty much like before, adding business logic in Page Load and button click events, and poof you have a full ajaxified application. While this works pretty much the same in any DotNetNuke module, it is important to do two things in your module otherwise you may not get the results you expect. The first is to set the SupportsPartialRendering equal to true. If just starting, this is done from the module definition for the specific control. Otherwise, it is done from a node in your dnn manifest file for your module. Next, the other thing you need to do is on Page_Init of your control you need to place a script manager on the page (if Ajax is installed). You can do this using the following code:    1: If DotNetNuke.Framework.AJAX.IsInstalled Then   2:     DotNetNuke.Framework.AJAX.RegisterScriptManager()   3: End IfOR:   1: if (DotNetNuke.Framework.AJAX.IsInstalled) {   2:     DotNetNuke.Framework.AJAX.RegisterScriptManager();   3: }</description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 19 Oct 2009 14:47:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:520</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/515/My-DotNetNuke-Core-Upgrade-Process-Simplified.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=515</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=515&amp;PortalID=2&amp;TabID=411</trackback:ping><title>My DotNetNuke Core Upgrade Process (Simplified)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/515/My-DotNetNuke-Core-Upgrade-Process-Simplified.aspx</link><description>The first step in my process of testing a DotNetNuke upgrade is to get a duplicate copy of the site you are going to upgrade. This involves taking a copy of the file system, as well as the database and restoring them as&amp;#160; a new site. I always use the same names for the directory/virtual directory and database except I add “TEST_” as a prefix to clearly identify it. After I get everything copied, I then setup my new IIS virtual web server and assign it some new host headers (ie. test.domain.com) and make sure I have a nice robots.txt in the directory that blocks everything (. The next step is to add a portal alias directory into my PortalAlias table on in my database. Once we have this and the connection string in the web.config has been updated, we are ready to test the copied site to make sure everything is working PRIOR to attempting the upgrade (This is a minor but important detail I find most people overlook). Once I have the site loaded and I can login once as host I make sure my control panel is set to the core one (as sometimes we @ AppTheory use our own custom version) because sometimes this changes and will cause immediate errors after the upgrade and you can only fix directly in db, so take care of it now if you remember.   One final thing before starting my upgrade, I generally take a backup of my new TEST_ database as well as my new TEST_ directory. This ensures that if my upgrade fails I can quickly roll back and save myself the time it would take to repeat the steps in the first paragraph. To continue, I download the appropriate upgrade package of DotNetNuke and unzip it onto the server. I then grab the release.config and use Beyond Compare to compare it to my copied web.config to see if anything has changed. If anything is different, I merge the changes and save the file as my new web.config for my TEST site. I then copy all files from the Upgrade package over top of my TEST site making sure to replace existing files and that I also replace the web.config with my merged one from the previous step. Now I call up my test URL in my browser and let the process begin. Once the installation finishes, save a copy of success/failure messages (especially if there is a failure) so you can reference it later. Remember, if you have SqlDataProvider install issues you can find those in your siteroot\Providers\DataProviders\SqlDataProvider folder. At this point, all you have left to do is update your modules, providers and any third party controls (so long as you didn’t have other install issues) and do lots of testing. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Wed, 07 Oct 2009 20:44:28 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:515</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=513</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=513&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke &amp;amp; Telerik CSS Clashes</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspx</link><description>This week I was spending more time working with Telerik controls in DotNetNuke modules. While I may have several other future topics to discuss because of this, waiting on a response from Telerik before I do that though, I do have some useful information. Previously, I was using pre DNN 5.x releases to create modules. What I am about to touch on was never a problem in any of those versions. However, moving into DNN (and mainly, the new skin) I found one thing that really annoyed me. I kept seeing bullet points next to (on the left) my RadListBox. About a month or two ago I was working with RadUpload and saw a similar problem there but it went away after I played with some options/properties of that control. In the case of the RadListBox, nothing like this was available. After some research I found out it appears to be some CSS conflict in the Extropy skin (and the key here is I never thought of ‘bullet points’ as a search term).The correction is adding a class to your module.css:    1: .rlbItem     2: {     3:     list-style-type:none !important;     4: }   </description><dc:creator>Chris Paterra</dc:creator><pubDate>Sat, 03 Oct 2009 08:43:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:513</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/512/Let-DNN-manage-workflow.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=512</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=512&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Let DNN manage workflow</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/512/Let-DNN-manage-workflow.aspx</link><description>How you can use AppTheory's content manager to solve workflow needs in your DotNetNuke content management system.</description><dc:creator>Ryan Wofford</dc:creator><pubDate>Fri, 02 Oct 2009 19:35:04 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:512</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=501</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=501&amp;PortalID=2&amp;TabID=411</trackback:ping><title>RadUpload Doesn&amp;rsquo;t Run Under Medium Trust</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspx</link><description>One thing I often take for granted is that DotNetNuke runs under Medium Trust. Of course, you can add modules and this may no longer be the case but out of the box it does work. As a core module developer, we are required to ensure our modules run in Medium Trust environments. However, most of my time is spent working on things for AppTheory where this requirement is often not necessary. Recently I was checking to see if our modules work properly under Medium trust (there is a setting in your DNN web.config file for this) and found that those using Telerik’s RadUpload had problems. After a bit of research I found that it cannot run under Medium trust. Telerik’s explanation is they require reflection (and with this component it does make sense) but I can’t figure out (honestly, haven’t spent much time investigating) what exactly they are doing that can’t be worked around. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 14 Sep 2009 07:08:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:501</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/500/DotNetNuke-Corp-acquires-Snowcovered.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=500</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=500&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Corp acquires Snowcovered</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/500/DotNetNuke-Corp-acquires-Snowcovered.aspx</link><description>DotNetNuke Corp. announced recently that it has acquired Snowcovered, the leading vendor of third-party modules and skins for the DNN platform.</description><dc:creator>Ryan Wofford</dc:creator><pubDate>Fri, 11 Sep 2009 20:18:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:500</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/496/Rendering-embedded-styles-during-a-AJAX-post-back-does-not-work-in-Internet-Explorer.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=496</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=496&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Rendering embedded styles during a AJAX post back does not work in Internet Explorer</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/496/Rendering-embedded-styles-during-a-AJAX-post-back-does-not-work-in-Internet-Explorer.aspx</link><description>I ran into this issue recently and it took me a few to determine the cause. We have a DotNetNuke module that provides live preview of a skin designer. It allows users to choose skins, themes, motifs, and supply custom colors, a logo, and a background image. This all worked perfectly when browsing with Firefox. However, in Internet Explorer it would work on page load (aka synchronous post back) however the changes would not be reflected during asynchronous post back. After a bit of digging I discovered that this is a known issue with Internet Explorer and the only workaround is to move the embedded styles to the head section of your page or apply the styles on the client side via JavaScript after the AJAX rendering is complete. Next week I’ll show you our solution to achieve just this.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Wed, 09 Sep 2009 01:16:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:496</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/495/Custom-Module-Permissions-in-DotNetNuke-5.aspx#Comments</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=495</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=495&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Custom Module Permissions in DotNetNuke 5</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/495/Custom-Module-Permissions-in-DotNetNuke-5.aspx</link><description>For several years DotNetNuke has permitted module developer to extend the types of permissions applied at the module. For example, in the Forum module there was a need to permit “Global Moderators” and “Forum Administrators” as columns in the permissions grid you see when editing a module’s settings. By adding the permissions to the grid, module editors can assign permissions via Role or User just the same as they do when setting “Edit” permissions on the module (if extending it beyond the default admin edit permissions). As module developers, you can take advantage of this by adding more granular permissions to your module and utilizing the core security classes to handle the majority of work for you (ie. you do a check on the current user, similar to how you would check if the user was an admin). If you would like to review an example, you can download the Source version of the Forum module from CodePlex and check it out, or you can take a look at an article that describes it here. (NOTE: The link and the current Forum Source 4.5.3 are examples for DNN 3.x and 4.x ONLY!)  Previously, if I wanted to implement custom permissions in my module the only way to do this was to use IUpgradeable. Unfortunately, IUpgradeable had some problems in its past. In early implementations, there was no guarantee it would fire off and even in later versions (closer to 5.x) it seems that it still wouldn’t fire (on install) in some scenarios. With the release of DotNetNuke 5, custom permissions no longer need to be setup via IUpgradeable and instead you can use new nodes in the .dnn manifest file. If properly placed in the manifest file, the module installtion process will do all the work for you without requiring code or the use of IUpgradeable. An example of this can be seen below.  &amp;#160;             1: &amp;lt;/moduleControls&amp;gt;

       2:  &amp;lt;permissions&amp;gt;

       3:   &amp;lt;permission code=&amp;quot;FORUM_MODULE&amp;quot; key=&amp;quot;FORUMADMIN&amp;quot; name=&amp;quot;Forum Administrator&amp;quot; /&amp;gt;

       4:   &amp;lt;permission code=&amp;quot;FORUM_MODULE&amp;quot; key=&amp;quot;FORUMGLBMOD&amp;quot; name=&amp;quot;Global Moderator&amp;quot; /&amp;gt;

       5:  &amp;lt;/permissions&amp;gt;

       6: &amp;lt;/moduleDefinition&amp;gt;

       7: /moduleDefinitions&amp;gt;
  


&amp;#160;


  
</description><dc:creator>Chris Paterra</dc:creator><pubDate>Thu, 03 Sep 2009 04:25:46 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:495</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/490/Know-Your-Deployment-Environment.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=490</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=490&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Know Your Deployment Environment</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/490/Know-Your-Deployment-Environment.aspx</link><description>In general there are lots of ways to design an application. There are many factors that play into to these choices and deployment environment is just one factor. A good example of this is a recent project in which the client needed video transcoding and cdn upload functionality. If the client had been using a shared hosting plan or did not have control of the server a DotNetNuke Scheduled task would be ideal. However, in this case we knew the client had dedicated private servers that they would be deploying this functionality to. This was a key factor in a design decision to create windows services to handle this functionality instead of using a DNN scheduled task. This gives us a bit of insulation in terms of memroy and cpu consumption since it is being run outside of the IIS arena. It also ensures a large degree of modularity. This is exactly why you should ask about deployment environment BEFORE spec’ing the project.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 25 Aug 2009 20:47:02 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:490</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=489</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=489&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke 5.1.1 and Telerik Skin Objects</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspx</link><description>In a previous blog post I discussed DotNetNuke 4.x to 5.1.1 upgrade issues I found upgrading the www.dnnforums.com site. Well, since that original blog post we have done several module upgrades and found a solution to some previous issues. One of the previous issues identified was the RadMenu skin object available via Telerik not properly showing icon paths for the menu. The reason behind this is that the path to the icons via the IconFile property has changed it’s format. Previously, icons were a relative link but since the 5.x base they have become absolute. We also found that this same situation can occur with the SolpartMenuProvider, which many installs still use today (although it is no longer actively developed, it was updated for DNN 5.x) and can typically be corrected by parsing the skin package. An example of the code change for the Telerik skin object can be found below, the item commented out is the old line of code used while the new one is below it.    1: If ((tab.IconFile &amp;lt;&amp;gt; String.Empty) AndAlso (node.ImageUrl.Length = 0)) Then   2:     Dim imgaddress As String   3:     If (tab.IsAdminTab Or tab.IsSuperTab) Then   4:         'imgaddress = CStr(IIf(Me.Request.ApplicationPath &amp;lt;&amp;gt; "/", Me.Request.ApplicationPath.ToUpper, String.Empty)) &amp;amp; "/images/" &amp;amp; tab.IconFile   5:         imgaddress = tab.IconFile   6:     Else   7:         imgaddress = PortalSettings.HomeDirectory &amp;amp; tab.IconFile   8:     End If   9:     node.ImageUrl = imgaddress  10: End If </description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 21 Aug 2009 16:48:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:489</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/484/DotNetNuke-on-Windows-7-RTM.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=484</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=484&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke on Windows 7 RTM</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/484/DotNetNuke-on-Windows-7-RTM.aspx</link><description>As many know, Windows 7 was released to manufacturers about a week ago. This release was also available to Microsoft Technet and MSDN subscribers with the hopes that some of the group would become early adopters. Having just purchased a new laptop about a month ago, I figured I would give Windows 7 a shot. I choose the Professional Edition as this will allow me to RDP into the machine if I find it necessary in the future. My laptop shipped with Vista Home Premium, so an upgrade to Professional was not an option (although I am OK with a fresh clean install to replace all the crap Dell included). Once I had the operating system installed and all of my programs (including Visual Studio and SQL Server 2008) I was ready to begin my DotNetNuke installation to try things out.  I created a new DotNetNuke folder within the typical inetpub\wwwroot folder, then I copied the latest 5.1.1 source files into the directory (having set the NETWORK SERVICE full control permissions before copying into the directory). Next I went through the typical steps, setup IIS (realized later on that I had to install some services I didn’t have setup via the Control Panel) then created the database in SQL 2008. I then called up the local site to begin the DNN installation process and got all the way to the part of the permissions test and saw it fail. I did some investigation which led me here: http://learn.iis.net/page.aspx/624/application-pool-identities/. The link article describes how to use the Application Pool’s identity and assign permissions. This was a must to go forward and as someone who only adapted Vista 3 months ago, this was some critical information I missed along the way (it appears it was just added to Vista in SP2). </description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 14 Aug 2009 19:56:15 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:484</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/481/HTTP-Timeouts-When-Updating-DotNetNuke-Core-Portal-Framework.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=481</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=481&amp;PortalID=2&amp;TabID=411</trackback:ping><title>HTTP Timeouts When Updating DotNetNuke Core Portal Framework</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/481/HTTP-Timeouts-When-Updating-DotNetNuke-Core-Portal-Framework.aspx</link><description>Depending on how may versions you are jumping between your core DotNetNuke portal framework upgrades; the process may take a considerable amount of time to complete. This is because there are a lot of different operations going on under the hood. These can include database schema changes and config file merging among other operations depending upon what has changed in the DotNetNuke core between the version you are on and the version you are upgrading too. This can be particularly true when performing major version upgrades. In order to facilitate larger upgrades you may need to increase your httpRunitme max values as mentioned in this post. Once again here is a sample of that elements markup:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 10 Aug 2009 01:10:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:481</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/480/DotNetNuke-Enforced-SSL.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=480</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=480&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Enforced SSL</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/480/DotNetNuke-Enforced-SSL.aspx</link><description>For those who are not familiar, DotNetNuke has had built in support for SSL for some time now. There are many different ways this can be setup, depending mainly on how your SSL certificate is set. The primary reason I am bringing this up today is to mention the SSL Enforced bit field (checkbox). This is configured from the Admin menu’s Site Settings module and contained within the Advanced –&amp;gt; SSL Settings section (shown in the image below). When this is checked, this avoids users being able to manually remove the s from https and thus all secure pages are forced into SSL mode, which is very important in shopping cart checkout pages.  </description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 07 Aug 2009 21:31:44 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:480</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/474/DotNetNuke-Core-4x-to-511-Upgrade-Issues.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=474</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=474&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Core 4.x to 5.1.1 Upgrade Issues</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/474/DotNetNuke-Core-4x-to-511-Upgrade-Issues.aspx</link><description>Recently I started upgrading some sites to DotNetNuke 5.1.1, which just released this week. In doing so, I found a few problems. The first thing I noticed is that skins do not necessarily behave the same as they did before. For example, in the 4.x code base I would see my left and right content panes collapse when only the middle content pane contained a module (and thus, the entire center content pane module would take up the full width). Post the upgrade, this was not the case in IE 7 or 8 regardless of which 'fallback skin doctype' I set (which is located under Host -&amp;gt; Host Settings). The solution is to change the skin, but definitely worth a mention here for those who are about to upgrade. An example of what I am talking about (post upgrade) is shown in Figure 1.0 below.   &amp;#160;   Figure 1.0  The next issue I noticed was also skin related. In most skins developed here at AppTheory, we utilize the RadMenu from Telerik. This is done by making use of an enhanced skin object Telerik provides specifically for DNN. Here at AppTheory, we added some additional options but it is almost identical to what Telerik provides. The problem that I found here is the icon paths are not set properly. We generally don’t use icons in for pages but the core itself has them available for all admin and host sub pages (as you probably know). This problem is likely in how Telerik populates the path for the menu icons via code and should be simple enough to fix. An example of what I am discussing can be seen in Figure 2.0.   &amp;#160;   Figure 2.0  So far so good, the two issues we have seen have been skin related and are not a bug in DNN core itself (although there is some obvious changes in how DNN has handled these). The only other problems I have seen, thus far, were either during the install (apparently there is a primary key column change on the EventLog table that caused me an error page shown but no actual problems), or in some custom modules we wrote that make use of Localization. There seems to be some sort of change around DotNetNuke.Services.Localization’s TokenAccessLevel which I haven’t quite figured out yet (or why it was changed). What we were using it for wasn’t really necessary so I seriously doubt most will run into this issue. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Thu, 30 Jul 2009 21:35:25 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:474</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/461/The-Importance-of-Validation-Groups-When-Developing-DotNetNuke-Modules.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=461</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=461&amp;PortalID=2&amp;TabID=411</trackback:ping><title>The Importance of Validation Groups When Developing DotNetNuke Modules</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/461/The-Importance-of-Validation-Groups-When-Developing-DotNetNuke-Modules.aspx</link><description>One pretty common mistake I see a lot of DNN developers make is not using Validation Groups in their modules. This is not such a huge problem with your typical ASP.NET application as you usually know at design time what content you expect to be on any given particular page. However, when you move into a CMS using Validation Groups becomes more important. Let us take for example a scenario where you have developed a categories module and a news module. A common use case may be to place them on the same page. If you do not use unique Validation Groups for each module when you call Page.Validate(); it will validate all controls on the page and not just the module you are attempting to interact with. This is a very frustrating experience for the end user as they have no idea why they cannot submit. This is especially true if the control failing validation is off of the users screen. Below is an example usage from the MSDN page</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 13 Jul 2009 00:54:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:461</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/459/DotNetNuke-Control-Panel-View-Modes.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=459</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=459&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Control Panel View Modes</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/459/DotNetNuke-Control-Panel-View-Modes.aspx</link><description>Every so often we get a panicked DotNetNuke user call or email and tell us one of the two below statements. 

Help, all my content is gone!
My user account is screwed up and I cannot edit any modules!</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 05 Jul 2009 23:39:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:459</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/457/The-Onion-Of-URL-Rewriting.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=457</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=457&amp;PortalID=2&amp;TabID=411</trackback:ping><title>The Onion Of URL Rewriting</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/457/The-Onion-Of-URL-Rewriting.aspx</link><description>We had a DotNetNuke client report today that they could not directly access .xml or .swf files that they could previously get to from their portal. So of course the first thing we did verify the files in question were actually on the file system, they were. We knew this particular client had moved hosts recently so we checked al the IIS configurations and the file mime types were registered and allowed to be served so that was not it. We were then made aware that the sites 3rd party URL rewriting had recently been updated. This peaked our interest an after a little digging we discovered that with this particular URL rewriter you had to explicitly ignore file extensions through regular expression matching exposed as a property on the friendly URL provider. After adding the ignores for said extensions everything was back to normal. So if you see anomalies in content being served and you have verified IIS is setup correctly. Then the next place to look on a DotNetNuke installation is typically the portals friendly URL provider.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 29 Jun 2009 00:35:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:457</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/452/Conditionally-Redirecting-From-A-Custom-404-Error-Page.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=452</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=452&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Conditionally Redirecting From A Custom 404 Error Page</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/452/Conditionally-Redirecting-From-A-Custom-404-Error-Page.aspx</link><description>In the comments of last weeks post a good question was asked: “I have multiple portals and I want to handle redirections differently for each, how can I achieve this?”. The short answer is you have to parse some of the query string parameters passed on by the ASP.NET ISAPI. Luckily for you I have already done this and have an example implementation to share. If you want to examine the original URL request you may do so like this:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 15 Jun 2009 00:42:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:452</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/453/The-Scourge-Of-Pasting-From-Microsoft-Word-Into-Rich-Text-Editors.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=453</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=453&amp;PortalID=2&amp;TabID=411</trackback:ping><title>The Scourge Of Pasting From Microsoft Word Into Rich Text Editors</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/453/The-Scourge-Of-Pasting-From-Microsoft-Word-Into-Rich-Text-Editors.aspx</link><description>One of the biggest challenges you face with user input apart from scripting attacks is the general tag soup that is produced when pasting from arbitrary source from a clipboard into rich text editors. A common example would be a blog module where the post body field is entered into a rich text editor in the user interface. DotNetNuke has built in functions in DotNetNuke.Common.Utilities.HtmlUtils. While I have found these useful the .Clean() method also seems to remove line breaks which tends to be problematic for us. At AppTheory we have created a DotNetNuke html provider for Telerik’s Editor control which allows us to have much more granular cleaning/formatting options when capturing user input. Specifically, you would want to look at the ‘StripFormattingOnPaste’ property of the Telerik Editor to see all of your options. Currently they are as follows:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 14 Jun 2009 23:21:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:453</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/433/DotNetNuke-MSBuild-Tasks.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=433</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=433&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke MSBuild Tasks</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/433/DotNetNuke-MSBuild-Tasks.aspx</link><description>After upgrading CruiseControl.NET earlier this month, I thought about how it might be beneficial to remove our dependency here on nAnt. Don’t get me wrong, nAnt has been a great little utility that has helped me and our team (including the DotNetNuke Core itself) for many years now. However, it certainly has presented new problems in my move to 64 bit computing and it certainly isn’t getting the attention it once did. On the other hand, MSBuild was utilized by nAnt to do the actual building so why not remove what is essentially an extra piece of the puzzle.   Well, today in the DotNetNuke Forums I saw a post that pointed to a CodePlex project that contains some tasks. I haven’t spent much time with it yet, but I did notice it has an installer which really just puts a new folder and a DLL in your MSBuild folder. For those of you that are using a tool such as CCNet, remember this will need to not only be installed on your local development machines but also on the server itself. In addition, you will need to have the MSBuild Tasks project installed on those same machines (the developers and the servers). I have a feeling that I will be reviewing this over the weekend and will have much more to write about next week.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 01 May 2009 21:19:38 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:433</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/421/DotNetNuke-Community-vs-Professional-Editions.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=421</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=421&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Community vs. Professional Editions</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/421/DotNetNuke-Community-vs-Professional-Editions.aspx</link><description>Since November when a Professional Edition of the DotNetNuke Core was announced, there has been a lot of speculation of what this means to the community.&amp;#160; Even those within the Core team itself were not sure what this meant. Well, this week we received two important blog posts that should hopefully clear up not only the difference between the two, but a Roadmap for what is to come. In the first post, here, Nik Kalyani explains the business model as well as an introduction to what the differences between the two editions are. In the next blog article from Nik, here, he introduces the Roadmap. In this second post he also mentions how they determine what should be on the Roadmap.   So, hopefully, this should clear up some confusion amongst community members as to what is available. It also sheds some light on what is in progress now and for the remainder of this year. Please do keep in mind, this is a roadmap for 2009 and not the next major release. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Tue, 21 Apr 2009 23:07:01 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:421</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/408/Microsoftrsquos-Public-Sector-Play.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=408</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=408&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Microsoft&amp;rsquo;s Public Sector Play</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/408/Microsoftrsquos-Public-Sector-Play.aspx</link><description>Web-based apps and cloud computing could be the future for Government entities.</description><dc:creator>Ryan Wofford</dc:creator><pubDate>Tue, 07 Apr 2009 16:49:10 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:408</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/382/DotNetNuke-Skinning-Defaults.aspx#Comments</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=382</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=382&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Skinning Defaults</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/382/DotNetNuke-Skinning-Defaults.aspx</link><description>When upgrading a pre DotNetNuke 4.7 site sometimes the  element is not written to the DotNetNuke.config file. This will result in host/admin being unable to view the skin tab. You will instead be presented with the following error:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 01 Mar 2009 19:57:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:382</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/292/DotNetNuke-Module-Online-Help.aspx#Comments</comments><slash:comments>2</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=292</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=292&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Module &amp; Online Help</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/292/DotNetNuke-Module-Online-Help.aspx</link><description>DotNetNuke provides two ways to associate help with any module. The first way is referred to as module online help and will touch on it in a moment. The second way, referred to as module help, is controlled via localization and module actions.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 08 Dec 2008 15:26:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:292</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/290/DotNetNuke-Open-Force-08-Vegas.aspx#Comments</comments><slash:comments>2</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=290</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=290&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Open Force '08 - Vegas</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/290/DotNetNuke-Open-Force-08-Vegas.aspx</link><description>5 of the AppTheory Team (Bryan Andrews, Chris Paterra, Scott Schecter, Ryan Wofford, Max Schneider) went out to Vegas this year for the Open Force conference and saw many of the usual suspects.</description><dc:creator>bryan andrews</dc:creator><pubDate>Fri, 05 Dec 2008 20:13:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:290</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/246/Pane-Level-Skinning.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=246</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=246&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Pane Level Skinning</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/246/Pane-Level-Skinning.aspx</link><description>DotNetNuke separates the UI (skin) from the actual content which allow us to easily change the page layout graphics. To specify the skin, we can do this at a variety of levels.</description><dc:creator>Ann Chanyoursang</dc:creator><pubDate>Tue, 28 Oct 2008 15:20:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:246</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=238</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=238&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke HTML Providers</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspx</link><description>A recent forum post on the DotNetNuke site had me thinking about the available DotNetNuke HTML Providers. Many people use DotNetNuke for their web site framework because, like me, they don't want to re-invent the wheel. Thousands of hours have been spent on the framework's development, not to mention the thousands of hours of development time spent on providers, skin objects, modules, etc. I have no idea exactly how many hours I have spent developing the forums module but I would say its multiple thousands of hours over a few years.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sat, 25 Oct 2008 22:24:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:238</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/205/Working-with-Language-Packs-in-DotNetNuke-4x.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=205</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=205&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Working with Language Packs in DotNetNuke 4.x</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/205/Working-with-Language-Packs-in-DotNetNuke-4x.aspx</link><description>If you are developing a module or simply want to install some additional language packs for your DotNetNuke portal, you first need to obtain some language packs. Depending on the language you wish to install, there are many resources available. While I will leave obtaining those resources up to you, I will say that if you are just trying to follow along or see how the language packs work that you can obtain some to work with from the German DotNetNuke User Group's site. Once registered on the site, you can download a language pack for your core installation in German and you can also obtain one for one of the core modules, such as the DotNetNuke Forum from this site (just make sure you match your download versions with your installed versions).</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sun, 28 Sep 2008 19:16:44 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:205</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/195/The-right-community-tools-for-the-job.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=195</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=195&amp;PortalID=2&amp;TabID=411</trackback:ping><title>The right (community) tools for the job.</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/195/The-right-community-tools-for-the-job.aspx</link><description>The bottom line is--if you have the desire to create your own social networking or social media site around your brand, DNN has the right tools for the job. The question that remains is--does your brand have the right culture for a community?
</description><dc:creator>Ryan Wofford</dc:creator><pubDate>Wed, 24 Sep 2008 15:09:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:195</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/181/DotNetNuke-Sites-with-Hundreds-of-Pages-amp-Caching.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=181</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=181&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Sites with Hundreds of Pages &amp;amp; Caching</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/181/DotNetNuke-Sites-with-Hundreds-of-Pages-amp-Caching.aspx</link><description>There are many web sites out there that require hundreds of pages of content. Because the content in DotNetNuke sites is dynamic, it is stored in the database unless it is a file or image in which case it may or may not be stored on the file system. Similar to most CMS frameworks available today, DotNetNuke enables what use to take hundreds of pages of HTML to be housed in a single page. This is accomplished using a TabID in DotNetNuke, and also programming modules to dynamically load their own content based on some parameters. These parameters will vary based on the specific module, but consider a Blog module. A single blog module instance resides on a single page within DotNetNuke (thus resulting in a single TabID). Additional parameters in the URL, such as EntryID for the blog module, tell the blog module how content should be loaded.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Wed, 17 Sep 2008 06:22:47 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:181</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/141/Avoiding-the-DotNetNuke-Admin-Skin.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=141</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=141&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Avoiding the DotNetNuke Admin Skin</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/141/Avoiding-the-DotNetNuke-Admin-Skin.aspx</link><description>Typically, DotNetNuke modules have multiple interfaces seen by end users. These interfaces can be something as simple as a control designated for creating new or editing existing content for a module. For example, the core Text/HTML module has an edit interface that is used to add or modify the content displayed when site visitors see the Text/HTML module on a DotNetNuke page.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sun, 24 Aug 2008 22:21:17 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:141</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=140</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=140&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 1: The Development Environment)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspx</link><description>The majority of developers who see this blog are probably use to collaborating with other developers on projects. However, many developers who have spent only a limited amount of time on DotNetNuke development may find the process somewhat overwhelming. This is because even though DotNetNuke is an ASP.NET application, it is a specific framework with its own API. As with other frameworks, sometimes only experience or the view point of someone with experience can permit you to identify common problems before they occur. While the team here at AppTheory cannot say we have seen it all, as something new always pops up, we have plenty of experience with development team collaboration and DotNetNuke. In an effort to share some of our experiences, I have put together some of best practices we find vital to a successful project.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sun, 24 Aug 2008 21:59:06 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:140</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/126/DotNetNuke-and-ADA-Compliance.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=126</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=126&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke and ADA Compliance</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/126/DotNetNuke-and-ADA-Compliance.aspx</link><description>In our never-ending quest for new business, I have come across more than a few
RFPs for web site and portal design, which mandate that the site contain
accessible features for individuals with disabilities...
</description><dc:creator>Ryan Wofford</dc:creator><pubDate>Wed, 20 Aug 2008 16:37:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:126</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/120/Open-Force-2008-Vegas.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=120</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=120&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Open Force 2008 - Vegas</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/120/Open-Force-2008-Vegas.aspx</link><description>AppTheory has reserved its booth for the 2008 Open Force in
Las Vegas -- Nov 10-13.
</description><dc:creator>Bryan Andrews</dc:creator><pubDate>Mon, 18 Aug 2008 00:38:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:120</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/36/How-to-make-a-webmaster-happy-pt1.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=36</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=36&amp;PortalID=2&amp;TabID=411</trackback:ping><title>How to make a webmaster happy pt1</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/36/How-to-make-a-webmaster-happy-pt1.aspx</link><description>You know that downtrodden individual working in your organization that always seems overworked?
</description><dc:creator>Danny Gladman</dc:creator><pubDate>Fri, 25 Jul 2008 21:06:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:36</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/27/dnngallerynet.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=27</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=27&amp;PortalID=2&amp;TabID=411</trackback:ping><title>dnngallery.net</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/27/dnngallerynet.aspx</link><description>DNNGallery.net is a repository of very nice, clean-looking, well-designed skins for DotNetNuke... </description><dc:creator>Ryan Wofford</dc:creator><pubDate>Mon, 21 Jul 2008 22:18:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:27</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/22/AppTheory-and-DotNetNuke-DNA.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=22</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=22&amp;PortalID=2&amp;TabID=411</trackback:ping><title>AppTheory and DotNetNuke "DNA"</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/22/AppTheory-and-DotNetNuke-DNA.aspx</link><description>AppTheory has been working with DotNetNuke “DNA” since the announcement of ASP.Net Beta 2 at TechEd Atlanta (June of 2001). This conference marked the “Go Live” release of the ASP.Net platform and also the first release of IBUYSPY Portal and Storefront samples which would later become DotNetNuke. This GoLive release and the compelling code “sample” –IBUYSPY -- built by Virtigo for Microsoft, marked the shift from ASP to ASP.net for AppTheory.
</description><dc:creator>bryan andrews</dc:creator><pubDate>Wed, 02 Jul 2008 04:49:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:22</guid></item></channel></rss>