Over and over I see DotNetNuke modules whose settings pages are created using the utilitarian look of the default DotNetNuke settings.  I personally don’t care for this appearance since the layout relies very heavily on the use of tables.  I really wanted to style my settings page along the lines discussed in the recent Sitepoint article on Fancy Form Design Using CSS.  Unfortunately, if you setup your module to use the standard settings page, then you do not have control over the stylesheets.  Unlike the standard page, your module.css is not injected into the page when viewing the settings page.  Sure, your users could go into the Site Settings and edit the portal.css, but that is probably beyond the skills of most administrators.  Instead, with a little bit of code in your module, then you can add your module.css to the page.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    Dim DefaultPage As CDefault = DirectCast(Page, CDefault)
    DefaultPage.AddStyleSheet("simplemenustyles", String.Format("{0}/module.css", Me.ModulePath), True)
End Sub

After adding this code and the appropriate styles to my module.css I now have complete control over the look of my settings within the module settings page.

July 4th 2008 marks another milestone in the evolution of DotNetNuke:  For the first time that I am aware of, we have distributed a completely automated build of DotNetNuke.  For the last 5 years Shaun has manually built and packaged every release of DotNetNuke.  For the bulk of those releases, the build occurred on a single machine that Shaun has nurtured throughout the life of DotNetNuke.  Not only was almost every release built on the same  machine, but they were built by Shaun.  Often the build and packaging process took a considerable amount of time which limited the frequency with which builds were released.

A couple of years ago Bryan Andrews had setup a CI server for the project but it was not really used beyond verifying that the project could compile without errors as new code was checked in.  We never used that server for creating the actual release packages.  Over time, the CI process broke down and for the past year or so we have operated without continuous integration.  This spring Bryan worked with Scott Willhite to revive our CI process and to enable us to create fully automated builds.  DotNetNuke 05.00.00 Beta 6 marks the first release to use the new CI server for building and packaging the official release. Beta 6 will not only be an opportunity for testing the latest DotNetNuke version but also for testing the new packaging.

So no longer will the 4th of July just be a celebration of the day America gained it’s Independence, it will also mark the day that the DotNetNuke project gained it’s independence from a manual build process.  Now Shaun can finally retire his old computer to the DotNetNuke Museum where it can take it’s rightful place alongside IBuySpy Workshop, the Techno-Skin and the soon to be retired Blue Skin.

Over the past couple of weeks, the DotNetNuke project has had to deal with a few different security issues.  As Shaun pointed out in his post, we take these issues very seriously and make every attempt to deal with them in a professional manner.  Even now, as we deal with the latest issue, it is important to note that the security of DotNetNuke is something that impacts everyone in the community.  While the DotNetNuke security team is responsible for isolating and fixing the security issues, there are some things that you as a member of the community can do to help.

Restrict discussion of security issues to official channels

The DotNetNuke team, like most organizations, prioritizes our communications.  Certain forms of communication will result in immediate action on the part of team members, while other channels may go for several hours or even days without being noticed.  If you have a security issue, then security@dotnetnuke.com is the right channel to use, since this email alias is closely monitored by our security team.  If for some reason, you do not get a response here, then direct communication via the phone or IM with a member of DotNetNuke corp will result in prompt attention.  If you have not relieved an acknowledgment within a reasonable amount of time, then a follow-up using a direct communication channel is warranted.  In no case should you make a public posting about the existence of nor the details of a security vulnerability until the team has had a chance to analyze the report and create an appropriate patch and security notice.

Give the team time

Security vulnerabilities are serious problems.  When creating a fix for a vulnerability, we try to be very thorough.  We need to make sure that we fully understand the nature of the vulnerability and that we have a fix that does not further compromise the application.  It is not uncommon to find out that what at first seemed like an isolated issue may in fact have a wider impact than first assumed.  Once a fix is created and the issue is reported in a security notice then hackers will begin analyzing the system to see if they can get around whatever fix is put in place.  If we did not spend time to make sure that we fixed the problem completely, we could end up just highlighting a problem rather than actually fixing it.  Generally speaking, once we have acknowledged that a problem exists and have enough details to reproduce the bug, then we will work internally to create a fix.  During this time we will not likely have any further discussion with the person originally reporting the issue.  Once we have the fix completed we may give a brief update to the person reporting the issue and may even enlist their assistance in testing the fix.  Do not think that because we have not talked with you in a few days that nothing is happening.  Depending on the nature of the issue it may take anywhere from a few hours to several days to actually find an acceptable resolution.

Follow good security practices

Users often get very nervous whenever word of a new vulnerability comes out.  This is understandable.  However, by following good security practices, you minimize your risk which means you are less apt to push us to deliver a fix before we fully understand the problem and the correct solution.  Some simple steps you can take to minimize your risks -

Make frequent backups

The more critical your data is, the more frequently you should make backups.  If you have a backup, then dealing with a site-defacement becomes a minor annoyance and not the end of the world.

Minimize the number of installed extensions

Every new module and skin introduces the potential for new attack vectors.  If you are not using a module then uninstall it.  If you are not using a provider then delete its assemblies from the /bin folder. 

Use trusted extensions

Modules, providers, skin objects and even skins pose a potential security threat.  You should be selective in what you install on a production system.  If you want to test out a new module from a vendor who you don't know, then do so in a sandboxed system.  Monitor the behavior of the module to ensure that it is not doing anything malicious.  If you have the skills, examine the code or look at the network traffic to ensure that there is nothing hidden going on in the background.

Don't share logins and passwords across sites

People have trouble remembering the username and password that they use for various applications and websites.  Invest in a good password manager that will allow you to create unique accounts for every site and application.  Once you have a password manager, be diligent in using it.  Your site/server is much more secure if the username and password is unique for that site.  Using a password manager means that you are much more likely to choose a secure password rather than worrying about creating something that is easy to remember.

Give users the least privileges needed to do their job

Even though you may trust a user with a host account, you should not give them host privileges unless they absolutely need those privileges to perform some task.  In past versions of DotNetNuke we made it difficult to apply this principle.  Often people were given full administrative privileges because they needed access to a single feature which was only available to admins.  There was no way to give them access to that one feature.  We are significantly improving this in DotNetNuke 5.0 by allowing access to admin modules to be delegated to users or groups.  We are also adding in the ability to deny permissions to a specific user or group.  These two changes will help ensure that you have the level of control needed to adequately lock down your site without impairing your ability to delegate administrative tasks as needed for your particular business processes.

In the end, good security relies on following well established practices.  As we resolve the current security issues and move past the events of the past few days, I hope people will keep these tips in mind.  I think they will go a long ways towards reducing problems in the future and ensuring that we can continue to put out a secure web application framework that will continue to be trusted by users all over the globe.

The OpenForce Call for Speakers was scheduled to end today, however due to some issues with the original session submission forms we have decided to extend the call for speakers submission date.  Please submit all session proposals by 5PM PST on Friday April 25th.

We have a lot of great sessions already submitted but we want to make sure that all speakers have an opportunity to get their session proposals submitted.  If you are having any problems with the session submission, please send me an email and we'll take care of it promptly.

While I was in the Netherlands for OpenForce Europe, I had the misfortune to lose my original Zune.  I thought the Zune software was ok and the player was so-so.  I really liked the promise of having integrated wi-fi, but found the initial implementation to be a bit lacking.  I was forced to go back to using my old iPod Mini. 

Now for all of you Apple Fanboys, I think the new iPod touch is awesome (if a little overpriced), but I am not a fan of Apple software at all.  I have way to many crashes with the Apple updater service.  Since I was back to using my iPod Mini, I found a new appreciation for some of the things I liked about the Zune. For all of the useability press that Apple gets, I just don't get the controls on the iPod.  It displays a vertical list (menu items or songs) and then requires me to make a circular motion to move up and down.  That is not intuitive at all.  This is one of those little things that made using the Zune much easier for me.  I wasn't forced to remember - do I move clockwise to move down in the list, or counter clockwise?  How do I change the volume?  With the Zune it was press up to increase the volume, press down to decrease.  Press left to move left.  Press right to move right.  My hand motions matched the visual cues I was being provided.

Well, after a lot of waiting and searching, I was finally able to find one of the new Zune 80's last week.  I like the Zune 2.0 software better than the 1.0 software.  The player is also a big improvement over the original.  It no longer seems like I am carrying around a brick.  It is kinda like the difference between cellphones that were offered in 1997 and those offered in 2007.  The ones in '97 seem so large by comparison.  Anyone, the new player has a larger hard-drive but is much smaller than the original 30GB version.

Not only did Microsoft make a lot of improvements to the hardware, but they also completely rewrote the firmware.  The new firmware is much more intuitive and has a cleaner design.  When paired with the Client software and the Zune Social site, I find that the Zune presents a much more integrated experience than it did before.  I think the Social site adds a unique twist to the Zune.  This is a great opportunity to see what others are listening to and opens me up to new possibilities.  If nothing else, it gives me something else to discuss with my network of friends.  The fact that it is tied in with my Xbox Live/Windows Live account allows me to start bringing my various social networks together and finding new commonalities with old friends.

Well, being the DotNetNuke geek that I am, I knew I had to create a DNN themed background for my zune.  I have posted the image on my flicker account (just click on the image below).  The white letters with the red background is a great contrast.

I have seen a few posts recently about other conferences (Adobe Max and Community Server Developer Conference) that made me think hard about how we have positioned the OpenForce conferences this year.  I remember in past years that events like JavaOne developed a reputation for being nothing more than giant sales and marketing event put on by Sun.  This is a trap that I hope we never fall into with the OpenForce conference.  Our goal from the very beginning has been to create an event where the community could come together and share our experiences and learn from other experts in the community. 

While I know that the community is interested in where we are going with the DotNetNuke and how DotNetNuke Corp plays into the big picture, I also know that few people want to spend their hard-earned cash just so they can sit through a marketing pitch.  Our challenge this year and beyond is to make sure we keep the focus where it belongs - on you - the community.  We worked very hard this year to attract some of the superstars in the community to come and speak at the conference.  Our goal was not only to get great speakers (which I think we have done), but also to make sure that we covered topics that would be relevant to our entire community - not just developers and not just people from North America.

If we ever lose sight of where our focus should be, I hope that someone from the community reminds us of why we created this conference in the first place.  This doesn't mean that we won't tell the community about some of the features we have planned or about some of the community support services that DotNetNuke Corp. offers, but we do not want that to become the focus of the event.

Our OpenForce events would not have been possible without the support and backing of both SDN and DevConnections.  They have allowed us to focus on getting the content right, while they did the heavy lifting on the logistics side of the house.  Even though a lot of effort has gone into preparing for both of these conferences, we know that we can do better.  Next year we look forward to streamlining our processes to identify speakers earlier, to expand the number of sessions and tracks that we offer, and to attract even more attendees and sponsors.

If you are attending OpenForce '07 next week, feel free to stop by the DotNetNuke Corp booth (booth #736), we would love to meet you and chat.  Yes, we may actually show you some of what we are planning for DotNetNuke 5.0, but we know you won't mind.

For the past couple of months I have been playing with PowerShell and it has been a real pleasure to dig-in and get my hands dirty in a command-line interface again.  Not since my early days with the Amiga and ARexx have I enjoyed learning about a new CLI and an associated scripting language.  The PowerShell team has done a great job of bringing windows scripting and the CLI into the 21st century.  Not only has Microsoft been putting in a lot of effort into PowerShell, but you are also seeing an explosion of third-parties who have also jumped onboard to push the new language and hosting environment.  Companies like Sapien, Quest, /n Software, and ShellTools are creating great tools and sponsoring community sites like PowerShellCommunity.org.

With all of this excitement and passion in the PowerShell community, how could I not look to see how I could use PowerShell with DotNetNuke.  Thus was born my session idea:  PowerShell for DotNetNuke which I will be presenting in Las Vegas at OpenForce '07.  During my session I will be showing how you can use PowerShell to enhance managing DotNetNuke, both for installing new sites and for sites that are already up and running. 

One of the early ideas I had was that I might even be able to create a DotNetNuke module that would let a user execute PowerShell commands and scripts on the server.  Since DotNetNuke allows you to lock down access to any module it is fairly secure.  The initial code for this module is based off earlier examples by Scott Hanselman and Dominick Baier.  Here is a sample video of my work so far.

I still have some enhancements that I will be making before the conference, but you can download the latest code here.

Nothing is ever easy in life.  The release of 4.6.0 and the subsequent release of 4.6.1 proved that.  4.6.1 was primarily concerned with fixing a couple of very nasty bugs from the 4.6.0 build.  The two worst bugs included a breaking change to the behavior of ModuleSettingsBase and a defect in the UserSettings page that caused the system to overwrite your usersettings whenever someone logged in.  Unfortunately, when we attempted to roll back the changes to ModuleSettingsBase to the pre-4.6.0 code, we did not get all of the relevant code rolled back.  This only made the breaking change worse.  This prompted us to take the unusual step of completely removing the 4.6.1 download until we could get a new version coded, tested and built to put back online.  Last night we posted the new 4.6.2 version which fixed the breaking change.

One of the lessons learned as we went through this exercise is that when building an API you must be constantly evaluating how your audience might use that API.  Often your customers may do things you never intended, but which you should have anticipated.  We need to strive to develop our APIs, not for how we intend to use them, but for how we anticipate our customers will want to use them.  Maybe I only need an add and an update method for some entity.  Should I create a delete method as well since it is likely that customers will need that feature?  This analysis affects not just what methods or properties I make available, but also how I architect the class hierarchy.  Finally, we need to be very careful and deliberate whenever a decision is made to remove a public member of an API.  It doesn't matter if we never use that portion of the API.  If it is public, then there is a good likelihood that someone will have found it and started using it in their code.  One of our overriding goals from day one has been to avoid breaking changes wherever possible.  We try to batch up breaking changes that are needed to evolve the platform and only introduce those changes in a single large release every 2 to 3 years.

The decision to remove the properties from ModuleSettingsBase was wrong.  Unfortunately, the architecture was not as clean as it should have been which meant rolling back the change was not straightforward as it impacted other parts of the system.  This also meant that a clean fix was also not possible.  The system has been patched to correct the initial bug which precipitated the change and to correct the rolled back code so that it works as expected.  We will likely revisit this portion of code in the future to clean up the inheritance chain so that this portion of code is not so brittle.

Last week DotNetNuke OpenForce Europe '07 kicked off our first round of officially sponsored conferences for the DotNetNuke community.  We have been planning for the OpenForce conferences for over a year and it was great just to get the first one out of the way.  Since we have never put together a conference before, we were not always sure what to expect.  The European conference was added in the early summer to our conference lineup, and we did not have as much time as we wanted to get all of the desired marketing pieces in place, but our European community members did not let us down.  Once they came back from summer vacation, the Europeans registered for the conference in record numbers.  Ultimately, the OpenForce conference resulted in a substantial increase over past SDC conference attendance numbers.  The community support could easily be seen in the conference rooms where DotNetNuke speakers often had more attendees and received higher scores than many of their SDC speaker counterparts.

Even with a short timeframe to plan the conference, we were able to work with SDC to create a great speaker line-up.  With topics ranging from localization, to skinning, to advanced module development, and even a discussion on DotNetNuke business opportunities, speakers provided relevant content for everyone in the DotNetNuke community.  Shaun and I also had a panel discussion, moderated by Richard Campbell from DotNetRocks, where we talked about where DotNetNuke is headed in the coming year.  Unfortunately, due to a travel mix-up, Carl Franklin was not present and we were unable to record DotNetRocks as originally planned.  It now looks like we will make this up at the OpenForce '07 conference in Las Vegas.

Everyone I talked to at the conference was excited by a chance to meet so many DotNetNuke experts in one place.  Without a doubt there has not been another single event where you could get as much in-depth information about DotNetNuke from people who clearly had "been there, done that".

One thing that I truly appreciate about DotNetNuke is the great community.  Not only did we have  great turnout for the conference, we also had community members who came to the Arnhem just to meet with some of the core team members.  We had a great meeting where we were able to discuss a lot of localization issues to be addressed in upcoming DotNetNuke releases.  I think that Peter Donker and the rest of the European contingent have a good handle on what is needed to help us complete the localization framework for DotNetNuke and I look forward to seeing some of their prototypes and designs that will help us resolve the last few remaining localization issues.  One aspect of the OpenForce conference which was very positive, is that we were able to help broaden the audience for SDC.  In the past, SDC has primarily consisted of attendees from the Netherlands.  This year, due in large part to the DotNetNuke community, we had people coming from all over Europe.

I want to give my sincere thanks to Joop Pecht, Remi Caron and the rest of the SDN staff.  We could not have pulled it off without their support and assistance.  Although I spent a lot of time on Skype and IM over the last couple of months with Joop, there is so much that they handled on our behalf behind the scenes that we could not have done without them.

I also want to thank Sebastian Leupold and Leigh Pointer for showing me around Haarlem and Amsterdam.  The food was great and the beer was awesome, although I am still not so sure about the whole windmill myth (for those who don't know, don't believe everything you see in pictures).  Next year I'll bring the wife and we can really hit the town.  Heck maybe we'll even see some wooden shoe wearing women selling tulips under a windmill.

For those who did not submit sessions when the call for speakers went out, you missed a chance to speak at a great conference.  Not only that, but Joop and the SDN really treat their speakers very well.  The trip to the movies and a day on the beach in Hoek van Holland were a great way to cap off a wonderful conference.

While it may be too late to partake in the festivities at OpenForce Europe, you can still make up for it by coming to OpenForce '07 in Las Vegas.  This conference promises to be even larger and more exciting than the European conference.  Where the SDC/OpenForce event had a combined attendance of almost 450 people, DevConnections/OpenForce '07 will have almost 10 times the number of attendees and a huge expo hall with over 100 exhibitors (including several DotNetNuke vendors).  Heck just the license for Visual Studio 2008 is a great reason to attend the conference.  Who knows, maybe you'll ride home on a brand new Harley Davidson with a copy of Visual Studio 2008 tucked under your arm.  I'll be there!  What about you?

DotNetNuke 4.6.0 is quickly approaching the release date.  We have gone through 2 different beta releases and have now packaged and release RC1 to our testers and benefactors.  While we have implemented a new beta testing group and added more default test cases into our test tracker, we are still not getting the level of testing that we feel is necessary.  We had a lot of people sign up for the beta test who ended up not being active participants which really hurt our testing efforts.  Out of nearly 60 people accepted into the program, fewer than 1/3 actually contributed feedback on the quality of the release.  We will continue to open up beta testing for future releases in order to increase our quality and ensure that we are getting feedback early in the release testing cycle.  For those who submitted feedback, we appreciate your efforts.

At this point we have addressed every Showstopper bug in Gemini and addressed quite a few major and minor bugs as well.  4.6 will see a number of new enhancements and new features, many of which have been blogged about by various team members.  I want to personally thank those core team members and project leads who have helped get this release ready in time for OpenForce Europe '07.  Specifically, I want to thank Cathal, Vicenc, Erik, Sebastian, Stefan, Mike, Dan and of course Charles.  Your hard work in fixing bugs and coding the enhancements, sometimes on very short notice, really helped pull this together.  I also want to thank Alex who spent a lot of time on this release getting bugs validated and moved over to the private  bug tracker for the team to fix.

This was really the first release where I have been actively involved in the entire cycle, from scoping the release, to coordinating bug fixes and ensuring we were getting testing accomplished.  For the past 4 years this has been primarily Shaun's responsibility and I am not sure how he was able to pull it off along with all of his other project and corporate responsibilities.

Below is a list all of the bugs, enhancements and new features which were addressed in this release.  You can see all of these in the 4.6.0 Roadmap, which will become the 4.6.0 Changelog once we go final.  At this point we don't expect any changes between now and the final release this weekend.  We should be dogfooding on DotNetNuke.com later tonight which is the last major hurdle before the release.

Finally, I want to welcome aboard two new project sponsors: Robert Half Technology, and AspDotNetStorefront.  Our project sponsors and advertisers help us keep the lights on, so we are very grateful to them for their support.