9

I'm currently working with Tridion 2011 SP1 and I'm come across an issue with search which means that it's not proving as useful as the client is expecting.

The client has a naming convention for components the follows a standard in which slashes are used heavily. eg:

this/is/a/component/1

This works well for their internal component management but it's causing major issues with Solr searches from within the CME.

Searching for part names (eg. 'this') in the above example returns no results.

I've had a look at the Solr schema for the tridion core and the culprit is the chosen tokenizer for the text field type.

<fieldType name="text" class="solr.TextField" positionIncrementGap="100">
  <analyzer type="index">
    <charFilter class="solr.MappingCharFilterFactory" mapping="mapping.txt"/>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.ReversedWildcardFilterFactory"/>
    <filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/>
  </analyzer>
  <analyzer type="query">
    <charFilter class="solr.MappingCharFilterFactory" mapping="mapping.txt"/>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>

As the main tokenizer in use is the WhitespaceTokenizerFactory, the component name isn't being tokenized into human searchable tokens (ie. split on slashes in this case).

This would all be solved by using a different tokenizer such as the StandardTokenizerFactory but this would obviously require changing the inbuilt Solr schema and running the reindex tool.

Is this a supported change? I understand that this would not be upgrade safe but it's becoming such a big issue for the client, I'm happy to manage the extra configuration but I don't want to make any unsupported changes to the internal config which would impact support agreements etc.

Improve this question
3
  • Great question and solution idea. It feels safe - you will need to document the solution and also re-index your content after updating the config. I'd suggest to write a blog post about it - and therefore document for yourself, the client and also the community.
    – robrtc
    Commented Oct 27, 2015 at 22:05
  • Hi @robrtc, thanks for the response. I'll propose the idea to the client if it turns out that 2013 doesn't work in the way we want either and if we go ahead I'll make sure there's a blog etc to support the approach and share that out.
    – Mike Percival
    Commented Oct 28, 2015 at 15:53
  • Just an update on this - here's Tridion support's response to the question: "Solr is a 3rd party tool which we use, the way it has been developed for use with Tridion is meant to work "as is". However there are other configuration possibilities that we may not have put into testing and so do not know the full effect. We cannot also test completely this change. If it works for you and does not have any effect on search then it should be fine, however if some search functionality does not perform as expected be ready to revert." It looks like that's a green light for making the change!
    – Mike Percival
    Commented Nov 2, 2015 at 10:36

1 Answer 1

Reset to default
1

With 2013 SP1, CME search works for components when using name as the search criteria (irrespective of whether there is "/" in the component name or not). As long as solr implementation hasn't changed on the backend between Tridion versions (2011 and 2013) it should work the same way in 2011 as well. Like with the example that you have provided, you can search like:

*this*

And it will return the component which has this in the name. Try this in your case and see if it works. If it does work in 2011 as well, then it is way easier to use OOB CME search as compared to changing solr configurations etc. which might not even be supported.

Update:

I have seen similar scenario earlier, anyways I tested with the exact scenario you have by naming component "this/is/a/component" with and without whitespaces in between the words and in both the cases Tridion CME search returned the component in search result when I searched for *this* or any other word in the component name

Based on this it looks like something did change between 2011 and 2013.

Improve this answer
4
  • 1
    Hi @Vipin, thanks for the reply but I'm not sure you've understood the issue. The users are wanting to search for "this" and it to return all results containing "this". However, with the WhitespaceTokenizerFactory that Tridion uses as a default, it will only tokenize "this/is/a/component/1" into a single token of "this/is/a/component/1" (as these are no spaces to tokenize from) and so it will not find that result when searching only for "this". Wildcarding will work but it would be nice not to have to wildcard all searches for performance reasons.
    – Mike Percival
    Commented Oct 28, 2015 at 8:33
  • I understood the scenario before responding to your question because I had seen this scenario earlier when an author was trying to do similar stuff. It works with wildcard search in 2013. I just replicated the exact scenario you have. "this/is/a/component" and it does work with this search and the component is returned along with any other match for "this"
    – Vipin Kothari
    Commented Oct 28, 2015 at 15:10
  • Hi @Vipin, thanks for the further update. I'll have a look at 2013 and see if I can replicate your results. We're looking to upgrade the client in the near future anyway so if this works, that would be great. I've checked a 2013 solr schema and it's not any different to a 2011 solr schema so unless the CME code has changed, I can't see it having a different output. I'll report back!
    – Mike Percival
    Commented Oct 28, 2015 at 15:41
  • As promised, here's the follow up - it works exactly the same in 2013. The only way I can get a component to be found based on it's title if there are no spaces is to wildcard or search for the full name. I'll confirm with SDL to see if changing the inbuilt Solr schema is supported or not and take it from there.
    – Mike Percival
    Commented Oct 29, 2015 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.