ContentHub integrates nicely with Sitecore XM through Sitecore Connect for ContentHub. Probably the most popular use case is referencing assets stored in ContentHub’s DAM instead of using classic Media Items. This is integrated nicely through an extension of the image field:
I faced the issue that checkbox values were not being updated in the index correctly. When I unchecked a checkbox and saved, the index would still have “1” stored as value for my field. To prevent this issue, use Sytem.Boolean as type instead of System.String.
<field fieldName=”MyCheckboxField” storageType=”YES” indexType=”TOKENIZED” vectorType=”NO” boost=”1f” type=”System.Boolean” settingType=”Sitecore.ContentSearch.LuceneProvider.LuceneSearchFieldConfiguration, Sitecore.ContentSearch.LuceneProvider” />
Internally, lucene still stores “0” or “1”, but when using System.String, values of false would be considered as “nothing” when updating the index, leading to not updating the value of the field. Changing to System.Boolean made it work.
We have faced a problem when working with multilists and custom indexes. Some of our multilists would not contain any data even though the lucene queries would have matches when querying the index directly. We found that the problem had to do with the way Sitecore determines the index to perform the bucket query on.
When working with custom indexes in the Backend (i.E. bucket queries, multilist with search,…), Sitecore has a method to determine which index is most appropriate to use for the base item (i.E. the bucket container) you’re querying on.
In version 7.2, basically, Sitecore checks, which indexes are defined for the context database and then checks if the base item is included in the respective index by checking include/exclude templates. The first matching index is used. It is important to know that the root paths configured on the crawlers don’t have any affect on this. That means in some cases an index may be selected that doesn’t actually contain any information about the data i’m querying. I bug imo.
To work around this you have the following options:
a) Index config files are read in alphabetical order. You might be able to move around your custom indexes to let Sitecore select the appropriate index.
b) Hook into the contentSearch.getContextIndex pipeline and implement your own logic.
Since a) is pretty straighforward but might not work for all scenarios, I’ll show an example of b):
I wrote a simple hook that allows me to read the name of a custom index from a field on the base item (i.E. the item bucket base item):This allows me to use a field named CustomSearchIndex to optionally set the index name used for querying.
To check which context index is resolved on specific items, i have implemented a simple admin page that allows me to resolve the index based on a GUID or an item path.
This workaround does the job, but it would of course be nicer to have Sitecore correctly resolving context indexes. Also it would be good to be able to set the index directly in the multilist / bucket configuration. I hope there will be an improvement here in future versions.
After upgrading to Sitecore 7.2 I ran into this exception in the crawling log when trying to index PDF documents:
Unable to create document builder (). Please check your configuration. We will fallback to the default for now.
The solution was to add the document builder type to my custom index configuration:
<documentBuilderType>Sitecore.ContentSearch.LuceneProvider.LuceneDocumentBuilder, Sitecore.ContentSearch.LuceneProvider</documentBuilderType>
After that, reading PDF content through my iFilter provider worked fine again.
After upgrading to Sitecore 7.2 we got the following exception when trying to build our custom indexes:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Sitecore.ContentSearch.LuceneProvider.LuceneIndex.Reset() at Sitecore.ContentSearch.LuceneProvider.LuceneIndex.PerformRebuild(IndexingOptions indexingOptions, CancellationToken cancellationToken) at Sitecore.ContentSearch.LuceneProvider.LuceneIndex.Rebuild() --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) at (Object , Object[] ) at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) at Sitecore.Jobs.Job.ThreadEntry(Object state)
The resolution to this is quite simple. Sitecore has included <initializeOnAdd> to the index configuration. If this field is missing in the configuration, building the index fails. Just make sure you have the following line to your custom index configuration:
<myCustomIndexConfiguration type="Sitecore.ContentSearch.LuceneProvider.LuceneIndexConfiguration, Sitecore.ContentSearch.LuceneProvider"> <indexAllFields>true</indexAllFields> <!-- Needed since SC7.2 --> <initializeOnAdd>true</initializeOnAdd> ....