<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/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/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/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/509/Easily-Identify-Missing-Localization-Keys-in-DotNetNuke.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=509</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=509&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Easily Identify Missing Localization Keys in DotNetNuke</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/509/Easily-Identify-Missing-Localization-Keys-in-DotNetNuke.aspx</link><description>One thing I find myself having to remind our developers at AppTheory, from time to time, is how to easily identify missing localization elements in the user interface. This can be done by setting the “ShowMissingKeys” property in the web.config. If you develop locally by starting with the development.config (as your web.config), this will already be set for you. When set to true, this will show a [L] in front of all items that are properly localized. If something does not display an [L] in front of it, it is not localized. While a very simple concept, it is something I have found myself explaining several times over again and figured it was worth repeating here.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 25 Sep 2009 21:02:45 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:509</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/507/Convert-A-ASPNET-Web-Site-Project-WSP-To-A-Web-Application-Project-WAP-Quickly.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=507</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=507&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Convert A ASP.NET Web Site Project (WSP) To A Web Application Project (WAP) Quickly</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/507/Convert-A-ASPNET-Web-Site-Project-WSP-To-A-Web-Application-Project-WAP-Quickly.aspx</link><description>I was asked what the quickest way to convert an ASP.NET Web Site Project (WSP) to a Web Application Project (WAP) was. The client had previously been creating a new project and copying in each file. I can imagine this became quite time consuming for them. Luckily, there is a better and much easier way to do this.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 22 Sep 2009 00:26:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:507</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/469/DotNetNuke-Code-Snippet-IsSuperUserOrAdmin.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=469</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=469&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke Code Snippet: IsSuperUserOrAdmin</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/469/DotNetNuke-Code-Snippet-IsSuperUserOrAdmin.aspx</link><description>Within the DotNetNuke portal framework the DotNetNuke Super User is the host level admin while the Administrator is the portal level admin. In a large percentage of DotNetNuke modules we write the business logic for a Super User or Administrator is the same and as such one little snippet that gets reused quite a bit is as follows.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 26 Jul 2009 23:02:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:469</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/447/Creating-A-Sitemap.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=447</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=447&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Creating A Sitemap</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/447/Creating-A-Sitemap.aspx</link><description>In our ongoing series of posts regarding the sitemap protocol we will now look at creating the actual Sitemap. Just to recap we now know that you may have up to 1000 Sitemaps for your site and that each Sitemap may have a maximum of 50,000 URLs per Sitemap. Before we take a look at the code needed to create the Sitemap let us look back at the example format provided.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 31 May 2009 23:58:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:447</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/446/Creating-A-Sitemap-Index.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=446</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=446&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Creating A Sitemap Index</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/446/Creating-A-Sitemap-Index.aspx</link><description>As I mentioned in last weeks post a site may have up to 1,000 sitemaps per the sitemap protocol. Having multiple sitemaps is primarily useful if you have a very large site with more than 50,000 URLs (the maximum items per sitemap) you would like to enumerate. Before we take a look at the code needed to create the Sitemap Index let us look back at the example format provided   &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt; &amp;lt;sitemapindex xmlns=&amp;quot;http://www.sitemaps.org/schemas/sitemap/0.9&amp;quot;&amp;gt;  &amp;lt;sitemap&amp;gt;  &amp;lt;loc&amp;gt;http://www.example.com/sitemap1.xml.gz&amp;lt;/loc&amp;gt;  &amp;lt;lastmod&amp;gt;2004-10-01T18:23:17+00:00&amp;lt;/lastmod&amp;gt;  &amp;lt;/sitemap&amp;gt;  &amp;lt;sitemap&amp;gt;  &amp;lt;loc&amp;gt;http://www.example.com/sitemap2.xml.gz&amp;lt;/loc&amp;gt;  &amp;lt;lastmod&amp;gt;2005-01-01&amp;lt;/lastmod&amp;gt;  &amp;lt;/sitemap&amp;gt; &amp;lt;/sitemapindex&amp;gt;   I had originally made a HttpHandler to serve both this and create each of the Sitemaps, however I eventually needed to access some properties that DNN stores in HttpContext so I ended up having to make actual ASPX pages to house them. Below is example code to create a Sitemap Index.   using System; using System.Data; using System.Configuration; using System.Collections; using System.Text; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Xml; using DotNetNuke.Entities.Tabs; using DotNetNuke.Framework; using DotNetNuke.Security; using DotNetNuke.Services.Exceptions; &amp;#160; namespace MyCompany.Modules.MyModuleName {  public partial class SiteMapIndex : PageBase  {  private const int MaxSiteMaps = 1000; &amp;#160;  protected void Page_Load(object sender, EventArgs e)  {  try  {  BuildSiteMap();  }  catch (Exception exc)  {  Exceptions.ProcessPageLoadException(exc);  }  } &amp;#160;  private void BuildSiteMap()  {  using (XmlWriter writer = XmlWriter.Create(Response.OutputStream))  {  if (writer != null)  {  writer.WriteStartElement(&amp;quot;sitemapindex&amp;quot;, &amp;quot;http://www.sitemaps.org/schemas/sitemap/0.9&amp;quot;); &amp;#160;  for (int i = 0; i &amp;lt; MaxSiteMaps; i++)  {  writer.WriteStartElement(&amp;quot;sitemap&amp;quot;);  writer.WriteElementString(&amp;quot;loc&amp;quot;,  string.Concat(&amp;quot;http://&amp;quot;, Request.Url.Host, TemplateSourceDirectory,  string.Format(&amp;quot;/SiteMap.aspx?page={0}&amp;quot;, i + 1)));  writer.WriteElementString(&amp;quot;lastmod&amp;quot;, DateTime.Now.ToString(&amp;quot;yyyy-MM-dd&amp;quot;,  System.Globalization.CultureInfo.InvariantCulture));  writer.WriteEndElement();  } &amp;#160;  }  } &amp;#160;  Response.ContentType = &amp;quot;text/xml&amp;quot;;  Response.ContentEncoding = Encoding.UTF8;  }  } }   As you can see this very simple code will created paged links up to 1000 each of which can point to a Sitemap instance. Next week we will look at how to create these Sitemaps.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 24 May 2009 23:51:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:446</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/442/Sitemap-Protocol-Overview.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=442</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=442&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Sitemap Protocol Overview</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/442/Sitemap-Protocol-Overview.aspx</link><description>Adding robust and accurate Sitemaps to your DotNetNuke site and/or module can be very helpful in making your content more discoverable to search engines. Out of the box DotNetNuke provides a basic Sitemap for all of its pages. This default Sitemap can be found at http://www.apptheory.com/sitemap.aspx for example on the AppTheory domain. However, it does not enumerate module content. We’ll cover that in more detail in a later post, so let’s just focus on the protocol for the moment. So what exactly is a Sitemap? sitemaps.org defines it as such:    Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional metadata about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site.  Web crawlers usually discover pages from links within the site and from other sites. Sitemaps supplement this data to allow crawlers that support Sitemaps to pick up all URLs in the Sitemap and learn about those URLs using the associated metadata. Using the Sitemap protocol does not guarantee that web pages are included in search engines, but provides hints for web crawlers to do a better job of crawling your site.  Sitemap 0.90 is offered under the terms of the Attribution-ShareAlike Creative Commons License and has wide adoption, including support from Google, Yahoo!, and Microsoft.  So a Sitemap is basically a UTF-8 encoded XML file containing the URLs within your site. The protocol simply specifies the format of the XML so spiders know how to parse said file. Each Sitemap may contain up to 50,000 URLs. You may also have multiple Sitemaps per site. In order to enumerate multiple sitemaps one may create a Sitemap Index . The Sitemap index is also a UTF-8 encoded XML file. As you may have guessed its purpose is to list each of the site’s multiple Sitemaps if the site has more than one. Below is a brief example of each format.    Sitemap Index          &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;

    &amp;lt;sitemapindex xmlns=&amp;quot;http://www.sitemaps.org/schemas/sitemap/0.9&amp;quot;&amp;gt;

       &amp;lt;sitemap&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/sitemap1.xml.gz&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2004-10-01T18:23:17+00:00&amp;lt;/lastmod&amp;gt;

       &amp;lt;/sitemap&amp;gt;

       &amp;lt;sitemap&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/sitemap2.xml.gz&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2005-01-01&amp;lt;/lastmod&amp;gt;

       &amp;lt;/sitemap&amp;gt;

    &amp;lt;/sitemapindex&amp;gt;
  


Sitemap


  
    &amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;

    &amp;lt;urlset xmlns=&amp;quot;http://www.sitemaps.org/schemas/sitemap/0.9&amp;quot;&amp;gt;

       &amp;lt;url&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2005-01-01&amp;lt;/lastmod&amp;gt;

          &amp;lt;changefreq&amp;gt;monthly&amp;lt;/changefreq&amp;gt;

          &amp;lt;priority&amp;gt;0.8&amp;lt;/priority&amp;gt;

       &amp;lt;/url&amp;gt;

       &amp;lt;url&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/catalog?item=12&amp;amp;amp;desc=vacation_hawaii&amp;lt;/loc&amp;gt;

          &amp;lt;changefreq&amp;gt;weekly&amp;lt;/changefreq&amp;gt;

       &amp;lt;/url&amp;gt;

       &amp;lt;url&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/catalog?item=73&amp;amp;amp;desc=vacation_new_zealand&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2004-12-23&amp;lt;/lastmod&amp;gt;

          &amp;lt;changefreq&amp;gt;weekly&amp;lt;/changefreq&amp;gt;

       &amp;lt;/url&amp;gt;

       &amp;lt;url&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/catalog?item=74&amp;amp;amp;desc=vacation_newfoundland&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2004-12-23T18:00:15+00:00&amp;lt;/lastmod&amp;gt;

          &amp;lt;priority&amp;gt;0.3&amp;lt;/priority&amp;gt;

       &amp;lt;/url&amp;gt;

       &amp;lt;url&amp;gt;

          &amp;lt;loc&amp;gt;http://www.example.com/catalog?item=83&amp;amp;amp;desc=vacation_usa&amp;lt;/loc&amp;gt;

          &amp;lt;lastmod&amp;gt;2004-11-23&amp;lt;/lastmod&amp;gt;

       &amp;lt;/url&amp;gt;

    &amp;lt;/urlset&amp;gt;
  




In my upcoming posts we will cover how to create each of these files for your DotNetNuke portal or module.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 17 May 2009 19:48:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:442</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/441/DNN-Scheduler-How-it-Works.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=441</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=441&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DNN Scheduler - How it Works</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/441/DNN-Scheduler-How-it-Works.aspx</link><description>Today I had an issue with a site not coming up (it was QA). The issue seemed awfully familiar. I restarted the QA site’s database and web server and still I had the issue. Then I remembered what this might be. About two years ago I ran into an issue with the Forum module’s email send task. It seems that something I did broke the ability for my install to restart (meaning I couldn’t get any portals to show up after the application was recycled or server rebooted). Considering someone on my developer team caused the same issue today, I figured it was worth posting a blog on my notes for it.   If a DotNetNuke installation is running the scheduler in Timer mode, issues can arise. The DNN scheduler runs in two modes: : Timer, Request.   When the scheduler runs in Timer mode it 'times' when the next run of the scheduler is based on the previous one. It will run at set time as long as the application doesn't shut down. (ie. crash, no activity for 20 minutes, etc.) In Request mode, which is default, things are a bit different and only another 'request' can cause the framework to check to see if a task needs to run. Instead of explaining in great detail, here is the example when referring to the forum's email queue task.   Request Mode: I post in a forum, this dumps into a table that it needs to be picked up by my scheduled task. If I do nothing else, or nobody else does either (no further requests) then the email will not go out until there is another request on for the site.    Timer Mode: I post in a forum, this dumps into a table that it needs to be picked up by my scheduled task. If I do nothing else, the task will be loaded at the next timed interval it was set for.     Warning: Before ever switching to Timer mode, ensure that absolutely no scheduled tasks (that run) are set to run at APPLICATION_START. If one is and you are in timer mode, this will keep your portal from coming back up once the application restarts.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 15 May 2009 05:07:16 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:441</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/440/Changing-DotNetNuke-Page-Description-And-Meta-Tags-Dynamically.aspx#Comments</comments><slash:comments>6</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=440</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=440&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Changing DotNetNuke Page Description And Meta Tags Dynamically</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/440/Changing-DotNetNuke-Page-Description-And-Meta-Tags-Dynamically.aspx</link><description>Previously we covered how to create SEO friendly links and how to change page and module titles. Now let’s continue in our series of posts regarding SEO (search engine optimization) on the DotNetNuke platform and look at how to change page description and meta tags dynamically from within a DNN module. Previously, I showed how to expose the BasePage property when changing the page and module titles, and it is through this base page that many other elements of the http page may be changed dynamically as well. Below is a sample of setting the relevant properties on the BasePage.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 11 May 2009 00:24:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:440</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/434/SEO-Friendly-Links-In-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=434</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=434&amp;PortalID=2&amp;TabID=411</trackback:ping><title>SEO Friendly Links In DotNetNuke Modules</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/434/SEO-Friendly-Links-In-DotNetNuke-Modules.aspx</link><description>Previously we covered how to change the page and/or module title in a DotNetNuke instance to match the contained content for better search engine optimization. Another great way to improve seo in DNN is to include article titles in the URLS your module creates for detail views. So let’s look at example of what we are looking to achieve before we get into the nuts and bolts of how to do so. Let’s pretend we have a blog module. Now I want to post a blog entry dealing with ‘FooBar Topic A’. Traditionally, without considering SEO a permalink to the article might look something like this in a DNN module:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 03 May 2009 19:36:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:434</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/393/Register-A-DotNetNuke-Scheduled-Task-From-A-SqlDataProvider-File-Within-A-Private-Assembly.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=393</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=393&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Register A DotNetNuke Scheduled Task From A SqlDataProvider File Within A Private Assembly</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/393/Register-A-DotNetNuke-Scheduled-Task-From-A-SqlDataProvider-File-Within-A-Private-Assembly.aspx</link><description>The DotNetNuke scheduler provides the ability to run arbitrary code on a schedule. Often when creating DotNetNuke modules you will want to have some arbitrary code executed in the background at a specific duration or time. You can always register your DotNetNuke scheduled task from Host &gt; SQL, but did you know you can also do this through TSQL in your SqlDataProvider file? Below is an example of how this can be accomplished.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 08 Mar 2009 23:55:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:393</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/371/Return-An-Alphabetized-Listing-Of-DotNetNuke-Usernames.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=371</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=371&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Return An Alphabetized Listing Of DotNetNuke Usernames</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/371/Return-An-Alphabetized-Listing-Of-DotNetNuke-Usernames.aspx</link><description>I had the need in an application the other day to return a list of DotNetNuke usernames ordered alphabetically. The core GetUsers() method returns an ArrayList of UserInfo types. You may be asking yourself since this an Array based type why not just call the .Sort() method on the ArrayList. This was my first thought as well, unfortunately the UserInfo type does not implement IComparable so this call to .Sort() will fail. Below is the workaround I came up with which copies the users to an SortedList type for display.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 23 Feb 2009 02:10:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:371</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/323/Caching-Objects-In-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=323</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=323&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Caching Objects In DotNetNuke Modules</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/323/Caching-Objects-In-DotNetNuke-Modules.aspx</link><description>One of the first things a developer should do to ensure maximum performance of their DotNetNuke module is too cache responsibly when pragmatic to do so. So the ideal candidate to be cached would be something that is not changed frequently but retrieved often. Typically when retrieving information that maybe cached one performs a check upon a known key in some key/value list. If this key is found then the cached content is returned. If no key is found then a new instance is created pushed into the cache then returned to the user. Below is a contrived example of how this might look in code.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 20 Jan 2009 01:35:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:323</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/312/Check-if-an-ASPNET-ScriptManager-is-registered-from-within-a-DotNetNuke-module.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=312</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=312&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Check if an ASP.NET ScriptManager is registered from within a DotNetNuke module</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/312/Check-if-an-ASPNET-ScriptManager-is-registered-from-within-a-DotNetNuke-module.aspx</link><description>When using ASP.NET AJAX from within a DotNetNuke module one needs an instance of a ScriptManger control to be registered. This is normally handles by the DotNetNuke framework on recent versions. Since a module developer has to deal with numerous application environments, its always good to check these things are warn users instead of getting a nasty exception message. Below is an easy way to check that the ScriptManager is registered before attempting to use ASP.NET AJAX.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 12 Jan 2009 02:52:29 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:312</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/308/Setting-Localization-On-A-Dynamically-Loaded-User-Control-In-DotNetNuke.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=308</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=308&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Setting Localization On A Dynamically Loaded User Control In DotNetNuke</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/308/Setting-Localization-On-A-Dynamically-Loaded-User-Control-In-DotNetNuke.aspx</link><description>Often times when developing DotNetNuke modules or any other asp.net application an easy way to modularize certain sections of your application is to create user controls for section(s) of functionality and then load them dynamically based upon some environmental criteria. To achieve this in DotNetNuke is not much different than your standard asp.net application. The primary difference you need to account for is the way DotNetNuke handles localization. The key is to override the init event so that the resource file is hooked up high enough in the application life cycle. Below is some sample code to illustrate the process.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 05 Jan 2009 02:37:40 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:308</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/304/Red-Herrings-And-Full-Databases.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=304</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=304&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Red Herrings And Full Databases</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/304/Red-Herrings-And-Full-Databases.aspx</link><description>Since DotNetNuke framework operations are so intertwined with database engine communications you will occasionally get some pretty sporadic error messages when this communication is interrupted. One such red herring will present itself when your database has no free space left. You will usually get two symptoms when your database has become full.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 29 Dec 2008 02:12:14 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:304</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/293/Could-Not-Load-Type-Errors-For-Non-Existent-Business-Controllers.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=293</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=293&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Could Not Load Type Errors For Non Existent Business Controllers</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/293/Could-Not-Load-Type-Errors-For-Non-Existent-Business-Controllers.aspx</link><description>We recently ran into an issue on a site where we would receive errors such as below for modules that did not implement ISearchable.

Message: System.Web.HttpException: Could not load type 'MyCompany.Modules.MyModule.MyModuleController'

We had verified that the value of the SupportedFeatures column in the modules entry in the DesktopModules table was set correctly to indicate that the module did not support ISearchable. We also verified that the BusinessControllerClass column value was null as it should be. After doing a little research it turns out that the EventQueue was actually the source of the exception. If a module is being upgraded and this process is interrupted the IsComplete column will have a value of 0 for false. If your dnn manifest file had a BusinessControllerClass that did not exist in the dnn file at this time it will cause the event queue class to continue to try and load the non existent business controller producing said error. In order to resolve the issue simply find the EventQueue record that mentions the type in question and delete it.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 08 Dec 2008 02:15:40 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:293</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/289/Adding-H1-tag-to-container-title.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=289</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=289&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Adding H1 tag to container title</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/289/Adding-H1-tag-to-container-title.aspx</link><description>H1 is the HTML element for the first-level heading of a document and it is used to show the most important keywords on a page. It influences your placement in search engines and you should use it when possible.</description><dc:creator>Ann Chanyoursang</dc:creator><pubDate>Fri, 05 Dec 2008 19:17:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:289</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/273/DotNetNuke-ScheduleHistory-Table-and-100-CPU-Usage.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=273</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=273&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke ScheduleHistory Table and 100% CPU Usage</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/273/DotNetNuke-ScheduleHistory-Table-and-100-CPU-Usage.aspx</link><description>DotNetNuke provides a scheduler for running arbitrary code at a designated time or interval via their scheduler classes. It stores the results of this execution in a table called ScheduleHistory. A few days ago we noticed that the db server of a site was pegged at 100% CPU usage. After firing up SQL Profiler and taking a look at some of the long running queries it became apparent that the DotNetNuke scheduler was the code creating the mass amounts of queries to the db server that was keeping the processor pegged. For whatever reason this table had grown to approximately 50,000 records and something in the scheduler classes was trying to load each record. I would of course choke, and then attempt again immediately. This was enough to peg the CPU of the server. One quick and easy way remedy this is to run the below TSQL</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 24 Nov 2008 00:29:18 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:273</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/255/Get-PortalId-In-a-DotNetNuke-Skin-Object.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=255</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=255&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Get PortalId In a DotNetNuke Skin Object</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/255/Get-PortalId-In-a-DotNetNuke-Skin-Object.aspx</link><description>Skin objects are a great way to integrate functionality in your DotNetNuke portal site wide. This can be helpful if you would like to provide a custom search for your modules, etc. In a recent ecommerce project we working on we needed to provide a search skin object to facilitate the searching of products. Sure, you can implement ISearchable in your module and then use the DotNetNuke core search. However, sometimes project requirements dictate additional functionality needs not provided by the DNN core search. DotNetNuke skin objects inherit from a different base class than DotNetNuke modules do. Modules inherit from the PortalModuleBase while skin objects inherit from SkinObjectBase. One issue that you may run into when creating a skin object is the need to get the PortalId of the current portal. There are several reasons you may need PortalId such as locating module instances, etc. The SkinObjectBase does not expose PortalId directly as a public property like PortalModuleBase, however there is a way to get this value. In order to access this value (and other usefule ones) take a look at PortalSettings.ActiveTab. From this you can get both PortalId and TabId which are needed quite often when using any of the DotNetNuke core methods.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 02 Nov 2008 21:39:10 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:255</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/240/Use-A-SMTP-Pickup-Directory-for-Testing.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=240</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=240&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Use A SMTP Pickup Directory for Testing</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/240/Use-A-SMTP-Pickup-Directory-for-Testing.aspx</link><description>Quite often when developing  a module or component for a client we will need to send an email containing some arbitrary information. There are many reasons one might not want to actually send the email out while developing such as security concerns, the need for an actual smtp server and the latency involved in sending the mail across the wire. One quick and easy way to solve this issue is to create a pickup directory in your configuration file. For a full rundown of the  element see this MSDN page.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 27 Oct 2008 00:59:03 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:240</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/234/Using-Telerik-RadGrid-On-DotNetNuke.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=234</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=234&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Using Telerik RadGrid On DotNetNuke</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/234/Using-Telerik-RadGrid-On-DotNetNuke.aspx</link><description>Recently on a project we replaced the standard DotNetNuke GridView's with Telerik RadGrids. There are plenty of reasons we chose to do this such as functionality, flexibility, and esthetics. Locally everything worked as expected, however on our Test and QA installations we were receiving JavaScript errors when viewing any page that contained a RadGrid. After a bit of Google Fu, I ran a few Telerik forum posts that suggested that partial rendering being disabled was the culprit. It seems that DNN does not include PageRequestManager object if this property is disabled, thus causing the error. Below is a quick piece of TSQL that can be used to enable partial rendering for all module controls.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 20 Oct 2008 00:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:234</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/224/HTTP-Timeouts-Uploading-DotNetNuke-Private-Assemblies.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=224</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=224&amp;PortalID=2&amp;TabID=411</trackback:ping><title>HTTP Timeouts Uploading DotNetNuke Private Assemblies</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/224/HTTP-Timeouts-Uploading-DotNetNuke-Private-Assemblies.aspx</link><description>Occasionally when installing DotNetNuke private assemblies you may receive an http timeout. This can be caused by several reasons. Your internet connection could be experiencing problems, but more likely the SqlDataProvider execution is taking too long, and thus causing the timeout. There is an easy way to control this however, and that is the httpRuntime element of the web.config. Below is an example of the httpRuntime configuration element found in the web.config.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 14 Oct 2008 21:44:29 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:224</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/220/Install-Multiple-DotNetNuke-Private-Assemblies-At-Once.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=220</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=220&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Install Multiple DotNetNuke Private Assemblies At Once</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/220/Install-Multiple-DotNetNuke-Private-Assemblies-At-Once.aspx</link><description>Sometimes when starting a new project, or updating a site in mass it is desirable to install multiple DotNetNuke private assemblies at once. Although the core PA installer does not expose this functionality via the user interface from Host -&gt; Module Definitions, there is another convenient way to achieve this. Simply follow the steps below.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 07 Oct 2008 01:13:06 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:220</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/212/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-4-The-Deployment-Process-amp-DNN-Manifest-File.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=212</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=212&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 4: The Deployment Process &amp;amp; .DNN Manifest File)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/212/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-4-The-Deployment-Process-amp-DNN-Manifest-File.aspx</link><description>This is a continuation of the "Best Practices: Development Team Collaboration and DotNetNuke" multi-part series of blogs. If you have not read Part 1: The Development Environment, or Part 2: The SqlDataProvider Files, Part 3: The References &amp; Project Structure, you may wish to do so before reading this entry. Unlike the previous blog posts related to this topic, this final installment requires some distinction between DotNetNuke 3.x - 4.x core versions versus the upcoming 5.0 release labeled as Cambrian. The separation is required because Cambrian supports what is referred to as "Extensions", which encompasses all skins, modules, containers, providers, class libraries, as well as skin objects. In versions prior to 5.0, items were installed as either modules or as skins and the term extension was not used. Before diving into specifics, we should first review some basics around the various installation environments for extensions.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Wed, 01 Oct 2008 12:15:33 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:212</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/206/Create-Thumbnails-For-Module-Images.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=206</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=206&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Create Thumbnails For Module Images</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/206/Create-Thumbnails-For-Module-Images.aspx</link><description>Often times when creating DotNetNuke modules or any other .net application development for that matter, you want to allow users to upload images with their content. Since the images the user(s) are uploading are most likely not going to be a unique size it is often beneficial to create a thumbnail image from the source image to use in your list view, etc. Below is a very simple function that will take a source image stored on the server, and create a thumbnail of a static size. The function below will only create the thumbnail image if it does not already exist.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 29 Sep 2008 00:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:206</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/189/Integrate-FeedBurner-Feeds-Into-Your-Module.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=189</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=189&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Integrate FeedBurner Feeds Into Your Module</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/189/Integrate-FeedBurner-Feeds-Into-Your-Module.aspx</link><description>You may remember last week I showed you how to enable live bookmarks for feeds that your DotNetNuke module may be creating. Once nice option for feed delivery is FeedBurner integration. FeedBurner can offer a lot of value added services to your feeds delivery and help ensure availability as well. At a very high level what we want to happen is that when anyone requests your feed we check the user agent. If the user agent is FeedBurner then we serve up the feed as normal. However, if the user agent is not FeedBurner then we want to redirect the request via 301 Moved Permanently to the correct FeedBurner feed. Below is some very simple code to give you an idea of how this can be accomplished.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 22 Sep 2008 00:26:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:189</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/178/Add-Live-Bookmarks-for-Your-Feeds.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=178</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=178&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Add Live Bookmarks for Your Feeds</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/178/Add-Live-Bookmarks-for-Your-Feeds.aspx</link><description>Have you noticed how most browsers can detect news feeds and give the client an indication to subscribe? While this is not done automatically for any URL on the page that contains a feed, it is trivial to add this functionality to a page in your module. The ability of the browser to identify a link as a feed revolves around its declaration to be of a type="application/rss+xml". Below is an example of how one would pragmatically create such a link to indicate to the browser that the page contains a feed that we wish visitors to be able to subscribe to.  //create client script manager to emit scripts at runtime and set proper typeClientScriptManager cs = Page.ClientScript;Type cstype = GetType();&amp;nbsp;//register client script block if not alreadystring csbDynamicVariables = "MyModule";if (!cs.IsClientScriptBlockRegistered(cstype, csbDynamicVariables)){ StringBuilder sb = new StringBuilder();&amp;nbsp; //add live bookmark for browsers and add to head //check for FeedBurner name and set url if needed string FeedBurnerName = (string)Settings["FeedBurnerName"]; if (!string.IsNullOrEmpty(FeedBurnerName)) { sb.Append( string.Concat("&amp;lt;link rel=\"alternate\"", " type=\"application/rss+xml\"", " title=\"", FeedTitle, "\" href=\"", "http://feeds.feedburner.com/", FeedBurnerName, "\" /&amp;gt;\n")); } else { sb.Append( string.Concat("&amp;lt;link rel=\"alternate\"", " type=\"application/rss+xml\"", " title=\"", FeedTitle, "\" href=\"", TemplateSourceDirectory, "/feed.aspx?tabId=", TabId, "&amp;amp;mid=", ModuleId, "\" /&amp;gt;\n")); }&amp;nbsp; //register client script block cs.RegisterClientScriptBlock(cstype, csbDynamicVariables, sb.ToString(), false);} You may have noticed that in the above example there is a module setting for a users FeedBurner account and that if they have entered this we use their FeedBurner URL instead of their actual feeds. Next week, I'll show you how set up your feed generation page to only serve up the feed for FeedBurner and to redirect all other requests to the FeedBurner URL.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 16 Sep 2008 00:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:178</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/176/Programmatically-Parse-DNN-SQL.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=176</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=176&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Programmatically Parse DNN SQL</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/176/Programmatically-Parse-DNN-SQL.aspx</link><description>$0When executing any SQL statement for the DotNetNuke platform a developer needs to consider the typical database owner. However, you also need to consider the DNN notion of an object qualifier. This is some string of characters that are prepended to your database tables to enable multiple DNN installs to run in one database. In DotNetNuke terms all SQL migrations are captured in a specialized TSQL format. These file have a .SqlDataProvider extension when dealing with SQL. In order to accommodate both database owner and object qualifier the core module private assembly installer will parse the tokens {databaseOwner} and {objectQualifier} respectively with information from the site configuration file. I had the need to replicate this behavior in a module, and here is the quick and dirty I came up with.$0
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 14 Sep 2008 02:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:176</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/163/Set-DotNetNuke-Page-Or-Module-Title-Dynamically.aspx#Comments</comments><slash:comments>7</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=163</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=163&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Set DotNetNuke Page Or Module Title Dynamically</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/163/Set-DotNetNuke-Page-Or-Module-Title-Dynamically.aspx</link><description>One easy way to improve your search engine optimization for any given module its to change the page/module title based upon content. Google likes it when a page title corresponds to the content it contains, and programmatically changing this for each detail item is a breeze. Below is an example implementation. As you can see, one needs to override OnInit to be far enough up in the page life cycle for this to work.
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 02 Sep 2008 02:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:163</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/146/Create-A-DotNetNuke-Scheduled-Task.aspx#Comments</comments><slash:comments>4</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=146</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=146&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Create A DotNetNuke Scheduled Task</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/146/Create-A-DotNetNuke-Scheduled-Task.aspx</link><description>From time to time you may need to execute arbitrary code on a schedule. DotNetNuke provides an easy API for creating scheduled tasks. In order to create a scheduled task for DotNetNuke you inherit from their SchedulerClient base class and override the DoWork() method. Below is a very simplistic class to give you an example implementation.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 26 Aug 2008 11:17:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:146</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/124/Get-DotNetNuke-Module-Settings-On-An-ASPX-Page.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=124</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=124&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Get DotNetNuke Module Settings On An ASPX Page</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/124/Get-DotNetNuke-Module-Settings-On-An-ASPX-Page.aspx</link><description>Have you ever created a DotNetNuke module that had an ASPX page but still needed to access your module settings on said page? An example of this scenario would be if you created an ASPX page to render an XML feed, or serve up a file, etc and it needed to know some of your module's settings. This can easily be done by passing the ModuleId in the query string to the ASPX page, and then using the GetModuleSettings(int moduleId) method of the PortalSettings type. Below is an example of how one would accomplish this.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 19 Aug 2008 11:24:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:124</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/106/Add-A-DotNetNuke-Module-Message.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=106</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=106&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Add A DotNetNuke Module Message</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/106/Add-A-DotNetNuke-Module-Message.aspx</link><description>One of the great things about programming for a framework is that most of the common tasks a web developer would ordinarily be in charge of implementing him/her self have already been taken care of for you. This can save you a tremendous amount of development time, and is always a nice head start. One of these common tasks is alerting users with a message in the UI. DotNetNuke provides methods for displaying messages at both the module and page levels. These methods are located in the DotNetNuke.UI.Skins.Skin namespace. Below is a sample of adding simple warning message for a module that has not yet been configured. You can assume the ModuleHasBeenConfigured() method is a boolean function that performs some checks to see if the module is properly configure.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 12 Aug 2008 11:48:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:106</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/95/Install-Multiple-DotNetNuke-Modules-Quickly.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=95</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=95&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Install Multiple DotNetNuke Modules Quickly</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/95/Install-Multiple-DotNetNuke-Modules-Quickly.aspx</link><description>Sometimes if you are updating you/client sites you will have a whole gaggle of modules that you need to install. There are a couple built in mechanisms to achieve this. If you want to be able to pick and choose which modules are installed in what order then you probably want to go to Host -&amp;gt; Module Definitions. Then, scroll down to the 'Available Modules' section and you will have a check box list of available modules to be installed.
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 05 Aug 2008 14:28:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:95</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/77/Add-Entry-to-DotNetNuke-EventLog.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=77</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=77&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Add Entry to DotNetNuke EventLog</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/77/Add-Entry-to-DotNetNuke-EventLog.aspx</link><description>Have you ever wanted to add an Event programmatically to the DotNetNuke
EventLog. The DNN framework has built in methods to allow module
developers to easily perform this action. They are located in the
DotNetNuke.Services.Log.EventLog namespace below is an example of
performing such an addition
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 29 Jul 2008 12:00:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:77</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/30/Preparing-for-DotNetNuke-50-Cambrian.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=30</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=30&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Preparing for DotNetNuke 5.0 Cambrian</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/30/Preparing-for-DotNetNuke-50-Cambrian.aspx</link><description>If you code modules for DotNetNuke 4, the changes required&amp;nbsp;for&amp;nbsp;Cambrian might not take much effort.&amp;nbsp;
</description><dc:creator>Chris Paterra</dc:creator><pubDate>Thu, 24 Jul 2008 11:19:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:30</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/20/Populate-A-DNN-Auto-Suggest-Web-Control.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=20</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=20&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Populate A DNN Auto Suggest Web Control</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/20/Populate-A-DNN-Auto-Suggest-Web-Control.aspx</link><description>Here is a small snippet that illustrates how easy it is to use the DotNetnuke Auto Suggest WebControl. The collection displayed is an EntitySpaces business object, but could easily be any POCO object.
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 01 Jul 2008 16:02:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:20</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/19/Dynamically-Path-Your-JavaScript-and-Styles.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=19</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=19&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Dynamically Path Your JavaScript and Styles</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/19/Dynamically-Path-Your-JavaScript-and-Styles.aspx</link><description>I ran into this little issue the other day where I need to have my Javascripts and styles pathed dynamically from my MasterPage. Of course I could simply create the string dynamically and add it to the head, but that made me feel dirty. So after a bit of Google Fu I found a neat little work around. Would you believe it was DataBinding?
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Thu, 26 Jun 2008 14:18:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:19</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/18/Programmatically-Authenticate-A-User.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=18</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=18&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Programmatically Authenticate A User</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/18/Programmatically-Authenticate-A-User.aspx</link><description>Have you ever needed to authenticate a user programmatically from your DotNetNuke module? I'm sure you have, or will in the future so here is a quick snippet to do just that. I hope it saves someone a minute or two.
</description><dc:creator>Scott Schecter</dc:creator><pubDate>Wed, 25 Jun 2008 15:42:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:18</guid></item></channel></rss>