All Posts From : 2015

In part 2 of this series, I talked about upgrading the site to 7.3. At this point we have a nice shiny site, but all of the additional functionality is currently in XSLT. The client this is for prefers their sites in Razor these days, so as an added thing to do, I now have to port the site over to Razor.

In the back office, all of the old templates were still listed, but as I hadn't copied the master pages across from the old site (as we're switching to MVC), they'rer all empty. It was fairly trivial to then just re-save each of those (which created the physical view pages in my project), and then adding a Layout file with the outer page. I copied all the HTML from the old templates, with a few minor changes. I was able to remove a couple of templates, and combine a couple of others!

The old site is nearly 5 years old, so pretty much everything is XSLT/Macros. Razor allows you to move everything into partials and controllers, so looking at the code, it's possible to do away with all of the Macros bar the one that allows you to embed a special corporate video into the Richtext editor.

I went through the site and converted all the old macro based functionality into Razor. Some of it could just be inlined in the templates, as it was template specific, the rest was turned into plain old partials.

A few parts of the code made sense to be surface controllers (the search, and a user profile page, as well as the login stuff). THese were pretty easy to port over.

With the XSLT, al ot of the code could just be ported over and rewritten. Quite a few macros were no longer needed, or could be combined. By the time I was done, I only had a handful of Partials, compare to the 20+ Macros on the old version of the site.

Once I'd tested everything to make sure it still worked compared to the old version of the site, it was time to tidy up. All of the old Macros and XSLT files were deleted from Umbraco.

At this point, we have a fully upgraded site, now running on the latest version of Umbraco! As an added bonus, between starting this and finishing, Umbraco crept up to 7.3.4, but a quick "Update-Package UmbracoCms" in Nuget in VS sorted that out very quickly and efficiently!

The site and database can now be deployed, replacing the old site, and we're good to go!

All in all, the process has been significantly less hassle than I expected, and I'm really imprressed with how straightforward it all was. I'd be much less hesitant to recommend upgrading a fairly straighforward Umbraco site than I might have been previously. I'd love to hear if anyone else has tried this, and whether your experiences were as painless as mine!

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>