Site upgraded to DNN 5.0.1

Jack Simpson

Head of Marketing and Communications

So it goes

I’ve been doing a lot of research on DNN 5, and although it’s very unstable (we uninstalled it in February after a number of aborted starts), it had a few features that really attracted me.  Plus, I couldn’t escape the feeling that I really didn’t want to do a 4.9.2 –> 5.1.0 upgrade when the site is live in May.  For that reason I thought I’d give the upgrade root another go.

I started by binning the XMod & XMod IDE modules, although we’ve paid for them, they’re just not ready for 5 yet, at least not really until XMod 5.5 is out, and frankly we’re not using them yet.  After that I backed up, can’t beat backing up when doing something stupid.

Applying a DNN upgrade should be as simple as copying the new files over the existing website and hitting the homepage.  But I’ve been learning a lot in the last month or so, so I took an altogether more cautious approach, besides I wanted to treat the update as if I was working with a live site.

Setting the error messages to redirect to holding page.

There’s many ways to bring a site down for maintenance, I plan on using www2 (the current live site) as a test and upgrade site in future, for now though it represents the live site, so instead I created a new, very simple site that defined the same headers on port 80 as the real site, this allowed me to stop the live site, and start the new site.  One of the key differences was the new site had only one page and all the error pages were set to redirect to it.  This has the effect that any page you ask for returns the default page, which, for now, just apologised for the site being down for maintenance.

Before I go really live, I’ll probably add a nice skinned version of this page for people to jump to.

Once the live site was offline, I changed it’s headers so it could only be accessed from localhost.  This allowed me to switch the site back on.  I know many other admins wouldn’t be able to access the server, but I prefer doing upgrades via remote desktop for a number of reasons, not least if I get connectivity issues the install will continue, but also there’s less likely to be timeouts due to uploads.

Anyway, once the site was accessible via localhost I started the upgrade.  The first step was to make a copy of the web.config, after which it was finally safe to dump the update files over the existing website.

I then took the step of comparing the new release.config with the historical web.config using a Diff tool.  This was especially important as there’s a lot of changes made in DNN 5, but our site uses PageBlaster and URL Master, both of which make a number of modifications to the web.config which need porting over.  All in all, checking the web.config carefully only took about 20 minutes, but was well worth the effort.

Once the new web.config was in place I hit the website through the local browser and the upgrade routine ran automatically, doing it’s magic first time.  I was hugely relieved not to see any errors this time, something that’s not always been true!

I clicked on the ‘View your portal now’ link, and up came an error page.  It turns out that URL Master hadn’t ‘reset’ itself or something, but navigating to /home.aspx, did the trick; it was a nervous few minutes first though!

Immediately, the custom skins threw errors so I deleted them and restored the included MinimalExtropy skin.  After that a quick check showed the tweet module to be broken, but I’d expected as much as it uses jQuery, which is now included in DNN 5 by default (one of the main reasons I wanted to upgrade).  The blog module also threw a null reference exception in Edit mode, but a quick forum search revealed it as a known issue (which they haven’t fixed).  Luckily, everyone is blogging through WLW so it’s not really an issue.

The first step was to upgrade the Blog module, but it didn’t fix the bug, so I set about redoing the skins.  The WebAppsSkin is a heavily customized version of the Minimalist skin by Evan O’Neil (which we paid for!), so I downloaded the DNN 5 version of the skin and did a comparison against the DNN 4 version of the skin, it took about an hour to rewrite the skins to incorporate the changes for DNN 5, but the results were worth it, and the errors disappeared.

Next step was to fix the Tweet module.  Firstly, I removed the existing jquery.min.js file, which was included with the module and added the following to the Page Load sub routine:

   1: Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

   2:     DotNetNuke.Framework.jQuery.RequestRegistration()

   3:     ...

   4: End Sub

This is the new DNN 5 command to register a modules interest in jQuery.  It supposedly includes the jQuery on the page whenever it finds any modules that call the method.  Unfortunately, it became apparent that the jQuery object wasn’t being created, and after a quick look, it was because the jQuery javascript was  being loaded after the tweet javascript code on the page.  This wasn’t supposed to happen, apparently, because the above command was supposed to ensure the jQuery code was loaded first.

The first suspect was PageBlaster, which rewrites the page, and moves around script tags. However PageBlaster could be a solution as it allows you to manipulate any page.  After a bit of work I came up with the following regex to ensure that the jQuery script always appeared first on the page:

Match: (<head[^>]*?>.*?<script)(.*?)(<script)([^>]+(jquery[^>]*).js[^>]+></script>)
Replace: $1$4$3$2


Adding the regex as a rule to Snapsis.PageBlaster.config did the trick:

   1: <rule>

   2:     <ruleName>Ensure all jQuery scripts are first scripts on page</ruleName>

   3:     <searchFor><![CDATA[(<head[^>]*?>.*?<script)(.*?)(&lt;script)([^>]+jquery[^>]*.js[^>]+></script>)]]></searchFor>

   4:     <replaceWith><![CDATA[$1$4$3$2]]></replaceWith>

   5:     <repeatTimes>1</repeatTimes>

   6: </rule>

   7: <rule>

   8:     <ruleName>Ensure main jQuery script is first script on page</ruleName>

   9:     <searchFor><![CDATA[(<head[^>]*?>.*?<script)(.*?)(&lt;script)([^>]+jquery(.min)?.js[^>]+></script>)]]></searchFor>

  10:     <replaceWith><![CDATA[$1$4$3$2]]></replaceWith>

  11:     <repeatTimes>1</repeatTimes>

  12: </rule>

And the tweets started working correctly.  The next think I wanted to change was the way the tweet time stamps were being reported, which I did with a quick javascript change.

Finally, with jQuery in place, I had the opportunity to use a drop shadow plugin, one key element for the new site was to not hardcode the page titles into the graphics.  Unfortunately, this really necessitated a good drop shadow effect so the title could sit above the banner graphic.  The DNN 4 solution I used was CSS based, but was ugly and only effective in some browsers, the jQuery plugin was much more robust, better looking, and supported more browsers.

It took a few hours and I’d be happy to explain some of the steps I took at a later date if people are interested, but now I hope you agree the result was worth the effort.

We’ll have to go through quite a bit more testing of the site on DNN 5, but for now it seems really good, and I’m pretty happy with the effort.