February 2013 » 7 Things Developers Should NOT Do With Kentico CMS
Feb 10

7 Things Developers Should NOT Do With Kentico CMS

If you are reading this blog post then you probably already know that I think Kentico CMS is the best ASP.NET based Content Management System around. Kentico is an incredibly powerful and flexible platform to build web sites and web applications with. With that being said, just like any other system on the planet, if you are not careful you can end up using it the wrong way. Today I am going to try to shed some light on a few common mistakes that I have seen in the wild with Kentico. Hopefully after you read this list you will be able to avoid some of them.

 

1. Run with Debugging Turned On

This applies in two areas. First do not ever run a production ASP.NET site with the following configuration in the root web.config file:

<compilation debug=”true” ... />

Instead use this

<compilation debug=”false” ... />

For an excellent breakdown on why this is true, check out this post on web.config debugging. Configuring this setting correctly is a real simple thing, but sometimes it gets forgotten after the final copy of a Kentico solution is uploaded to a QA or Production environment because by default it is enabled.

Also the numRecompilesBeforeAppRestart attribute on the compilation node is also important here. This setting sets the limit of how often you can have a file change within Kentico’s directory structure. I.E. if you are adding or modifying  a bunch of web parts, modules, or templates that are in turn creating .aspx or .ascx files and a recompile is dynamically required.

The default ASP.NET value for this setting  is 15, and the Kentico smartly increases the default to 100 in a base install. If you have ample memory (RAM) available on your web server you can increase this number even higher (like 999) to prevent restarts to the application when a page is updated dynamically, this mostly applies to the web site solution version of Kentico.

The second aspect of this point is don’t forget to enable the Disable Debugging checkbox in CMSSiteManager -> Settings -> Performance. You may have forgotten that during devlopment you enabled SQL Debugging or Macro Debugging in the Performance settings section. These debugging settings are a great feature, but also would slow down a site running in production mode.

 

2 - Rely on a Web Part Control ID Property for CSS styling or Client Side Script

In the last few projects I have been brought in to optimize I have seen the occasional line of javascript that looks like this:

jQuery(“#p_lt_ctl06_pph_p_lt_ctl04_gm_map”).show();

Or even worse yet, lines of CSS that look like

#p_lt_ctl06_pph_p_lt_ctl04_wp_span {
    display:block;
    margin:0 20px;
}

The lines above show javascript and css using the generated user control id property from a built in web part. The reason you should not do this is that the control hierarchy of a page can change! Pretend that this line of javascript is within a normal page template that inherits content from the Master Page Template. If two weeks down the road you decide to add or remove a web part or web part zone in the Master Page Template that simple action can change the the actual auto generated id of each and every other web part on the inner page template. I.E. you may end up with a new control id that looks like p_lt_ctl07_pph_p_lt_ctl05_gm_map and your script will totally break.

The correct way to handle this situation would be to wrap the control with a unique containing element via the HTML Before and HTML After properties and use a unique id or unique class to identify the container and use a jQuery selector to get a reference to the object you want based off of that.

jQuery(“#myMap div”).show();

For the CSS issue it’s the same solution, generalize your rules from a container

table.myTable tr td span {
    display:block;
    margin:0 20px;
}  

 

3. Nested Data Listing / Repeater Controls in Transformation with Default settings

If you attempt to show a parent and child relationship via nested repeaters in Kentico and you aren't careful you can slow down a listing page without even realizing it. I see this sometimes in a transformation that is used in a parent repeater. Imagine if we were using a transformation like the one below.

<ul><a href=”<%# GetDocumentUrl() %>”><%# Eval(“DocumentName”) %></a>
<cms:Repeater runat=”server” id=”repNested” Transformation=”newsarticles.listall” ClassNames=”CMS.Article” Path=”/News/{0}/%”  />
</ul>

In most cases the intention of this code would be to show the children nodes of a parent node, or in this case, show all of the articles underneath a certian category of news articles. But what happens in there are 20 news categories with hundreds or more artices in each one. You have to realize that the above transformation is going to run a sql query EACH time, for all rows in the parent datasource, plus you usually have to add a bit of code in your transformation to set the WhereConidtion properly. Like I said, this can really slow down a page. In this situation you should set DelayedLoading to True to ensure that the first base query does not run.

But really the best way to implement nested controls in Kentico is to use the the newer Universal Viewer or Hierarchical viewer that were introduced in Kentico CMS 6.0+. This control is optimized to show hierarchical data. It really can't be beat and is simple to setup. Also remember there is a custom query version of this web part too.

 

 

4. Expect All pages and Urls will automatically be added to the Google XML SiteMap

Don’t forget about important SEO settings like this. The Google SiteMap feature in Kentico CMS is one that we use in just about every project we do. It handles generating the correct XML SiteMap for you that you can use to submit to Google. One thing that it doesn’t do is automatically add a node for Document Categories or custom Document Types out of the box. By default, only CMS.MenuItem Document Types render like this:

<urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ...>
 <url>
  <loc>http://www.mcbeev.com/</loc>
  <lastmod>2013-02-09</lastmod>
 </url>
 <url>
  <loc>http://www.mcbeev.com/About</loc>
  <lastmod>2013-02-08</lastmod>
 </url>
 <url>
  <loc>http://www.mcbeev.com/Contact</loc>
  <lastmod>2013-02-08</lastmod>
 </url>
</urlset>

One option to correct this is to read my post on the Google XML SiteMap generation in Kentico 4.x, 5.x, or 6.x. The best way to handle this in Kentico 7 is to utilize the new Google XML Sitemap web part. After you add this web part to a page in the content tree, you can control the built in sitemap properties, the query that runs behind the scenes, and the transformation that renders the xml. You do have to enable the other new setting located at Site Manager -> Settings -> URLs and SEO -> SEO -> Google SiteMap Path to point to your new page though. This is nice because you no longer have to edit the file on the filesystem.

As developers, we tend to care more about functionality than content. We leverage Kentico to create awesome websites that can display our structured content using custom Document Types, Custom Tables, or Modules. Just remember to make sure search engines can find the content. Your marketing department will be happy you did not forget.

 

5. In Kentico EMS, Forget to Tie On-line Form Submissions to Conversion

I’ve talked about how important On-line Forms are in the past many times. A form submission really is the most used “activity” that easily lends itself to tracked via a Conversion. You can add any On-line Form to a Web Part Zone, or inside a content block as an Inline Widget. But once it is there the Conversion tracking feature of Kentico EMS does not start logging until you have selected a certain conversion in the Web Part Properties or In-line Widget Properties. The screen show below shows creating or modifying a form. But it is not always obvious to developers that this is not the place to specifiy the conversion. It is instead when you actually use it on a page or zone.

One side note, If you do not see the Conversion selector in the In-line Widget Properties window you many need to configure the property to show on the Editing Form via the Site Manager. Just select the On-line form Widget, edit it’s properties, and click the Display on Edit Form checkbox. I mention this becuse this is common for a site that has been upgraded to Kentico EMS. Once that is setup you should see the Conversion tracking settings like so:

 

6. Use Macros with Normal Syntax in a Page Layout

In a Page Layout or Template Layout you cannot use macros the way you might expect, aka just like in a web part property.

The normal macro syntax (which you cannot use):

{%CurrentDateTime%}

Instead can use:

<%= CMSContext.CurrentResolver.ResolveMacros("{%CurrentDateTime%}") %>

Quick Tip: This is one way to handle the copyright line in the bottom of the footer in the Master Page Template of a Kentco site, aka the Copyright 2013 line.

 

7. Hotfix an Installation of Kentico CMS with NO Backup or Directly in Production

This one is kind of a no brainer but I do get asked this question. The Kentico Installation Manager (KIM) that was introduced in Kentico 6.0 is a great tool. I often mention it because it makes the process of updating and patching a Kentico site much easier.

There is a good reason that KIM gives you the option to backup the code of the site and database right inside of the tool, and makes you explicitly state that you have made a backup before applying any changes. You can really shoot yourself in the foot if you ignore these precautionary steps.

A Hotfix is actually a set of file changes, assembly (dll) changes in the bin directory, and sql scripts that need to all successfully complete in order for the patch to take effect. If something goes wrong with one of those three, i.e. the file was locked by IIS, or customizations prevent one of them from running your site could be left in an unusable state. It is always best practice to have that backup on hand in case something goes wrong.

Quick Tip: If you are working in a shared development environment I recommend performing the Hotfix on your local machine first, because the hotfix or upgrade process in KIM could add and/or remove files inside of the application. Prove that it works on your local instance and then commit your changes. Once everything is committed then you can merge or publish your changes to QA or Production.

 

Conclusion

I hope that the seven items I have identified above help you side step atleast a few painful mistakes when it comes to developing with Kentico CMS. There are definitely more possibilities out there so if you want to share your own common mistakes in the comments to this post. 

 

You might also be interested in

[X]

Be the first to know about my latest Kentico Tips & Tricks!

Do not show again