This is partly a follow-up post of my previous post on Workign with Solr and Sitecore Content Search in Sitecore 9. In that post I raised a few issues that needs to be dealt with, and I’ve found some more. Most of what’s in this post I’ve found on Sitecore 9.0 update-1 and/or Sitecore 8.2 update-5, and it seems like most of the things applies to many more versions too. So I’ve focused on how you can verify if your solution needs patching too.

This is essentially just a brief list of some issues I’ve found over the last few weeks, while working against the clock towards the releases of two large Sitecore projects. Big thank you to all my great colleagues that have put an enormous effort into getting things to work.

Indexes are not updated on language fallback

When using the syncMaster strategy, typically on the sitecore_master_index, it may not update properly when using language fallback. Here’s how to test this on a fresh instance:

• Have enableFieldLanguageFallback set to true for indexes and the sites “shell” and “website”
• Configure some languages and have their language fallback point to the “en” English language.
• Have a template with at least one versioned field that has Enable language fallback set to true.
• Have an item based on the template above and ensure it has a few language versions.
• Let the versioned field fallback to the “en” English master language. All or some language versions should now have inherited/language fallback values
• Re-build the sitecore_master_index and verify that the item has been properly indexed.
• Change the value of the versioned field on the “en” English language and save the item
• Look again in the sitecore_master_index and check if the fallback values have been updated

If the fallback versions hasn’t been updated, you’re also affected by the bug. At the time of writing this, there is no patch to this as far as I’m aware of. You’ll have to contact Sitecore support and ask for a fix. I’ve seen this error in multiple versions.

Indexes are not updated when using Publish Service when editing shared fields

When using the onPublishEndAsync strategy together with the Sitecore Publish Service, your web indexes may not update properly. Here’s how to test this on a fresh instance:

• Have a template with a shared field
• Have an item based on that template, with multiple language versions
• Publish the item and rebuild the web index, to ensure a correct state
• Change the value of the shared field and publish the item
• Look in the sitecore_web_index and check if the shared value has been updated

If the shared value has been updated only on the version that you actually edited and published, and the index was not updated for all other language versions of the item, you’re affected by this bug. At the time of writing this, there is a patch for this. Personally I don’t like the way this has been solved, but at least it works. You’ll have to contact Sitecore support and ask for the fix, as I’ve been asked not to distribute the patch. This bug seems to exist in all current versions of the Publish Service.

Indexes are not updated when using Publish Service when editing unversioned fields

Update: This might have been a side effect of another problem I had, so this might not be a bug after all. However, the patch above is still relevant.

This bug is very similar to the one above. Here’s how to test this on a fresh instance:

• Have a template with an unversioned field
• Have an item based on that template, with multiple versions on the same language
• Ensure the latest version is not publishable, like having it in Draft state or similar
• Publish the item and rebuild the web index, to ensure a correct state
• Change the value of the unversioned field on the latest, non-publishable version of the item
• Publish the item again. At this stage, there is no “change” to the published item itself, but the unversioned field causes a content change.
• Look in the sitecore_web_index and check if the unversioned value has been updated

If the unversioned value have not been updated, you’re affected by this bug. At the time of writing this, the patch above seems to solve this error as well. You’ll have to contact Sitecore support and ask for the fix, as I’ve asked not to distribute the patch. This bug seems to exist in all current versions of the Publish Service.

Publish Service may not publish all versions

When moving an item, the Publish Service may not publish the item properly. Here’s how you can check this:

• Create two items as children of a Home item. I’ll refer to them as A and B. Ensure both items have at least two language versions.
• Create a child item to A. I’ll refer to this item as C.
• Select the Home item and choose Publish -> Publish Item. Check “include subitems” and publish. Ensure the languages are checked
• Verify that the web database has been properly updated
• Move the child item C from A to B.
• Select the Home item and perform the same publish operation again as above
• Look in the web database and verify the existence of language versions of the C item.

If the C item doesn’t have all the expected languages you’re affected by this bug. At the time of writing this, the very latest version of the Publish Service has fixed this, so you’ll have to make an upgrade. Many thanks to John for finding this!

The search.log file may be flooded with warnings

Your search.log may be flooded with warnings during an index rebuild. The warning messages looks like this:

WARN Processing Field Name : __validator_bar_validation_rules Search field name in Solr with Template Resolver is returning no entry.

This is a confirmed bug, no 195567, but Sitecore says the warning message “is expected”. There is currently no fix for this, but as a workaround you can add a filter to your log4net config in order to suppress the messages. Many thanks to Thomas for finding this!

Index rebuild based on index data

During an index rebuild, you may see search.log flooded with queries like this:

INFO Solr Query - ?q=_name:(noindex)&rows=0&fq=_templatename:("Template field")&fq=_indexname:(sitecore_master_index)&wt=xml

Yes, Sitecore is querying the index that is currently being re-built… These log entries may be for several fields for every item version, so it’s easy to run out of disk space. That’s how I found it with a 10GB+ log file. This is a confirmed bug and at the time of writing this there is no fix for it. As a workaround you can specify all the field names and their types in the fieldNames section, like this:

<fieldNames hint="raw:AddFieldByFieldName">
<field fieldName="your_field_name" returnType="text" />

I don’t know what happens if you have two different templates having a field each sharing the same name but with different types. I don’t know the actual cause of this, but to me it seems like Sitecore doesn’t look at the configured <fieldType> mapping.

Lucene config in the Solr files

If you’re using Solr, you may want to take a look at your config file Sitecore.Marketing.Definitions.MarketingAssets.Repositories.Solr.IndexConfiguration.config. It may have incorrect Lucene references, though it doesn’t seem to do too much harm. You can simply change it to follow the Solr config pattern.

Clone errors in the publish log

When using clones together with the Publish Service, you may get the following error in the publishing.log (the log for the Publish Service – not the one in Sitecore Data/logs):

[Warning] Clone Source Item a40fff41-e146-45f0-a225-0508da3a6477 does not exist on source database. Clones will still be published.

The error itself is incorrect. I’ve ensured that the source item do exist and is in a publishable state. At the time of writing this, I haven’t found the cause of this nor what affect it has on the published content. It might be connected with the next error, but it doesn’t seem like that right now.

Published clones may lose data

When using clones together with the Publish Service, you may find missing field values in the published web items. Here’s at least one scenario where this can happen:

• Have a “master” item.
• Clone the master item into a “clone-item”. Leave the original values.
• Clone the clone-item into a “clone-of-clone-item”. Leave the original values.
• Publish the three items using the Publish Service.
• Look at the clone-of-clone-item in the web database.

If you’re missing field values in the web database, you’re affected by this bug. At the time of writing this, I’m not aware of any solution to this. Your only option is really to go with the old publisher. If you let the old publisher correct the data and then enable the Publish Service again, it will remove the field values again. I also need to spend some more time to see if this is the only scenario where data gets lost, but it takes time on a solutions with 450k+ items…

This error is really serious, since content is actually lost on the published site.

Wrap up

So these are just some of the issues I’ve been fighting over the last few weeks. Some of them are hard to spot, so you may be affected by some of those issues without knowing it. Maybe this can help you smash some bugs in your solutions too.

Sitecore: When will you start a bug bounty program?