DotNetNuke Blogs On DNN, For DNN

DotNetNuke Tips and Tricks #12: Creating your own Authentication Provider

Joe Brinkman — Mon, 13 Jul 2009 15:55:29 GMT

DotNetNuke has a lot of great features that come built-in, but there are often situations where the default implementation is not what the customer wants for their website. This was a big limitation of early versions of DotNetNuke – changing basic functionality often required the user to customize the core DotNetNuke code.

In DotNetNuke 2.0 all of that began to change with the introduction of Providers in the framework. This is also where we began focusing on a rich extensibility model that would allow users to install skins, skin objects, and modules as separate packaged extensions. Over time, the framework has evolved to include different extension types, and in DotNetNuke 5.0 we moved to a unified extension model that treats all extension types in a similar manner during the install and uninstall process.

One of the extension types that was added in the last couple of years was the Authentication Provider. Unlike most other providers, an authentication provider is not configured in the web.config and actually looks and behaves more like a module than an actual provider.

An authentication provider installs up to 3 UI elements that the framework cares about – a login control, a settings control and optionally a logout control. It is certainly possible to use more controls if needed, but these are the only three the core framework interacts with directly. Once installed the authentication provider can appear as one option in the standard DNN login. In the image to the left you can see the standard login on DotNetNuke.com with the LiveID tab selected. This clearly shows a different UI than the standard username and password.

Recently there has been a lot of discussion around a change made to recent versions of DotNetNuke. In the past, it was possible to define a custom login page and put the Account Login module on the page. This allowed you to create an SSL enabled login page or to put a login control directly on the home page. Unfortunately, users would sometimes change the custom login page setting without putting a login module on the page. In other cases, the login module would be added to the page, but the user wouldn’t have permission to see the page or the control. Recent versions of DotNetNuke try to detect this situation and prevent you from setting the custom login page to a location without a login control that is visible to unauthenticated users.

Unfortunately, there are a number of third party login modules currently on the market which are not implemented as Authentication Providers and this new behavior makes it impossible to use them with the latest DNN release. We’ll work on the behavior change to make it possible to use these modules but I thought that this highlights one of the issues with DNN. When we introduce an official extensibility point, we then start coding the core to use and rely on extensions which conform to the extensibility model. If you are coding a skin object that doesn’t conform to the official model then we may well break your skin object in future DNN releases. The same is true with Authentication Providers. Had these modules been code as Authentication Providers instead of Modules then they would have continued to function.

The real failure in this case rests with the core team and not the module vendors. When we introduce new features we often haven’t had the resources to fully document how to take advantage of the new feature. This is especially true for core API changes. The end result is that the core team ends up coding to the new APIs long before 3rd party vendors start upgrading their extensions. The biggest reason for this is because we haven’t done a good enough job in documenting how to use the new feature.

With all of this as background, I thought it would be good to run through exactly how to create your own custom Authentication Provider. In this example, I am going to start from the standard DotNetNuke Authentication Provider. For the sake of simplicity, I am going to code this as a WSP project, although the techniques apply just the same to a WAP project (LiveID, OpenID and AD providers are all WAP based implementations).

The first thing I do is make a copy of the DNN Authentication provider which is located in the DesktopModules/AuthenticationServices/DNN folder. I have renamed my copy to Demo so that we can distinguish it from the original. I have gone into the Login and Settings controls and changed the namespaces to avoid collision and changed them from DotNetNuke.Modules.Admin.Authentication to DotNetNuke.Modules.Admin.Demo.Authentication.

At this point I have a useable Auth Provider, but I don’t have a method to install it. I could use the Host/Extensions page to create a new package but since this is my first time I decided to build my manifest file using the manifest from the LiveID Authentication Provider as a template. After making a few modifications to the manifest to add a CSS file (more on that in a minute) and to fix some file names, I am almost ready to zip everything up.


    
        
            DotNetNuke Demo Authentication Project
            The DotNetNuke Demo Authentication Project is an Authentication provider for DotNetNuke that shows how easy it is to create your own custom auth provider.
            
                DotNetNuke Corporation
                DotNetNuke Corporation
                www.dotnetnuke.com
                support@dotnetnuke.com
            
            
            
            
                05.00.00
            
            
                
                    
                        Demo
                        DesktopModules/AuthenticationServices/Demo/Settings.ascx
                        DesktopModules/AuthenticationServices/Demo/Login.ascx
                        
                    
                
                
                    
                        DesktopModules/AuthenticationServices/Demo
                        
                            App_LocalResources
                            Login.ascx.resx
                        
                        
                            App_LocalResources
                            Settings.ascx.resx
                        
                        
                            Login.ascx
                        
                        
                            Settings.ascx
                        
                        
                            Login.ascx.vb
                        
                        
                            Settings.ascx.vb
                        
                        
                            license.txt
                        
                        
                            ReleaseNotes.txt
                        
                        
                            DemoAuth.css

Before packaging the system however, I want to make some changes to the login controls just to make it a little clearer when I am using my new control versus the standard DNN version. The DNN login uses tables for handling the form layout, and I am going to use a definition list. I also want to get rid of the help icons next to the form labels and use some different styling on the actual textboxes. Finally, I want to get rid of the Captcha control.

The first step is to clean up the login HTML

<%@ Control language="vb" Inherits="DotNetNuke.Modules.Admin.Demo.Authentication.Login" CodeFile="Login.ascx.vb" AutoEventWireup="false" Explicit="True" %>

After making these changes I make the corresponding changes in my code-behind to remove references to the captcha control and to update the visibility code for the verification control/label. This is pretty much all that is needed for the Login control.

The next set of changes are made to the settings control. We need to make sure that we are saving our control settings using unique settings keys (although you are free to store your settings using whatever method you are comfortable with). In this case I create a new DemoAuthConfig class to replace the core AuthenticationConfig class. I then go back and update the settings and login pages to reference my new config class rather than the old class. I also remove all references to the captcha setting since I am not using it here.

Finally, I want my login control to have it’s own look which I may choose to surface on the settings page at some point. To handle this I include a CSS file in my project since I don’t want end users to have to muck around trying to edit core CSS files. My CSS file changes the way the definition list is displayed to show up as two columns.

One last bit that I need to update is to edit the login.ascx.resx resource file. This resource file contains the Title.Text resource which controls the tabname that is used when displaying the various login controls. In my case I used “Demo Auth” for my Title.Text.

At this point I am ready to package everything up in a zip file so that it is ready for installation. Installing an authentication provider in DotNetNuke 5.0 is exactly the same as installing a module. Navigate to the Host/Extensions page and select the “Install Extension Wizard” option from the module action menu. This will walk you through the installation process.

Once the provider is complete, you will need to go to the Host/Extensions page and edit the new Authentication Provider settings to make sure it is enabled (it should be enabled by default). To edit the settings, click the edit (pencil) icon next the the DNN_DemoAuthentication extension listing.

You should see the following settings which allow you to enable or disable this authentication provider for all portals.

Once the provider is enabled at the Host level, you are now free to go to each portal and enable the provider for each portal where you wish to use it. Just go to the Admin/Extensions page and click on the edit (pencil) icon for the demo auth provider to bring up our custom settings page. Now we can enable our new AuthenticationProvider.

If you have followed along to this point, when you go to the login page, you should see two authentication types – Standard and Demo Auth. If you look at the Demo Auth page, you will notice that the “help” icons are removed and the text boxes are displayed using a custom style.

At this point you should be ready to create your own custom Authentication provider which plugs into the standard login system. This is the recommended method for providing custom layouts and authentication types for DotNetNuke and I highly recommend you check it out.

Download the demo code DemoAuth.zip

New Samples Site for Tressleworks Modules

TressleWorks — Thu, 09 Jul 2009 00:48:00 GMT

In recent weeks, I have been working on a sample site for all of the Modules currently available from Tressleworks. There have been examples on my site, but they had been rather limited. So I have created a child site off www.tressleworks.ca called www.tressleworks.ca/samples. Original n'pas?

More...

Open Source = Open Door to Hackers?

AppTheory DotNetNuke Blog — Wed, 08 Jul 2009 21:38:01 GMT

Is open source software more or less secure than proprietary software?

Lost Admin/Host Password in DNN

DotNetNuke Blog from CodeMyPantsOff — Wed, 08 Jul 2009 16:34:28 GMT

I had someone forget their admin password to a portal I installed 5 years ago, apparently the sticky note fell off the site administrators monitor and got thrown away (#grin*). They called me to get it back but of course I had them change it when I left. Thinking this is a problem for others I have the standard database hack/solution for this that works for the DNN user system.

*You need access to the database to do this:

Create a new user account by registration (this time, please remember the password you enter!)

If "register" is not displayed for the portal, go to table "Portals" in your database and enter value "2" into column "UserRegistration".

Go to database, enter table "ASPNet_Membership"
Go to new user account (usually the last one) and copy the encrypted values of columns "Password" and "PasswordSalt" into the same columns of user account "host" (usually the first entry in this table)
Login as user "host" using the new password and delete the newly created user.
If you changed the “Portals” table, revert UserRegistration mode in Site Settings.
Remember your password!!!!!!!

Using Active Directory in Dotnetnuke 5.x

Hilbert Solutions, LLC — Wed, 08 Jul 2009 15:25:26 GMT

Active Directory Integration has changed a bit since DNN 4. This guide is intended to help you setup Active Directory on your Dotnetnuke 5.x website.

Active Forums 4.2 - Configuration and Permission Sets

Active Modules, Inc. — Tue, 07 Jul 2009 16:14:42 GMT

Active Forums 4.2 is going to address several items, but also introduce some changes that will greatly improve performance and scalability. Active Forums 4.0 was a completely new module and data structure when compared to previous versions. I have been told before that I'm an extremist when it comes to performance, but performance is the key ingredient to a successful product. This has always been the strong point of Active Forums. However, with Active Forums 4.x it takes a little more to make it truly perform it's best. Now, 80% of all sites using Active Forums will never notice any sort of performance degradation. The remaining 20% represent a combination of sites with high traffic, large volumes of content or simply poor server resources. We could have simply written some documentation or raised the minimum requirements, but that really doesn't solve the problem.

Another strong point of Active Forums is the lengthy and flexible feature set. While addressing some of the performance issues, we also wanted to improve individual forum configuration. We also needed to make configuration options easy to access. Active Forums 4.2 will introduce a new feature called "Config Sets". A "Config Set" is the collection of all the settings that are available for a forum. This gives you the ability to define a set of features and apply them to any forum. You can define a Config Set before you even create the forum. You can also create a Config Set based off of an existing forum. Super Users have the option to mark a Config Set as "global" or "global default". The global setting makes the config set visible to all module instances across all portals. Global default replaces the Active Forums default configuration across all portals. Many other features are on the road map that are specific to Super User configuration, but those will be after the 4.2 release. For instance, we want to give the Super User the option to lock configurations. This would mean that a portal owner or module admin would have to select from a list of predefined configurations. Of course, the default behavior would be just as it has always been.

Permission Sets are very similar to Config Sets. Permissions will be separate from configurations. When we were going through various scenarios and use cases we found that you would end up with more Config Sets when permissions were included.

How does this help performance? It really comes down to the way we store and retrieve the settings with each page request. We are able to cache this information in a much more efficient way that works well across various server configurations. Our database queries are optimized so that they are retrieving less data and focused on content rather than configuration. We have eliminated the need to store specific settings for each forum which reduces database size and memory utilization. Even if you wish to have unique settings for each forum, fewer resources will be used and you will still see better performance.

I'm sure there are more than a couple customers thinking this sounds like the makings of a painful upgrade. This will be a direct upgrade, just like all others with the exception of 3.7 to 4.0. The upgrade process does make several database changes and migrate data. We have added several precautions to make sure the upgrade will not cause any downtime for your site. First, we are not going to delete anything. We will leave the structure for your old settings untouched for several releases. Second, the conversion to Config and Permission Sets is the very last part of upgrade install. If the script fails Active Forums will still use your old settings, but display a message in the Active Forums control panel telling you to contact support. The majority of the install problems we see are related to installs where data was imported from another product. We have been testing with several large installations and have not encountered any upgrade issues yet.

The upgrade process will attempt to consolidate your current settings into new permission and config sets. The worse case scenario is that you will end up with unique config sets for each forum. All it will take is for one setting to be different and a new config set will be created. The upgrade script also scans the database looking for any forums that are inheriting settings from a group. If any are found it will create a config set based upon the group and apply that to the proper forums.

What excites me the most about the Config Set feature is how we have made it easier for you to manage your forums. You can manage forums the same way you always have or use some of the new features. All Config Sets are listed in the Active Forums Control Panel. Each Config Set lists the forums where it is currently being used. If you have the proper permissions, you can also view and/or edit the forum configuration without accessing the control panel. This should make Active Social customers extremely happy since they will be able to manage group forums from within the Active Social Control Panel.

Active Forums 4.2 will be feature complete this week. The following week will be nothing but internal QA and security testing. A release date will be set the week after.

Silverlight 3 Launch Confirmed for July 10

DotNetNuke Consultant Blog - Arrow Consulting & De — Tue, 07 Jul 2009 12:25:55 GMT

Microsoft confirmed rumors in their MCP newsletter "MSDN Flash" last night that they are launching Silverlight 3 on July 10. The new version of the platform...

Display on All Pages -- got that wrong!

TressleWorks — Mon, 06 Jul 2009 17:34:00 GMT

It seems that I was thinking too hard when I attempted to understand how "Display on All Pages" might be implemented. Well I was all wrong and have been living under a misconception for quite some time. There were clues that my conceptualization was incorrect, but I ignored them because I was right -- and it must be something else ... yes -- pure ignorance.

OK, so how is this feature implemented and what are some of the issues associated with it?

More...

DotNetNuke Control Panel View Modes

AppTheory DotNetNuke Blog — Sun, 05 Jul 2009 23:39:00 GMT

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!

Social Networking DNN Module Suites: 300-Level Comparison

The Mighty Blog — Sat, 04 Jul 2009 17:10:00 GMT

There are two well-known module suites for the DotNetNuke® web application framework. First, there is the Open Smart offering by Smart-Thinker, and then there’s the Active Social offering by Active Modules. We are going to briefly compare the two right now.

Before I begin, please know that I have not been compensated in any way, and do not have any affiliation with either module suite, or their respective owner(s).

Smart-Thinker: Open Smart

Smart-Thinker is a company and website run solely by Rodney , who is also known for PokerDIY.com. In fact, his modules were originally written for his poker site. He released these modules to the public as a commercial product. At this time, I do not remember the price for the individual modules, but they each had to be purchased separately. Now they are all offered for free, and are open source. This is very important to me for any module. I love having source code to build, and implement custom business logic into.

I was happy to find that these modules are built to work on DotNetNuke version 4.06.02 and higher. This is no longer an issue for me, but the site I was considering putting the modules on was running that version at the time. It has since been upgraded.

Upon installing the modules, I had no issues at all. There were no errors on the installation log, or in the Event Viewer. I am the type of person that, when it comes to modules, I do not like reading the documentation until after I have tried to run the module and explored its features and settings. This presented a HUGE problem with this module suite. Why? Well, once installed, this module suite becomes a 21 installed modules, or module views. When you look at the list of modules to choose from in your module drop down list, it is overwhelming to say the least.

I don’t know about you, but my time is worth money. Every moment that I do not spend working on some that is going to give me a quick turn around is wasted time, and wasted money. I tried dropping one of the modules on to the page, and gave up. I went on the Smart-Thinker website to look for documentation, and didn’t find anything. Instead, I found a document that was put together by a Smart-Thinker customer. While it was a great document, it did not help me get through the set-up of the module suite any faster.

I ended up giving up on this module suite after a while. It is simply too difficult to get all of the modules on pages where they need to be.

Active Modules: Active Social

Unlike Open Smart, Active Social was very easy to install and configure, and it is not free at $$$. However, they do have a very well-written document that gets you started with the suite. From my testing, I do not think I would have really needed it. Once you figure out the key to their “views” that are switched in the module settings, the rest is easy. I did use the documentation though. It was written in a way that was easy to understand, and easily followed for those who are like me and are always in a rush. Following the documentation, I literally had a social site up and running within 30 minutes.

The Active Social suite already has most of the feature that any social network implementation would need. I did find a few bugs and reported them immediately. They were not show stoppers by any means though. The suite has many points of customization, allowing you to easily change the way the module suite works for your visitors, and quite possibly making two different sites function completely differently.

I have met Will Morgenweck at the Day of DotNetNuke® not long ago. Will impressed me when I spoke to him about his module suite. His current road map is aggressive, and it has all of the features that I was looking for that I didn’t find during my demo. Everything that I am looking for should be in the module suite in the next 2 months.

The Bottom Line

If you want a high-quality module suite for your online social network, and you have time to waste, the Open Smart module suite can do the job. If you want a social networking website and time is precious to you, then Active Social is for you. Sure, you’ll spend a little money buying the module suite, but at least you will have a fast, reliable, and stable module.

Technorati Tags: DotNetNuke,DNN,DNN Blogs,Social Networking,Modules,Review

Modifying the Default DotNetNuke Module Templates

The Mighty Blog — Sat, 04 Jul 2009 08:22:00 GMT

A great feature of DotNetNuke® is that each version comes with project templates for both the website, skins, and modules. What is a project template? Well, if you want to build your first module, then executing the project template inside of Visual Studio will give you a really great starting point, instead of having to figure out the files and file structure all on your own. The project template puts all of that together for you. All you have to do is give it a name, and then rename/change the code and files as you see fit. (And then build your module of course.)

Any developer though has their own style of both creating the files and code within their user controls, and other related code files. For example, you might have a specific namespace that you always like to work in, or you might always have specific properties that you create each time you build a user control. Luckily, the project templates can be easily easily altered to remember the way you like to start with a module.

Where are the Project Templates?

I am not going to walk you through creating a new project template from scratch. Instead, I will be showing you how to change a previously installed project template. IN order to do that, you need to know where the template files are found. They can be found at the following path:

C:\Documents and Settings\[Username]\My Documents\[Visual Studio Version]\Templates\ItemTemplates
C:\Documents and Settings\[Username]\My Documents\[Visual Studio Version]\Templates\ProjectTemplates

The Item templates are where you’ll find the simple module and skin templates. The Project templates is where you’ll find the DNN website template, and the compiled module template. At this time, module templates only are available for VB, and not C#.

What are the Templates?

The templates themselves are zip files, named as follows (the availability of the templates below will vary, depending on the DNN StarterKit(s) you have installed):

Module_VB.zip – This is a WSP version of a module template that has a DAL.
Simple_VB.zip – This is as WSP version of a module template that does not have a DAL
Skin.zip – This is a skin package template
Module_Compiled_VB.zip – This is a VB version of a WAP module
Module_Compiled_CS.zip – This is a C# version of a WAP module
DotNetNuke.zip – This is the DNN website template, which gets you started on a working instance of DNN

If you extract the contents of one of those archives into a folder, you will see a familiar folder structure for the Module_VB and Module_Simple templates (that is, if you’ve ever looked at the file system for a DNN instance. The compiled versions will look much different, and since they are much more complicated for this type of article, I will focus on the WSP modules.

Before you modify the default templates, I would suggest saving a copy of them to help you restore them later, if necessary. Additionally, it would be a good idea to just work out of your own archive and files, resulting in you generating your own template.

Modifying the Templates

Modifying the templates is easier than you might imagine. Since they are just archives, it literally can be as simple as extracting the files, changing them, and putting them back into the original archive. Modifications will need to be made in one or more of the following places. The most important place to make a change, is in the .vstemplate file. Even though it does not have the XML extension, it is just an XML file. Open it with your favorite text editor.

Most of the XML should be self-explanatory, if you understand XML. In fact, it carries several similarities to the DNN manifest file. For example, it allows you define the template name, folders, and files, much like the DNN manifest does for a module. Here is a quick run-down of the XML elements you need to know.

DefaultName – This is the name that Visual Studio will use to name your folders, when created. This is used due to a limitation in the templating system.
Name – This is the name that you wish to show up in the dialog that appears when Visual Studio reads and loads the templates. This happens when the New Item or New Project dialogs are opened.
Description – This is mostly necessary for yourself, but does appear as a tooltip in the Visual Studio IDE.
ProjectType and ProjectSubType – These values are mainly used for the folder structure within the templates directory. I suggest you leave them alone, unless you really know what you’re doing.
Icon – This names the icon file that needs to be in the root of the template archive. If you wish to have something other than the DNN icon, put it in the root of the archive, and then name it here.
Folder – This node names and then defines the folder(s), and the subsequent files that should be put into those folders. A Folder element can have another child element of the same name.
ProjectItem – This element allows you to define a file within a folder. Using the $fileinputname$ parameter, you can customize the file name, as you will see with the DNN manifest file.

Now that you know what the elements are, and how they are used, we can concentrate on the things that you really want to worry about, the code files.

Modifying the Template Code Files

If you open any of the class files, you will immediately see a familiar parameter from the previous step, namely $fileinputname$. This allows you to customize things like class names, namespaces, property names, and so on. Simply insert the parameter into your code files where you would like it to be replaced with the name value entered by the person creating the project in the Visual Studio New Item dialog.

You should now continue to alter the code as you see fit. For example, changing the namespaces to match yours, adding namespaces, and so on. Once you do, simply save the file and place it into your template archive. If you add any new files or folders, do so but make sure that you add the folder and files to the .vstemplate configuration file.

Deploying the Template

Deploying the template is extremely easy, though I am not telling you the standard way. Instead, I am going to tell you the easy way.

Hopefully, you have created a copy of the template archive, and renamed it to something more meaningful to you. After doing so, save a new copy of the archive into the same directory that you pulled the original archive out of. That’s it! Nothing messy here. You don’t need to unzip it or anything. Visual Studio will do the rest of the work for you.

Technorati Tags: DotNetNuke,DNN,DNN Blogs,Development,Templates

Improving the Debugger Experience Using Attributes

Mitchel Sellers DotNetNuke Blog — Fri, 03 Jul 2009 14:44:00 GMT

I have often found that when debugging applications that a lot of time is spent drilling down into the various custom objects to see what the values are of specific instance methods. In this blog posting I will demonstrate the default behavior of Visual Studio when debugging a class, I will then show how you can improve the debugging experience with the addition of a simple attribute.

Changes to Future Blog Programming!

Mitchel Sellers DotNetNuke Blog — Thu, 02 Jul 2009 20:16:00 GMT

After doing this blog for almost three years I have came to a conclusion that I need to take a step back, and re-focus a bit and manage the content a bit more. To do this, I am making a few changes, don't worry not only will you keep getting the same quality of content, but you will start seeing more content and a better organization system behind the scenes. Overall this is a three step process, each phase of the changes will be outlined below.

Changes to Blogging on MitchelSellers.com

The first stage of change here is working to solidify the types of articles that will continue to be published via the communication channel. I will continue blogging about .NET and DotNetNuke technical topics, as well as product reviews. Therefore trying to stay with a more technical focus.

In addition to this, as part of becoming a C# MVP, you will start to see more C# articles here as well.

New Blog at IowaComputerGurus.com

The second stage of change is the introduction of a new blog on the company website, IowaComputerGurus.com. This blog will become the new home for the best practices, case study, and "doing business" blog articles. Trying to focus a bit on the proper implementation/leveraging of both the .NET and DotNetNuke platforms from a business perspective. These articles will be less technical in nature and are geared more towards doing business, we hope to include success stories of DotNetNuke implementations as well.

NOTE: if you are an existing IowaComputerGurus customer and would like your project featured in a case study on the new blog, please e-mail me msellers@iowacomputergurus.com.

Tutorials Aggregation

The final stage of change will come from a future "tutorial aggregation" system. This will be a new place for the storage of items that are currently being posted to this blog that are much more directly "tutorial" related; items such as the DotNetNuke installation, upgrade, backup and restore tutorials. Right now, although very popular articles these are a bit harder for individuals to identify and access.

The exact plan and home of this new system is unknown, therefore, all blogs of this nature that are created will be tagged with the "Tutorials" tag, so they can still be easily identified.

Comments/Suggestions Appreciated

As with any change, some people will not like the direction that things are going, I welcome comments and suggestions on better ways to manage this information. Otherwise, stay tuned for future blogs and announcements.

New ArrowDesigns.com Site Launched!

DotNetNuke Consultant Blog - Arrow Consulting & De — Thu, 02 Jul 2009 16:26:43 GMT

I’m very excited to announce our new website at www.ArrowDesigns.com. We’ve spent several months tweaking it and getting it just right and I’m really proud of what we have. Check it out and drop me a line to let me know what you think – ryan atsign arrowdesigns dot com. Some of the highlights: Software Consulting Web Design [...]

Upcoming .Net Community Events in Florida

The Mighty Blog — Thu, 02 Jul 2009 12:10:00 GMT

There are quite a few events coming up in Florida in the next few months. They are all free, and most will give you the opportunity to win free stuff just for showing up. Awesome! If you find yourself in or around any of these events, I strongly recommend you stop by. I have been to most of them, and they are great.

All of the following information came from the Orlando DotNetNuke® Users Group (ODUG) website. See our events page.

July 9 - Orlando DotNetNuke® Users Group
Will Strohl (nobody) will be talking about the Core DNN Blog Module.

July 14 – Orlando PASS
Chad Miller will be discussing Powershell with SQL Server.

July 15 – Space Coast .Net User Group
Oleg Sych will be presenting on VSTS and TFS.

July 16 – Orlando .Net User Group
Joe Healy (Microsoft Developer Evangelist) will be speaking about the developer features in IE8.

July 16 – Space Coast SQL User Group
Don King and Clay Seifert will be each presenting a different session. They will be speaking about SQL Server 2005 Clustering and SQL Server Analysis Services, respectively.

July 21 – Lakeland .Net User Group
This user group will be holding a session entitled “Lakeland’s .Net Speaker Idol” and it promises to be a fun time, where you will see speakers compete against each other for prizes.

August 4 – Orlando DotNetNuke® Users Group
DNN author, Darren Neese will be showing the new features in the DNN skinning engine.

August 18 – Space Coast .Net User Group
Topic and speaker TBA. (sorry…)

August 20 – Orlando .Net User Group
Christopher Bennage (MVP) will be showing the attendees SilverArcade.

August 20 – Space Coast SQL User Group
Joe Healy (Microsoft Developer Evangelist) shows the group SQL Server 2008 enhancements from a developers perspective.

August 29 – Jacksonville Code Camp
The Jax Code Camp crew overcame some very challenging obstacles last year. I was extremely impressed. I expect them to put on a great event again this year.

September 5 – Tallahassee Code Camp
Tallahassee Code Camp was a great time last year. They always have some great presenters on-hand.

September 10 – Space Coast SQL User Group
Jack Corbett will be presenting a yet to be determined topic.

November 5 – Orlando DotNetNuke® Users Group
DNN Blog Project Team Lead, Antonio Chagoury, will be presenting “Mashing Up Your DotNetNuke Using RESTful APIs.”

Technorati Tags: DotNetNuke,DNN,DNN Blogs,.Net,Code Camp,Events,User Group,ODUG,Orlando DotNetNuke Users Group,ONETUG,Orlando .Net User Group,Space Coast SQL User Group,Space Coast .Net User Group

Kudos ODUG

Brian Scarbeau — Wed, 01 Jul 2009 21:42:32 GMT

Today marks the day when the Orlando DotNetNuke User group officially has 200 members.

It was a year and half ago that I started this group with about 7 members who came and met on a Saturday morning to discuss issues relating to the best open source web portal, DotNetNuke. Will Strohl was there along with a co-worker. Will has been a great member and now great leader of the group.

More recently, Will was in charge of putting together the Day of DotNetNuke held last month at the Microsoft Office in Tampa, FL.

Many members are benefitting from this user group and I wish it continued grown and success.

Technorati Tags: ODUG,DotNetNuke

Peter Donker to present at OpenForce 2009 EU

Peter Donker — Wed, 01 Jul 2009 19:42:05 GMT

After the good news for OpenForce US for this year (see this post) I am very pleased to have been selected to present at OpenForce EU as well. The sessions are entitled "Advanced Module Development in DNN", and "Extension Software Protection in DNN".

More...

Reorganizing the bookshelf at the local Borders

ChrisHammond.com — Tue, 30 Jun 2009 05:09:38 GMT

So tonight after work and before the St. Louis .Net User Group meeting I ran to Borders to see if I could find my book on the shelf. Well guess what, I did!

I was pretty stoked to find it, but was shocked to only see the DNN4 book on the shelf, not any of the other DNN books. Well after digging around for a while I found them on another section, so I took the opportunity to organize a little :D Here’s the result.

Issue 46 - DotNetNuke ASCX Skinning and Open Web Studio Tutorials

DNN Creative Magazine — Mon, 29 Jun 2009 22:26:00 GMT

July 2009

Welcome to issue 46 of DNN Creative Magazine

In this issue we look at the professionals method for creating DotNetNuke skins, ASCX skinning.

We did some quick research via twitter for the preferred method of skinning with the DotNetNuke professionals in the community and 100% of the skinners preferred the ASCX method for skinning.

ASCX skinning provides you with several benefits over the other methods of skinning in DotNetNuke. The main benefit is that it is much quicker to create a skin in DotNetNuke using the ASCX method.

Further benefits include you can make changes live on the website without re-parsing or re-installing the skin, you can instantly see edits and changes you make to your skin code, you can view at a glance all of a skin tokens properties, and a really useful feature is that if you are using Visual Web Developer Express it will suggest the attributes that are available for each of the DotNetNuke tokens.

We demonstrate all of these techniques and show you how to get started with ASCX skinning in DotNetNuke.

Accompanying the skinning, we have part four in our series on the Open Web Studio Tutorials. In this episode we demonstrate how to add personalisation to the knowledgebase module using InterModule Communications and creating a ‘my saved articles’ module. We also demonstrate how to create a Tooltip using JQuery, how to change the “fetching data” message, how to enable Rich Text / HTML articles and how to create a multi-category selection for each knowledgebase article.

Finally, we have a podcast covering the latest DotNetNuke News as well as more tips and tricks.

This issue comes complete with 11 Video Tutorials and 1 Podcast!

Tutorials:

Skinning:	DotNetNuke ASCX Skinning for Professional Skinners (6 videos - 58mins)
Module Development Series:	Personalization, Text Editor, Logging and Reporting in Open Web Studio – Part 4 of 6 – How to Build a Public Knowledge Base with OWS (5 videos - 58mins)
Podcasts:	DotNetNuke News, DataSprings Dynamic Forms, DNN 5.1 Professional, Openforce 09, Snapsis PageBlaster (25mins)

View issue 46 to download all of the videos in one zip file

DNN Creative Magazine for DotNetNuke Web Designers
Covering DotNetNuke module video reviews, video tutorials, mp3 interviews, resources and web design tips for working with DotNetNuke.

In 46 issues we have created 441 videos!

Engage: Publish 5.4 Released

DotNetNuke Developer — Mon, 29 Jun 2009 21:37:25 GMT

So it’s been way too long, 6 months to be pretty exact, since we had a new release for Engage: Publish . Well last Thursday it finally came! We released Publish 5.4 on our website, though without announcement because of everything else we have had going...(read more)

The Onion Of URL Rewriting

AppTheory DotNetNuke Blog — Mon, 29 Jun 2009 00:35:00 GMT

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.

How to Manually Delete A DotNetNuke Module

The Mighty Blog — Sun, 28 Jun 2009 19:31:00 GMT

I was recently asked how someone could manually delete a module once it is installed. The number of use cases where this would be useful is limited, but it is still a valid scenario that needs to be considered – especially during development. Here is a walk through of the general steps required to delete a module manually.

Run the Uninstall script (if necessary)
Delete the module files from the DesktopModules and App_Code folder
Grab the DesktopModuleId
Delete the permissions associated with the module
Delete the module from the database
Refresh the site cache to update the UI with your changes

While I have not fully verified these steps to be the same in DNN version 5.x, they should generally be the same. Here is some guidance to follow each of the defined steps above…

WARNING! Performing these steps incorrectly could result in your DNN site being broken and/or no longer accessible. In some cases, this might be permanent. It is HIGHLY recommended that you perform a complete backup of your database and file system before performing these steps. Doing so will give you a restore point, should something go wrong.

Run the Uninstall Script

Not all modules require a Data Access Layer (DAL), as some modules only perform utility functions and do not need to save and retrieve information from the database. The majority of the module out there do have a DAL though, and in turn will have an uninstall script in their folder. Look for a file named Uninstall.SqlDataProvider in the DesktopModules folder for the module you’re deleting. Here is a reference path for you to use:

~/DesktopModules//Uninstall.SqlDataProvider

Assuming your module is named “WNSUtility”, the above path would look like this:

~/DesktopModules/WNSUtility/Uninstall.SqlDataProvider

Using the SQL Module in the Host Menu, execute this script. Be sure to load the script, and then check the checkbox for Run as Script before you execute it.

Please Note: If you are using a different Data Provider, the file extension for your uninstall script will be different.

Delete the Module Files

Deleting the files from a module is easy. Find the module directory for your module. Using the example from above, it would be:

~/DesktopModules/WNSUtility/

Delete all files from that directory, and the directory itself. You might run into one or more errors do to files being loaded into memory. Should this happen, you can release the file(s) from memory by recycling the Application Pool, or restarting IIS.

Grab the DesktopModuleId

This is a very important step, as the final two steps would be incredibly difficult without the DesktopModuleId. There is not always an exact science to finding the DesktopModuleId, but we will need it for the following steps. In most cases, I simply perform the following query on the database:

     SELECT * FROM [dbo].[DesktopModules] 

    WHERE [IsAdmin] = 0 

    ORDER BY [FriendlyName] 

    -- or 

    SELECT * FROM {databaseOwner}{objectQualifier}DesktopModules 

    WHERE [IsAdmin] = 0 

    ORDER BY [FriendlyName]

From the above script, locating the module in question is usually easy. Simply find the module using its Friendly Name, and then record the DesktopModuleID associated with it.

Delete the Module Permissions

This step gets executed in three parts. As long as there aren’t a lot of instances of the module in your site, these queries should execute quickly, and error free.

Using the DesktopModuleId from the previous step, execute the GetModuleDefinitions stored procedure, taking note of each ModuleDefID. For each module definition returned, you will next need to execute the GetPermissionsByModuleDefID stored procedure, this time taking note of each PermissionID. Finally, execute the DeletePermission stored procedure for each PermissionID that was returned.

Delete the Module from the Database

Now, we actually delete the module. Doing so is very easy. Like the previous step, we just need to execute a stored procedure using the DesktopModuleID we grabbed a little while ago. Execute the DeleteDesktopModule stored procedure to delete the module.

Refresh the Site Cache

The final thing to do is to clear the cache on the site to remove the module from all of the user interface, such as the drop down lists. You just need to clear the cache on the site. I have blogged about clearing the DNN site cache before.

Technorati Tags: DotNetNuke,DNN,DNN Blogs,Module Development

Changing the Default Favicon for Your Site

The Mighty Blog — Sun, 28 Jun 2009 01:33:00 GMT

In DotNetNuke®, a favicon of the DNN gear logo is placed as the default favicon. For some websites, this is no big deal. However, for any site that requires its own branding, changing the favicon is a really big requirement. Luckily, DNN makes changing this easy, and flexible.

First of all, in the root of your DNN site, there are two favicons:

favicon.ico
DotNetNuke.ico

Both files contain the same image, the DNN gear.

You could just overwrite the favicon file with your own. However, that is technically making a core code change, and if you end up putting a second portal on your DNN instance, both sites will be using the same favicon. This will likely put you into the same position that you originally were in, in the first place.

The real solution is to put your favicon into the root of your portal directory, saved as favicon.ico. For example, for the root site, your file name and path might match the following:

~/Portals/0/favicon.ico

When your site is loaded, the DNN framework will automatically grab and send the new favicon to the web browser, instead of the one on the root of your DNN installation. This will work for each and every portal that you have as part of this single DNN instance. For example, if you have 50 portals hosted in your DNN instance, each one can have its own unique favicon using this method.

Technorati Tags: DotNetNuke,DNN,DNN Blogs,Favicon

SharePoint VS DotNetNuke, a Recap

CTO 2.0 - Antonio Chagoury — Sun, 28 Jun 2009 00:32:49 GMT

Yesterday afternoon Hal Hayes and I were invited to speak at the SharePoint Technology Conference hosted and organized by the SharePoint User Group DC (SUGDC).

The event was packed with sessions hosted by leaders and top professionals in the Microsoft SharePoint space. I was quite honored to be invited to speak, and if that wasn’t enough, I was speaking more on behalf of DotNetNuke rather than SharePoint.

More...

ODUG Celebrates it’s One Year INETA Anniversary

The Mighty Blog — Sat, 27 Jun 2009 21:06:00 GMT

The Orlando DotNetNuke® Users Group (ODUG) is not very old. We are still working toward finishing our second year as a user group. Our first meeting was February of 2008. However, it was several months later before we actually were able to claim our status as member of INETA. Well, a few days ago I was reminded of this, as there was a package that showed up for me at work.

Looking at the package, I was confused since it was from INETA. I wasn’t expecting any packages, much less one from INETA. When I opened it, I was greeted with a pleasant surprise. It was a mounted certificate, celebrating our one year anniversary with the INETA user group program.

For those of you who are not sure what that means… INETA sponsors user groups in a way that most other organizations cannot. It gives support in a number of ways to user group leaders. The most notable way they sponsor user groups comes in the form of flying in speakers. INETA provides two speakers per year, with all of their expenses paid. So far, we have only used one of these. INETA flew in Chris Hammond to us earlier this year. We are already planning to use our 2nd one in December of this year.

I have only one thing to say, “Thank you, INETA!”

Technorati Tags: DotNetNuke,DNN Blogs,INETA,User Group,ODUG,Orlando DotNetNuke Users Group