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:

Warnings
  • 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.

 

Advertisements

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!

 

How to Disable or Enable a Field in SPEAK

I’m not sure if Sitecore Rocks is the only way to do this, but I recently had to enable a disabled field of a SPEAK form. I figured you would be able to change field settings  in the content editor of Core, but I couldn’t find any way to do it from there. This post will describe how to change field properties through Sitecore Rocks; if there is another way to do this, please let me know through the comments. In my case, I was using SPEAK 2 with Sitecore 8.1.

  1. Open your instance via Sitecore Rocks and navigate to your app’s task page in the Core database.
  2. Right click the Item and select Tasks -> Design Layout.
  3. You should see some fields under Renderings and Placeholders. Double click the field you wish to edit.
  4. On the right, a properties dialog will appear.
    1. To disable the field – which will prevent text entry and make the background gray – set IsEnabled to False, IsReadOnly to True and add disabled=disabled to the  Parameters field.
    2. To enable the field, set IsEnabled to True, IsReadOnly to False and remove the disabled=disabled parameter.

Hopefully this helps other SPEAK developers out there! Feedback is appreciated.