http://www.apptheory.comRSS feeds for AppTheory60http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/540/Home-From-OpenForce.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=540http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=540&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/540/Home-From-OpenForce.aspxAs most of you who read this know, AppTheory had a booth at OpenForce ‘09 last week in Las Vegas where we handed out flyers and discussed DotNetNuke with anyone who stopped by and wanted to chat. Surprisingly, there were many people who had tons of questions.Chris PaterraFri, 20 Nov 2009 20:40:00 GMTf1397696-738c-4295-afcd-943feb885714:540http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/531/New-Telerik-Release.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=531http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=531&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/531/New-Telerik-Release.aspxTelerik released their updated set of components for Q3 2009 the today. One of the things I find great about this release is their Visual Style Builder is now capable of producing detailed skins for all of their controls now. If you haven’t heard about the Style Builder, it basically allows you to redesign the user interface of the Telerik controls without having to write a single line of code or HTML code. To checkout the Visual Style Builder, follow this link to create your own set of custom Telerik control skins: http://stylebuilder.telerik.com/. New controls which are included in the release that may appeal to DotNetNuke developers is their new SiteMap control (which allows you to render from the google xml sitemap created by DNN, if you so desire), RadRating control, RadListView (basically a data list replacement), A new skin for all controls, Suite control installer now permits upgrading (instead of a completely re-install) and some performance enhancements. Also worth mentioning is it looks like they are getting about a 30% performance gain by removing some generic reflection use that was done in all controls previously vs. Telerik releases of the past. You can read the full details for this release here:http://www.telerik.com/products/aspnet-ajax/whats-new.aspxChris PaterraWed, 04 Nov 2009 22:01:04 GMTf1397696-738c-4295-afcd-943feb885714:531http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/528/DotNetNuke-lsquoIs-Web-Farmrsquo-Changes.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=528http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=528&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/528/DotNetNuke-lsquoIs-Web-Farmrsquo-Changes.aspxI 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!Chris PaterraMon, 02 Nov 2009 04:56:33 GMTf1397696-738c-4295-afcd-943feb885714:528http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/522/DotNetNuke-SSL-Wild-Card-Certificates.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=522http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=522&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/522/DotNetNuke-SSL-Wild-Card-Certificates.aspxIn 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 –> 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. Chris PaterraMon, 26 Oct 2009 14:49:08 GMTf1397696-738c-4295-afcd-943feb885714:522http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspx#Comments1http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=520http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=520&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspxIf you have worked with Telerik you are probably familiar with the “RadAjax” component which is a part of the ASP.NET Controls suite from them. Generally, you throw a RadAjaxManager on your page/control and you are pretty much set to have full Ajax functionality in your application. From here you can include/exclude controls and add a loading panel that can be shared by all panels on the page. Finally, you code your application pretty much like before, adding business logic in Page Load and button click events, and poof you have a full ajaxified application. While this works pretty much the same in any DotNetNuke module, it is important to do two things in your module otherwise you may not get the results you expect. The first is to set the SupportsPartialRendering equal to true. If just starting, this is done from the module definition for the specific control. Otherwise, it is done from a node in your dnn manifest file for your module. Next, the other thing you need to do is on Page_Init of your control you need to place a script manager on the page (if Ajax is installed). You can do this using the following code: 1: If DotNetNuke.Framework.AJAX.IsInstalled Then 2: DotNetNuke.Framework.AJAX.RegisterScriptManager() 3: End IfOR: 1: if (DotNetNuke.Framework.AJAX.IsInstalled) { 2: DotNetNuke.Framework.AJAX.RegisterScriptManager(); 3: }Chris PaterraMon, 19 Oct 2009 14:47:00 GMTf1397696-738c-4295-afcd-943feb885714:520http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/515/My-DotNetNuke-Core-Upgrade-Process-Simplified.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=515http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=515&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/515/My-DotNetNuke-Core-Upgrade-Process-Simplified.aspxThe 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  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. Chris PaterraWed, 07 Oct 2009 20:44:28 GMTf1397696-738c-4295-afcd-943feb885714:515http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=513http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=513&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspxThis week I was spending more time working with Telerik controls in DotNetNuke modules. While I may have several other future topics to discuss because of this, waiting on a response from Telerik before I do that though, I do have some useful information. Previously, I was using pre DNN 5.x releases to create modules. What I am about to touch on was never a problem in any of those versions. However, moving into DNN (and mainly, the new skin) I found one thing that really annoyed me. I kept seeing bullet points next to (on the left) my RadListBox. About a month or two ago I was working with RadUpload and saw a similar problem there but it went away after I played with some options/properties of that control. In the case of the RadListBox, nothing like this was available. After some research I found out it appears to be some CSS conflict in the Extropy skin (and the key here is I never thought of ‘bullet points’ as a search term).The correction is adding a class to your module.css: 1: .rlbItem 2: { 3: list-style-type:none !important; 4: } Chris PaterraSat, 03 Oct 2009 08:43:00 GMTf1397696-738c-4295-afcd-943feb885714:513http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/509/Easily-Identify-Missing-Localization-Keys-in-DotNetNuke.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=509http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=509&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/509/Easily-Identify-Missing-Localization-Keys-in-DotNetNuke.aspxOne 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.Chris PaterraFri, 25 Sep 2009 21:02:45 GMTf1397696-738c-4295-afcd-943feb885714:509http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/505/Missing-DotNetNuke-Controls.aspx#Comments2http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=505http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=505&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/505/Missing-DotNetNuke-Controls.aspxRecently I was reading some forum posts on www.dotnetnuke.com and I noticed that a handful of people are missing module controls after an installation. What I mean when I say this is that they are using a module, they do something that should load a different view (such as a module action, thus a ctl=key) and nothing displays on the page. After some investigation into some of these issues, I found that those posts were related to missing DotNetNuke controls for the module definition. What was happening is during the install process the controls were in the .dnn manifest file but somehow were not added to the definition. I know in some 5.x betas this was a problem but the team had fixed this (it was related to caching). So my question to all of you, has anyone else seen this type of behavior after installing a module (most likely upgrade, but possibly new installs too)?Chris PaterraFri, 18 Sep 2009 21:37:37 GMTf1397696-738c-4295-afcd-943feb885714:505http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=501http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=501&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspxOne thing I often take for granted is that DotNetNuke runs under Medium Trust. Of course, you can add modules and this may no longer be the case but out of the box it does work. As a core module developer, we are required to ensure our modules run in Medium Trust environments. However, most of my time is spent working on things for AppTheory where this requirement is often not necessary. Recently I was checking to see if our modules work properly under Medium trust (there is a setting in your DNN web.config file for this) and found that those using Telerik’s RadUpload had problems. After a bit of research I found that it cannot run under Medium trust. Telerik’s explanation is they require reflection (and with this component it does make sense) but I can’t figure out (honestly, haven’t spent much time investigating) what exactly they are doing that can’t be worked around. Chris PaterraMon, 14 Sep 2009 07:08:00 GMTf1397696-738c-4295-afcd-943feb885714:501http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/495/Custom-Module-Permissions-in-DotNetNuke-5.aspx#Comments3http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=495http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=495&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/495/Custom-Module-Permissions-in-DotNetNuke-5.aspxFor several years DotNetNuke has permitted module developer to extend the types of permissions applied at the module. For example, in the Forum module there was a need to permit “Global Moderators” and “Forum Administrators” as columns in the permissions grid you see when editing a module’s settings. By adding the permissions to the grid, module editors can assign permissions via Role or User just the same as they do when setting “Edit” permissions on the module (if extending it beyond the default admin edit permissions). As module developers, you can take advantage of this by adding more granular permissions to your module and utilizing the core security classes to handle the majority of work for you (ie. you do a check on the current user, similar to how you would check if the user was an admin). If you would like to review an example, you can download the Source version of the Forum module from CodePlex and check it out, or you can take a look at an article that describes it here. (NOTE: The link and the current Forum Source 4.5.3 are examples for DNN 3.x and 4.x ONLY!) Previously, if I wanted to implement custom permissions in my module the only way to do this was to use IUpgradeable. Unfortunately, IUpgradeable had some problems in its past. In early implementations, there was no guarantee it would fire off and even in later versions (closer to 5.x) it seems that it still wouldn’t fire (on install) in some scenarios. With the release of DotNetNuke 5, custom permissions no longer need to be setup via IUpgradeable and instead you can use new nodes in the .dnn manifest file. If properly placed in the manifest file, the module installtion process will do all the work for you without requiring code or the use of IUpgradeable. An example of this can be seen below.   1: </moduleControls> 2: <permissions> 3: <permission code="FORUM_MODULE" key="FORUMADMIN" name="Forum Administrator" /> 4: <permission code="FORUM_MODULE" key="FORUMGLBMOD" name="Global Moderator" /> 5: </permissions> 6: </moduleDefinition> 7: /moduleDefinitions>   Chris PaterraThu, 03 Sep 2009 04:25:46 GMTf1397696-738c-4295-afcd-943feb885714:495http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/493/Telerik-Upload-Progress-Indicator-Disappears-in-FireFox-35.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=493http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=493&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/493/Telerik-Upload-Progress-Indicator-Disappears-in-FireFox-35.aspxAs you can probably tell from any of my blogs in the past, we often work with Telerik controls (specifically their ASP.NET AJAX suite) and integrate them with DotNetNuke solutions here at AppTheory. Typically, we don’t rush to upgrade our Telerik dependency in modules and instead we usually wait until we are going to upgrade a site’s DNN core and then update all of our modules and providers. Well, there is one exception to that and it is when Telerik releases a major bug fix or a security fix (I am not sure in the past 4 years or so I have seen a security fix publicized).Today, I was doing some work with replacing the core URL control’s upload mechanism with the Telerik equivalent. The primary purpose of this is to handle large file and display a progress of the upload to the site visitor. After wrapping up the development and pushing to a remote server (btw, it’s difficult to really test file upload progress locally because it happens so fast) I did my initial testing in IE and things went great. I then had one of our other developers take a look and he informed me that he is not seeing any progress. Initially, I figured he was using such a small file that he wasn’t seeing the area (I mean, I just saw it with my own eyes). I then remembered that he uses FireFox so I started up FireFox and saw that it was still working (I figured as much, I generally test locally with FireFox as well). I then asked him which version of FireFox he was using and he told me the latest 3.5. I checked mine, realized I was on 3.0 something and then upgraded. Once I loaded up the site I saw immediately the problem he was having, but I wasn’t sure why. I did some searching and came up with the following statement from the Telerik support team “Indeed there is a problem with Q1 2009 under FireFox 3.5, but it should work as expected in IE. For Q2 2009 we have fixed the FF bug as well.”So, if you are using the Telerik Upload component and/or the ProgressArea you should really consider a move to Q2 2009 which just so happened to have a point release just this past Wednesday.Chris PaterraFri, 28 Aug 2009 22:12:00 GMTf1397696-738c-4295-afcd-943feb885714:493http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=489http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=489&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspxIn a previous blog post I discussed DotNetNuke 4.x to 5.1.1 upgrade issues I found upgrading the www.dnnforums.com site. Well, since that original blog post we have done several module upgrades and found a solution to some previous issues. One of the previous issues identified was the RadMenu skin object available via Telerik not properly showing icon paths for the menu. The reason behind this is that the path to the icons via the IconFile property has changed it’s format. Previously, icons were a relative link but since the 5.x base they have become absolute. We also found that this same situation can occur with the SolpartMenuProvider, which many installs still use today (although it is no longer actively developed, it was updated for DNN 5.x) and can typically be corrected by parsing the skin package. An example of the code change for the Telerik skin object can be found below, the item commented out is the old line of code used while the new one is below it. 1: If ((tab.IconFile <> String.Empty) AndAlso (node.ImageUrl.Length = 0)) Then 2: Dim imgaddress As String 3: If (tab.IsAdminTab Or tab.IsSuperTab) Then 4: 'imgaddress = CStr(IIf(Me.Request.ApplicationPath <> "/", Me.Request.ApplicationPath.ToUpper, String.Empty)) & "/images/" & tab.IconFile 5: imgaddress = tab.IconFile 6: Else 7: imgaddress = PortalSettings.HomeDirectory & tab.IconFile 8: End If 9: node.ImageUrl = imgaddress 10: End If Chris PaterraFri, 21 Aug 2009 16:48:00 GMTf1397696-738c-4295-afcd-943feb885714:489http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/484/DotNetNuke-on-Windows-7-RTM.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=484http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=484&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/484/DotNetNuke-on-Windows-7-RTM.aspxAs 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). Chris PaterraFri, 14 Aug 2009 19:56:15 GMTf1397696-738c-4295-afcd-943feb885714:484http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/480/DotNetNuke-Enforced-SSL.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=480http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=480&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/480/DotNetNuke-Enforced-SSL.aspxFor 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 –> 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. Chris PaterraFri, 07 Aug 2009 21:31:44 GMTf1397696-738c-4295-afcd-943feb885714:480http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/474/DotNetNuke-Core-4x-to-511-Upgrade-Issues.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=474http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=474&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/474/DotNetNuke-Core-4x-to-511-Upgrade-Issues.aspxRecently I started upgrading some sites to DotNetNuke 5.1.1, which just released this week. In doing so, I found a few problems. The first thing I noticed is that skins do not necessarily behave the same as they did before. For example, in the 4.x code base I would see my left and right content panes collapse when only the middle content pane contained a module (and thus, the entire center content pane module would take up the full width). Post the upgrade, this was not the case in IE 7 or 8 regardless of which 'fallback skin doctype' I set (which is located under Host -> Host Settings). The solution is to change the skin, but definitely worth a mention here for those who are about to upgrade. An example of what I am talking about (post upgrade) is shown in Figure 1.0 below.   Figure 1.0 The next issue I noticed was also skin related. In most skins developed here at AppTheory, we utilize the RadMenu from Telerik. This is done by making use of an enhanced skin object Telerik provides specifically for DNN. Here at AppTheory, we added some additional options but it is almost identical to what Telerik provides. The problem that I found here is the icon paths are not set properly. We generally don’t use icons in for pages but the core itself has them available for all admin and host sub pages (as you probably know). This problem is likely in how Telerik populates the path for the menu icons via code and should be simple enough to fix. An example of what I am discussing can be seen in Figure 2.0.   Figure 2.0 So far so good, the two issues we have seen have been skin related and are not a bug in DNN core itself (although there is some obvious changes in how DNN has handled these). The only other problems I have seen, thus far, were either during the install (apparently there is a primary key column change on the EventLog table that caused me an error page shown but no actual problems), or in some custom modules we wrote that make use of Localization. There seems to be some sort of change around DotNetNuke.Services.Localization’s TokenAccessLevel which I haven’t quite figured out yet (or why it was changed). What we were using it for wasn’t really necessary so I seriously doubt most will run into this issue. Chris PaterraThu, 30 Jul 2009 21:35:25 GMTf1397696-738c-4295-afcd-943feb885714:474http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/441/DNN-Scheduler-How-it-Works.aspx#Comments2http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=441http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=441&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/441/DNN-Scheduler-How-it-Works.aspxToday 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.Chris PaterraFri, 15 May 2009 05:07:16 GMTf1397696-738c-4295-afcd-943feb885714:441http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/433/DotNetNuke-MSBuild-Tasks.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=433http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=433&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/433/DotNetNuke-MSBuild-Tasks.aspxAfter upgrading CruiseControl.NET earlier this month, I thought about how it might be beneficial to remove our dependency here on nAnt. Don’t get me wrong, nAnt has been a great little utility that has helped me and our team (including the DotNetNuke Core itself) for many years now. However, it certainly has presented new problems in my move to 64 bit computing and it certainly isn’t getting the attention it once did. On the other hand, MSBuild was utilized by nAnt to do the actual building so why not remove what is essentially an extra piece of the puzzle. Well, today in the DotNetNuke Forums I saw a post that pointed to a CodePlex project that contains some tasks. I haven’t spent much time with it yet, but I did notice it has an installer which really just puts a new folder and a DLL in your MSBuild folder. For those of you that are using a tool such as CCNet, remember this will need to not only be installed on your local development machines but also on the server itself. In addition, you will need to have the MSBuild Tasks project installed on those same machines (the developers and the servers). I have a feeling that I will be reviewing this over the weekend and will have much more to write about next week.Chris PaterraFri, 01 May 2009 21:19:38 GMTf1397696-738c-4295-afcd-943feb885714:433http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/426/DotNetNuke-Adding-a-child-portal-Alias.aspx#Comments1http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=426http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=426&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/426/DotNetNuke-Adding-a-child-portal-Alias.aspxToday I ran into a situation using a core DotNetNuke 4.9.x build (not sure of the specific one off the top of my head) where we had to add a portal alias for an existing portal. No big deal, I logged in with a host account and added the alias. However, I attempted to call the site up and I got a page not found message. Although it never really occurred to me, if you add a child portal alias and it is NOT during the portal creation time, no sub-directories will be created within your web root. As most of you probably know, you must have the child portal alias as a directory name within your site. To avoid confusion on with regards to child portals and virtual directories, please see examples: Example 1: www.domain.com/myvirdir – If something is setup as the virtual directory, that is the full name and it is technically a parent portal. Example 2: www.domain.com/child – If something is setup as a child portal, it is not a virtual directory and the root domain is pointed to the web root home directory. Now, lets say we are doing example two and we have domain.com/child as our initial alias when creating the portal originally. This would have created a directory within your web root called child and copies a default.aspx into the folder so ASP.NET knows to handle it (no .aspx page ASP.NET couldn’t pick up the request). Where the issue I had above occurred is that I wanted to create another child portal alias, that pointed to ‘child’, in this case lets call it newchild. Because I added this alias after creation, I manually had to go into the file system and create the newchild folder and copy the default.aspx from the original child folder. That’s it, all is resolved now. Chris PaterraFri, 24 Apr 2009 21:30:27 GMTf1397696-738c-4295-afcd-943feb885714:426http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/425/Cruise-Control-NET-Upgrades.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=425http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=425&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/425/Cruise-Control-NET-Upgrades.aspxThe CruiseControl.NET project has had a lot of activity recently, which encouraged me to upgrade. I was previously running 1.4.1, which was released around Nov 2008, and now I moved to the 1.4.4 RC1 which released this week. Normally I would avoid use of an RC but in this case I felt comfortable implementing it. So far, I was able to use the Validator tool (which was recently added to validate configuration files for ccnet) and get things updated as expected. However, I saw that my installation was now ‘crashing out’. First, I went to see if the Service was running (and it was not). Next, I called up a command prompt to attempt start ccnet, this also will display information in detail as to what is wrong since you can’t get to the web interface now (if there is a problem starting it that is). This in turn showed me the problem, thus allowing me to fix it. Apparently, there were two projects using the same name and this caused a conflict. The important thing to take away from this, the Validator tool doesn’t tell you if you have duplicates so keep an eye out. Chris PaterraFri, 24 Apr 2009 18:54:13 GMTf1397696-738c-4295-afcd-943feb885714:425http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/421/DotNetNuke-Community-vs-Professional-Editions.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=421http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=421&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/421/DotNetNuke-Community-vs-Professional-Editions.aspxSince November when a Professional Edition of the DotNetNuke Core was announced, there has been a lot of speculation of what this means to the community.  Even those within the Core team itself were not sure what this meant. Well, this week we received two important blog posts that should hopefully clear up not only the difference between the two, but a Roadmap for what is to come. In the first post, here, Nik Kalyani explains the business model as well as an introduction to what the differences between the two editions are. In the next blog article from Nik, here, he introduces the Roadmap. In this second post he also mentions how they determine what should be on the Roadmap. So, hopefully, this should clear up some confusion amongst community members as to what is available. It also sheds some light on what is in progress now and for the remainder of this year. Please do keep in mind, this is a roadmap for 2009 and not the next major release. Chris PaterraTue, 21 Apr 2009 23:07:01 GMTf1397696-738c-4295-afcd-943feb885714:421http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/414/Developers-Moving-to-64-bit-Vista-Workstations.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=414http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=414&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/414/Developers-Moving-to-64-bit-Vista-Workstations.aspxRecently I decided to buy a new workstation to use at home, one that I would build myself. When deciding what I was going to purchase I wrote down a list of needs typically like I do requirements for a project I am proposing.Chris PaterraWed, 15 Apr 2009 15:11:48 GMTf1397696-738c-4295-afcd-943feb885714:414http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/292/DotNetNuke-Module-Online-Help.aspx#Comments2http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=292http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=292&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/292/DotNetNuke-Module-Online-Help.aspxDotNetNuke 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.Chris PaterraMon, 08 Dec 2008 15:26:00 GMTf1397696-738c-4295-afcd-943feb885714:292http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=238http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=238&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspxA recent forum post on the DotNetNuke site had me thinking about the available DotNetNuke HTML Providers. Many people use DotNetNuke for their web site framework because, like me, they don't want to re-invent the wheel. Thousands of hours have been spent on the framework's development, not to mention the thousands of hours of development time spent on providers, skin objects, modules, etc. I have no idea exactly how many hours I have spent developing the forums module but I would say its multiple thousands of hours over a few years.Chris PaterraSat, 25 Oct 2008 22:24:00 GMTf1397696-738c-4295-afcd-943feb885714:238http://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#Comments1http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=212http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=212&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/212/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-4-The-Deployment-Process-amp-DNN-Manifest-File.aspxThis 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 & 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.Chris PaterraWed, 01 Oct 2008 12:15:33 GMTf1397696-738c-4295-afcd-943feb885714:212http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/205/Working-with-Language-Packs-in-DotNetNuke-4x.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=205http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=205&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/205/Working-with-Language-Packs-in-DotNetNuke-4x.aspxIf 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).Chris PaterraSun, 28 Sep 2008 19:16:44 GMTf1397696-738c-4295-afcd-943feb885714:205http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/203/Setting-up-NAnt.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=203http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=203&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/203/Setting-up-NAnt.aspxHere at AppTheory we often build custom modules for clients and deliver them source code when completing a project. After we handoff the code, I often receive many questions about how to automatically package installable modules as we do so customers can have their own developers make changes and deploy them without requiring interaction from AppTheory. To do this, we not only handoff the code we also provide the customer with custom build files we use. Even if you are not an AppTheory customer, you may find this article useful as several DotNetNuke core modules also use nAnt for packaging such as the core Forum module. Please note that if you are an AppTheory customer, one thing that you should keep in mind is that we distribute multiple build files that depend on one another. Because of this, paths are an important thing to keep in mind and we will email you details specific to our environment but all other items discussed here still pertain to you.Chris PaterraWed, 24 Sep 2008 18:56:18 GMTf1397696-738c-4295-afcd-943feb885714:203http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspx#Comments3http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=202http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=202&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspxThis 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, Part 2: The SqlDataProvider Files, you may wish to do so before reading this entry. The second installment covered not only the actual SqlDataProvider files, it also covered how to use those files to keep database structure synchronized for all developers collaborating on a project. This installment will cover some basic project structure, primarily focused on the WAP project structure, and also how to manage references for your team collaborating on a single project.Chris PaterraTue, 23 Sep 2008 10:25:00 GMTf1397696-738c-4295-afcd-943feb885714:202http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/181/DotNetNuke-Sites-with-Hundreds-of-Pages-amp-Caching.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=181http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=181&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/181/DotNetNuke-Sites-with-Hundreds-of-Pages-amp-Caching.aspxThere 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.Chris PaterraWed, 17 Sep 2008 06:22:47 GMTf1397696-738c-4295-afcd-943feb885714:181http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/180/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-2-The-SqlDataProvider-Files.aspx#Comments1http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=180http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=180&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/180/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-2-The-SqlDataProvider-Files.aspxThis 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, you may wish to do so before reading this entry. The first installment not only covers the development environment setup, it also covers some target audience things you may wish to review as well before diving into this post. This installment is dedicated to database structure changes using the SqlDataProvider files.Chris PaterraWed, 17 Sep 2008 05:19:36 GMTf1397696-738c-4295-afcd-943feb885714:180http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/141/Avoiding-the-DotNetNuke-Admin-Skin.aspx#Comments1http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=141http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=141&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/141/Avoiding-the-DotNetNuke-Admin-Skin.aspxTypically, 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.Chris PaterraSun, 24 Aug 2008 22:21:17 GMTf1397696-738c-4295-afcd-943feb885714:141http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=140http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=140&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspxThe majority of developers who see this blog are probably use to collaborating with other developers on projects. However, many developers who have spent only a limited amount of time on DotNetNuke development may find the process somewhat overwhelming. This is because even though DotNetNuke is an ASP.NET application, it is a specific framework with its own API. As with other frameworks, sometimes only experience or the view point of someone with experience can permit you to identify common problems before they occur. While the team here at AppTheory cannot say we have seen it all, as something new always pops up, we have plenty of experience with development team collaboration and DotNetNuke. In an effort to share some of our experiences, I have put together some of best practices we find vital to a successful project.Chris PaterraSun, 24 Aug 2008 21:59:06 GMTf1397696-738c-4295-afcd-943feb885714:140http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/30/Preparing-for-DotNetNuke-50-Cambrian.aspx#Comments0http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&ModuleID=1002&ArticleID=30http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=30&PortalID=2&TabID=411http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/30/Preparing-for-DotNetNuke-50-Cambrian.aspxIf you code modules for DotNetNuke 4, the changes required for Cambrian might not take much effort.  Chris PaterraThu, 24 Jul 2008 11:19:00 GMTf1397696-738c-4295-afcd-943feb885714:30