Crawling root naming “gotcha!”

Short post for a small “gotcha” I experienced with indexing / crawling roots. I’m using indexing roots with Coveo for Sitecore (Hive) v4.1. I updated my roots and named them how I wanted them to be named, then rebuilt the index – only to find 0 items indexed, and the cloud panel reporting nothing happening.

The problem was, there wasn’t a crawling root with the default naming of ContentCrawler (or MediaItemCrawler for the media library). If you are indexing things in the content tree, you need at least one crawler with that exact name, or the rebuild will do nothing.

I don’t think you can have multiple crawlers with the same name, unless the crawlers are for different databases – meaning you can have two crawlers, both named ContentCrawler, one in your master index element and one in your web index element.

From my experience, other content crawlers after that (but within the same index element) can be named however you choose.


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!

Sitecore Security Acronyms – ar|au|pe|pd – What Do They Mean?

If you’ve ever explored the SharedFields table of the Sitecore content database, you might have noticed occasionally seeing field values like this:

ar|sitecore\Sitecore Client Maintaining|pe|+item:create|+item:delete|+item:publish|+item:write|pd|+item:create|+item:delete|+item:publish|+item:write|

You may also notice that the FieldId you see in rows that contain that value is always the same. It’s the __Security field of course, which is a shared field used across all Sitecore items. Makes sense, we are querying a table called SharedFields.

So what does this field value mean? To find this out, I simply checked the value of the __Security field on the item specified in the row. You may have to check Standard fields in the View tab to see this field. Scroll down to the Security field section and expand it, and you will see the permissions that role has to this item. You can also see the original string if you check Raw values in the View tab.

To understand what the four individual acronyms mean, I had to do some educated guessing based on how the permissions appear in Access Viewer:

  • ar – Permission applies to a role
  • au – Permission applies to a user
  • pe – Item-level permissions
  • pd – Descendant-level permissions

Additionally, a + sign in front of an item:action means permission was granted. A – sign means permission was denied.

I didn’t really have to know this, I was just curious. Hopefully this explains it for others out there too. If you have any additional information to share, please leave a comment!