The Accidental Geek

DotNetNuke Symbol files and Intellisense

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 30 Oct 2009 05:58:48 -1000

For the past 7 years, the DotNetNuke project has provided various packages for users to simplify different installation and upgrade scenarios. Each package was built to address specific requests from the community. We have recently begun receiving requests for symbol files (.pdb files) and xml comments. As a result of these requests, starting with DotNetNuke 5.2.0, we will be releasing a new Symbols package with each release.

The first set of files included in the Symbols package are all of the .PDB files for the core framework. Essentially, any project which is included in the default solution file will generate a .pdb file that will be available in this package. Many developers have long assumed that .pdb files were only generated for debug builds, however, that does not have to be the case. It is possible, and even desirable, to generate .pdb files for release builds as well. To generate the pdb files follow the steps outlined below:

Open the Project Properties
Select the Compile tab
Set the configuration mode to Release
Click on the Advanced Compile Options button
Set the “Generate debug info” to “pdb-only”

You should see a screen similar to the image below.

Most users will never need the pdb files for their installation, however, if you are troubleshooting error messages in your event log then the pdb files will provide additional information which can aids in troubleshooting. To see how pdb files can help, lets look at a sample error message from the event log:

While there is some useful information in this error message in the stack trace, it just gives you a list of classes and methods to look through. If your methods are not granular enough, just knowing the method may not be enough. If you have installed the pdb files into your DotNetNuke installation then you will receive additional information in your stack trace as shown below.

Notice in the highlighted section that I now have an exact line number where the error occurred in the DotNetNuke source code. This greatly simplifies identifying the root cause of errors and makes it much easier to take corrective action. This is just one of the uses for pdb files, but is a great benefit when trying to isolate and troubleshoot problems in a production environment

In addition to symbol files, the new Symbols package will include XML Comments that are generated as part of the build process. The XML Comments will be used in the near future to create detailed API documentation for the core DotNetNuke framework. In addition to their usefulness in creating documentation, they are also useful when you are writing code that uses the core API. Lisa Feigenbaum has a great article in the May 2009 issue of MSDN magazine that fully explains the benefits of the XML Comments files.

Over the coming months, the new DotNetNuke Reference team will be going through and helping to get the core framework documented with XML Comments. This will allow us to provide more useful Intellisense and complete API reference documentation that also includes code samples for how to use various portions of the API.

The first version of the Symbols package which was released today along with DotNetNuke 5.2.0 Beta 5 requires you to unzip the files over the top of your existing DotNetNuke installation. It doesn’t matter if you are using the Install, Upgrade, Source, or StarterKit package for creating your DotNetNuke installation. The only requirement is that the Symbol files are only valid for the specific version where they were generated. This means that you cannot use the 5.2.0 Beta 5 symbols with any release other than Beta 5.

We are working on updating the Symbols package so that in the final 5.2.0 release you will be able to install and uninstall the Symbols package from the Host/Extensions page. This will make it possible to install Symbols for any installation where you have host access, even if you don’t have full access to the file system for directly uploading files.

In the end, I think this is a good addition to the current set of packages we already provide. For those who care about symbol files and intellisense, you will be able to use them without much difficulty and install them with whatever package you prefer to use. For those people who don’t want them, you will be able to continue using the same packages you always have without any size bloat from files which you don’t want.

Beta Testers Wanted: DotNetNuke 5.2.0 Beta Now Available

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 13 Oct 2009 04:38:16 -1000

One of the benefits of Open Source development is that you have a lot of community members to kick the tires and make sure everything is working correctly before you finalize a release. In the past DotNetNuke has limited our beta releases. Usually it would start with a small internal team and move from there to a selected group of public beta testers. We generally did not hold wide open public betas. This year we are changing all of that. We have added many resources to the team that allows us to better manage the beta testing process. We are also busy adding new tools to make this process much more automated. As a result, we are better able to handle wider releases and more frequent releases.

I am happy to announce that DotNetNuke 5.2.0 Beta is now available for download. You can find out more information on the Beta Testing page on DotNetNuke.com. This is just one of many changes you will see in the coming months to open up the release process. We believe these changes give people greater visibility into the state of the project, and foster greater community involvement and are excited to be making these positive steps forward. We will be announcing even more changes at OpenForce Connections.

Please note: Do not apply beta test software to production websites. Always ensure you backup files and data before attempting any upgrade. You will not be able to upgrade automatically from one beta build to another, or from beta builds to the final release. Beta testing software is for testing purposes only.

DotNetNuke 5.1.4 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Thu, 01 Oct 2009 15:06:05 -1000

After we released DotNetNuke 5.1.3 last night, a community member discovered a packaging error in the release. Specifically the DotNetNuke WebControls 02.02.00 package was not properly integrated. This package was added in 5.1.2 and included some additional defensive coding to help harden the DotNetNuke Web Controls against potential security issues. The latest web controls package does not fix any specific security vulnerabilities, but rather improves the baseline security posture of the platform and makes it more difficult for a hacker to find and exploit vulnerabilities. As a result of the mispackaging we felt it was prudent to release a new version to address this issue and ensure that the community and our Professional customers had a version which included these enhancements.

Upgrading to 5.1.4 is not necessary, but it is recommended. The changes included in 5.1.4 help keep you safe from future attacks and as such is the recommended version for all of our users. if you are running 5.1.2 or 5.1.3 you can gain these same benefits by downloading and installing the latest version of the DotNetNuke Webcontrols project (02.02.00) from CodePlex (http://dnnwebcontrols.codeplex.com/).

This incident highlights one of the great benefits of Open Source software in general, and the DotNetNuke community specifically. Because the community has access to the product source code they are able to perform a more thorough review of each release. Many of our community members take pride in the fact that they have a direct hand in helping to improve DotNetNuke. I want to personally thank Jan Olsmar for quickly identifying the problem and bringing it to our attention so that we could correct it in a timely manner. None of the proprietary software companies I have worked in had access to such a passionate and knowledgeable community and as a result I don’t think those proprietary products were as good as they could have been.

This packaging issue also highlights another important topic – Quality. Over the course of our history, DotNetNuke, like many Open Source products, has faced many challenges in ensuring the quality of our releases. Overall, I think we have done a fairly good job, but I know we can do better. We have had some releases, like 5.1.3 where our processes broke down and mistakes were made. We are currently undergoing some changes to the DotNetNuke core team and the DotNetNuke Corporation team to help meet these challenges and further improve the quality of our releases. I will be speaking more on this topic at DotNetNuke OpenForce Connections where we’ll be making some exciting new announcements in this regard. Until then know that we are working hard to address our challenges and that we greatly appreciate the continued support and assistance of the entire DotNetNuke community in ensuring that we put out the best product possible.

DotNetNuke 5.1.3 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Wed, 30 Sep 2009 19:25:16 -1000

With the month of September coming to a close it is time once again for another DotNetNuke Stabilization release.

DotNetNuke 5.1.3 resolves almost 40 issues with the previous release and further stabilizes the 5.x codebase. Given the stability of the recent 5.x releases it should not come as any surprise that the fixes in this release tend to be narrow edge cases or resolved problems where well known workarounds were available. We also added a minor modification that improves the ability of administrators to email event logs to their support providers. This will allow system integrators, hosters and consultants providing DotNetNuke customer support to get a better snapshot of errors that the user is experiencing without relying on the user to accurately cut and paste error messages. The changes outlined below were incorporated in these releases. As usual, the complete details for all of the changes can be found in the ChangeLog.

Major Highlights

Added the ability to specify a subject line when emailing event viewer logs
Modified the event viewer to include event logs as email attachments when emailing the event logs
Added the ability to use dictionary objects for token replacement in system messages
Fixed an issue which caused an error whenever edititng the Site Settings.
Fixed issue which caused an error trying to retrieve a role group by name
Fixed an issue which prevented a skin from being able to be re-installed or uninstalled.
Fixed issue where Html module was displaying unpublished content
Fixed issue where URLs for pages within the site were always being created as relative which is a change from previous versions.
Removed solution explorer page from the Admin menu and removed the Marketplace feed from the OPML file.
Fixed issue with upgrading DotNetNuke 4.x skins when upgrading site to DotNetNuke 5.x
Fixed issue which resulted in incorrect URL for SiteMap in a child portal
Fixed issue which caused error when deleting files from the Host file manager.

Security Fixes

None

Updated Modules/Providers

The following modules and providers have been updated in the 5.1.3 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

HTML 05.01.04
Form and Lists 05.00.03
Forum 04.05.03

Providers

AspNetMembershipProvider 05.01.03
DNNMembershipProvider 05.01.03
FileBasedCachingProvider 05.01.03

Technorati Tags: DotNetNuke,Release

DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 22 Sep 2009 09:47:54 -1000

There are many times when doing DotNetNuke development that your module needs to send emails. You often have emails that need to go out to several different addresses i.e. an email to the user, one to the system administrator and maybe one to a fulfillment partner. You frequently have different emails that get sent based on specific configuration settings or that change based on the role of the user.

When developing for DotNetNuke I often create a custom installation devoted to the module under development. In the past I have not always had an easy method for configuring the SMTP server so that I could trap all the emails being sent out from the system. I would try to set all the emails to one of my many email addresses and set my SMTP settings to use one of my production email servers. The problem with my previous approach is that I often missed emails. Unless all the emails are directed to my personal email accounts, I had no way to trap the emails on my dev box to make sure they were correct. My previous method also did not make it easy to follow the entire email workflow.

All of these problems were solved recently when I discovered a simple little application called Papercut after reading a blog from Scott Watermasysk. Papercut provides a nice GUI that allows me to actually view the raw email content, the text content and an HTML view where appropriate. Neptune is not as nice in this The added bonus with Papercut, is that I can also forward emails to whatever email address I wish.

Now whenever I configure a new DotNetNuke test instance, I just set the SMTP server to localhost and startup Papercut. Every email is trapped and ready for me to inspect. When I think everything is working correctly, I can forward the appropriate emails off to my Marketing director for final approval. At no time did I clutter my inbox or worry about customers inadvertently receiving test emails.

While doing some research for this post, I also found another solution called Neptune which also traps emails during development. It works a bit differently and is designed for integration into the development environment with interfaces exposed for automated unit testing. You can trigger an email to be sent and then programmatically inspect the actual email that was sent.

Being able to easily inspect and test emails will greatly improve your email handling code. Tools which simplify this task make it more likely that you will run through more scenarios without worrying about filling your inbox or being worried about sending inadvertent emails to customers. This is a good thing. I will definitely be using both of these tools on all my future DotNetNuke development work.

DotNetNuke 4.9.5 and 5.1.2 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Wed, 02 Sep 2009 10:50:18 -1000

DotNetNuke 4.9.5 and 5.1.2 are now available for download. DotNetNuke 5.1.2 is a stabilization release focused exclusively on fixing outstanding bugs which did not make the cutoff for DotNetNuke 5.1.1 or which were discovered after 5.1.1 was released. DotNetNuke 4.9.5 includes some security fixes and a critical fix which affected module caching. DotNetNuke 4.9.5 represents that last release in the 4.x product line with all future development being focused on the 5.x platform. As usual, if there are critical security issues, then we will certainly evaluate whether it warrants another 4.x release. The DotNetNuke 5.1.2 Professional and Community edition releases continue the stabilization work that was begun with 5.1.1. This release further solidifies an already great product and is the recommended version for production sites. The changes outlined below were incorporated in these releases. As usual, the complete details for all of the changes can be found in the ChangeLog.

DotNetNuke 4.9.5

Major Highlights

Fixed issue which caused the starter kit not to install properly
Fixed issue where cache was not working properly for web crawlers

Security Fixes

HTML/Script Code Injection Vulnerability in ClientAPI
HTML/Script Code Injection Vulnerability when operating with multiple languages

Updated Modules/Providers

The following modules and providers have been updated in the 4.9.5 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

HTML 04.09.05
Events 05.00.02

Assemblies

WebControls 02.02.00
ClientAPI 04.01.02

Providers

none

DotNetNuke 5.1.2

Major Highlights

Fixed issue which caused modules not be properly upgraded to 5.x if they were missing a manifest file
Fixed issue where register link on the login module did not work when portal was configured for private membership
Fixed issue where en-US language was always enabled after an upgrade
Fixed issue where the language pack writer was not creating full language packs.
Re-added the PageStatePersistence setting to the Host Settings page with additional warning messages.
Fixed breaking change in ActionBase where properties were inadvertently removed instead of being marked obsolete.
Fixed issue where User settings were relying on default values, but the email API was not aware of the defaults.
Fixed issue where the HasObjectDependencies property of ScheduleItem was not properly calculated.

Security Fixes

HTML/Script Code Injection Vulnerability in ClientAPI
HTML/Script Code Injection Vulnerability when operating with multiple languages

Updated Modules/Providers

The following modules and providers have been updated in the 5.1.2 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

HTML 05.01.03
Events 05.00.02

Assemblies

WebControls 02.02.00
ClientAPI 04.01.02

Providers

none

Let’s Get This Party Started: (re)Launching the Cleveland DotNetNuke User Group

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 18 Aug 2009 12:27:00 -1000

Overview

A little over 18 months ago we had the first meeting for the DotNetNuke User Group in the Cleveland Ohio area. Unfortunately, that was our only meeting. It was always my intention to help get the Cleveland area DotNetNuke User Group off the ground but as the months dragged on other events just always seemed to take precedence. Since that first meeting I have had the opportunity to speak at several different .Net and DotNetNuke User Groups. The more I saw the success of the Capital DotNetNuke User Group (CDUG), the Los Angeles DotNetNuke User Group, and the Orlando DotNetNuke User Group (ODUG) and even some of the smaller, growing groups like those in St Louis, Connecticut, Dallas, and Arizona, the more I get excited about having a user group in my own backyard. The Europeans also have several large and very active user groups like those in the Netherlands, Germany and France.

This area has a really strong base of DotNetNuke users and even some well known DotNetNuke related companies. Onyaktech, IHostAsp.net, AspDotNetStorefront, Technology Workgroup and Voller Solutions are just a few of the DotNetNuke organizations in the area. Having local companies who are active members of the DotNetNuke ecosystem is certainly a big help in that it gives us a nice foundation upon which to build a local User Group. It also means that we have a wealth of local talent that can help keep the group going so the full weight does not fall on one persons shoulders.

With all of the that said, I would like to announce that we are now ready to really get the Cleveland DotNetNuke User Group off the ground. I invite all those Cleveland area DotNetNuke users and developers to our meeting as we kick this group into gear. You can find all the pertinent details for the meeting below. If you are in the area, but are unable to attend, please leave me a comment so we can make sure you get early notification for our upcoming meetings.

Meeting Information

Date: Wednesday, August 18th, 2009

Time: 6:30 PM

Location:

Energy Focus Inc.
32000 Aurora Rd.
Solon, OH 44139

If you get lost then feel free to contact me at 330-564-6898 for help.

Topic/Speaker:

DotNetNuke and jQuery
The featured topic this month will be a presentation by Joe Brinkman on DotNetNuke and jQuery. Over the last couple of years, jQuery has been growing in popularity. This ultimately resulted in adoption by Microsoft as part of the AJAX strategy for ASP.Net and will be shipped with Visual Studio 2010. Shortly after Microsoft’s announcement, the DotNetNuke team announced that we would be supporting and shipping jQuery as well as part of DotNetNuke. In this session we’ll look at jQuery and show how easy it is to use it in DotNetNuke.

Since this is our first real meeting, we’ll spend the first part of the meeting getting input around group logistics. What is the best meeting time and day, identifying a permanent meeting location, coming up with an official group name and other items like that. I would really like the users to feel that this group really represents them and so we’ll try and cater to what works out best for the whole group.

Food/Drinks:

We are still looking to line up some sponsors for our meetings. For tomorrow’s meeting we’ll have drinks but no pizza or food, so grab a quick bite before you come to the meeting. If you would like to sponsor the meeting or would like additional information about sponsoring the user group, please contact me at joe AT dnncorp.com.

User Group Website:

IHostAsp.Net has agreed to provide hosting for the user group website. Once we have a final name picked out, we’ll start working on getting the groups website setup.

DotNetNuke Tips and Tricks #13: Re-using Content with jQuery

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Thu, 13 Aug 2009 08:00:50 -1000

Over the past 6 years I have watched as DotNetNuke matured into a well-rounded platform that is capable of meeting the needs of a wide variety of individuals and organizations. One of the keys to the platform’s success is that it continues to leverage technology to make it easy to build sites the way you want.

A user recently asked me how they could re-use the content from one page on another page in their site. A couple of years ago I would have suggested that they make a “copy” of the module using the built-in capabilities. This works well when you are trying to duplicate the entire content of the module, however, there are times when you just want a portion of the content. In the past the answer would have been to split up the content on the original page – which might require changing your skin and may not be possible when using 3rd party modules.

The optimal solution would not require me to make any changes to the original page, but would instead allow me just to grab specific content and display it on a new page. Thanks goodness we added jQuery support in 4.9 and 5.0. This problem is really easy to solve with some simple html and a jQuery one-liner.

For a simple scenario, lets assume I want to copy the quicklinks from default template on my site’s homepage (I’m using the standard DotNetNuke install so you can follow along). The quicklinks are a subset of the content from an HTML module on the home page.

Add a test page to your site so that we can see how this works. The test page should come pre-installed with an HTML module. If your copy does not, go ahead and add one now… don’t worry, I’ll wait for you to finish.

Now we edit the content in our HTML module and place a simple div in our content.

<div id="placeholderId" >This content will be replaced.</div>

I use a simple trick that Kevin Schreiner showed me a couple years ago to inject a script into my page without worrying about the HTML module stripping it out. Open the module settings and expand the “Advanced Settings” node to display the module Header and Footer items. We’ll place our JavaScript into the Header which is not altered when it is injected into the page.

The following JavaScript will run after the page has finished loading.

<script type="text/javascript">
jQuery(function($){
    $("#placeholderId")
        .load("http://localhost/dnn511pe/Default.aspx #QuickLinks");
});
</script>

The $("#placeholderId") line gets a reference to the element we defined in our HTML. The .load method, makes an AJAX call to retrieve the home page, and then finds the content that matches the #QuickLinks selector.

All of this works really well, but this is DotNetNuke and we can make this much easier. So lets create a simple module that handles all this drudgery for us. I’m going to call this module ContentGrabber.

The ContentGrabber module has a simple view page that will inject our placeholder and JavaScript. We also add a settings page because it wouldn’t be very interesting if we could only grab the quicklinks from the home page.

My view page has very little markup. One change I did make to our original script and HTML was to add a few code expressions to allow us to specify different pages and jQuery selectors. We also made sure to generate a unique content ID so that we could add multiple modules to the same page.

<%@ Control language="vb" 
    Inherits="DotNetNuke.Modules.ContentGrabber.ViewContent" 
    CodeFile="ViewContent.ascx.vb" 
    AutoEventWireup="false" Explicit="True" %>

<% If Not String.IsNullOrEmpty(PageURL) Then%>

<script type="text/javascript">
    jQuery(function($) {
        $("#contentGrabber_<%=moduleid %>")
            .load("<%=PageURL %> <%=Query %>");
    });
</script>

<% End If%>

<div id="contentGrabber_<%=moduleid %>">
    Update the module settings to replace this content.
</div>

Now the only thing left to do is add some code to the code-behind to retrieve the PageURL and Query values from our module settings. Notice that there are really only two lines of actual code, beyond the boilerplate namespace, class and property declarations.

Imports System

Namespace DotNetNuke.Modules.ContentGrabber

    Partial Class ViewContent
        Inherits Entities.Modules.PortalModuleBase

        Public ReadOnly Property PageURL() As String
            Get
                Return CType(Me.Settings(GRABBER_URL), String)
            End Get
        End Property

        Public ReadOnly Property Query() As String
            Get
                Return CType(Me.Settings(GRABBER_QUERY), String)
            End Get
        End Property

    End Class

End Namespace

So now that our view page is complete, lets create a page to handle editing our settings.

<%@ Control language="vb" 
    Inherits="DotNetNuke.Modules.ContentGrabber.Settings" 
    CodeFile="Settings.ascx.vb" 
    AutoEventWireup="false" 
    Explicit="True" %>
<%@ Register TagPrefix="dnn" 
    TagName="Label" 
    Src="~/controls/LabelControl.ascx" %>

<table width="550" cellspacing="0" cellpadding="4" border="0" width=100%>
    <tr>
        <td class="SubHead" width="150" valign="top">
            <dnn:label id="plPage" controlname="txtPage" runat="server" />
        </td>
        <td>
            <asp:TextBox ID="txtPage" runat="server" Width="300"></asp:TextBox>
        </td>
    </tr> 
    
    <tr id="rowWorkflow" runat="server">
        <td class="SubHead" width="150" valign="top">
            <dnn:label id="plQuery" controlname="txtQuery" runat="server" />
        </td>
        <td>
            <asp:TextBox ID="txtQuery" runat="server" Width="300"></asp:TextBox>
        </td>
    </tr>
</table>

There is not much interesting going on here. Yes, yes. I know. I used a table. It’s ok. The W3C hasn’t completely deprecated that tag yet. If you would prefer to be semantically correct then feel free to use divs and CSS. We’ll wait the extra 10 minutes for you to catch up.

OK. Hopefully I didn’t lose any readers over that whole table thing. Let’s move on the code-behind.

Imports System
Imports System.Web.UI

Namespace DotNetNuke.Modules.ContentGrabber

    Partial Class Settings
        Inherits DotNetNuke.Entities.Modules.ModuleSettingsBase

        Public Overrides Sub LoadSettings()
            Try
                If Not Page.IsPostBack Then
                    txtPage.Text = CType(ModuleSettings(GRABBER_URL), String)
                    txtQuery.Text = CType(ModuleSettings(GRABBER_QUERY), String)
                End If
            Catch exc As Exception    'Module failed to load
                ProcessModuleLoadException(Me, exc)
            End Try
        End Sub

        Public Overrides Sub UpdateSettings()
            Try

                ' update modulesettings
                Dim objModules As New DotNetNuke.Entities.Modules.ModuleController
                objModules.UpdateModuleSetting(ModuleId, GRABBER_URL, txtPage.Text)
                objModules.UpdateModuleSetting(ModuleId, GRABBER_QUERY, txtQuery.Text)

            Catch exc As Exception    'Module failed to load
                ProcessModuleLoadException(Me, exc)
            End Try
        End Sub

    End Class

End Namespace

This code was a little more involved, but still pretty simple. I’ll leave it up to the user to create the associated resource file for our labels. At this point we have a fully working module that packages up our original script in a nice little module with settings to handle the customizable behavior. As you can see in the image below, both approaches provide the same results.

I have left a few exercises for the reader.

Substitute the URL control for the URL setting.
Add an AJAX waiting image while loading the HTML.
Allow the user visually select the page element(s) they want to copy.

Download the working module from CodePlex.

Getting your DotNetNuke Website Up and Running

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 07 Aug 2009 14:03:58 -1000

Over the last 5 years, DotNetNuke has been blessed a large number of books being written about the platform. I was fortunate to be part of the team that co-authored a couple of the first books on the platform, and I continue to try reading every book that comes out on the platform. Some books, like Professional DotNetNuke 5: Open Source Web Application Framework for ASP.NET cover multiple aspects of the DotNetNuke platform and is a great book for Administrators, Developers and Designers, but it necessarily can’t cover every topic in depth. Other books, like DotNetNuke Module Programming, are narrowly targeted at Module developers.

Recently I had the chance to read the new DotNetNuke 5 User’s Guide from Wrox press and came away very impressed with the book. The book is written by Chris Hammond and Patrick Renner from Engage Software, who both have extensive background working with DotNetNuke. Chris is an active community and core team member, is the project lead for the DotNetNuke Wiki project and is the lead developer on the Engage:Publish module. Patrick is a project manager and trainer at Engage Software and has worked on numerous DotNetNuke implementation projects.

This book is very clear in that it is targeted specifically at DotNetNuke Administrators and it does a very good job of staying focused on the topic. You won’t find any information about developing modules or skins in this book, which is as it should be. While the book says that it is for DotNetNuke users of all experience levels, I found that the vast majority of the information is clearly targeted at people who have little or no knowledge of DotNetNuke. If you have been working with DotNetNuke for a few years, then many of the topics discussed in this book will already be familiar to you. There are a few chapters in the back of the book that target more experienced users, however I still found that much of that material is more applicable to someone with just a moderate amount of experience. While this may seem limiting, I actually found that it helped to keep the book more focused and cohesive. Often, when trying to write for multiple experience levels, authors inevitably do a poor job of bringing the new users up to the necessary level to understand the advanced content. This was not the case with the DotNetNuke 5 User’s Guide.

So what about the rest of the book? I found the rest of the book to be extremely well written. It does a good job of getting a new DotNetNuke user up to speed on basic DotNetNuke concepts. After learning the basics, the book gives a good walkthrough of the installation process. It is not an exhaustive look at installing DotNetNuke which could easily lose most readers. Instead, Chris and Patrick focus on the most common scenarios so that the reader can quickly taste success. This is a pattern that is repeated throughout the book. Keep the reader focused and engaged, and don’t get bogged down in all the little nuances and permutations of every single setting.

After bringing the reader up to speed on the basic DotNetNuke concepts and installation procedures, Chris and Patrick spend a bit of time showing how to configure DotNetNuke and associated modules for different usage scenarios; a small personal website, a sports league site, and a small business site. Each of these scenarios identifies common usages for many new DotNetNuke users and the authors do a good job of showing how to use a couple standard DotNetNuke modules to create the particular site. Like the rest of the book, these walkthroughs do a good job of showing the user the most important aspects of setting up a DotNetNuke site. By the end of these chapters, the reader should be readily able to setup simple sites.

The last couple of chapters cover more intermediate to advanced topics like multi-portal configuration, file management, page and site templates, system health and system maintenance. Once again, I think these topics are covered sufficiently so as to be useful but not so much that they become dry and boring.

All in all I think that this book is a great introduction for new users of DotNetNuke. The writing style and the focused approach of the authors makes it easy for new users to follow along without getting lost, which is fairly rare for many technical books. I really enjoyed reading this book and highly recommend it for users with little to moderate experience, though if you are an experienced user you will probably be more comfortable with the Professional DotNetNuke 5 book.

Unboxing my new Android phone

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 31 Jul 2009 05:01:55 -1000

It has been almost 3 years since I got my last cell phone, a Blackberry 8800. While it was nice, the UI was very sparse, and dare I say ugly. Ever since the Palm Pre was announced earlier this year, I have been itching to get one. Unfortunately, they are not available on my current provider. My wife, her parents, and I all share a family plan on the T-Mobile network which allows us to keep our cell phone charges way down so if I was going to get a new phone, it would have to be one that T-Mobile offered. When my wife's phone suddenly died 3 weeks ago, we started looking at new phones and finally settled on the new MyTouch phones from T-Mobile. My wife does not use 90% of the features on her phone because she finds it a bit challenging to figure out. To help solve this problem, we both decided to get the same phone, so that I would be able to help her out if she had any questions or issues.

Because we were already T-Mobile customers, we were able to pre-order the new MyTouch, but it would require waiting a few weeks for delivery. So, over the last 3 weeks, I have been researching the Android platform and the various applications available so that I would be ready to go when the phones arrived. I have become more and more excited about the new phones as I saw what they could do, and aesthetically they were a huge leap forward over my blackberry. Even better, I found an application from AppCelerator which allows me to use my web development skills to quickly create applications for the new phones. Some friends and I even came up with some cool ideas for an application which would tie into DotNetNuke (the application that my company produces).

The day is finally here. Last night 2 cell phones were delivered to the house and I have to say, so far I am very impressed. T-Mobile really did a great job on this phone in terms of really making your initial experience very positive. Below are a few photos I took as I unboxed the new phone.

View Full Album

I really love the case that the phone comes in. Perfect for traveling and keeping all my accessories available in one spot. Usually I just pack everything in my bags where the charger and everything else tends to get tangled up. Now I can keep them in one nice little package and I even have room for a few additional items as well,

So far I have installed a dozen or so apps (all of them free, but of very high quality) and I am really loving the experience. Finding applications in the marketplace from the phone could be a little better, but the installation process once you locate an app is pretty seamless.

One of the standouts for me has been an app called Locale. Have you ever been in a movie or even worse, Church, and had your phone accidentally go off? What if your phone knew where you were at and configured itself appropriately. When you walked into the theater, the phone could go into silent mode, unless someone important was calling – in which case the phone would vibrate. Even when I remember to mute my phone in the theater, I often forget to unmute it when I come out. I have missed more calls as a result. Locale solves this problem and much more. Locale marries maps, GPS, and custom rules which you define, to determine how to configure your phone based on your location or other predefined events which you configure. Locale even provides plug-ins so that beyond just changing phone configuration you can have your phone automatically take actions – like post to twitter when you arrive at your hotel on your next business trip. This is just the tip of the iceberg with this app.

All in all, I have to say this is one of the best phones I’ve purchased to this point. That is not to say that it is perfect, just that it seems to suit my purposes for now. I’m sure that in 2 years I’ll be looking for another shiny new toy and who knows maybe it will be another Android phone. If they keep up with the same pace of development as they have in the past year, then I can’t wait till it’s time for the next upgrade.

DotNetNuke 5.1.1 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 28 Jul 2009 09:53:00 -1000

DotNetNuke 5.1.1 is now available for download. This version of DotNetNuke is a stabilization release and focused exclusively on fixing outstanding bugs which did not make the cutoff for DotNetNuke 5.1 or which were discovered after 5.1 was released. As many people in the community are aware, DotNetNuke.com had some difficulty running DotNetNuke 5.1 under extremely heavy loads. As a result of that experience the DotNetNuke engineering team was able to isolate several performance issues which did not show up in any of the prior testing. Fixes for those issues were incorporated in this release along with the changes outlined below. As usual, the complete details for all of the changes can be found in the ChangeLog.

Major Highlights

Fixed issue which mis-assigned page permissions to new modules
Fixed issue where a fallback language is not defined
Fixed issue where portal administrator could not manage user roles
Added core sqlconnection pool segmentation to protect core from any module issues
Fixed issue where Authenticated Caching setting was not getting saved correctly
Fixed issue where code sub-directories are not properly removed in web.config
Fixed issue with UpgradeIndicator which could throw an error under some conditions
Fixed issue where data could become corrupted under extremely heavy load
Fixed issue where GetPortalRoles stored procedure was missing new audit fields
Fixed issue where some DataReaders were not guaranteed to be closed if an error occured
Fixed issue where GetFolders API method was changed resulting in a breaking change
Improved performance by removing use of regular expressions in Globals.CreateValidId
Fixed issue where all installed languages are enabled on all portals after an upgrade
Fixed sitemap priority to use invariant format
Fixed issue where 05.00.00 SQL Upgrade script is incompatible with SQL Server 2000
Fixed issue where HTML/TEXT module was not correctly handling Encoded data
Fixed issue where hierarchical lists are not properly deleted
Fixed performance issue where delayed loading of some PortalSettings results in race condition
Fixed issue where banners were not properly rotated
Fixed issue where "Create Language Pack" creates an empty package
Fixed upgrade issue when Active Directory provider is installed
Fixed issue which changed the Edit Module permission in 5.1 and restored the 4.9.4 behavior.
Fixed issue where the resource verifier misses files to report
Fixed issue with control panel after installing the Turkish Language Pack
Fixed issue where deprecated properties of the Membership provider resulted in errors in the Token Replace API
Fixed PageLoadException errors caused by specific UserAgents being mis-identified by the browser definition files
Fixed issue where "Premium Modules" settings don't work for upgraded sites
Removed Classic ControlPanel from the distribution
Improved locking mechanism of GetCachedData

Security Fixes

none

Updated Modules/Providers

The following modules and providers have been updated in the 5.1.1 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

HTML 05.01.01

Providers

FilebasedCachingProvider 05.01.01
DatabaseLoggingProvider 05.01.01
AspNetMembershipProvider 05.01.01
DNNMembershipProvider 05.01.01
SearchProvider 05.01.01

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

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Mon, 13 Jul 2009 07:35:12 -1000

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 type="Package" version="5.0">
    <packages>
        <package name="DNN_DemoAuthentication" type="Auth_System" version="01.00.00">
            <friendlyname>DotNetNuke Demo Authentication Project</friendlyname>
            <description>The DotNetNuke Demo Authentication Project is an Authentication provider for DotNetNuke that shows how easy it is to create your own custom auth provider.</description>
            <owner>
                <name>DotNetNuke Corporation</name>
                <organization>DotNetNuke Corporation</organization>
                <url>www.dotnetnuke.com</url>
                <email>support@dotnetnuke.com</email>
            </owner>
            <license src="license.txt" />
            <releaseNotes src="ReleaseNotes.txt" />
            <dependencies>
                <dependency type="CoreVersion">05.00.00</dependency>
            </dependencies>
            <components>
                <component type="AuthenticationSystem">
                    <authenticationService>
                        <type>Demo</type>
                        <settingsControlSrc>DesktopModules/AuthenticationServices/Demo/Settings.ascx</settingsControlSrc>
                        <loginControlSrc>DesktopModules/AuthenticationServices/Demo/Login.ascx</loginControlSrc>
                        <logoffControlSrc/>
                    </authenticationService>
                </component>
                <component type="File">
                    <files>
                        <basePath>DesktopModules/AuthenticationServices/Demo</basePath>
                        <file>
                            <path>App_LocalResources</path>
                            <name>Login.ascx.resx</name>
                        </file>
                        <file>
                            <path>App_LocalResources</path>
                            <name>Settings.ascx.resx</name>
                        </file>
                        <file>
                            <name>Login.ascx</name>
                        </file>
                        <file>
                            <name>Settings.ascx</name>
                        </file>
                        <file>
                            <name>Login.ascx.vb</name>
                        </file>
                        <file>
                            <name>Settings.ascx.vb</name>
                        </file>
                        <file>
                            <name>license.txt</name>
                        </file>
                        <file>
                            <name>ReleaseNotes.txt</name>
                        </file>
                        <file>
                            <name>DemoAuth.css</name>
                        </file>
                    </files>
                </component>
            </components>
        </package>
    </packages>
</dotnetnuke>

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" %>

<dl id="DemoLogin">
    <dt><asp:label id="plUsername" controlname="txtUsername" runat="server" resourcekey="Username" /></dt>
    <dd><asp:textbox id="txtUsername" columns="9" width="150" cssclass="NormalTextBox" runat="server" /></dd>
    <dt><asp:label id="plPassword" controlname="txtPassword" runat="server" resourcekey="Password" /></dt>
    <dd><asp:textbox id="txtPassword" columns="9" width="150" textmode="Password" cssclass="NormalTextBox" runat="server" /></dd>
    <dt id="verifyLabel" runat=server visible="false" ><dnn:label id="plVerification" controlname="txtVerification" runat="server"/></dt>
    <dd id="verifyControl" runat=server  visible="false"><asp:textbox id="txtVerification" columns="9" width="150" cssclass="NormalTextBox" runat="server" /></dd>
</dl>
<asp:button id="cmdLogin" resourcekey="cmdLogin" cssclass="StandardButton" text="Login" runat="server" />

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

DotNetNuke 5.1.0 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 23 Jun 2009 10:30:17 -1000

After more than 18 months of development, months of testing, and many, many long nights troubleshooting performance issues I am proud to announce the release of DotNetNuke 5.1.0. This release represents the future of the DotNetNuke platform and is now officially recommended for production use. While many users have been successfully running DotNetNuke 5.0 and 5.0.1 in production for many months, we feel that this 5.x release is finally mature enough that we recommend it for use in production environments. This release includes hundreds of bug fixes and dozens of enhancements and new features. Below is a list of just a few of the highlights from the 5.1.0 release. As always, you can find a complete list of changes on the

Major Highlights

Added Content Versioning and simple workflow to the HTML module.
Added Admin Console module to simplify access to administrator and host pages
Added publicly accessible skin engine lifecycle events
Added audit trails to core system tables
Added built in support for Google Analytics
Added custom sitemap priorities
Enhanced the permission system to use the provider model, allowing for custom permission providers
Enhanced caching to enable access by distributed caching systems
Enhanced installation and upgrade logic to automatically detect .Net 3.5 and to upgrade the web.config as appropriate.
Enhanced the extensions pages to show which modules are used and to show the pages where they are currently in use
Enhanced the Scheduler to show a checklist of available servers in the webfarm where scheduled tasks can be executed.
Enhanced the Scheduler to support multiple instances running on the same server
Fixed issue with removing Superuser role from a user.
Fixed issue with deleting users which was not fully recognized by the rest of the application.
Fixed issue with upgrades which would fail if .Net 3.5 was installed
Fixed issue with skins installed using the batch installer.
Fixed change to GetModulesByDefinition API method which resulted in breaking change from DotNetNuke 4.x
Fixed CloakText API method which was broken in 5.0.1
Fixed issue with stored procedure for Dashboard which would fail with an error if database account did not have permissions to the MSDB database.
Fixed issue where pages added while on a host page will not be associated with a portal.
Fixed issue where the ReturnURL for the SendPassword and Register links on the Login page were broken.

Security Fixes

none

Updated Modules/Providers

The following modules and providers have been updated in the 5.1.0 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

Forms and List 05.00.02
Announcements 04.00.03
Reports 05.01.00
Events 05.00.01

Providers

FckHtmlEditorProvider 02.00.04
AD Provider 05.00.02

DotNetNuke Tips and Tricks #11: Using jQuery in DotNetNuke

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 26 May 2009 05:26:10 -1000

During the last several months I have been doing more and more jQuery development and have found a few key tricks that have improved my code and made my development experience much more enjoyable.

1. Inject the jQuery library reference in the head section.

jQuery does not know about the DNNMenu and the ClientAPI. It will step all over them if given half a chance. Of course, DNNMenu and the ClientAPI are aware of possible conflicts with popular JavaScript libraries and will take steps to avoid any conflicts IF the jQuery library is already loaded. The ClientAPI is loaded at the top of the ASP.Net page form so loading jQuery in the header ensures it is loaded before the ClientAPI.

If you are building a module that injects a jQuery library reference, add it in the page header and you will be safe. If you just want to include a jQuery script on a page then you can edit the Page Settings/Advanced Settings to add the script reference to the Page Header Tags.

2. DotNetNuke 4.9.1 and above already include jQuery.

If you are using DNN 4.9.1 and above, then jQuery is already included in the distribution. The DNN 4.9.x versions will require you to add your own jQuery reference to the page, but DNN 5.x will add the reference to the page if the framework decides it is needed.

In 4.9.1+ you can either inject the jQuery using code or by using the Page Settings shown above. By default, DNN 4.9.x will use jQuery 1.2.6. If you require a newer version, then you should store your copy of the script in your module directory or in a portal directory. This will avoid some potential conflicts with other modules which may require a specific version of jQuery.

DNN 5.x will add jQuery to any page if the service is requested (see my previous jQuery post for the needed code). The DNN Widget framework, which is enabled by default, automatically registers every page. So as long as the widget framework is enabled, then you are covered. If not, have your module register the request or use the Page Settings shown above.

3. Don’t use the $ alias

One of the first things that a new jQuery user learns is the $ alias. Using $(selector) to get some page elements is a truly powerful concept. It is such a powerful concept that the $ alias is used by most of the major JavaScript frameworks. Since most of my work is in DotNetNuke, I find that it is just easier to avoid using the $ alias in my scripts. 5 extra characters seems a small price to pay for peace of mind. By staying away from the use of $ I have avoided a lot of problems.

For some people however the $ is an important feature of jQuery. Maybe they have existing scripts that they want to use and replacing all of the $ references would be too painful.

4. Wrap your jQuery in a closure to properly map the $ alias if you must use it.

For example the following jQuery code does not work in DotNetNuke:

$(function() {
    $('#box span').hide();
    $('#box').click(function() {
        $('#box span').hide();
        $('#box').css({'background-color': '#ccc'})
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { $('#box').css({'background-color': '#988'}); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                $('#box span').show(1000, function() {
                    $('#box').css('background-color', '#333').css('color', '#fff');
                });
            });
    });
});

Getting this function to work is easy – wrap the code in a simple function and pass the jQuery object as a parameter.

(function($) {
    //Your jQuery code here
})(jQuery);

5. Variables are overrated

One of the greatest strengths of jQuery is that it allows you to chain method calls. Most methods in jQuery return a jQuery object. Using chaining allows you to minimize the creation of temporary variables which in turn makes your code easier to read.

There are still places where variables are useful. If you are creating multiple jQuery objects using the same selector or where you might be able to use a common ancestor element to get at the necessary elements, then you can gain a performance advantage by creating a temporary jQuery object and chaining subsequent method calls off that element.

Using a cached version of the jQuery object in the above script would result in:

$(function() {
    var box = $("#box");
    box.click(function() {
        box.find('span').hide();
        box.css({ 'background-color': '#ccc' })
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { box.css({ 'background-color': '#988' }); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                box.find('span').show(1000, function() {
                    box.css('background-color', '#333').css('color', '#fff');
                });
            });
    }).find('span').hide();
});

This script uses a single variable but avoids four calls to the jQuery constructor to create the same object, and chaining the find operation off this common element shouldn’t result in any performance degradation.

5. The End() function is your friend

The last example forced me to change the ordering from my original script and hide the span after creating the click event handler. Sometimes ordering is important so it is useful to know how to use a common jQuery element, modify descendents and then go back and modify the parent last. This is where the end function comes in. Essentially this function reverts the jQuery matched set to the list of elements prior to your previous destructive change. Using this technique, I can keep the same ordering in my code as the first example, and still make use of a common variable (yes I do know that I could create a second variable to cache the span object but then I wouldn’t be able to show you this example ;) ).

$(function() {
    var box = $("#box");
    box
        .find('span')
        .hide()
    .end()
    .click(function() {
        box
            .find('span')
            .hide()
        .end()
        .css({ 'background-color': '#ccc' })
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { box.css({ 'background-color': '#988' }); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                box.find('span').show(1000, function() {
                    box.css('background-color', '#333').css('color', '#fff');
                });
            });
    });
});

6. Keep things lite

It is important to remember that all this JavaScript is not without a cost. There is a bandwidth cost to download the code to the client and there is an execution cost that the user also must pay. If you bloat up your page with too much JavaScript then it will affect the performance of the page for users running older machine or older web browsers. You should always keep the end user in mind when adding jQuery and JavaScript to the page because it has a double impact on your site performance. Just remember that in addition to your code, DotNetNuke is going to load the ClientAPI, the jQuery framework and the AJAX framework. That is a lot of JavaScript already on the page.

Where this becomes important is in the area of plugins. Often jQuery users will use a jQuery plugin because it has a lot of functionality, but if you are not using all of the functionality and you can reasonably code the needed functionality in a fraction of the code, then you are better rolling your own code and forgoing the use of the plugin. A great example of this is the jQuery UI tabs control. As I showed in my post How to create JQuery Tabs in DotNetNuke, you can build great looking tabs using very little JavaScript (about 23 lines of code plus 10 lines of CSS). Compare this with almost 13k of compressed code for the jQuery UI version of the tab control (plus 110K for the core jQuery UI library). Unless you really need all the functionality of the jQuery UI tabs and the UI library, then you are paying a huge price for very simple functionality.

Technorati Tags: DotNetNuke, jQuery

DotNetNuke 4.9.4 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Thu, 21 May 2009 01:52:03 -1000

DotNetNuke 4.9.4 is a minor stabilization release for the 4.x codebase. This release is targeted at resolving a major defect with the module caching code and also addresses two minor security issues. We do not anticipate any further releases of the 4.x codebase.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights in this release

Fixed a major module caching issue which resulted in empty content for webcrawlers
Improved performance of FormatRemoveSQL method

Security Fixes

Low - Errorpage information leakage
Low - HTML/Script Code Injection Vulnerability

Updated Modules/Providers

The following modules and providers have been updated in the 4.9.4 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

Announcements 04.00.03

Providers

Removed the AD Provider so that it cannot be installed by the Install Wizard. It can still be manually installed.