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!

Advertisements

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!

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.

Data at the root level is invalid. Line 1, position 1.

I recently ran into this error in Sitecore 8.2 when trying to change a link in a field in Sitecore. The field appeared blank,  so I clicked “Insert Link” and a Sitecore modal popped up displaying this error: “Data at the root level is invalid. Line 1, position 1.”

Sometimes when an invalid value is entered into a link field in Sitecore, the field will still appear blank to the casual observer. This of course, does not mean that the field contains no value at all. It just means that the field does not contain a valid link.

To resolve this issue, in the Content Editor click the View tab, then check Raw Values. The editor will refresh, and you should see something in that field of yours. It might be an ID or some form of garbage data. Clear that out completely, save the item, then uncheck Raw values. You should now be able to insert a link into the field. Hope this helps!

 

 

Resolving ClearScript V8 assembly issues

I recently worked with a colleague on a ASP.NET MVC / Sitecore project that had some references to ClearScript, which is a 3rd party assembly that lets you add and run scripts from C#/.NET. We noticed issues with trying to publish files from the solution to the webroot, which always seemed to break the site. The most common issue was with ClearScript. These issues resurfaced as we refactored the solution and made subsequent QA deployments to the client’s servers.

The first thing we did to fix this was reinstall ClearScript and JSEngineSwitcher through Nuget. We then kept making code pushes to the webroot until we encountered a new error, which we usually had to install through Nuget as well, or troubleshoot/fix in other ways. Many of the assemblies were way out of date, since the solution had not been updated in a long time. Also, because the webroot was part of the solution, we found that some Nuget packages were installed into the webroot project, not the Web project that we were building out of, which also caused issues. To update this, we right clicked the solution and selected Manage Nuget packages for this solution, then checked each package and clicked Manage, and checked the box for the Web project.

We eventually got the code pushes to the webroot to work. The next problem was moving the code changes to QA. The main issue we ran into was an error stating Could not load file or assembly 'ClearScriptV8-(32 or 64).DLL' or one of its dependencies. The specified module could not be found. Some solutions for this issue:

  • Right click the IIS application pool and select Advanced Settings. Change the value for Enable 32-bit Applications to true.
    • Some people have had success with the opposite (setting it to false). I am still not sure what effect this value has.
  • The error can mean that the ClearScript DLLs reference another DLL that is not present on the current machine. This makes sense considering I did not get this specific error on my machine with the same bin folder and site files. I looked into this and it seems like different versions of ClearScript require different versions of Visual C++ Redistributable:
    • For ClearScript versions 5.0-5.3, install Visual C++ Redistributable 2012.
    • For ClearScript versions 5.4 -?, install Visual C++ Redistributable 2013
    • I installed both 32-bit and 64-bit versions of both, although I’m not sure if that was required.
  • In my case, neither of the previous solutions worked, and it turned out that instead of copying over the bin to the QA server files and merging, I had to delete the bin folder and copy over new from my local webroot, which ended up fixing the issue.

I hope this helps others out there, this issue was quite an annoyance!