Gravatar for

Question by chris williams, Apr 10, 2016 9:29 PM

Computed field returns value on master but not web on dev server on Azure

On my local machine everything works fine. I have Coveo local to my laptop and it returns results. On Azure, I have a dev box. It has both coveo and sitecore on the same box like I do on local.

As the box has McAfee which uses 8080 I had to move the rest api to 8082. I get all green on the diagnostics. I get the results back if I change sitedef config to master. If it is set to web I dont. I looked at the indexes and under fields -> custom fields the computed field is showing up. I tried a full publish of the site. I tried a rebuild of the web index as well from Sitecore.

What else can I try to get this to work?

Btw, I tried to register for the portal with my email address but is too large. You can answer here or email me back.

Gravatar for

Comment by Simon, Apr 11, 2016 1:36 PM

I informed the community manager of your issue with the email being too large.

1 Reply
Gravatar for

Answer by Simon, Apr 11, 2016 1:27 PM

So the problem is that you do not see results against your web source correct? The point with the computed field must be because you are using that field in your queries, is that also correct?

If so, how do you add this computed field to your search queries? Using a query builder in the aspx/cshtml of your search component? If so, is it possible that you may not be using ToCoveoFieldName and hardcoding the hash?

Still following the same assumption about the computed field, you validated that the computed creation in the Field set in the Administration Tools, but did you look at the value applied to your documents? You can see the list of fields attached to a document in the Index Browser (Content >> Index Browser). The documents will have a Details >> Field tab.

Let me know what you find.

Gravatar for

Comment by chris williams, Apr 11, 2016 2:09 PM

I found the problem but not sure how to fix it. The ComputedField does a site crawl and stuffs the results in the index. The problem was that during publish the site context is shell so none of the urls work. For some reason when using master index this was not happening. Now the dilemma is that each item has 11 different urls per item (one per language). The language is defined in the site definition and the 11 sites share the same tree in sitecore. So when I publish an item and it triggers the custom field I am lost because really there needs to be 11 indices. Have you run into this before?

To summarize it is 11 sites defined with sitedef entries in sitecore. App point at the same site node but define language. Currently I have a 1 master and 1 web index. If I create 1 per "site" how do I stuff the content into the right index. Can Coveo handle this scenario or is this totally custom?

Gravatar for

Comment by Simon, Apr 11, 2016 4:09 PM

Coveo should support it, here are my observations, tell me if I am heading in the wrong direction.

1- The computed field does a Site Crawl and adds data to the index. Is it to grab the full content of the rendered pages? If so, instead of coding a computed field, I would use the HTML Processor :

2- Coveo for Sitecore adds the Context language based on the Sitecore item language version. The Language is added in the Constant query and should look like this:


_language being the Sitecore field added to the item according to it's language version.

3- As for the url using shell, this is a known behavior. The Indexing is happening in the shell context, which is not a problem for the master. For the web, we modify the URL when the request is received using the Parse REST response processor:

Hope it helps,

Gravatar for

Comment by Simon, Apr 12, 2016 9:39 AM

Just to add a bit more clarity. You should NOT split your indexes, since we will filter by language instead.

The said:

1- You need to make sure that your items are using Sitecore language versions. This way, Coveo will index the item 11 times, and for each, the _language field will be different.

2- At query time, we inject the language based on the language version of the search page. This mean that you will need 11 pages, one for each language.


Ask a question