Setup and Install SOLR 7.5.0 for Sitecore 9.2

It’s super easy to Setup SOLR 7.5.0 for Sitecore 9.2 and with the gist shared by Mark Cassidy  here, it will take just few seconds to install and make SOLR up and running.


I have used the same and updated few parameters like:

  • Solr Port
  • Solr Host
  • Solr Version (7.5.0)- (This is prerequisite for Sitecore 9.2)
  • OpenJDK Version

Ran the script and few seconds later SOLR 7.5.0 was up and running.


SOLR admin was up and running.


Thanks to community members contributions.

Hope this helps!

Happy searching 🙂


Disable index rebuild while installing sitecore package


If you also came across issue with failed package installation/taking lot of time to install because of the no of items package contains and the background activity it performs like index rebuilding- there are two options you can choose from to install Sitecore package successfully:

  1. Disable Index Rebuild while installing Sitecore package.
  2. Install package using SPE (

Disable Index Rebuild while installing Sitecore package: In this option you can add/deploy a patch to temporarily disable index rebuild and set the indexing strategy to be manual. once the package installation is done this patch can be removed.


We need to specify the indexes available and set the index update strategy to manual.

Install package using SPE: This option is handy and can be used as an alternative to install the package, here is the script which can be used to install package with SPE.

We can also disable index rebuild while installing the package.

PS master:\> Install-Package -Path -InstallMode Merge -MergeMode Merge

This has saved lot of our time and you should give it a try if your package installation is taking a lot of time and failing.

Hope this helps!

Happy learning 🙂



Faceted Search with Sitecore

Facets are used to group and classify content items, it’s used to aggregate the count of terms in a field to help a user filter their search more and more to get to the specific results they are after.


As per the documentation of SOLR, facets are described as “… the arrangement of search results into categories based on indexed terms…”. faceting makes it really easy for the end users to look and explore for something which they are looking for. An example can be which provides faceted navigation based on the selected keyword, which facilitates users to do look into specific category and narrowing down their results.


Lucene and SOLR both provides support for Facets using ContentSearch API,which means you write facets one and that can be re-used for other search engines as well.
Using ContentSearch API we can use FacetOn() method on the IQueryable<T> instance to set what to facet on, and then call GetFactes() method to get the list of results.

context.GetQueryable<SearchResultModel>().Where(predicate).FacetOn(x => x[“ProperyName”], 1).GetFacets();

The second parameter to FacetOn() method is optional, it’s a min count and if we provide the min count, it means it’s going to return facets that is greater then equal >= to the value which has been set there.

Complete example:

using (IProviderSearchContext context = selectedIndex.CreateSearchContext())

var searchResults = context.GetQueryable<SearchResultItem>().Where(predicate).FacetOn(x => x[“ProperyName”], 1).GetResults();

// To check if we have any facet categories exists or not…
if (searchResults.Facets != null && searchResults.Facets.Categories.Any())


// Get all the facet categories…

// get facet category values and fetch facet name and aggregate count for each

// var facetName=facet.Name;

//  var facetCount= facet.AggregateCount;



If we want to facet based on multiple fields, we can just do it with adding chain of method calls and we should be all set to go.

context.GetQueryable<SearchResultItem>().Where(predicate).FacetOn(x => x[“Propery1Name”], 1).FacetOn(x => x[“Propery2Name”], 1).GetFacets();

Facets with tokenized fields:

Default field type in SOLR is tokenized which means it will split the string value in your index, and if the facet field value has space on it, it will be considered as two facets, as a workaround we should create a new computed untokenized index field and use that field instead.

Please see the below page for more details:

Sitecore Drop List Faceting Phrase Space Issue with Solr Search

Hope this helps.

Happy learning  and wish you all a very happy New Year 2018 🙂

Perform basic search with Sitecore

In this blog post I’ll be doing a introduction of the ContentSearch API found in Sitecore followed with a basic search example.
There are several articles which are available, but i will show a very simple working example of it.


ContentSearch API:

ContentSearch API acts like an abstraction over the low level details of search technologies like Lucene or Solr. Sitecore provides an API that can be used to work with Lucene or SOLR, there might be some changes between the two, but those will be just configuration changes.

Same code can be leveraged for Lucene or SOLR, this also helps and provides flexibility during Sitecore upgrade or switching the search providers, you will end up making configuration changes to match the version and you will be all set.

It depends on the business requirements what search provider best fits your needs, there is official documentation provided by Sitecore on Lucene Or SOLR-

Sample Search:

Here are the steps that are required to perform a simple search.

  1. Get the search index you want to use.
  2. Get the search context (which is also known as opening the connection) and
  3. Use the search context and perform queries.

Get the search index you want to use:

We need to get the index that we are going to use in the application, it can be out of the box indexes or custom indexes that we created, some of the indexes that can be referred are as follows:

  • sitecore_master_index
  • sitecore_web_index
  • sitecore_product_index (custom index)

We need to call GetIndex() method of ContentSearchManager class, which returns ISearchIndex instance.

ISearchIndex selectedIndex = ContentSearchManager.GetIndex(“sitecore_master_index”);

Once we have the index we can get other index details out of it, and can also perform operations like rebuilding of the index if required.

Get the search context:

This is more of opening a connection to search index, once we have the index available, next step is to create search context which allows us to perform search queries and operations against the selected index.
We create the search context using CreateSearchContext() method.

using (IProviderSearchContext context = selectedIndex.CreateSearchContext())


The search context is wrapped in using statement, so that it can be disposed when we are done performing the queries.

Perform queries:

Once we have the search context, it can be used to perform queries,
By using GetQueryable<T>() we can define our LINQ statements for filtering and getting the results.

using (IProviderSearchContext context = selectedIndex.CreateSearchContext())
var searchResults = context.GetQueryable<SearchResultItem>().Where(x => x.Content.Contains(“hello”));

By default the API will map to the SearchResultItem class for the result

This is a very basic example where we covered how get the index for search, create the context so that queries can be performed and finally using the context to perform the queries.

I hope this helps someone who is writing it’s first search code in Sitecore.

Happy learning 🙂

Please let me know your thoughts and feedback.

Return null or String.Empty for Computed fields in Sitecore

It is quite obvious that we have to create computed fields in Sitecore, to process some of the information well before it get indexed, and not processing it while requesting for the data.


There are chances when you don’t find any value to be added to you computed field, in those cases we can return either null or String.Empty().

Returning null basically tells that there is nothing to be indexed, and it won’t take any space in your index, but when we return string.Empty() , it actually creates an entry in index with no value.

Returning String.Empty() is helpful when you want to validate something based on empty string, but most of the case it is not worth.

Also, consider a case when you are dealing with several thousands Sitecore items, and if you are going to return String.Empty() for few thousands also, it will just get indexed that takes up space in you index.

We should carefully think about this, if there is a need to return String.Empty() we should do the same, but if not we should always try to return null.

Hope this helps someone.

Happy learning 🙂

Creating multiple crawlers for custom Index in sitecore

When we discuss/talk about indexes to be used in sitecore solution, various indexing strategies, no# of indexes, application performance  and etc, following are few things which we should review and discuss first:

  1. What is the search requirements, which depends more on business requirements.
  2. Do we really need indexes?
  3. Can we make use out of the box sitecore APIs to get the data from sitecore?, or extra index set up required.
  4. If index required, can we make use of out of the box sitecore indexes(lucene/SOLR or Coveo)?
  5. Do we need to set up custom indexes?
  6. If custom index(s) needed, what are the different content you want to add to your index?

These are some of the questions which we should think, before discussing anything more or making any call for indexes and it’s setup.

But, i would like to focus on the area where the business justifies the need of indexes and custom indexes to be more specific, and which is mainly this blog is focused on.

Question: Can we make use of sitecore out of the box indexes for any custom implementation?

I would say No to this, as we should always try to architect the solution as loosely coupled as possible, but again it also depends on the requirement sometime, we shouldn’t be thinking about making a new custom index when the custom need is not that complex, and didn’t affect the performance of the application as a whole.

Following are couple of things to consider:

  1. How update index strategy will work based on specific conditions and scenarios.
  2. Any configuration update to the index, which is needed for the custom implementation.

In certain scenarios where we want to make the implementation as clean as possible and want to make sure it didn’t affect the maintenance and updates, I think we can definitely go with custom indexes, and make changes to the settings based on the requirement.

Let’s looks the configuration of default SOLR index:


If you see the locations tag, there exists a crawler which will make sure to index the contents of the applications from specific database and specific location within sitecore, In this specific case it will index everything under sitecore, because that’s what the value we have under Root node.

Now, let’s think about a scenario where we want to index only two locations:

  1. All page items(which has presentation added to it) and
  2. All media items or any page item(s) which are structured outside of home node.
  3. To be more generic, we are trying to add two different locations in index, it can exists within home or outside home.

In order to support this scenario, we can add multiple crawlers for the same index, please see the below config for sample:


From the above screen shot you can see we have the same index, but with two crawlers which points to two different locations in sitecore.

Also,we  have to make sure that  both the crawlers in this case use the different name, which is more meaningful to the content type which will be indexed, we have used “PageCrawler“- which index all page items under home node and “MediaCrawler“- which index all media items under media library folder.

Following are the advantages of having multiple crawlers in the same index:

  1. Helps in boosting sitecore/application performance.
  2. Helps in applying business rules directly in the query, like pagination,sorting of pages,as now we get the different types of items from the same index.
  3. Easy maintainance.

Setting up only one crawler, or going with multiple crawlers is something point of discussion and  it mainly depends on the requirements of the application, as in general we should always keep in mind the application performance and maintenance in mind before wiring up any solution to the system.




I hope this post can help someone who has some questions on where and how to implement multiple crawlers in sitecore, and indexing question(s) in general.

Happy learning 🙂