Attackmonkey Blog

In part 1 of this series, I talked about preparing for the site upgrade. In this part I'm going to talk about how I did the actual Upgrade.

Before we start, I pulled down the site files and a backup of the Database from the live site. I set both up to run on my local machine, and did some house keeping first. On this particualr site, we were removing a section and some of the DocTypes, so I did that on the old copy first, to make things easier later on. I then took another backup of the database once I was done (in case anything wet wrong and I needed to start again).

Next, I set up a new VS.Net project, and installed Umbraco 7.3 using NuGet, along with some essential stuff, like the core property value converters (also installed from NuGet). Once those were installed, I opened the web.config file for the newly installed copy of Umbraco and set the connection string to point to my old database. I decided against merging in my config values etc at this point, as I wanted there to be as few errors as possible.

With baited breath, I ran the website from VS.Net. I got the Umbraco installer screen, and it flagged that I was running an upgrade rather than a fresh install, hapy days! I clicked the next button, aaaaand got a big fat SQL error. The error message that I got was a bit misleading, as it lists all of the tables etc that aren't in the core install, and I though that was the problem, however, after much digging through the log files, it turned out to be a SQL server permissions issue on the database. I sorted that out and ran the site again. This time, after a couple of minutes, I saw the success screen, and it redirected me to the back office.

I had a click around and everything seemed OK. The two DataTypes that weren't v7 compatible were showing as labels, but everything was working. At this point, I backed everything up again, and then merged in my config files, master templates, scripts, CSS and images etc. If you're updating from a Web Forms site, don't forget to change the default rendering engine to Web Forms from MVC in the umbracoSettings site.

At this point I ran into a couple of issues. the first was that older versions of Umbraco let you have a - in the alias of DocTypes, and the newer versions don't. This particular site had a couple of DocTypes that had - in them, so I had to re-save the DocTypes and restart the App Pool to get rid of the error that was being generated. Next was that the EXSLT extensions were removed in 7, so some of my XSLT broke. Not to worry though, you can get a package for that from the mighty Lee Kelleher. In this particular instance, I don't care about fixing the XSLT, as I'm going to replace all the XSLT with Razor.

The only other issue that I had was that there appears to be a bug in one of the database Migrations that scrambles the order of some of your DocType properties. But that was easily fixed by re-ordering the properties on the affected DocTypes and re-saving them.

Finally, in the Data Types section, I swapped the MNTP pickers from uComponents (which were now labels) ot the new built in one, and as they were set to store CSV, that just worked. The other DataType (Embedded Content) was removed and replaced with Nested Content. This required a bit of set up, and re-entering the data, but it only took about an hour.

At this point, I have a (mostly) functional site, upgraded from 4.7.2 to 7.3. It was much less hassle than I was expecting, and it seems to have worked very well for me. Your mileage may vary, I suspect that for a much more complex site, you'll have a lot more issues, especially if you are using quite a few custom DataTypes.

In part 3, I'm going to cover switching the site over from XSLT and Master Pages to Views, and tidying everything up, ready to go up to the live site again.

In my previous article, I talked about how impressed I was with the Umbraco upgrade process in 7.3. I'm now much further through the full upgrade, so I'm going to blog about it, in the hope that it helps others considering doing the same.

In this part, I'm going to talk about the planning for the upgrade.

I have a client who has an old 4.7.1 site, and they'd like to use some functionality that's only present in v7. Previously I was looking at a full rebuild and re-importing content, but due to the volume of content (10,000+ pages), I wasn't too keen on this, as copying content between installs is notoriously fiddly.

So, when Neils announced that the new version would upgrade the database and it actually worked, I decided to give it a go, as it could potentially save me a LOT of time.

So, the existing site:

• Runs on 4.7.1
• Has 10,000+ pages
• Uses XSLT Macros and MasterPages
• Uses a handful of packages, mostly event based stuff (CustomMenus, AutoFolders etc)
• Uses two custom DataTypes (Embedded Content and uComponents MultiNode tree picker)

First up, what do we want to achieve with the upgrade?

• Upgrade to 7.3
• Swap out all of the XSLT/MasterPages for Views/Razor
• Remove some unused sections of the site

So, what issues are you likely to hit? Firstly, not all of the packages may have been updated for v7. In this case, we were using the MultiNode tree picker from uComponents, which isn't available in v7. This one is pretty straightforward. Make sure the DataType is set to store as CSV (if it isn't already), and republish all the pages with the DataType on. That way we can just swap DataType to the built in v7 Multiple Content Picker after the upgrade, and we won't lose any data.

Embedded content can be replaced with either Archetype, or Nested Content. HOWEVER, the data cannot be just swapped over. When you upgrade Umbraco to v7, any DataTypes that are non-core are turned into labels, and the values preserved, and the DataTypes are set to a non-editable control. You could write some custom code to reformat the data for your new DataType using the API once you've done the upgrade, but in this case, the DataType was only being used to display some widget boxes on the home page, and nowhere else, so re-adding the 8 boxes after we've upgraded is probably quicker than messing aroud trying to reformat the data.

So, now that we've covered the basic issues we're likely to hit, what next? I decided to take the following approach to the upgrade:

• Take a copy of the database
• Remove all the stuff that we don't need on the old version of the CMS
• Backup the database (in case it goes horribly wrong)
• Create a new Visual Studio project and install Umbraco 7.3 and packages through NuGet
• Run the Upgrade
• Merge in the stuff I needed and then start changing view/macros etc
• Test thoroughly
• Deploy
• Retire to somewhere hot and drink cocktails with tiny hats

So, having done a bit of prep work, we're ready to rock. Watch out for part 2, where I'll talk about the initial upgrade process.

A week or so ago Niels from Umbraco tweeted that you could now upgrade the database from an old 4.7.1 install all the way up to 7.3 with the new installer. This was pretty exciting news, as upgrading Umbraco (especially through a lot of versions) is traditionally a very painful experience.

As luck would have it, we had a client who wants to update an old 4.7.1 site to 7.3 to use some of the newer features. Fortuitously, it's also a fairly simple Umbraco install with only handful of plugins, most of which aren't needed in 7.

So, fully expecting things to not go as smoothly as expected, I embarked on my upgrade quest. I decided to do a fresh install of 7.3 via Nuget into a VS project, and then merge in the relevant config bits into the site. I'd check the database had upgraded OK, then add back in the bits that I needed. Next I pointed the installer at the old 4.7.1 database (use the customize option during the setup wizard). Finally I copied in my masterpages, CSS, JS and images.

I ran the wizard and immediately hit an error that I thought was down to some of the additional tables in the database, but which turned out to be down to an issue with schema ownership in the database. Once I'd fixed that, I ran the installer again, and crossed my fingers. About a minute later, and BAM!!! I was staring at the 7.3 back office with all of the content from the old site in it!

I went through the site, and everything seemed to be working fine, happy days! I then swapped the uComponents tree pickers for the built in multinode pickers (as I was storing them as CSV already), and viola, it all worked! I had to go through and re-add some of the associated packages, but other than that, I was golden. I ran into a couple of minor gotchas on the XSLT front, mostly caused by the site using EXSLT extensions that were removed from the site in v7. Those were pretty straighforward to fix though.

All in all, I'm very impressed with the way it went, it really was remarkably straightforward, and it makes upgrading much older sites a much more appealing prospect. If you have a more complex site with tons of custom DataTypes etc, you'll need to port those to Angular and migrate the data, but for most simple sites, it should be relatively painless to upgrade from the look of it.

Kudos to the HQ guys for the hard work they've put into this, it looks like the effort paid off!

Once I've fully completed the upgrade, I'll document it here on my blog, to help anyone else who's considering upgrading older sites.

If you have an Umbraco site that's load balanced, you may have a dedicated admin sub-domain to force your users to use the primary server (e.g. admin.yourdomain.com). That being the case, you may also want to lock that domain down so not just anyone can access it.

You COULD do that with IP restrictions in IIS, but that doesn't allow for the client wanting to work on a train, or in a coffee shop, or for you needing to jump onto the site away from the office in case of emergency.

I came up with a simple solution that uses IIS Rewrite. You can use IIS Rewrite to check the value of cookies, so on the admin site, we allow access only to the /umbraco/ URL so that you can log in. Any other URL will result in you being redirected to the primary domain. The rule checks for the presence of the UMB_UCONTEXT cookie that's set by the back office, and if it's set, it allows you to access the rest of the admin site. Simples!

Here's an example of the rule:

<rule name="AdminLockout" stopProcessing="true">
                   <match url="(.*)" />
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
                        <add input="{URL}" pattern="(favicon\.ico|umbraco|webresource|scriptresource)" negate="true"/>
                        <add input="{HTTP_COOKIE}" pattern="UMB_UCONTEXT=(\b[A-F0-9]{8}(?:-[A-F0-9]{4}){3}-[A-F0-9]{12}\b)" negate="true" />
                        <add input="{HTTP_HOST}" pattern="^admin\.mysite\.co\.uk" />
                    </conditions>
                   <action type="Redirect" url="http://www.mysite.co.uk/{R:1}" appendQueryString="true" />
             </rule>

We all know some CMS's are more user firendly than others, but sometimes, even the nicest CMS can be scuppered by an abysmal implementation. Usually this is either the developer not being familiar with the CMS, being on drugs of some kind, or possibly just being a bit rubbish :P

I got to thinking on this recently after being involved in some pitches where the client has stated up front that they hated Umbraco. That's quite unusual for us, most of our clients really love the CMS, so we asked what it was they hated, and got shown the CMS systems they were currently using built on Umbraco. What an eye opener! I think I'd hate my CMS if every single page was just one tab, with a single TextArea that says "Paste HTML here" next to it (and yes, I've seen an actual implementation like this).

We showed the clients some Umbraco implementations that were actual sane, and they changed their mind about Umbraco (yay!) once they saw what you could do with a decently thought out site. This isn't just something I've seen with Umbraco though, I've seen some terrfifying examples with other CMS systems and home grown CMSs as well. Without naming any names, here are some examples I've seen over the years:

• the aforementioned every single page is a text box that you paste HTML into site
• a site where the developers put a custom caching framework on top of the CMSs quite fast caching framework, slowing it down to the point that it had to be load balanced just to get even crappy performance out of it
• a 10 page mobile site that had an insane amount of IOC, business logic and interfaces, probbaly the second most over engineered site I've ever seen
• sites where all the properties are on one page, sometimes 50+ of them, with little information about what they're for, other than not particularly descriptive labels.......
• Dropdowns to select things with mystery meat names (how are you supposed to know what Offer 1, Offer 2 and Offer 3 actually are?)

It just goes to show how important it is to think about the editor experience when you build your sites with a CMS. The site could look quite pretty, but if the editor experience is shit, the users will hate using the CMS, and they won't get the most out of it!

So, what are some of your worst CMS horror stories that you've come across?

:)