Month: November 2011

Targeted content widget not working

The Ektron Targeted Content widget forms part of the Marketing Optimisation Suite. The widget allows content authors to specify conditions around which different items of content will be presented on the site. You can hook into lots of things such as user properties, the referring URL, cookie values, etc. Based upon these values you can specify conditions like “if user is in the Prospects Group then show them content item A” (or something similar).

If you ever run into a problem with the Ektron Targeted Content Widget whereby it does not allow you to add a condition when in edit mode, it may be that the App_Data folder is missing from the root of the website. The App_Data folde contains a number of data files, some of which allow the geo-location lookup facility to work. The Targeted Content widget makes use of this data and so the folder and its files need to be present.

The files in question are :

  • GeoIPDomain.dat
  • GeoIPOrg.dat
  • GeoLiteCity.dat

These files are present as part of a normal Ektron install (a cms400min site).  I saw this happen recently where a site had not been deployed properly so thought it would be good to share.

Write efficient taxonomy code

Ektron’s Taxonomy feature allows categorisation of content, users and community groups.  The Ektron API allows this grouping of content to be retrieved and manipulated in code.

One common problem I have encountered on projects is poor performing API code due to a lack of understanding of just how the API works.  Your taxonomy API requests should be specific and exact: retrieve only what you need to from the CMS.

The Framework API in version 8.5 does a lot to remedy these problems so I am focusing here on the pre-Framework-API-world.

Below is some example code (edited for brevity) from a recent project that performs a taxonomy request, looking for content items:


Ektron.Cms.TaxonomyRequest taxonomyRequest = new TaxonomyRequest();
taxonomyRequest.TaxonomyLanguage = CultureInfo.CurrentCulture.LCID;
taxonomyRequest.TaxonomyId = id;
taxonomyRequest.IncludeItems = true;
Ektron.Cms.API.Content.Taxonomy taxonomyApi = new Ektron.Cms.API.Content.Taxonomy();
taxonomy = taxonomyApi.LoadTaxonomy(ref taxonomyRequest);

On face value there is nothing wrong with this code. However, if I also state that the purpose of this call was just to get the Taxonomy Path you might then spot a few issues immediately.

Firstly, the “IncludeItems” property is set to “true”. This means the API will retrieve all of the content items in addition to the taxonomy information. A taxonomy could contain tens or hundreds of items, massively increasing the amount of data that the CMS has to retrieve.

Secondly, the “Depth” property has not been set. The Taxonomy Depth property specifies how “deep” the request should go, i.e. how many levels of sub-categories should be pulled back. By not specifying this you risk getting lots and lots of categories retrieve. Combine this with the first problem and you can easily see how slow this could become!

Thirdly, as we only want to get information about the taxonomy (and not the items in the taxonomy) we should instead use taxonomyApi.ReadTaxonomy rather than taxonomyApi.LoadTaxonomy. The former performs less queries as it ignores whatever is in the categories.

There have been several projects I have worked on where there were complaints that the CMS was slow. Quite often the problem was tracked down to a poorly written taxonomy request like this one.