Kentico Tips for Developers

02/03/2017 by Santiago A Fernandez

A little over a year ago, my team and I started working on a project to move a site to the Kentico CMS system. Not knowing the platform posed an interesting challenge, and the whole team was tasked with learning as much as possible in a very short time frame.

As we worked on the project, we experienced some issues, resolved them, and learned a tremendous amount in the process. Learning is, of course, part of the fun! From this whole experience, I can pick out a few take-aways that might make life easier for those who are also starting to get familiar with Kentico. If you are not moderately familiar with Kentico, some of my points below might not connect. But, since I’m a geek, being technical is inevitable.

Use user controls. We used Kentico9. Kentico9 is made with, and works best with, .Net Webforms. To elaborate, sites using Microsoft .Net technologies often use either WebForms or Model View Controller, and Kentico widgets and web parts work need to be made as WebForms. Generally speaking,  anything that faces the user is best made in WebForms. While it is possible to get a site running partially in MVC and partially in Webforms, the MVC part will not be customizable in the CMS and will lack the content editing features inside of Kentico. If you’re thinking about a website that will be powered by Kentico, make sure you design your website knowing which parts users should be able to edit and which ones will be only code-based and inaccessible.

Rich text can be tricky. The rich text user control that ships with Kentico offers strong WYSIWYG functionality. If the rest of your layout is properly styled and you only need basic text input by users not familiar with HTML, it can save time to get content changed by anyone you’d like. That said, it is possible that if you use certain styling elements, or intend on hitting the view source button and pasting some HTML with styles, there may be some issues, specifically, if you use elements that rely on empty tags like Glyphicons or FontAwesome icons.

Say you want to put a small rocket icon, and find a snippet like  <i class="fa fa-rocket" aria-hidden="true"></i>. You go to the rich text editor, hit View Source, paste that snippet, and save. Then you might need to edit it, so you’ll load it up in the page editor and go to edit that specific part. Upon loading that component again in the WYSIWYG editor, the empty tags will be discarded because they don’t have content and you’ll no longer have the anything related in that empty tag. As a result, your website might look a little strange.

To step around this issue, you need to either use a static text control and have everything in HTML or structure content in such a way that such styles are not mixed with rich text editable content. This method requires a bit of planning and may require learning some skills, but it will result in a more consistent experience.

Two ways to show content on a page/template. Especially in the world of technology, there are many ways to execute a single task. In the world of Kentico, there are at least two ways to show content specific to a page within a given template.

First, a bit of context: In Kentico, besides the master template needed for a page (which is a good idea for placing the general style, header/menu and page footer), you might find it useful to create other more specific templates for a group of pages. For example, the template could show a large image and three columns under it, and another one could have two columns spanning the entire height of the page without the image.

You can choose to establish some content at the template level if said element is consistent across several of these pages, and with a rule at the WebPart’s visible checkbox. Click on the More icon and enter a rule similar to {%  if (NodeAliasPath.Contains("Welcome")) { return true; } else { return false; } #%}.

A macro like this will show up on a page whose URL contains the word Welcome, and it will be hidden everywhere else.

If content will vary across all pages, in the page editor, go to the Design tab, click the corresponding WebPart zone, and make sure the Customization by page editor option is enabled.

Image of workflow for kentico blog

Keep in mind that not all Widgets you place in a page may allow editing in the design view, so make sure the intended widget has the following options checked in the Widget’s page security tab:

screenshot image of widget from a kentico blog

Following this process will allow you to establish content in the Page tab of the page editor as opposed to the design tab.

If the content looks wrong in the page preview mode, you might have some bad styles. If you’re in the page edit view, you have a widget that you dragged and dropped and need to rearrange, but you can’t select it, you’ve done something wrong.

<iframe src="//" width="480" height="260" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="">via GIPHY</a></p>

Creative interpretations of rules (i.e., a hack) or a simple styling/markup error may cause the elements in the page edit mode to not appear, or to not be selectable. You won’t be able to drag and drop selected elements into their intended positions. If this happens, check your markup, and make sure everything on the markup and CSS side is in order.

Want to see a mobile layout and edit items? Size the preview screen to mobile. Most websites made in the past years have a responsive functionality that will make the page rearrange its content to best fit the device you’re using to view the page. If you made your page responsive from the template level and already hid/showed/rearranged elements at that level, you may find that editing the page in a big monitor will hide tablet/mobile-only elements. The solution is simple—just resize the page editor window to have a lesser width, more in line with a tablet/mobile device width, and you should see the desktop-only elements work correctly; the mobile-only elements should then pop up as you’ve intended them to. 

Santiago A Fernandez