Media Library searching with SOLR

Question

Sitecore 8.2 U5

SOLR 6.6.2

In the content editor, I can search for any words or phrase. Sitecore will return results for any item where that word or phrase is used, in any field.

But in the media library, using the same search. I only get back search results where the the word or phrase is in the item name. No fields on the items are search. This happens only in the media library.

Nothing exciting in the configs. Pretty much vanilla Sitecore. When I look in SOLR, my media fields are indexed. If I do a custom field search Description|Danger2, it also returns no results when there are items that match that query. I have rebuild index and searched the logs. No that points to an answer yet.

UPDATE

We are noticing in the Media Library, in SOLR, we are searching the index sitecore_marketing_asset_index_master. It is searching _content field, but that field does not have the proper data in it. If we search Sitecore using the proper field author_t|jerry, we get results. So it seems like _content is not being populated in sitecore_marketing_asset_index_master and why are we using that index and not sitecore_master_index.

27824 11:16:31 INFO Solr Query - ?q=((((_content:(Bumpy) OR _name:(Bumpy) OR _displayname:(Bumpy)) AND _path:(2b7a070b5ddd4692b808d8c30cbd633c)) AND _latestversion:(1)) AND _datasource:(sitecore))&start=0&rows=20&fl=*,score&fq=_indexname:(sitecore_marketing_asset_index_master)

Answer 1

May be that is not answer, but it step by step guide how to troubleshot it.

What you can to do:

1. Open Sitecore Content Editor, Media Library
2. Do search by "test" text term
3. Open your SOLR log file: {location of SOLR on your machine}\server\logs\solr.log
4. Check last lines in file, they should contain SOLR query that was executed

5. For my instance it was:

   (((_content:(test)+OR+_name:(test)+OR+_displayname:(test))+AND+(_path:(3d6658d8a0bf4e75b3e2d050fabcf4e1)+AND+_latestversion:(1)))+AND+_datasource:(sitecore))&fl=*,score&start=0&fq=_indexname:(sitecore_master_index)&rows=20&version=2.2

It means that "test" term search query was executed on fields: _content, _name, _displayname.

6. Check that terms that you are look for ("test") is present in one on _content field.

I think it will be absent in these field, next - you can try to figure out why your field values are not added to _content search field.

UPD:

7. Find out type of _content filed. Configuration should be present in Sitecore.ContentSearch*.config files.For my current instance it is Sitecore.ContentSearch.ComputedFields.MediaItemContentExtractor,Sitecore.ContentSearch.
8. Open Sitecore.ContentSearch.dll(depending on step 6) with IlSpy(or any similar reflector). Find out how field works, and what is missed.
9. Create your own class for _content field that will be inherited from class in step 6 and will add values that you need from media items.
10. Create patch config file to register your field type in Sitecore

Answer 2

If you are trying to search the text of a pdf file you'll need to use iFilter. for my solution, I used PDFBox so I could search pdf files. It is available as a nuget package. I also had to install the Microsoft filtering pack on the servers as well for searching microsoft documents.

I used a computed field which used my custom class using PDFBox to extract the text of the pdf file

<fields hint="raw:AddComputedIndexField">
:
    <field fieldName="_content" returnType="string" type="xxx.Business.Search.PdfCrawlerV2,xxx.Business">
 xxx.Business.Search.PdfCrawlerV2,xxx.Business
    </field> 
:
</fields>

This works like a charm!

There are other iFilters as well and not all are free.

Adobe PDF iFilter

Foxit

iTextSharp

NOTE: When indexing documents, indexing time drastically slows down!

Answer 3

We were experiencing the same thing with some extended media template fields our content authors were expecting to be able to search on. I was able to track it down to an issue (feature?) with the SolrDocumentBuilder. For whatever reason, it skips adding to the "_content" field for media item text fields (oddly enough, this is not the case for Lucene or Azure document builders).

The fix for us was extending the SolrDocumentBuilder to make sure that happens. Here's the code:

/// <summary>
// For whatever reason, the default SolrDocumentBuilder skips adding to the "_content" field for media item text fields.
// This means we're unable to search for these field values in various places in Sitecore (Select Media dialog, Content Tree search, etc).
// This extended version makes sure those are aggregated.
/// </summary>
public class SolrDocumentBuilder : Sitecore.ContentSearch.SolrProvider.SolrDocumentBuilder
{
    public SolrDocumentBuilder(IIndexable indexable, IProviderUpdateContext context) : base(indexable, context)
    {
    }

    protected override void AddField(IIndexableDataField field)
    {
        base.AddField(field);

        if (!IsMedia || !IsTextField(field))
        {
            return;
        }

        var fieldValue = Index.Configuration.FieldReaders.GetFieldValue(field);
        if (!(fieldValue is string) || string.IsNullOrEmpty(fieldValue.ToString()))
        {
            return;
        }

        StoreContentFieldValue((string)fieldValue);
    }

    private void StoreContentFieldValue(string fieldValue)
    {
        if (Document.ContainsKey(BuiltinFields.Content))
        {
            Document[BuiltinFields.Content] = Document[BuiltinFields.Content] + " " + fieldValue;
        }
        else
        {
            Document.GetOrAdd(BuiltinFields.Content, fieldValue);
        }
    }
}

And the config patch:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
        <contentSearch>
            <indexConfigurations>
                <defaultSolrIndexConfiguration>
                    <documentBuilderType>My.Project.SolrDocumentBuilder, My.Project</documentBuilderType>
                </defaultSolrIndexConfiguration>
            </indexConfigurations>
        </contentSearch>
    </sitecore>
</configuration>

This was on Sitecore 9.0.2 (rev. 180604).