Early tomorrow morning I am flying out Seattle to see my Mom.  About 6 days ago she called to deliver some bad news – the cancer was back. 

Over the past 3 years my Mom has battled a couple of different forms of cancer.  First there was the Breast Cancer.  Fortunately the doctors caught it early.  They operated quickly, performing a lumpectomy and lymph node removal at the same time.  Following radiation treatment everything seemed to be good.  No further cancer was found in the lymph nodes and my mom seemed to have recovered fairly quickly.  More...

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.