Attackmonkey Blog

Over the years (and it's been quite a few years now) I've come to realise that one of the most important skills a developer can have is also probably of the most underrated. The ability to methodically investigate and get to the bottom of a problem.

The ability to really dig into an issue and try and track down what's going on is a really important skill for a developer to have. Often you might be working on something that was written by someone who no longer works at a company so you have no way of knowing why something was done, or in some cases how. The issue might be super obscure, or be very hard to replicate, but if you can doggedly Sherlock the shit out of your problem, you'll eventually get to the bottom of the issue.

All to often I've seen people just have a quick look at the code, stick a question on SO and forget about it, when they could just spend a bit of time digging into the issue to try and work out the solution. If nothing else, it'll help you to understand the bit of code you're working on.

So remember, if you hit a problem, do a bit of investigating!

If you're doing a one to one translated language site, you'll want to be able to switch the language. You could do this by setting a cookie and reloading the page, but that's crap for SEO, and means users can't share links to the pages in the different languages.

Conventional wisdom states that you should include the language in the URL in some fashion. One option is to include it in the querystring (don't laugh, I've seen this done in the wild). DON'T!!! You then have to remember to pass the variable around everywhere, and it's easy to forget, so the selected language randomly gets lost, and the user switches language without meaning to. You can also have different subdomains/domains for each language, but that's a bit faffy to set up and configure, especially if you're continually adding new languages.

Ideally, you want to make the language code part of the URL. I've seen site that add it to END of the URL, like "/my-page/de/", this is also not great. It makes the URLs harder to hack around. Take "/about-us/awards/" for example, if you knock off the awards part, you know you're getting the about us page. If you have the language at the end, if you don't leave the language on the end when you hack off the awards part, you get the about us page in English, not German.

For this reason, you should always include the language at the START of the URL, that way you can hack around to your heart's content, and the language will be kept!

If you're using Umbraco, you can do clever things with UrlProviders and Resolvers to automatically include the language in the URL without much extra work (I'll blog about this at a later date).

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.

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>