5 things to look out for when upgrading a Kentico Site

By Ansel Pineiro On November 29, 2016

5 things to look out for when upgrading a Kentico Site
The complexity of upgrading Kentico Websites varies from site to site and version to version. It can be anywhere from being as simple as running the upgrade procedure, to having to rewrite significant amounts of code.

If the site has no custom code, and does not make use of views in the queries, then just running the upgrade procedure may be enough. However, a lot of Kentico sites have custom code and will need additional work. 

Here are some of the main things you’ll need to watch out for.

1. API Changes

API changes make upgrades difficult.  They cause custom code that worked flawlessly in one version to be completely broken in another.

In my experience, upgrading from 7 to 8 has the most stumbling blocks in terms of API changes.  That may change for upgrading to Kentico 10, but as of the time of this writing, the upgrade from 7 to 8 is the most difficult when it comes to API changes in currently supported versions.

One problem I commonly see are the namespaces “CMS.CMSHelper” and “CMS.GlobalHelper”.  These are no longer used starting in Kentico 8, and have been replaced with “CMS.Helpers”.  Sometimes just replacing those namespaces will solve the API issues.


Version 7

image01.png

Version 8+

image00.png


Sometimes the API Call itself has been replaced.  For example, the API Call to get the site name is different in versions 7 and 8.

Version 7
string siteName = CMSContext.CurrentSiteName;

Version 8+
string siteName = SiteContext.CurrentSiteName;

Kentico’s website has a great tool for finding the API Changes.

2. Repeater Path Issues

Sometimes after upgrading from 7 to 8+, you’ll find that repeaters that loaded child elements in 7 are no longer loading the data. That’s annoying, but it’s easy to fix by simply adding “./%” to the Path in the Repeater web part properties.

image02.png

That sets the path to search for the child elements of the current page.  I would like to point out this problem does not occur with every repeater.  I have yet to determine what exactly causes this, but the types of pages the repeater loads seems to be a factor in it.

3. Custom Macros

There is a big difference between how custom macros work in Version 7 and Versions 8+.  It is actually a lot simpler in Versions 8+ to make custom macros, but when upgrading you’ll need to  to remake the Macros work the 8+ way.

Version 7 required you to create the logic for the macros in one class  
 
 public static object SampleCustomMacro(params object[] parameters)

{

    return “Sample Custom Macro Output”;


} 

And in the same class, wrap those in a registration method.
 
 public static void RegisterMethods()

{





    MacroMethod sampleStringCustomMacro = new MacroMethod(“SampleCustomMacro”, SampleCustomMacro)

{

    Comment = “Returns an example string.”,

    Type = typeof(string),

    AllowedTypes = new List<Type>() { typeof(string) }    

};

The class should look something like this
 
 public static class CustomMacroMethods

{
















 
public static void RegisterMethods()

{





MacroMethod sampleStringCustomMacro = new MacroMethod(“SampleCustomMacro”, SampleCustomMacro)

{

    Comment = “Returns an example string.”,

    Type = typeof(string),

    AllowedTypes = new List<Type>() { typeof(string) }    

};

    }





public static object SampleCustomMacro(params object[] parameters)

{

    return “Sample Custom Macro Output”;

}









}












 

That Registration method needs to be called in a class that inherits CMSLoaderAttribute
 
[MacroMethodLoader]

public partial class CMSModuleLoader

{

    Private class MacroMethodLoader : CMSLoaderAttribute

    {

        Public override void Init()

        {

            CustomMacroMethods.RegisterMethods();

        }

        

    

    }









}








 

It’s a lot simpler in Kentico 8.  It can all be done in one class, without the need for a registration method.  Just simply setting the right bindings
 
 [assembly: RegisterExtension(typeof(BZSMacros), typeof(string))]

Public class CustomMacroMethods : MacroMethodContainer

{





    [MacroMethod(typeof(string),  “Returns an example string.”, 0]

public static object SampleCustomMacro(params object[] parameters)

{

    return “Sample Custom Macro Output”;

}









}








 

Helpful resources on macros can be found at Registering custom macro methods for Kentico 7 and Registering custom macro methods for Kentico 8

4. SQL Changes

After upgrading from 7, there are a few annoying things that change SQL wise.  For instance, queries are more picky about missing things like ##COLUMNS##, ##TOPN##, ##WHERE## and ##ORDERBY##, and if you should wrap those in single quotes depending on the nature of the query.  Things like this, which didn’t make a difference in Kentico 7, can break entire pages in versions 8+.

Starting in Kentico 8 is built in SQL Injection protection on macros in webparts.  This can be turned off by adding “|(handlesqlinjection)false” to the macro. While doing that may bring about security risks, it is not really adding any risk that did not exist before the upgrade. This may be a good time to test the protection your site has against SQL Injection.

When upgrading from 8 to 9, you’ll need to be aware of Page and SKU related views, as Kentico 9 no longer uses them.  Anything on the site that relied on those views will be broken.  The quick fix here is to just recreate those views, but there are alternatives to the views that Kentico recommends, which you can find in this article, Database changes in Kentico 9 – How to deal with missing views.  The alternatives are a better option if time permits.

5. Custom versions of built in Kentico classes

It’s not uncommon for a web part or form control to be cloned and modified to suit more specific needs.  When this happens, you don’t want to just do simple API fixes.  API fixes will be impractical as there are likely a lot more that’s been changed.
Instead what you want to do is have the code from the upgraded version be the basis for the cloned class, and manually add back the customizations made.

Final Points

Unless your site has no custom code, and does not make use of database views, chances are you will run into problems upgrading your site. 

Upgrading from 7 to 8 tends to have the most problems when it comes to the API.

Upgrading from 8 to 8.1 and 8.1 to 8.2 tends to be painless for the most part.

Upgrading from 8.2 to 9 tends to have the most problems when it comes to SQL Views.


 

Share This Post:

Twitter Pinterest Facebook Google+
Click here to read more Kentico posts
Start a Project with Us
Photo of the author, Ansel Pineiro

About the author

Ansel is the Hotfixer. Whenever a site needs to be hotfixed or upgraded, he gets it done lightning fast. He always seeks to find the right balance between performance and readability in all the code he writes. Between code writing and hotfixes, he makes the office a more enjoyable place to work by finding new music and desktop wallpapers for everyone to enjoy. Some think he’s crazy, but Bizstream knows him as The Hotfixer!

View other posts by Ansel

Subscribe to Updates

Stay up to date on what BizStream is doing and keep in the loop on the latest with Kentico.