One of the issues that every DotNetNuke skin designer faces is how to design skins for multiple browsers.  Often, getting a skin to work in Firefox, Chrome, Safari and Opera is pretty straightforward and doesn’t require much tweaking.  Unfortunately, the same cannot be said of Internet Explorer.  Making your skin work with IE6, 7 and 8 along with all the other browsers can be a bit of a nightmare.

I previously addressed this issue in DotNetNuke Tips and Tricks #3: Conditional StyleSheets.  In that post, I created a skin object that allows you to conditionally add a stylesheet to the skin based on a condition defined by the designer.  This skin object was subsequently added to the core framework and is currently being used by many designers.  In fact, Artisteer uses it in all the DotNetNuke skins that their software generates.

Recently, I found a method that I like better than using conditional stylesheets.  One of the downsides to conditional stylesheets is that you end up causing stylesheet bloat.  Conditional stylesheets add round trips to the server which we should be trying to minimize.  Conditional stylesheets also require you to maintain multiple stylesheets which can be a little painful.  If you make a change in your main stylesheet, you will need to find the corresponding section in your IE specific stylesheets and potentially make changes to them as well.  From a maintenance and development perspective, this is far from optimal.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Myths and Misconceptions

Over the past several years designers have expressed a number of frustrations about the DotNetNuke skinning engine.  Often these frustrations may be based on some particular difficulty they are having and therefore there is a kernel of truth to the issue.  What I frequently find when digging into these challenges is that there is a misunderstanding by the designer which leads to the frustration or the design is constrained by limitations in HTML and CSS.  Fundamentally, we need to do a better job of providing documentation to the design community which helps them to better address their points of frustration.  Below I present some of the common myths about DotNetNuke skinning.

Very early in the life of DotNetNuke, modules were fairly limited in their functionality.  Modules could have multiple behaviors attached to them by the framework which were displayed as a list of link buttons.  Very quickly this UI became very cumbersome as we continued to add more and more behaviors to the standard list of behaviors. This UI greatly limited the amount of actions that could be attached to a module and at the time the list of behaviors was fairly static. 

One of the first enhancements that I worked on for my own modules was the ability to create a menu that was attached to the module.   This menu was intended to be customizable by the module developer and the framework and would remove the space limitations that plagued the early framework.  When I showed Shaun the menus he instantly saw the potential and we incorporated them into the framework.

The module action menus were originally designed to be extremely flexible.  I wanted to be able to create links that could perform client-side actions as well as trigger events on the server side, depending on the needs of the module developer.  Many module developers have taken advantage of the server side functionality over the years, but I have not seen many modules which have taken advantage of the client-side functionality.  When I first created the menus, I documented the API using XML Comments, which were not being used anywhere else in the framework.  Until recently the project was not even publishing the API documentation, so these comments went largely unnoticed by the developer community.  I am happy to say that with 5.5 that has changed and the API documentation for the core framework is now available with the rest of the Community Edition download packages.

I am happy to announce the release of DotNetNuke 5.5.1.  This release includes many bug fixes for the most critical issues identified in DotNetNuke 5.5.0 which we released last month.  As a result of the recent ASP.Net Padding Oracle Vulnerability, which was discussed by Shaun Walker and Cathal Connolly in their recent blogs, we have added additional checks and upgrade enhancements in this release to ensure that DotNetNuke sites running the latest version are using the recommended CustomErrors configuration.  

As we have noted in many of our recent releases, we continue to increase our Quality Assurance efforts with each release.  Given the critical nature of the ASP.Net vulnerability, we paid extra attention to more than 40 different upgrade scenarios to increase the stability and reliability of the upgrade process, and to ensure that once upgraded your site would be protected.  As always, even for those unfortunate few who have issues upgrading, the community stands ready to assist you with any problems you may encounter.  We highly recommend that everyone upgrade to the DotNetNuke 5.5.1 release as soon as possible.  For those who are unable to upgrade their sites we anticipate having a standalone module which we will make available later this week which provides the same benefits against the padding oracle vunlnerability as the core enhancements made in 5.5.1.

As long-time DotNetNuke users well know, DotNetNuke contains an extensive API that makes the platform extremely powerful and flexible.  Over time the core APIs have continued to expand as new features were added and existing features were enhanced.  One of the core APIs which has been part of DotNetNuke since 4.6 was released three years ago today is the XML Merge API.

The XML Merge API was developed to enable developers to define changes that need to occur to any xml based file within the website.  It is primarily used by the core framework to make updates to web.config but has utility beyond just updating web.config.  Web.config management was a huge problem in early versions of DotNetNuke.  Managing and applying the web.config changes every time you upgraded DotNetNuke was a time-consuming and error-prone process.  The XML Merge API was developed in part to address this need.

When I first created the API, I needed a way to merge dozens of custom URL rewriter rules into the siteurls.config for the AspDotNetStorefront module.  These rules could change with new versions of the ASPDNSF module and so I also needed to support the ability to apply these changes in a version specific manner.  My first version was included as part of the ASPDNSF module, but due to a contractual arrangement, I was able to make this API available in DotNetNuke as well.

Have you ever installed a piece of software but weren’t sure where to go from there? Have you struggled to find that feature that you know is there, but you’re not quite sure how to turn it on?  Have you occasionally had problems just getting some complex piece of software installed?  These are challenges faced by the average user of almost every piece of software ever created.  Few software applications are so straight forward and simple that no documentation is required.  As software becomes more and more complex, the documentation and training requirements increase as well.  You need documentation and training that caters to the beginner as well as the expert.

I have heard many DotNetNuke users recite these same challenges.  Like every content management system or application framework I have ever encountered, DotNetNuke is a complex system, so it is not unusual that some new users will find it challenging to get started.  It is also not unusual that many experienced DotNetNuke users and developers will find new features and capabilities that they never knew existed.  The biggest hurdle for many users is the perception that DotNetNuke is not well documented or that the only place to find information is in the forums.

Over the last 8 years, the DotNetNuke team, and the DotNetNuke community has created a wealth of documentation, videos and books covering all aspects of DotNetNuke.  As an Open Source project, DotNetNuke has relied heavily on community members not just for coding and design skills, but also for providing much of the documentation that is available for the platform.  Unfortunately, we have not always done a very great job of making that information easy to find for users.  Some of the information is available on DotNetNuke.com, but often you may need to venture out to other websites to get information provided by the broader DotNetNuke community.

My purpose with this post is to provide a good starting point for anyone who is new to DotNetNuke, and even for many long-time DotNetNuke users, administrators, designers and developers.  This list is far from exhaustive, but will provide a very solid foundation that should answer a lot of questions.  I have used everyone of these resources and know that they are all provide high quality material that is fairly up to date.  If you have been using DotNetNuke for any period of time, I am sure you have your own list of resources that you find valuable.  Feel free to leave a comment and tell me what documentation and training resources you have found helpful.

This article is cross-posted from my company blog.

Do you use Windows Live Writer and the DotNetNuke Blog module?  I do, and I just discovered a great new WLW feature which is going to greatly simplify the steps I have to perform for every blog post.

I have been using Windows Live Writer (WLW) for a few years now.  I really love WLW for writing my blog.  In fact I loved it so much that it was one of the reasons I had shifted my personal blog to BlogEngine.net.  At the time, the DotNetNuke Blog module did not support a posting API which could be used with WLW.  You don’t know real pain until you have tried to write a blog post with nothing but a web based rich text editor.  Once you lose one or two posts because of a session timeout or your post gets mangled because of the way the editor handles script blocks or xml blocks, you will quickly swear off all blogging with an RTE.

Once I started using BlogEngine, I came to really appreciate some of its features.  It really tries to leverage the capabilities of WLW to make the blogging experience as pain free as possible.  One feature that I use quite a bit is the ability to split my blog into a summary along with the full post just by including the “[more]” tag in my post.  Everything before the tag will be used when displaying the blog summaries.  The entire content will be displayed when viewing a specific blog post.  This is great, although it does limit your ability to craft a great summary that differs from the opening of your blog post.

Unfortunately, the DotNetNuke Blog module does not support the “more” tag.  If you don’t provide a summary when creating a post for the Blog module, then it will try to create a summary using the first 1000 or so characters.  This rarely works with my blog posts and even when it works it is generally not optimal.  Because I usually include an image at the top of my posts, the auto-summary feature usually just chokes and I am forced to hand enter a summary for my blog on DotNetNuke.com.  This is definitely a problem.  My blog posts often include coding examples.  When I edit a blog post just so I can hand craft the summary, it also has the side effect of opening the main blog content in the RTE which then reformats my code blocks when I go to save the summary.  Hello mangled code samples.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Packaging

History

One of the great strengths of the DotNetNuke platform over the past 6 years has been the rapid growth of the ecosystem for modules and skins.  Very early in the project’s history we realized that in order to promote redistribution of extensions, we needed a standard method to package modules.  At the time, one of the community members contributed their code for reading a standard xml file located inside a zip file containing all of the module files.  Using this contribution as the foundation, I created the core module installation feature for DotNetNuke.  The xml file that controlled the installation process came to be known as the module manifest. 

The purpose of the manifest file was to identify key files within the package and designate where they should be installed.  This manifest also contained some additional metadata that was necessary for creating the needed entries in the different module tables within DotNetNuke.

Over time, Charles and myself continued to extend the module manifest and the packaging standard so that we could handle more and more installation scenarios. Even with these additions, the manifest and packaging standard was still basically the same as what I had originally built in 2004.

When Skinning was introduced with DotNetNuke 2.0 it used a different packaging standard.  Instead of relying on a manifest, it used a convention based approach and depended on having files follow a specific naming standard.  This worked well, but it had a number of limitations.  Like the module packaging standard, this remained largely unchanged until fairly recently.

This article is cross-posted from my DotNetNuke blog.

On August 18th we kicked off the Mobile DotNetNuke Hackathon at the St. Louis DotNetNuke User Group. ...