Two weeks ago I posted this blog entry in which I showed my solution in moving the DNN partial postback progress bar. It turns out that there is a significant flaw in that solution. Briefly, the solution was to use jQuery to locate the the element that contains the progress bar - $("div[id$='_UP_Prog']") – and then appending that element to a new element that I created as the desired new location for the progress bar.

This works fine on initial page load and for the first time the module performs a partial postback. On any subsequent partial postback, however, the progress bar disappears. It is neither in the old or the new location. Why did that happen?

In retrospect, it’s obvious: the _UP_Prog div lies outside the update panel performing the partial postback, but the new target location for the progress bar lies inside the update panel. When the update panel re-renders, the relocated progress...

When partial postback is enabled for a DotNetNuke module, DNN very helpfully wraps the entire module in an update panel and then places an animated progress bar at the bottom of the panel that becomes visible during partial postbacks. In most cases this is just fine, but on my current project the business owner requested that the progress indicator be moved to a different location because it was frequently not visible below the fold. I looked to see if DNN had any built in functionality to specify the location of the progress bar, and quickly discovered that none existed. No worries, though, a little dollop of jQuery and everything was working exactly as the business owner wanted.

Today I stumbled across a very interesting issue, and I thought I would share it.  I am currently working on a large DotNetNuke module, and as a part of it I am making use of the jQuery UI libraries. I included a link to the stylesheet for the jQuery UI theme I am using, and it seemed to work just fine... until I triggered a partial postback and saw all of my pretty jQuery UI formatting get lost. The first trick I learned, and the one that got me 90% of the way there, is to make use of the PageRequestManager to add a function for handling the formatting after a partial postback completes. The javascript looks like this: jQuery(document).ready(function () { Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler); function EndRequestHandler(sender,args) { SetUI(); } function SetUI() { jQuery("a[id$='NewEventLinkButton']").button({ icons: { primary: "ui-icon-plusthick"...

Over the past few weeks I have upgraded more than a dozen DotNetNuke websites to the current latest version, v5.4.2. For some of those sites it was a trivial upgrade coming from a very recent version, but for many of them it was a long trip from as far back as v4.6.2 released in October of 2007. Happily, most of the updates went flawlessly. Some of them, however, hit a few bumps in the road along the way. After finishing my last update, I thought it would be worthwhile to write about some of the common pitfalls in performing a DNN upgrade, and how to deal with them when they come up.

Rule #1 – Backup, backup, backup The first and most important thing to do before starting any upgrade is to back up both your database and your file system. Backing up the file system should be simple enough for anyone performing the upgrade – if you have access to be able to upload the DNN upgrade files, then you have access to back up the existing files. Do not skip this step, it is not optional. Depending on how your website...

Welcome to my new technical blog. I also updated three websites to DotNetNuke v5.4.1 today - and this site is one of them.