In this tutorial, you will learn about some of the code tweaks that you will need to make when upgrading a site from Umbraco V7 and below to Umbraco V8. The focus of this tutorial is code. In the first part of this series of posts, I covered the process I went through when upgrading my personal website. Sharing the pains I felt upgrading my database (pains mainly experience from me not reading the prerequisites). In this article, you will learn about the coding errors I encountered and how you can fix them. If you encounter them on your own upgrade. If you are considering upgrading to Umbraco 8, then read on.
Consider Which Plug-ins You Need To Consider
First up, a lot of the community packages that I was using simply had to go. The site I upgraded (this one) was originally built in Umbraco 6, then upgraded to 7. I wanted to use a code-first approach so I used uSiteBuilder At the time, using uSiteBuilder allowed me to use strongly-typed models throughout out my project. uSiteBuilder is not supported in v8. Umbraco also now supports ModelBuilder out-of-the-box, which meant uSiteBuilder had to go. As uSiteBuilder was deeply caked into my codebase, removing it resulted in a lot of refactorings. All the view models, views and controllers had lots of things that needed updating.
Another community package that I like to use is Slimsy. When V8 came out, Slimsy did not work in V8. This meant that when I upgraded site Slimzy had to go and my page speed was slower than it was on v7. Slimsy now works great in V8!!
When planning your own V8 upgrade, it is recommended to check all the Umbraco packages the site uses first. If you heavily rely on one, check, then double-check if it's supported in v8. In my case, the switch from uSiteBuilder to ModelBuilder added on an extra two weeks of extra refactorings and fixes. These upgrading pains are one of the reasons why I recommend that developers should try to avoid using third-party community packages wherever possible.
How To Get Your Code Working Again
When you upgrade if you find yourself with 6000+ failing errors, then I suggest you adopt this approach. Unload all the failing class libraries and uncomment all the failing code. Do not try to fix everything in one large big bang. Instead, add things back slowly, one controller at a time. First, create a new blank class library, and move the homepage controller and view-model out of the old location and into the new one. Compile the site. Fix all the errors and bring in any dependencies the code relies upon. When the project compiles again, load the homepage. If the page throws any errors, fix those.
After you get the homepage running, pick another page and repeat the process. Continue repeating this approach on every other document type within your solution, until the whole site is working. This approach may take a while but at least you can see small steady progress.
Code Change In V8
As Umbraco v8 is such a big rewrite a lot of your code will need to be refactored and upgraded. In this section, I'll cover some of the main areas that affected my upgrade experience:
Controllers: In version 7 and below, a controller looks like this:
In V8 RenderModel
needs to change to ContentModel
:
UmbracoContext.Current: The way you talk to Umbraco in code changed in v8. V8 now finally supports dependency injection. After upgrading, you will need to change any code that looks like this, UmbracoContext.Current
. In my project, I had lots of code within my controllers that did this, so this took a big refactoring effort to update.
In V8, if you need to get data about a page you can use the IUmbracoContextFactory
. You can inject IUmbracoContextFactory
into your controller - or any other class - via constructor injection, like so:
Using IUmbracoContextFactory
you can get access to UmbracoContext
. From UmbracoContext
you can get page data like this:
If you have code that accesses IPublishedContent
, it is handy to note that its namespace moved from Umbraco.Web;
to Umbraco.Core.Models.PublishedContent
. This change is another refactoring that you will likely need to apply throughout your codebase.
Those five changes (package no longer working, dependency injection, namespace moves, code retired) definitely caused the most pain during my upgrade journey. My main tips when upgrading is to read the pre-requisite, disable all erroring code and then enable things one controller at a time. Happy coding!