Created a widget but can’t select it in the Pages application?

I have a quick solution to share for an issue that took me longer to troubleshoot and resolve than I thought. I was working in a Kentico project (not my usual foray) and created a web part, then a widget to reference that webpart. I used the right directory structure which mimicked that of the web part and the user control in the solution.

Then I went to the Pages application, opened a page and picked a widget zone to place this widget I created. Unfortunately, my widget, nor its directory structure were there; which was strange, because I could see my widget in the Widgets application.

I noticed that other widgets other developers had implemented were there, so I compared the settings of one of those with mine, and I found the solution. In the Security tab of the widget, I had to check the “Allowed for” box for the “The widget can be used in editor zones” option. After saving that change, I was able to select my widget from the Pages application.

Surprisingly, absolutely no useful results returned from various Google searches on this issue, including the title of this blog post (at the time), so I thought I’d share what I found. Hope this helps.


Render computed index field value in Coveo Hive search result template

There may come a time when you need to render the value of a custom field you created in the search results of your Coveo Hive search interface. Specifically, you would want to edit the search result template – hopefully you created a new one based on the file provided out of the box. How do you make the value appear though? I found this to be much more involved than I expected.

The isExternal setting

When it comes to rendering the value of the custom field, one setting is very important. In the fieldMap where you defined your custom field, you can choose whether you wish the field to be treated like a Coveo for Sitecore field (and to consequently appear in the content browser in a format such as fmyfield99999), or to be treated as an external (non-Sitecore) field, but still work with Coveo (and thus, appear without any characters added, like myfield). The setting you need to add or check: isExternal. Example:

 <fieldType fieldName="resultDate" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" isExternal="true" />

The underscore code required will depend on whether the value of that setting is true or false (false being the default). Whether you use {{ }} or <% %> syntax is up to you.

Coveo for Sitecore Fields

If the setting is false or not supplied, your field is a Coveo for Sitecore field, and could be rendered in one of the following ways:

1. Using the coveoFieldValue helper.

{{- coveoFieldValue("myfield") }}

2. Using the coveoFieldName helper in a div (WordPress didn’t like HTML in my blog post so I had to strip out the tag syntax):

div class="CoveoFieldValue" data-field="{{- coveoFieldName("contentType")}}" /div

If these don’t work, try adding @@ before the field name.

External Fields

If you provide the isExternal setting with a value of true, you can render the value of it using raw.

{{- raw.myfield }}

Using the coveoFieldName helper in a div also works.

Note that when using raw, the name of your field needs to be all lowercase, or the value will not be rendered. I was confused by this, because I entered my field name in the Coveo.SearchProvider.Custom.config as myField. Coveo support answered:

All the fields are actually translated to the index’s format, restricted to only lowercase letters, numbers and underscores:

During the indexing process, any field name that do not meet those requirements will be translated to that format (Coveo for Sitecore fields also get a unique hash added so that they are unique to each index).


You should be able to use the image() and date() helpers just fine now that you are using the correct syntax. Just note that if your field is external and you are using raw, your field name must be in lowercase. From what I can see, it doesn’t need to be all lowercase if you are using the other helpers. Hope this helps!

Error when serializing the property “RankingState”

I noticed this warning in the Experience Editor of a Coveo Hive search page, specifically on the search interface:

  • RankingState
    • Error when serializing the property "RankingState". (Exception has been thrown by the target of an invocation.)

I immediately checked the Sitecore logs and found a long winded exception chain. The head exception was of course, “Exception has been thrown by the target of an invocation“. Many nested exceptions below that, at the very bottom of the chain, I found this error:

Exception: System.InvalidOperationException

Message: Cannot use DataAdapterProvider as xDB is disabled.

Source: Sitecore.Analytics.DataAccess

   at Sitecore.Analytics.DataAccess.DataAdapterProvider..ctor()

   at Sitecore.Analytics.Data.DataAccess.MongoDb.MongoDbDataAdapterProvider..ctor(Func`2 driverFactory)

Researching that error, I found that the problem was my settings in the Sitecore.Xdb.config file (under App_Config/Include). I had XDB disabled, but not XDB.Tracking disabled. I disabled XDB.Tracking and the warning went away. I assume if you have XDB disabled, you should also disable tracking because it relies on XDB. Just thought I’d quickly post this problem and solution as I continue working with Coveo Hive.


The Coveo Analytics are not enabled for this Search Interface

Last week I started working with Coveo Hive. There are a few strange things I ran into or wasn’t sure how to resolve. I’ll be writing a series of blog posts on these things as I continue to work on my very first Coveo Hive project.

I set up a Coveo Hive search page using the basic layout provided with Coveo for Sitecore. Opening the page in the Experience Editor, I immediately noticed an error in red:

The Coveo Analytics are not enabled for this Search Interface. Insert a Coveo Analytics component to record Coveo Usage Analytics data.

I thought the instruction here was a little bit vague. I also was shocked to not find much information in the documentation about this (specifically, how to enable usage analytics in Coveo Hive). In the previous Coveo framework, you would select the search interface in the Experience Editor, and check a box to enable Coveo Usage Analytics. In Hive, you add a component (as the literature dictates).

I wasn’t sure exactly where to insert it though, and how; but here’s what worked for me. The solution was to add a Coveo for Sitecore Analytics component to the UI Header, above the search box and search box settings. You may have to do some clicking and navigating the hierarchy of components to find the UI Header. Hope this helps!

Coding and the Dangers of Familiarity: Keep Your Senses Sharp

When I started at my current company, we essentially had one major project that everyone in the team worked on. It was a client that we had been working with for a long time.  It was a fun project to work on, and I learned a lot about ASP.NET MVC and Sitecore. Even when the project closed, I had no regrets about working on it for nearly two years, with very little other projects coming up during that time.

It wasn’t until the project closed that I realized how it programmed me into doing a certain set of coding practices. They weren’t particularly bad practices, but you could say they weren’t the accepted, best way of doing things. Soon, I was being assigned to projects where the best practices and/or frameworks were in use and I was expected to use those. I’ll give you two key examples, which were both shocking once I realized what I had not done:

  • Glass Mapper. I started a new project where Glass was being used extensively. I had some small training/research on Glass in the past, but this was first project where I had to use it. I did end up using it somewhat effectively, but what shocked me was how suddenly, my defensive coding instincts did not kick in. For example, for 1.5-2.0 years, I was used to doing this:
if (item != null && item.Fields["Heading"] != null && !string.IsNullOrEmpty(item.Fields["Heading"].Value))

The second I would use .Fields[] call in Sitecore development, I would know to do extensive null checks; it’s the way I was trained – but now, I was not using that call anymore. The code was completely different, and so I did not even think of checking for null for some reason. I don’t know why I wouldn’t check for null – maybe I thought Glass would take care of it and never return null? Silly me.

  • Logging. I learned Sitecore development in an environment where I never had to add logging in case an error occurs. My former co-workers that wrote the site added a global try/catch around everything, so that whenever some code in a controller errors out, the details of the error would be entered into a record in an Exception (SQL) table. Essentially, I very rarely or never had to use Log.Error to write an error to the Sitecore log, since the Exception table would always catch that. Well, this convenience turned me into a poor developer; I realized this as soon as some code I wrote went live for a new project. It unexpectedly errored out, but I had no way of finding out what the error was because the site had a custom error page.

This is just my personal experience, and I don’t mean to rag on the project that taught me how to do Sitecore development, but the point I’m trying to make is: if you do the same thing over and over, and suddenly have to do something new, make sure you do some common sense checks before committing the code; namely:

  • Null check all the things.
  • Log information, warnings and errors for each functional part of the code that will be running.
  • Also, will your change negatively affect something that you did not intend? Carefully observe the differences between your new code and the old code.

Additionally, If you’ve been working on one project for a long time, and the development practices generally used in that project are not optimal, keep you coding senses sharp by learning about the best practices in your spare time. Read articles, watch videos, create a Sandbox project which includes those better practices in use. If you have any similar experiences, I would love to read them – thanks!